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

Booting ARM Linux the standard way

tuxphones.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Booting ARM Linux the standard way

#21

Post by edgyquant »

yjftsjthsd-h wrote: post #13
markstos wrote: post #7

Earlier quoted context omitted.

> There's going to be a lot of resistance to distros shipping a binary they didn't build from source. Tow-Boot appears to be MIT Licensed. There appears to be nothing stopping them from building Tow-Boot from source.

Sure, there's no technical blocker, but the article seems to be implying that they shouldn't: > One of the nice things about Tow-Boot is that it leverages the Nix build system to generate a nice reproducable build of the platform firmware. This should take away some of the doubts of having a prebuild platform firmware instead of every distribution figuring out how to do this from source. Also distributions not doing…

What’s the difference between a reproducible binary and one they’ve built themselves? Can’t they just build it from source and check that the digests match?

Re: Booting ARM Linux the standard way

#22

Post by edgyquant »

MartijnBraam wrote: post #9
markstos wrote: post #7

Earlier quoted context omitted.

> There's going to be a lot of resistance to distros shipping a binary they didn't build from source. Tow-Boot appears to be MIT Licensed. There appears to be nothing stopping them from building Tow-Boot from source.

But distros's don't have to. On most hardware it should be possible to flash Tow-Boot to some form of on-board boot storage and after that the board Just Works(tm)

After doing the thing that most people won’t know how to or want to do, it just works.

Re: Booting ARM Linux the standard way

#23

Post by josteink »

aseipp wrote: post #16

I'm happy to see something like this; in my own research, for my use cases, it seems like using U-Boot to create a UEFI compatible environment was a solid alternative to e.g. TianoCore for many cases. (Not that they don't work; I'm running a TianoCore build on my RPi4 successfully, too.[1]) One of the reasons I concluded this was actually highlighted in this article in an indirect way: U-Boot is very easy to build an…

> U-Boot is very easy to build and patch and hack on, and it's well known in these streets.

U-boot is very simple and very good at booting device-specific OS images.

What it fail at is providing abstractions and interfaces to provide to device-agnostic images so that they can boot without being tailored to a specific piece of hardware.

Which is why most Rpis are running Raspbian, not Debian.

For better or worse UEFI solves this and allows you to boot a plain Debian ARM64 ISO on any ARM64 machine with UEFI-compliant firmware.

Just like you (of course!) can on a regular PC. That’s where we need to get with ARM too. Make them work just like regular PCs.

Aarch64 has this solved in user-space. Now we need to get booting fixed too.

Re: Booting ARM Linux the standard way

#24

Post by LanternLight83 »

edgyquant wrote: post #21
yjftsjthsd-h wrote: post #13

Earlier quoted context omitted.

Sure, there's no technical blocker, but the article seems to be implying that they shouldn't: > One of the nice things about Tow-Boot is that it leverages the Nix build system to generate a nice reproducable build of the platform firmware. This should take away some of the doubts of having a prebuild platform firmware instead of every distribution figuring out how to do this from source. Also distributions not doing…

What’s the difference between a reproducible binary and one they’ve built themselves? Can’t they just build it from source and check that the digests match?

I mean heck, since it's a Nix Package, couldn't they just build it with Nix as the build system? And if for any reason that is the issue (installing Nix on a foreign distros can be pretty invasive, containerized?), the recipe for how to build it is right there.

Re: Booting ARM Linux the standard way

#25

Post by StillBored »

MartijnBraam wrote: post #5
yjftsjthsd-h wrote: post #2

