Hacker News Reader

Comment by DCKing | Hacker News Reader

IIRC this was a major problem with the Bay Trail generation (32 bit EFI, 64 bit CPU). These are Cherry Trail generation chips (one generation newer) which did get 64 bit EFIs. That's not to say this board has a 64 bit EFI, but the vendor could avoid problems if they're smart.

View on HN

I have 4 different BayTrails (manufacturers/etc) running in my apartment. There is zero issue with them in Linux but they have a funky requirement:

- they must be booted into legacy i.e. on EFI mode. EFI mode boot does not work reliably.

- the boot disk must have MBR and not GPT disk label.

I'm not surprised, EFI is a mess in general. Good old BIOS has worked for 30+ years, and is simple enough that it's not hard to get right (yet there are/were some that still did...) --- load the first sector of the boot device at 7C00 and jump to it.

And then spend then next 400,000,000 cycles progressively switching from 40 year old 8086 real mode to the present, reading some newer firmware configuration tables from that same BIOS (which are often buggy), compensating for those bugs, etc.

That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns.

Granted, the mess that [U]EFI is, it might still be the better option. But the old BIOS is only "good" because of the crazy (sunk and continuing) cost to effectively implement "good new bios" within the operating systems.

BIOSes have been executing mostly in "unreal"/flat-real mode since at least the 486 days, and I recall one of the later ones switching into that mode only a dozen instructions after FFFF:FFF0.

EFI is ridiculous complexity, more than that of early OSs, mostly just to do things which the OS would again do when it boots up.

I have found the [U]EFI mess to be really unbearable. It is too hard to debug. I mean, they learned nothing from the workstation or minicomputer era wrt. boot diagnostics.

> That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns.

So? The OS already does it.

The device I allude to in my other comment here is a Cherry Trail device. I did query the supplier as to why the EFI was not 64-bit and was told essentially that "The 2 GB version of the device comes with 32-bit UEFI because it doesn't support 64-bit OS". Another variant of the device with more RAM does come with a 64-bit UEFI, apparently.

I can _kind of_ see the logic -- when you have only 2 GB of RAM, you aren't really going to want to put a 64-bit OS on it.

Part of the issue there as well is, as I understand it, UEFI can only load EFI applications (of which the bootloader is) of the same bitness as the UEFI implementation -- 64-bit UEFI can _only_ load 64-bit bootloaders.

Reply on news.ycombinator.com