Raspberry pi 3 - why the FAT partition?

Question

I am just getting started with a Raspberry pi 3, with wifi. I'm building with one of the Ubuntu images I downloaded. After I wrote the image to the SD card, I saw the first partition was FAT32. Why is this necessary? I've seen this same thing for bootable USB thumb drives as well, but never could find a good reason as to why. I posted to StackOverflow.com, and was told I should post here instead. But I was given a somewhat uninformative answer:

"Because the bootloader only knows how to read files from a FAT filesystem"

My question is, "Why?". I mean, a regular hard drive installation of Linux doesn't need to play this game, does it?

Answer 1

When the BCM2837 first boots it needs to read it's code from a permanent storage, most processors do this by talking to NAND flash (i.e. the BIOS) because it's very easy to do. But we don't, instead we implement the filesystem reading code in the bootrom to read a file called bootcode.bin and then execute that.

Because of this we need to format the SD card in a way that is easy to implement. If you've ever wondered how difficult it could be to implement ext4 go have a look at the spec... In comparison I've written the FAT code in about 250 bytes.

The other problem is that SD cards have traditionally been formatted with FAT when you buy them and therefore there's no real point in implementing anything else. The only other option is exFAT due to this supporting file sizes > 4GB.

If you format it with ext4 then you can't read it on a PC (without third party tools), if you format NTFS you can't write it on a linux box (actually there are tools but they're not very reliable), HFS is again closed and not shared!

FAT and exFAT are the only filesystems that are common across operating systems...

Answer 2

I suspect this topic is similar to the reasons the Pi has no real time clock (RTC) or why it cannot be booted via wake on LAN. To put it simply, to save costs, the Pi doesn't have a normal PC BIOS. A BIOS must be stored in flash ROM. Adding flash ROM to the Pi would cost money. Simply storing the Pi's equivalent of BIOS files in a separate partition on the SD card saves money and allows for easier and less risky updating.

As for why that partition is formatted in FAT32, I'd suggest that's a very simple and pragmatic compatibility choice. Most people run Windows (ooh I can hear all you FOSS zealots cringing ... I'm sorry, but it's fact). To verify the boot files have been successfully written (in Windows, Linux or OSX), there's only one choice: FAT32.

Sure you can install a program like Linux Reader by DiskInternals to read an ext4 partition on Windows, but that's just a lot of messing around the average kiddie or parent (whom the Pi is primarily aimed at) just shouldn't have to tolerate.

Answer 3

There are several ways to interpret this question:

• Why does a single operating system require two partitions; more specifically: two volumes?
• Why does that extra partition require a FAT32 filesystem, as opposed to e.g. NTFS or Ext4?
• (implicit question?): What files are on this FAT32 filesystem.

1. The answer to the first is:
It doesn't technically require two partitions, just that the partition with the boot files is FAT32.
Since FAT32 isn't great for running an entire OS the developers are forced to use two filesystems, hence two partitions. I believe Ext4 is common for linux OS partitions.

2. Why FAT32 for the boot files? We speculate the following reasons:

• Easy/compact to implement the filesystem driver in a bootloader. Most other filesystems are complexer. Writing a bootloader isn't easy, especially if you need to minimize as much on-chip NAND as possible.

• Other filesystems may include (higher) licensing costs or are not properly documented.

• The FAT32 filesystem is supported by common operating systems such as Windows, MacOS and Linux. So no need to install special drivers to access the files on the SD card/image.

3. The boot files are like a lobotomized version of GRUB, and I believe they're closed source. It should contain all the files needed to load your kernel of choice, including basic drivers (which may differ from--or be added to--the kernel drivers that are loaded later).

---

Regarding your analogies:

I've seen this same thing for bootable USB thumb drives as well [...] a regular hard drive installation of Linux doesn't need to play this game, does it?

Actually, they did. And do, in some cases. E.g. installing Windows 7 on a BIOS machine will create 2 partitions, a 100MB NTFS partition that contains boot files. It is common for linux machines to have a separate /boot partition that contains the bootloader (e.g. GRUB) and kernel+driver files. The separation isn't strictly necessary because those bootloaders use the MBR, but using the MBR is 'hackier' than using a proper filesystem. This is why the newer UEFI booting firmware also prefers a separate FAT filesystem for boot files (which is probably what you saw on your thumb drive).

Answer 4

The /boot is in that partition so you put the disk in a card reader on your PC and fix boot problems including editing /boot/config.txt.

Answer 5

The "boot loader" (and in many cases that is only the the 'first stage' boot loader) is responsible for loading the code that brings the rest of the OS in.

On a typical PC the BIOS does this using code that does not even reside in a disk partition. In the case of Linux that would be GRUB (previously LILO.) That's the code that goes to the Linux /boot partition and loads that and that in turn loads the rest of the OS.

On the Pi, the equivalent of the BIOS goes to the SD card and looks for a FAT partition to load from. For all I know, that partition may be required to exist at some fixed offset on the device. It loads that code and that is what reads the OS from the EXT4 card.

I am less familiar with UEFI loaders and cannot comment on them. I also might not be correct about two boot loader stages. There may be more. If you're interested, google PC boot loader and you will find more info.