3 ms·

ARM and firmware specifications

27 points by AndrewDucker 13y ago

marshray 13y ago
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?
- wmf 13y ago
  Or we should expect that UEFI/ACPI is such a high cost that there will be very few boards that support RHEL.
- mjg59 13y ago
  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)
mtgx 13y ago
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 13y ago
  I ranted about this: http://www.parodycheck.net/rants/on-uefi.html http://www.parodycheck.net/rants/on-uefi.html
  - mjg59 13y ago
    "the one thing UEFI doesn't specify is an exact, reliable procedure to boot an operating system" Nonsense. This is very, very well specified. Implementations may, of course, fail to implement the specification.
  - drv 13y ago
    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 13y ago
      Thanks for the clarification.
bitwize 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.

27 points by AndrewDucker 13y ago

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?

wmf 13y ago
Or we should expect that UEFI/ACPI is such a high cost that there will be very few boards that support RHEL.
mjg59 13y ago
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)

mtgx 13y ago

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 13y ago
I ranted about this: http://www.parodycheck.net/rants/on-uefi.html http://www.parodycheck.net/rants/on-uefi.html
- mjg59 13y ago
  "the one thing UEFI doesn't specify is an exact, reliable procedure to boot an operating system" Nonsense. This is very, very well specified. Implementations may, of course, fail to implement the specification.
- drv 13y ago
  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 13y ago
    Thanks for the clarification.

bitwize 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.