Fedora 30 Aims To Make UEFI The Default Boot Means On ARMv7

[phoronix]

Phoronix: Fedora 30 Aims To Make UEFI The Default Boot Means On ARMv7

Fedora 29 aimed to provide UEFI support for ARMv7 given the maturing support to U-Boot and other components, but that didn't turn out as planned so is now being worked on for Fedora 30...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-30-UEFI-ARMv7

[benjamin545]

I know uefi has got a lot of hate before in the x86 world, I think because of crap ass implementations and windows only secure boot. But the uboot efi support is pretty cool. I have made use of it on a tegra k1 laptop and it is really nice how it can read a .dtb file and auto load a efi binary and pass the .dtb file on to the efi binary allong with the efi boot stub.

I used this to boot a standard debian grub bootloader built for arm and uefi. Grub would use the efi boot stub to provide hardware drivers for storage, display and input, and then use its own filesystem drivers to load a linux kernel, boot it and pass the .dtb file allong.

The kernel version from debian at the time didn't seem to support using the efi stub (or grub wasn't passing it correctly) on arm32, but on architectures where it is working correctly, the linux kernel can use the efi stub drivers for early boot display support and input if something goes wrong.

Looks like officialy arm is supose to be using uefi with acpi instead of device tree, and that is unfortunate. Acpi would imply that the kernel will make use of binary blob driver handling board specific hardware like temp sensors and fan controlers like it currently works on x86.

[oiaohm]

Looks like officialy arm is supose to be using uefi with acpi instead of device tree, and that is unfortunate. Acpi would imply that the kernel will make use of binary blob driver handling board specific hardware like temp sensors and fan controlers like it currently works on x86.

That not quite the case.

https://github.com/torvalds/linux/blob/master/Documentation/arm64/arm-acpi.txt

Its in fact both device tree and acpi. Linux kernel is being designed to use device tree if present and fall back to acpi if it not. There are still a few technical limitations in device tree.

Only if arm boot loader is UEFI is acpi allowed at all. UEFI boot on arm64 is allowed to provide device tree only and skip out on providing acpi as well.

Really i would love to see device tree grow ebpf support for hardware platform init stuff.

[uid313]

I know uefi has got a lot of hate before in the x86 world, I think because of crap ass implementations and windows only secure boot.

Linux can also use UEFI Secure Boot.
Microsoft have signed the UEFI shim.
So Ubuntu can be booted using UEFI Secure Boot.

[reey]

I have made use of it on a tegra k1 laptop and it is really nice

Do you have some instructions on how you did that? I'm trying to do the same on my nyan-big chromebook..

[NotMine999]

That not quite the case.

https://github.com/torvalds/linux/blob/master/Documentation/arm64/arm-acpi.txt

Its in fact both device tree and acpi. Linux kernel is being designed to use device tree if present and fall back to acpi if it not. There are still a few technical limitations in device tree.

Only if arm boot loader is UEFI is acpi allowed at all. UEFI boot on arm64 is allowed to provide device tree only and skip out on providing acpi as well.

Really i would love to see device tree grow ebpf support for hardware platform init stuff.

If I have read that arm-acpi.txt file correctly, ACPI AML bytecode is written/provided by someone (hardware manufacturers?) to support an OS on their boards.

I see that approach commonly used in ACPI AML bytecode, generally the DSDT table, to support features for various releases of Windoze.

I know that ACPI code can be decompiled and reviewed, for the most part; based on my own experience not all ACPI files found in "/sys/firmware/acpi/tables" provide useful information.

So does that approach satisfy RMS and the "free & open software" crowd?

[oiaohm]

Linux can also use UEFI Secure Boot.
Microsoft have signed the UEFI shim.
So Ubuntu can be booted using UEFI Secure Boot.

That answer is wrong in some cases. The KEK used to sign the UEFI shim is different to the KEK used to sign the windows boot loader. This is how apple allowed booting windows in secure boot mode but prevent everything Linux from booting.

Really distributions need to provide their own KEK key and PK generation tool just in case you hit a system configured this way and you can replace the keys. The hardware don't allow KEK set replacement and you don't have the right KEK you can be stuck if it is also impossible to disable secure boot(yes apple has already done this at one point).

[benjamin545]

That not quite the case.

https://github.com/torvalds/linux/blob/master/Documentation/arm64/arm-acpi.txt

