7

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?

Jessica 6
  • 193
  • 2
  • 7
  • I won't bother giving a complete answer in the hopes that someone who knows the technical details better will, but that answer is essentially correct -- it has to do with the proprietary hard/firm/software that boots the device (it is not an open platform). This is necessary on all models of pi regardless of OS, and you cannot use the general purpose bootloaders associated with linux (e.g. GRUB). – goldilocks Mar 14 '16 at 13:20
  • But why doesn't this hold true for hard drive installations? If I check my Linux Mint hard drive, I see no FAT32 partition on it. Or is it just not visible with fdisk? – Jessica 6 Mar 14 '16 at 13:24
  • I'll clarify what I meant by "the device" in *"it has to do with the **proprietary** hard/firm/software that boots the device (it is not an open platform)"* -- the device is the raspberry pi, and it is not a hard drive, or a laptop, or a smartphone, etc (although it is much closer to the last one than the first two). A normal computer has configurable firm/software (BIOS, UEFI) that checks what is connected and what device it is supposed to load boot code from. The pi does this too, except it is not configurable and there is only one option: the first, fat32 based partition on the SD card. – goldilocks Mar 14 '16 at 13:31
  • ...And on there it expects to find some proprietary (?) bootcode. I believe this can and has been reverse engineered (it may not even be truly proprietary), but the main issue is there's only one option as to how it is loaded (and what it is used for subsequently -- I believe it bootstraps *the GPU*, loads firmware into it, then that loads an OS kernel into RAM and the CPU proper). – goldilocks Mar 14 '16 at 13:34
  • I'm beginning to understand, but I've seen this sort of thing when making a bootable thumbdrive for a standard PC: The first partition is FAT32. I just thought this was the reason for it being the same for the raspberry pi. So, my question is about bootable thumbdrives as well. – Jessica 6 Mar 14 '16 at 13:55
  • Standart PC has NOR flash with very fat bootloader. RPI's bootloader is MUCH simpler. – edo1 Mar 14 '16 at 20:21

5 Answers5

8

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...

GSH
  • 431
  • 3
  • 2
  • By FAT you mean FAT32, and I'm not sure exFAT is that common: "Microsoft has not officially released the complete exFAT file system specification and a restrictive license from Microsoft is required in order to make and distribute exFAT implementations" [(wiki)](https://en.wikipedia.org/wiki/ExFAT#Restrictive_licensing_and_software_patents). – jiggunjer Jan 19 '17 at 11:32
  • Actually that has a bearing on why the RPis can only support Flash/USB devices up to 32GByte - as the larger devices of 64GB or more seems to mandate the proprietary [exFAT](https://en.wikipedia.org/wiki/ExFAT) file-system which, as @jiggunjer points out, is not going be usable in a F.O.S.S. operating system like Raspbian... – SlySven Oct 24 '17 at 00:31
3

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.

pd_au
  • 51
  • 3
  • 3
    IMHO FAT is selected because it is very easy to implement. It is MUCH simpler than ext2 or xfs. – edo1 Mar 14 '16 at 20:17
  • I think technically the Pi's version of a BIOS would be whatever code is run before reading the first partition... – jiggunjer Sep 13 '16 at 02:58
0

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.

Jacobm001
  • 11,797
  • 7
  • 45
  • 56
PaulF8080
  • 307
  • 1
  • 7
0

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.

HankB
  • 149
  • 5
0

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).

jiggunjer
  • 101
  • 3