Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Installing UEFI Firmware on ARM SBCs

interfacinglinux.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Installing UEFI Firmware on ARM SBCs

#41

Post by p_l »

heavyset_go wrote: post #17
userbinator wrote: post #13

Earlier quoted context omitted.

ARM SoCs have always been very proprietary and fragmented, and until/if something like the x86/PC comes along I don't think just UEFI is enough. The PC flourished because of many de-facto standards, and not just the BIOS. Unfortunately the companies these days seem to love their proprietariness, so I don't think something like that will happen again.

It's this. UEFI doesn't solve the problem of peripheral discovery, for example. SBSA standard in the server realm seems to have it figured out.

Arguably, "full" UEFI implementation mandates use of ACPI, which solves discovery of components that don't have self-discovery mechanism to use (including finding the very roots of various self-discovering buses)

Re: Installing UEFI Firmware on ARM SBCs

#42

Post by p_l »

hbogert wrote: post #30

i understand why OP did it. But wouldn't it be nice if we took it all the way and just let the OS figure this out? [1] This is a radical departure from the abstraction-on-abstraction that is implicated by BIOS/UEFI but it feels like it would make the whole architecture not feel like a fossil once it's out of the vendor's hands. This would mean that every OS would need to make an implementation and feels like wasted e…

UEFI and ACPI is actually blowback from living in exactly that kind of world.

ACPI even included "compatible interface discovery" to handle the possibility that newer features might confuse older OSes without requiring end user to install newer OS (which they might not want to for various reasons) which used to be the norm. I owned a ~1994 UNIX workstation whose manual came with explicit instructions "you need to use at least this specific emergency upgrade version or the OS won't boot". PPC macs despite OpenFirmware had the same issue, because OpenFirmware had no such "interface discovery" mechanism allowing varying interface according to OS being run - it could only specify compatible device identifiers, which was not enough.

Also, you often need (a bit less today, but still important in server systems) considerable amount of vendor-specific drivers in firmware just to get to the OS.

Of course you can also go the completely other way, and implement always-virtualized environment like some IBM POWER systems, where the CPU wakes up with all of hardware already initialized and instruction pointer pointing to hypervisor scheduler loop.

Re: Installing UEFI Firmware on ARM SBCs

#43

Post by p_l »

shrubble wrote: post #32
stephen_g wrote: post #28

Earlier quoted context omitted.

Why would we base modern computer firmware around a 1994 standard, on which work had mostly stopped by 1998?

I could see myself supporting OpenFirmware which is a fraction of the size and complexity of UEFI and has a very limited attack surface. You could literally boot up a SPARC machine across the Internet with OFW in the mid 1990s, if you’re worried about functionality. And for configuring your system it’s simple and straightforward. The OLPC laptops used it, so it’s already somewhat proven on ARM.

And a major issue with OpenFirmware was that like other comparable interfaces from its time it required you to release a new OS version to support a new machine if it used different devices.

Something as simple as handling evolution in available steps in backlight control can require updated OS build on OpenFirmware.

ACPI was built for a world where a newly released computer had to still boot properly a system that predated it, which is major source of complexity in its bytecode.

Re: Installing UEFI Firmware on ARM SBCs

#44

Post by p_l »

pjmlp wrote: post #29
userbinator wrote: post #13

Earlier quoted context omitted.

ARM SoCs have always been very proprietary and fragmented, and until/if something like the x86/PC comes along I don't think just UEFI is enough. The PC flourished because of many de-facto standards, and not just the BIOS. Unfortunately the companies these days seem to love their proprietariness, so I don't think something like that will happen again.

PC flourished, because IBM lost control, what is happening with ARM is basically what every other 8 and 16 bit home computers used to be.

And part of the lost control was emulating IBM PC enough that software that ignored sanity and did weird things to hardware or assumed certain behaviours worked even on clones and most importantly, upgrades

Re: Installing UEFI Firmware on ARM SBCs

#45

Post by the_biot »

dingi wrote: post #26

There are two fundamental issues in the ARM ecosystem for general-purpose computing: the lack of a standard boot environment and the lack of a reliable device auto-discovery mechanism. Device trees still require a lot of manual intervention. I haven't yet come across an ARM board that can boot a vanilla Debian AArch64 image without extra work. This makes me skeptical about the prospects of ARM in the desktop and lapt…

Hear, hear.

I find it amazing that ARM hasn't come up with an auto-discovery mechanism for their platforms. They're the only ones in a position to do it, and they've done exactly nothing about it. The device tree junk we have to live with is here to stay.

The U-Boot situation is really no better. Nearly every vendor ships with U-Boot, and it's always, always a fork that never gets updated. ARM should have taken that situation in hand decades ago, too.

Re: Installing UEFI Firmware on ARM SBCs

#46

Post by shrubble »

p_l wrote: post #43
shrubble wrote: post #32

Earlier quoted context omitted.