Its in fact both device tree and acpi. Linux kernel is being designed to use device tree if present and fall back to acpi if it not. There are still a few technical limitations in device tree.

Only if arm boot loader is UEFI is acpi allowed at all. UEFI boot on arm64 is allowed to provide device tree only and skip out on providing acpi as well.

Really i would love to see device tree grow ebpf support for hardware platform init stuff.

yes, i did mean to clarify that, i think there is an article on here from last year talking about the decision for arm64 servers to use acpi like x86 does, while embedded will continue to use devicetree as they have been doing.

while the discussion is about arm64 servers, i assume that is only because of the rise of arm64 servers that is making it necessary to address the issue, if arm64 ever starts gaining traction on desktop or laptops, i assume that the same decision will be made for that as well. i would much rather devicetree than acpi, but i think hardware vendors much prefer the acpi route, as that allows them to write the hardware support in the firmware and not have to write it in drivers for different OS's and get it accepted.

[techzilla]

If I have read that arm-acpi.txt file correctly, ACPI AML bytecode is written/provided by someone (hardware manufacturers?) to support an OS on their boards.

I see that approach commonly used in ACPI AML bytecode, generally the DSDT table, to support features for various releases of Windoze.

I know that ACPI code can be decompiled and reviewed, for the most part; based on my own experience not all ACPI files found in "/sys/firmware/acpi/tables" provide useful information.

So does that approach satisfy RMS and the "free & open software" crowd?

It damn satisfys us users, "Windoze" gets it right on hardware support that doesn't screw all of us. We need a standardized boot platform or nobody can maintain a Linux system, the only people who get to are OEM's who stop updating almost immediately. It has HELPED build Apple and Google into monopolies, and hurt all of us users.

Do you need the studies? ARM commissioned their own studies that said with complete certainty, it was screwing everyone by not having it, I say screw whoever didn't plan this from the start.

[techzilla]

I know uefi has got a lot of hate before in the x86 world, I think because of crap ass implementations and windows only secure boot. But the uboot efi support is pretty cool. I have made use of it on a tegra k1 laptop and it is really nice how it can read a .dtb file and auto load a efi binary and pass the .dtb file on to the efi binary allong with the efi boot stub.

I used this to boot a standard debian grub bootloader built for arm and uefi. Grub would use the efi boot stub to provide hardware drivers for storage, display and input, and then use its own filesystem drivers to load a linux kernel, boot it and pass the .dtb file allong.

The kernel version from debian at the time didn't seem to support using the efi stub (or grub wasn't passing it correctly) on arm32, but on architectures where it is working correctly, the linux kernel can use the efi stub drivers for early boot display support and input if something goes wrong.

Looks like officialy arm is supose to be using uefi with acpi instead of device tree, and that is unfortunate. Acpi would imply that the kernel will make use of binary blob driver handling board specific hardware like temp sensors and fan controlers like it currently works on x86.

The UEFI hate was only valid for secure boot locks that users couldn't undo, and so far it's been handled in a way that addresses our concerns. It also wasn't at all UEFI's fault, the vender chooses how or if they do it.

However please listen to me about ACPI, we want ACPI, it's been working GREAT for years now. The community got through the buggy years, and its paying dividends big time. Without ACPI, getting to things like a power button requires chipset specific drivers. I'm not saying we should stop supporting the DT's, but we need to get the full windows style hardware support. We need the vendors to do lots of work for us, so we don't need overworked kernel devs to do practically everything by themselves.

IF the embedded community took leadership, they could have made UEFI with DT the standard, but they did no such thing for us. They instead threw pot shots at everyone, and the users got stuck with a bunch of electronic bricks after their last officially provided update. O want to install your own distro on your own device, the one you purchased with your own money? Looks like you need to be an embedded developer to install your own OS on a 4 core 4 Gib device, did I forget to mention your also in a fragmented community that will die when this device leaves the market?

So now we will have the same people who did ACPI do what they do for ARM devices, and everyone will be far happier because their hardware is supported in places where developers didn't even think about their specific device. Their power functions all work also, suspend, hibernate... the whole kit. Bringing up multiple CPU cores in a standardized way, the benefits of ACPI go on and on. The stone throwers will go down as self-interested propagandists, who harmed every Linux user for no reason, I have many powerful devices rotting in a box in my closet thanks to them.