

ARM and firmware specifications - AndrewDucker
http://mjg59.dreamwidth.org/26535.html

======
marshray
So we should expect generic/customizable UEFI and ACPI implementations to
become available and at least as easy to configure as Linux itself for bare-
metal board builders.

The main question left is how much overhead will this impose on embedded
systems?

~~~
mjg59
Tiano's already fairly modular - it's not too difficult to replace chunks of
the hardware-specific code. ACPI is more of a problem. Long-term I'd expect
SoC vendors to provide reference tables which end up being hacked by board and
system vendors, which is actually pretty much what happens already in the x86
world (your BIOS vendor ships a reference table that includes code from people
like Intel, and then you modify it to match your specific board)

------
bitwize
This doesn't make any sense. AFAICT, the only widespread ARM OS to require
UEFI -- Windows RT -- is also Microsoft's biggest lead balloon since Bob. And
UEFI doesn't really _fix_ the problem that ARM has for distros: there's no
well-understood, standard way to go from power on to starting a kernel. It
doesn't fix it because the same is true for UEFI. Each implementation is
slightly different, and can do different things.

~~~
mjg59
All UEFI implementations have a minimal level of functionality, and a well
defined way of passing control off to the OS. You're guaranteed that it can
read a FAT filesystem, and you're guaranteed that if you put the path to a
UEFI executable in the default boot variable that that executable will be run
on boot.

~~~
wmf
Boot variables are kind of a PITA, especially if you're not used to them
because they didn't exist in the BIOS world.

~~~
mjg59
You've got two choices as far as bootloader design goes. You can put the
bootloader in a well-known location (such as in the first 512 bytes of a
drive), or you can tell the firmware where to look. UEFI actually supports
both, but the problem with using a well-defined location is that you
inevitably have conflicts between different OSes wanting to use the same
location. Boot variables are well-defined and work just fine, except in the
small number of cases of vendors who have implemented something that's not
actually UEFI.

------
mtgx
Great, another thing Microsoft is ruining for us "thanks" to UEFI. Are they
pretty committed to this instead of device tree, though? I mean Windows RT is
pretty dead in the water. Is ARM really going to dump everything else just for
the almost dead Windows RT OS?

I wish people protested the move to UEFI and the forcing of OEM's and chip
makers to use it. I think in the future we'll look back and more people will
agree with this.

~~~
bitwize
I ranted about this: [http://www.parodycheck.net/rants/on-
uefi.html](http://www.parodycheck.net/rants/on-uefi.html)

~~~
drv
Big fat disclaimer: I work for Intel, but these thoughts are my own, and I
have played no part in defining the UEFI specification.

I'll be the first to admit that the UEFI specification is not perfect - and I
use it in my day-to-day work, so I feel like I have some room to complain
about it. :) Some parts are under-specified, but the boot procedure is
documented fairly clearly, at least by my reading.

In particular, for OS installers, see section 3.4.1.1, "Removable Media Boot
Behavior"; the default is to load \efi\boot\bootARCH.efi, where ARCH is ia32,
x64, or arm. Notice that there is no mention of \EFI\Microsoft\Boot anywhere
in the specification; that path is used internally by the Windows bootloader,
but it also has a bootloader in the standard place on the install media.

Each OS installer is expected to create an NVRAM variable pointing to the
device path and filename of the bootloader for that OS; there's no hardcoded
Windows-specific path or anything like that. Windows plays by the rules and
creates a boot entry pointing to its bootloader; installers for other OSes can
do the same. The firmware should provide a way to select from these boot
entries on systems with multiple OSes installed.

Now, whether the firmware actually implements the spec correctly is another
question, of course... In reality, many implementations are indeed only tested
against Windows, but that's no different than the state of affairs with the
traditional PC BIOS.

If the firmware has hard-coded checks for "Windows" or other special
bootloader paths or names, it's a bug in the firmware, not a problem with UEFI
itself.

(Another small factual inaccuracy: traditional PC BIOS systems start up in
16-bit real mode, not "8-bit mode", but either way, it's not a pleasant
programming environment; EFI's flat-mapped 32- or 64-bit mode with C-based
APIs is heaven in comparison.)

~~~
bitwize
Thanks for the clarification.

