Raspberry PI boot FAT32 arrangement

Question

I recently thought about tinkering with Raspbian by adding an initramfs. But I have still some unresolved questions about the boot (FAT32) partition.

1. Does the partition have to be on a specific location? I mean, is the 4,2MB of nothing before it necessary?
2. Does the partition need to be of a fixed size?
3. Is the boot partition needed at all? I mean if the bootloader even cares if there is a FAT32 or it just picks a predefined location from the SD and loads it's (physically ordered) stuff from there (which would imply question 1 to be true)
4. Does the bootloader rely on file names inside the FAT32 or just about their location within? (Does the partition need to have specific structure?) In that case can you rename them and make sure they're at the beginning using fatsort?
5. Can the boot partition be on a GPT? (Condition question 3 evaluates true)

Please be specific with answers. I couldn't find more stuff about this anywhere.

Answer 1

Here are some answers to your questions:

1. Does the partition have to be on a specific location? I mean, is the 4,2MB of nothing before it necessary?

The boot partition must be the first one. It doesn't matter where it starts. The very fist sector of the boot device contains the master boot record (MBR). You can show it with

rpi ~$ sudo hd -v -n512 /dev/mmcblk0

This MBR contains a very tiny program as entry point to the operating system and the partition table at offset 440. Raspbian does not need the entry point but the partition table is needed. If you like you can clean up the MBR partially with

rpi ~$ sudo dd if=/dev/zero of=/dev/mmcblk0 bs=1 count=440 conv=notrunc

So the first partition can start at the earliest on sector 1 (when counting starts with 0). But this is very bad for access performance because it is organized in blocks (some sectors). You get best performance on block boundaries and partitioner respect this. For example with parted you will get an optimized first partition of 512MB with:

rpi ~$ sudo parted /dev/sda mkpart primary fat32 0% 513
rpi ~$ sudo parted /dev/sda unit s print free
Model: Mass Storage Device (scsi)
Disk /dev/sda: 7744512s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start     End       Size      Type     File system  Flags
        63s       2047s     1985s              Free Space
 1      2048s     1001471s  999424s   primary  fat32        lba
        1001472s  7744511s  6743040s           Free Space

The first block is only used for the MBR, and yes there is an unused gap to the next block boundary. It doesn't matter on which block the first partition starts. It can also start on later blocks. It's only waste space.

2. Does the partition need to be of a fixed size?

No, see answer to question 1 but should be restricted to block sizes.

3. Is the boot partition needed at all? I mean if the bootloader even cares if there is a FAT32 or it just picks a predefined location from the SD and loads it's (physically ordered) stuff from there (which would imply question 1 to be true)

Yes, the boot partition is needed in any case. It must be FAT formatted and it must be the first partition, no matter where it is laying on the storage but there cannot be another partition before it. This is restricted by the firmware bootloader.

4. Does the bootloader rely on file names inside the FAT32 or just about their location within? (Does the partition need to have specific structure?) In that case can you rename them and make sure they're at the beginning using fatsort?

Yes, the bootloader rely on file names inside the first partition. If the first partition isn't FAT then the boot up fails. The boot files (bootloader, kernel etc.) must exist in the root of the partition. It must also contain a directory /overlays/ that contains the overlay files. For example if you rename bootcode.bin or move kernel.img to the /overlay directory then the boot up will fail.

5. Can the boot partition be on a GPT? (Condition question 3 evaluates true)

I don't know what you mean with GPT.

To get some ideas about using an init ramdisk you may have a look at How can I use an init ramdisk (initramfs) on boot up Raspberry Pi?.

Answer 2

Looking at how NOOBS boots may also help you. NOOBS basically makes the assumption that you have a FAT32 filesystem, and you just unzip the files to it. The Pi then boots as usual, but has an extra "OS" that serves to choose and boot into the real OS. For that matter, I'm fairly sure that's what NOOBS uses for the first-stage OS -- an initramfs. (I may be wrong on that last point)

The important part of all that is that it works with any FAT32 FS in any location, so long as there are no preceding partitions, and it doesn't care about the physical file locations in that filesystem so long as the paths are correct (and names).

The boot process basically looks for the first partition, assumes it's FAT, and then looks up a specific filename (and THAT then looks for another file...) in there to load to boot from. A large number of these are hardcoded names, if not all, though some names are preferentially called depending on which hardware version you have (1/2,3,4).

For the Raspberry Pi bootloader process, there's thus no need for particular filesystem offsets, sizes, or DD'd UBoot images (which has made me very happy with the Pi 4, since I get the specs and RAM, but without the secret-blob-at-position stuff). It's literally just a FAT partition with a few files in it.