Some disconnected thoughts: Title is misleading: Tow-Boot wants to become the standard way, but it isn't one today. There's going to be a lot of resistance to distros shipping a binary they didn't build from source. It might work if you could ship Tow-Boot on the hardware and make it optional for the OS to care, but unless I've missed something OS integration is needed (if nothing else, because it has to share storag…

Tow-Boot isn't the standard yet no, but it provides the standard EFI booting interface so it's at least somewhat true. Distro's is shipping binaries that aren't build from source all the time, it's called firmware. Which is why this should probably be managed by fwupd, not packaged by distributions.

"but it provides the standard EFI booting interface so it's at least somewhat true."

AFAIK, it just provides the uboot-uefi interfaces, which are only standard if you are okay with throwing out the vast majority of things marked mandatory in the UEFI specification. The efi bits are just a tiny shim over uboot that provides just enough of the UEFI protocol interface to boot grub/etc from some subset of the available devices.

Its a vast improvement over uboot by itself, but just barely scrapes the surface of fixing the arm boot problem. On many of the platforms there still isn't a uboot/pcie driver so booting from NVMe rarely works. None of uboot-uefi supported platforms provide the full set of UEFI drivers/protococls required by the spec, so its a crapshot if one deviates much from the expected emmc/sd boot path whether it works.

In a few years that might change because there continues to be a fair amount of ongoing work to make it more spec compliant but as of today, its a bit of a misnomer to call it uefi. Going forward some of this work is going to be quite difficult as the core architecture of uboot still isn't even segmented sufficiently to support UEFI runtime services, or ACPI platforms.

Re: Booting ARM Linux the standard way

#26

Post by StillBored »

MartijnBraam wrote: post #6
als0 wrote: post #4

Noble goal, but I want to point out that ARM recommends using UEFI as the standard way to boot. Then you can just boot whatever popular distro you want without weird tweaks. I’m not a fan of EFI but I think the downsides are less bad these days.

This implements EFI.

Sorta, UEFI is a lot more complete than the small part of the spec that uboot implements. Put another way, its not yet a spec compliant implementation.

Re: Booting ARM Linux the standard way

#27

Post by hpcoke »

It's great to see cross-distro activity in removing the burden from distributions of packaging different builds of u-boot.

I use Tow-Boot on my Pine64 RockPro64, with a plain NixOS aarch64 installation. Bliss!

Thanks Samuel and Martijn!

Re: Booting ARM Linux the standard way

#28

Post by garaetjjte »

josteink wrote: post #23
aseipp wrote: post #16

I'm happy to see something like this; in my own research, for my use cases, it seems like using U-Boot to create a UEFI compatible environment was a solid alternative to e.g. TianoCore for many cases. (Not that they don't work; I'm running a TianoCore build on my RPi4 successfully, too.[1]) One of the reasons I concluded this was actually highlighted in this article in an indirect way: U-Boot is very easy to build an…

> U-Boot is very easy to build and patch and hack on, and it's well known in these streets. U-boot is very simple and very good at booting device-specific OS images. What it fail at is providing abstractions and interfaces to provide to device-agnostic images so that they can boot without being tailored to a specific piece of hardware. Which is why most Rpis are running Raspbian, not Debian. For better or worse UEFI…

U-Boot can provide basic UEFI environment. Hardware description is another thing, either ACPI or DeviceTree can be used.

Re: Booting ARM Linux the standard way

#29

Post by aseipp »

josteink wrote: post #23
aseipp wrote: post #16

I'm happy to see something like this; in my own research, for my use cases, it seems like using U-Boot to create a UEFI compatible environment was a solid alternative to e.g. TianoCore for many cases. (Not that they don't work; I'm running a TianoCore build on my RPi4 successfully, too.[1]) One of the reasons I concluded this was actually highlighted in this article in an indirect way: U-Boot is very easy to build an…

> U-Boot is very easy to build and patch and hack on, and it's well known in these streets. U-boot is very simple and very good at booting device-specific OS images. What it fail at is providing abstractions and interfaces to provide to device-agnostic images so that they can boot without being tailored to a specific piece of hardware. Which is why most Rpis are running Raspbian, not Debian. For better or worse UEFI…

Attached device enumeration and boot firmware are somewhat orthogonal concerns; though certain ARM standards for various boot certifications ("ServerReady") do, in fact, require ACPI. But for mobile phones there's no need for it. You can just use a device-tree for the system and be done with it. (And yes, there are a lot of device tree files needed for all the devices, and while "self describing" would be nice it's ultimately a lot easier to just "have a lot of small files")
Post reply on HN