Many EFI Updates Prepped For Linux 4.7 Kernel

[Kano]

@DrYak

Bootloaders like GRUB(2) always used the space before the first partition. It was relatively small with the partition scheme used up to Win XP (first partition at sector 63) but after the rise of 4k drives (with emulated 512 byte sectors) it was standard to begin at sector 2048. So the bootloader can take now up to 1 MB in the first stage (before 31 KB). For btrfs you need the new aliginment, otherwise it would be too small. EFI has got none of those restrictions, you can freely chose how huge your EFI partiton should be. But back to ARM: using EFI instead of other ways to boot makes the system more generic, you can use the same way to create live images and use the same installers as you might be already used too. I think this is very nice.

[DrYak]

I was originally considering all the *-Pi products like Orange/Banana/Odroid, also routers with NOR flash.

...and you're right: for *those* devices, (U)EFI doesn't make really sense.

Something like uBoot (or even simpler like Qi - BTW does that thing still exists? I haven't touched my Openmoko FreeRunner the past couple of years) would be better.
Or a build of Coreboot that strips anything which is not "load kernel from flash media" (so using some minimalist payload as FILO).

[caligula]

@caligula:
Short version until my longer post gets approved:
- EFI (and coreboot) handles a lot peculiarity (simply load a file from a partition) that aren't handled by simpler firmware and need to be handled by the boot loader.
- ARM64 will get used in things bigger than a raspberry pi. things like laptops and servers where a full featured firmware like EFI (or Coreboot) makes more sense.

Right, I guess it could have its uses in enterprise server systems, but many embedded devices can have two devices, one smaller than 2 TB for booting, and larger storage for.. something else. I was originally considering all the *-Pi products like Orange/Banana/Odroid, also routers with NOR flash.

[DrYak]

@caligula:
Short version until my longer post gets approved:
- EFI (and coreboot) handles a lot peculiarity (simply load a file from a partition) that aren't handled by simpler firmware and need to be handled by the boot loader.
- ARM64 will get used in things bigger than a raspberry pi. things like laptops and servers where a full featured firmware like EFI (or Coreboot) makes more sense.

[DrYak]

Why couldn't they support booting from large (um, > 2 TB?) drives without EFI?

EFI natively supports GPT partition scheme, and natively supports loading an executable file (in EFI format, usually a boot-loader like GRUB or ELILO, but could be a straight Linux kernel with efistub) from a special FAT partition (the EFI System Partition) and provides some minimal APIs (like filesystem access and graphical console to output graphics, error messages, boot menus, etc.)

It's got quite some features.

At the opposite range (though luckily only confined to x86 world, not on ARM) you have the BIOS which basically just able to load the first sector of a boot drive into RAM and run it. It doesn't provide anything beyond a few API to display text and/or load sectors from disk.

This MBR, in only 512 bytes (minus partition table) must be able to load anything necessary so the boot loader can start.
(Or load a partition's boot sector which will do this job).
This small piece of code receives no API beyond "read random sectors through BIOS INTerrupt calls" and must be able to fends its way all the way up to "Grub is up and running". (This includes find a way to load some driver code that in turn will be able to read actual partitions - e.g.: grub's "stage 1.5". Its usually done by using some reserved space at a fixed position after the boot sector - GPT introduced a special "BIOS BOOT" type of partition of that purpose).

Most ARM firmware fall somewhere inbetween these two extremes.

Luckily most ARM board tend to be very specific and allow very few customisation. Firmware usually need to do something like "stream ${N} MiB from flash memory connected to a very specific port of the SoC" (which contain either a more complete boot environment, or contains a directly executable Linux kernel + initrd).
So event while not as feature complete as a EFI firmware (or as Coreboot with a good high quality payload, for that matter) they are good enough for most cases.

On ARM? {...} I'm perfectly happy with old style partition tables and < 2 TB on ARM. The biggest eMMCs are like 512 GB and they're huge for anything embedded. You can still plug in 8 TB drives just fine.

When you read "ARM" you probably think about your Raspberry PI. And indeed a GiB-range microSD card is well enough for that use case.
The classical "stream a few MiB from MMC port 0" approach is good enough for you.

But, the thing is, there are other possible usage for ARM, specially since ARM64 took off: use case which were traditionally served by low power Intel chipset until now.

Things like low-power file servers. Or laptops.
i.e.: things that have a lot more connection possibilities than a raspberry pi (the file server is going to have a couple of SATA drives and should be able to load an OS from one of them. the laptop is going to need to be able to boot either from its SSD or a rescue system from an USB Boot Disk. Or maybe a bootable CD-R, if optical drives still exist then).

For these use case, an EFI firmware (or Coreboot) start to make sense.
Because it covers all the more advanced boot scenarios beyond "loading the kernel from the SD card" pretty well and provides a lot of flexibility thanks to all its advanced features and APIs (again, same could by said for Coreboot).
And in the specific case of server and laptop, it will also help with familiarity if the firmware is similar to what other servers and laptops come with. So using EFI on ARM64 like on Intel based hardware makes sense from a user experience (or Coreboot if that your favorite firmware in your server farm. But definitely not something simpler like uboot which will look alien to anyone else)

[Uramekus]

why would anyone want efi on their devices?

efistub <3

[caligula]

Secure boot. Better support for larger harddrives. Faster hardware initialisation. Fancy GUIs.

On ARM? Why couldn't they support booting from large (um, > 2 TB?) drives without EFI? I'm perfectly happy with old style partition tables and < 2 TB on ARM. The biggest eMMCs are like 512 GB and they're huge for anything embedded. You can still plug in 8 TB drives just fine.

[caligula]

Secure Boot is somehow boring until you see it as one of many steps to secure your system. Alone it is pretty much useless. But you can even boot without any additional bootloader and in best case it POSTs much faster - with one SSD you can partly enable fastboot and skip some more things. GUI is not always fancy... can be as basic as 20y old BIOS ;-)

What BIOS? Wasn't this article talking about ARM & EFI? My ARM boards boot in few seconds (kernel and busybox) from eMMC.

[uid313]

Interesting that much of this UEFI code relates to ARM, which interesting coming from a Intel guy since they do x86 not ARM.

I wish Intel would put more resources into open source UEFI implementations, such as their TianoCore.

[Kano]

Secure Boot is somehow boring until you see it as one of many steps to secure your system. Alone it is pretty much useless. But you can even boot without any additional bootloader and in best case it POSTs much faster - with one SSD you can partly enable fastboot and skip some more things. GUI is not always fancy... can be as basic as 20y old BIOS ;-)