With a better understanding of what's happening with the Beagle Board validation images I've started to redesign the boot process for BeagleBox.  First, the sd card will be partitioned with two partitions.  The first is the FAT32 partition to hold the kernel image, boot scripts and an initial ramdisk (initrd).  The ramdisk will be extremely light weight – its only purpose is to allow a fast boot and pivot to the root file system on the second partition.  We can even eliminate the initrd and boot directly to the second partition but that will require some experimentation to find which boots faster – with initrd or without.

With only the kernel image, a small initrd and u-boot script the first partition on the SD card can be very small.  Initial experiments show that 20MB should be plenty, leaving lots of space for the root file system.  Even bumping that to 25MB just to be safe still leaves lots of room on a 1GB SD card, which is the maximum size specified in the Design page on the wiki.  Note, however, that a FAT32 partition won't format on a small partition so you may have to use FAT16.  I just tried that and it works fine.

The boot script is read by the bootloader, re: u-boot, in order to get configuration and commands to run.  On the C4 board there is a u-boot installed in nand flash from the factory (or whoever builds them).  There is no need for the u-boot on the SD card unless we want to flash a new u-boot to NAND flash.  The boot script provides the proper boot arguments that u-boot will pass to the linux kernel.  The kernel is stored on the first partition of the SD card and loaded into memory by u-boot.  The proper way to deal with u-boot and x-loader updates is to create a separate SD card image that handles it automatically.  The user just has to swap cards, reboot, and swap cards again to get the stb running again.

The kernel will have only enough drivers compiled in to mount the root file system from the second partition on the SD card.  That means the driver for the SD card and the ext2 filesystem. The root file system is formatted as ext2.  Why ext2?  Because journaling file systems would cause the SD card (re: flash memory) to be written too often, causing it to become worn out faster than it should.  We don't need journaling anyway.  This isn't a desktop.  It's a consumer device – a set top box.  Also, reducing the number of drivers compiled into the kernel and moving the others to loadable modules in the root file system will mean the bootloader has a smaller file to copy from the SD card to memory at boot time – thus a faster boot.

The root file system will contain everything needed to run the STB from user space, including applications and libraries.  The build system already handles loadable modules installation to the root file system build thanks to the sgx library integration.  Now there will be more loadable modules.   The reason a small initrd is used to pivot to the root file system is so u-boot doesn't have to copy the root file system into memory.  Such a copy operation takes a long time at boot time and also uses up DDR memory when we don't have to do that.  However, running the root file system off the SD card instead of out of memory means we need to make writeable files and directories on the root filesystem redirected to files and directories stored in ramdisks.  Because of the limited write nature of flash memory we want to reduce the number of writes to the SD card as much as possible.  That will require some special handling when it comes to user space configuration options, but we can deal with that later and within the context of the BUI (beaglebox UI) project.  The process for creating ramdisks and symlinking files and directories to them is covered by the validation images.  See FS#40 for details on use of the volatile.cache which will be integrated into the root file system build.

I've already started implementing this process in the build system.  I have an initrd build working and the boot script is written and integrated into the u-boot build.  This will all be checked in a bit later after I've had some time make sure the updated build is producing a set of files (the pkg target does this) for installation on the SD card.  One thing I wasn't able to do was figure out how to use fakeroot to mount an ext image to copy in the files and create device files for the initrd.  So that particular part of the build requires running as root.  If we skip the initrd and simply use root=/dev/mmcblk0p2 in the kernel boot arguments this would go away, so there is an argument for dropping the initrd even if it boots faster.   I'll just have to experiment a bit to see what works best.  Unless someone tells me how to make fakeroot do this for me.