The Extensible Firmware Interface vs early Linux
Posted Aug 22, 2011 20:13 UTC (Mon) by giraffedata
In reply to: The Extensible Firmware Interface vs early Linux
Parent article: The Extensible Firmware Interface - an introduction
I would say, checking that the beginning of the MBR is not completely blank is still acceptable, to allow someone to boot without removing all USB stick plugged-in - but checking Windows MBR assembly crosses the limit.
I think you've misunderstood what the ROM bootloader does in this scheme. It is intentionally too dumb to choose a boot device. It always loads the next stage from the same physical place (a particular USB socket inside the box). The code loaded can use fancy intelligence that evolves with technology to choose a boot device from which to load the OS.
Note that in your scheme, you still want to simply write your Linux kernel to the USB disk (and not do "cat kernel > /dev/sdb") so you need a bootloader which will analyse the partitions and the filesystem inside it - so once the bootloader is running it still need access to the underlying device to access that file
I don't know what you're saying because there are at least 3 things that can be called "bootloader" here. One is in ROM, one is in the first block of the USB first-level boot device, and one is the complete Linux system that resides on the first-level boot device.
The ROM boot loader doesn't know anything about partition tables or filesystems. It knows how to read the first block of a USB storage volume, plugged into a socket/hub/controller permanently married to that ROM. The contents of the USB volume is much like we once put on floppy disks: not "cat kernel >/dev/sdb", but "cat bootstrap loader2 kernel >/dev/sdb". Maybe the volume actually has a partition table and the kernel thus loaded knows how to find filesystems on the volume.
to post comments)