The Extensible Firmware Interface vs early Linux

Posted Aug 19, 2011 9:53 UTC (Fri) by etienne (guest, #25256)
In reply to: The Extensible Firmware Interface vs early Linux by giraffedata
Parent article: The Extensible Firmware Interface - an introduction

> read bytes from USB storage device plugged into a particular socket inside the box and branch to them

Well, they have first to recognise that the USB disk first sector contains executable code, else they will often jump to a lot of zero instructions.
How some do it is a little bit boring; in my experience with Gujin few BIOS will check that the Windows MBR is present by checking bytes at offset 0x0c to be identical to the Windows MBR ones.
IHMO checking the first byte would be better (either jmp or cli) when the 0xAA55 signature is present.

But what I wanted to say is that at the bootloader level you do not have USB, you have OHCI, UHCI, EHCI or xHCI - and more in the embedded world.
The complexity for the boot sequence is that you may be on a BIOS/EFI which only handle a previous generation (only USB1 on USB2 hardware, only USB2 on USB3 PCIe card) so you know where (PCI address) is the device you are booting from, but in Linux this PCI address do not exists because the full USB chipset is supported.
Handling these corner cases (as I tried in Gujin) is not really easy.

The Extensible Firmware Interface vs early Linux

Posted Aug 19, 2011 16:10 UTC (Fri) by giraffedata (guest, #1954) [Link] (4 responses)

Well, they have first to recognise that the USB disk first sector contains executable code, else they will often jump to a lot of zero instructions.

I think I'd prefer that it not do that check. It's an opportunity for something to become incompatible.

at the bootloader level you do not have USB, you have OHCI, UHCI, EHCI or xHCI - and more in the embedded world.

But that is just between the bootstrap ROM and the USB host controller, both of which are permanently attached to the same piece of hardware in my scheme. So there's no chance of incompatibility.

The standardness of USB that I'm interested in is between the host controller/hub and the USB stick, such that you can 1) easily get media; and 2) easily write the media using pretty much any computer.

The Extensible Firmware Interface vs early Linux

Posted Aug 22, 2011 14:39 UTC (Mon) by etienne (guest, #25256) [Link] (3 responses)

> I think I'd prefer that it not do that check. It's an opportunity for something to become incompatible.

Well, they could have trusted that if the device contains a partition which is marked bootable, the device is itself bootable, but most BIOS manufacturer did not do so.
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.

Note that in your scheme, you still want to simply write you 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 (using BIOS/EFI disk services), the BIOS/EFI still need to respond to USB interrupts.

The Extensible Firmware Interface vs early Linux

Posted Aug 22, 2011 20:13 UTC (Mon) by giraffedata (guest, #1954) [Link] (2 responses)

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.

The Extensible Firmware Interface vs early Linux

Posted Aug 23, 2011 9:36 UTC (Tue) by etienne (guest, #25256) [Link] (1 responses)

> I think you've misunderstood what the ROM bootloader does in this scheme.
> It is intentionally too dumb to choose a boot device.

I wish it worked that way in the real world.
In real PC you buy today, the BIOS is doing a lot more than that, that is why people have so much problems booting off USB.
After a lot of debugging Gujin, I can tell you that (for instance) the EEEPc 900 BIOS will not report it has an extended BIOS disk service interface if it detect the 0x29 signature at offset 38. Also, the "HP Compaq 8000 Elite" PC will crash if it is booted with a USB device which do not contains 0x1F 0xFC 0xBE signature at 0xB (the windows MBR opcodes).
There is a reason why Grub has now the Windows MBR opcodes at its MBR beginning...
Also, I do not know of a single BIOS which will not test the 0xAA55 signature at the end of the MBR, and I have found BIOSes which will only boot if there is only a single partition on the device, and it is the 4th one - else the ROM code decides (without meaningful message displayed) that the device is not bootable, and the next device has to be tried.
(I think that was the test for ATAPI 100 Mbytes floppies).
The BIOS should be dumb, but in practice it does look at the MBR content, and because "there is no more floppies" the only test case is: does Windows boot.

The Extensible Firmware Interface vs early Linux

Posted Aug 23, 2011 18:05 UTC (Tue) by giraffedata (guest, #1954) [Link]

The BIOS should be dumb, but in practice it [isn't].

And in case it wasn't clear, this is exactly the point I opened the thread with, if BIOS means "the code fixed to the motherboard that boots the OS."

I would like to see that intelligence moved into a physically changeable, easily creatable storage device and suggest that a Linux system on a USB disk is the best choice for that.