I could see myself supporting OpenFirmware which is a fraction of the size and complexity of UEFI and has a very limited attack surface. You could literally boot up a SPARC machine across the Internet with OFW in the mid 1990s, if you’re worried about functionality. And for configuring your system it’s simple and straightforward. The OLPC laptops used it, so it’s already somewhat proven on ARM.

And a major issue with OpenFirmware was that like other comparable interfaces from its time it required you to release a new OS version to support a new machine if it used different devices. Something as simple as handling evolution in available steps in backlight control can require updated OS build on OpenFirmware. ACPI was built for a world where a newly released computer had to still boot properly a system that p…

I’m not sure I’m following you; wouldn’t a driver solve that issue? You don’t have to release a new OS build for a new PCI card being released…

Re: Installing UEFI Firmware on ARM SBCs

#47

Post by the_biot »

stephen_g wrote: post #28
eschaton wrote: post #25

Ugh. Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275 Open Firmware.

Why would we base modern computer firmware around a 1994 standard, on which work had mostly stopped by 1998?

Since you ask: because it's the only firmware that has its own song, that's why.

https://www.youtube.com/watch?v=b8Wyvb9GotM

Re: Installing UEFI Firmware on ARM SBCs

#48

Post by phendrenad2 »

jeroenhd wrote: post #36
phendrenad2 wrote: post #34

Earlier quoted context omitted.

UEFI+ACPI+PCIE+XHCI pretty much covers everything you could want.

In theory yes, in practice ACPI isn't always a great solution (as can be seen by the many lines of kernel logs about broken DSDTs on my motherboard). Manufacturers kind of suck at actually describing the hardware on their motherboards and hacks and workarounds are very much required to provide a usable experience on many machines. Unless manufacturers stop lazily copy-pasting their DSDTs with minor changes, we should…

Actually, I take that back. ACPI is fine except for the DSDT system, which should be nuked from orbit. These lazy PC hardware manufacturers keep pushing "please bro just let us run arbitrary code on your machine bro". This goes back to VGA BIOS (ugh). There's no need for it, other than the fact that it makes hardware vendor's lives slightly easier. Definitely something to avoid when designing a new interface.

Re: Installing UEFI Firmware on ARM SBCs

#49

Post by aseipp »

p_l wrote: post #37
iod wrote: post #14

U-Boot does basic enough UEFI emulation for most use cases. I find that I don't need native UEFI firmware and I can just build U-Boot with UEFI support for most ARM devices. For example, right now I have an old armhf i.MX6 Wandboard Quad that runs: U-Boot -> UEFI (with Secure Boot if desired) -> Systemd Boot (or Linux EFI Boot Stub) -> Debian (or other distro) That same layout should be doable on any U-Boot¹ supporte…

Does it provide ACPI and the RuntimeServices fully enough to operate as SBSA system?

U-Boot is implementing ACPI, yes, there was something at FOSDEM this year about it for ARM64 machines. QEMU can apparently now boot an arm64 virt machine with only ACPI tables and no device tree. This is all very recent. When I was working on a vague equivalent of systemd-stub last year as a fun exercise in UEFI development, I settled on U-Boot for UEFI and QEMU (but with virtualized device tree). I can't remember the specifics of what's unsupported by RuntimeServices when I was working on it. I'm like 99% certain it's not enough for SBSA compliance, at least.

Honestly, my opinion after all this was that UEFI is pretty convenient and nice, and I'm glad U-Boot has its own implementation, even if it isn't fully grown yet; UEFI for the executable spec with a DTB for bringing up the SOC with nothing else was nicer than a lot of embedded boot flows I've handled.

Re: Installing UEFI Firmware on ARM SBCs

#50

Post by p_l »

shrubble wrote: post #46
p_l wrote: post #43

Earlier quoted context omitted.

And a major issue with OpenFirmware was that like other comparable interfaces from its time it required you to release a new OS version to support a new machine if it used different devices. Something as simple as handling evolution in available steps in backlight control can require updated OS build on OpenFirmware. ACPI was built for a world where a newly released computer had to still boot properly a system that p…

I’m not sure I’m following you; wouldn’t a driver solve that issue? You don’t have to release a new OS build for a new PCI card being released…

Backlight is a trivial example.

In the past it meant you were unable to even boot the install media, these days it often means something might boot but ends up stuck because it can't initialize for example input devices so you can't load extra driver - which you first need. For every OS you want to boot.

EDIT: In fact, I have a funny example. On my laptop, out of laziness, vendor didn't include necessary ACPI data for sound to work properly.

Why?

Because for windows they could just ship a minimal INF file that declared a "driver" for the speakers which was actually just collection of parameters for a generic driver. As we say in Poland, "finished, time for Counter Strike".

On Linux working sound required patching drivers to include potentially dangerous settings as "quirks", including things like capacitance of capacitors connected to amplifiers.

Post reply on HN