1

I am building a very compact Linux kernel for my RPi 3.

I have stripped a lot of features from the kernel. The current kernel size is around 4 MB.

Currently I only have ext4 and vfat FS enabled. I tried formatting /boot as ext4 to get rid of vfat code in kernel, but the system wouldn't boot.

After some research, I learnt that the RPi bootloader requires a vfat /boot partition. VFAT itself requires NLS features. => Large size

Any way I can get away with an ext4 /boot partition? I am building an embedded setup so the eventual plan is to get the RPi boot from a single Squash file system that would contain / and /boot in the same partition. So the final kernel would only have to support SquashFS.

2

You can pull the FAT partition out of your Linux system without a problem but you would need to do some stuff with a loader for Linux.

Okay the basic here is the ARM CPU(s) are co-processor to the GPU and the GPU needs a FAT partition to load the ARM code up before releasing them.

The GPU has its own FAT reader and it reads four mandatory files which must reside on a FAT partition

  1. bootcode.bin
  2. fixup.dat
  3. start.elf
  4. kernel.img

The kernel.img is our user code and you can basically do whatever you want from there.

So the bottom line here is there has to be a FAT on the card but no you don't have to be able to read FAT in your code. If you look at any bare metal code on the Pi I assure you that almost none have a FAT partition reader. The thing that reads the FAT for them is the GPU.

So long as Linux is happy to leave the FAT partition alone and you have a loader that can pass into linux, then Linux itself requires no understanding of the FAT system.

I suspect you will have to put the driver tree files on your Linux partition and load them at the startup of linux because I suspect Linux will need them.

If I was going to do it I would compile code for the linux loader for the Linux file system. Place it on the fat partition and write a small piece of bare metal code that simply places the file at 0x8000 onwards in the Pi and then jump the cpu0 to 0x8000 and it should run straight into linux without ever knowing about FAT. Any reasonable bare metal coder would be able to write that code and know what it does.

1
  • I baked all the needed drivers within the kernel itself; not as modules. So no need for copying drivers. Then I simply removed vfat from kernel, and asked fstab not to mount /boot on startup. Working like a charm now. – Fulcrum Sep 1 '18 at 6:32
2

I looked into something similar to this briefly some time ago. My conclusion was that RPi hardware requires a vfat partition for booting, and this is an infrangible requirement, for all practical purposes anyway.

That said, you can use other bootloaders (e.g. U-Boot), which may or may not buy you something. The best source I've found on this subject is the RPi U-Boot page. I'd encourage to read through the documentation here; it's always possible that someone has "broken the code" since I last checked, and discovered a way around an infrangible rule :) Even if they haven't, some of the information here is useful; e.g. there is a (very) brief summary of the boot process.

You may also wish to consult some of the documentation The Organization publishes; e.g. Raspberry Pi Boot Modes describes all published boot modes, and contains some interesting options that you might find useful, and Boot Options for the config.txt file may also be useful. And finally, while I'm blethering here, I'll mention that there are options for network booting in addition to the USB and HDD options.

So, not the answer you were hoping for I fear, but hopefully this will give you something to ponder.

10
  • I think you would find that while a FAT partition is required for boot, this happens BEFORE the OS starts, and is done by the bootloader. The OS then mounts as /boot - but this can be removed. The whole exercise seems futile! – Milliways Jul 26 '18 at 19:10
  • @Milliways: Maybe... could you cite an example of that? That is, an example of an OS that's booted on RPi without a vfat partition? – Seamus Jul 26 '18 at 20:22
  • I said "a FAT partition is required for boot", the code required is in the bootloader files, but it does not need to be mounted for the OS to run. – Milliways Jul 26 '18 at 20:43
  • I'm not sure what you're saying exactly, but you needn't explain. – Seamus Jul 26 '18 at 20:52
  • 1
    @Fulcrum: That's a very interesting result! If I can make a suggestion, please post details of your approach as "the answer" to your question. I'm very keen on seeing how this works. – Seamus Jul 27 '18 at 17:45
0

I doubt it. I think the SoC boot loader needs FAT. You have no control over the SoC boot loader.

2
  • May be a stupid question: Does the Root FS really need access to /boot? Since data in /boot is required by bootloader, doesnt it mean that the kernel itself doesnt need to access /boot? I tried keeping /boot as vfat and removed support from kernel for vfat. The system booting went smoothly. But systemd threw an error saying that it (obviously) failed to mount the vfat /boot, and gave me a rescue shell. – Fulcrum Jul 26 '18 at 15:38
  • I think it just looks at the first SD partition. But I know almost nothing about the boot process. – joan Jul 26 '18 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.