[johnklos]

The Rock 5 ITX+ is a nice board. I wish a 1U back panel were available for it.

UEFI does make things a lot easier. It's a shame that this isn't more common for Arm boards, but it's good to see things heading in the right direction.

[LargoLasskhyfv]

That backside is looking rather full. Nothing which a few blocks of styrofoam from packaging residue, maybe some cardboard or other plastics, and adhesive metal tape, and/or some super/hot-glue couldn't easily fill.

Or something 3D-printed...

Or did you mean the height of the ports on the backside itself is too large for 1U already?

[johnklos]

The ports would easily fit in a 1U case, as would everything else, including the fan and heat sink.

The metal back panel is standard. It'd be nice to have one that's made to fit 1U cases.

[ajb]

Serious question: what things does it make easier? Other than booting windows. I don't know anything about it except that it seems much more complicated than u-boot.

[general1465]

Then you can have ARM64 Linux which boots on anything what has UEFI, like today having x86/x64 Linux which boots on everything what has x86 processor inside under expectation that the mother board has BIOS/EFI/UEFI as well.

Just look on Android phones - i.e. Lineage OS, special Android build for every phone. That would not be necessary if booting process would the same.

[bpye]

Having UEFI in some form means you can just boot your preferred Linux installer and install to disk, much as you would for an x86 device, rather that needing to get a specific disk image and dd it to an SD card.

[heavyset_go]

UEFI is one step in many missing steps PCs take in the boot process that ARM SoCs in general don't.

[johnklos]

No idea about Windows. No interest, either.

UEFI makes it so you can boot your Unix OS, like NetBSD, without needing to have specific bootblocks that are tailored to the given machine. You can move drives between Arm machines, too. Much simpler.

[JdeBP]

OpenBSD, too. I haven't tried FreeBSD on EFI on arm64 yet, but FreeBSD has done EFI on amd64 since version 10.

[yusyusyus]

maybe one of the BSP people can give more info, but i believe that it comes with e.g. ACPI and such to avoid device trees.

[raggi]

what areas of u-boot do you find much simpler than edk2?

[ajb]

I have not developed using EDK2/UEFI - that's why I'm asking

[raggi]

They don’t have exactly the same coverage. UEFI provides a standard set of APIs, some optional, some mandatory. It also specifies a boot path via gpt and efi system partitions.

A common secondary piece is ACPI, which isn’t strictly mandatory, but when you provide both UEFI and ACPI then you can skip the whole dtb mess. Sadly ACPI isn’t the simplest of approaches, as it’s encoded in a way that requires executing bytecode in a stack machine. There are real and valid security concerns that come with this, but there are also big advantages- the abstraction generalizes over a lot of what would otherwise be specialization that has to be carried around in the bootloader and OS.

Uboot implements a subset of the uefi spec, but typically is used where there is no ACPI type configuration, with the gap filled by a combination of dtbs and vendor forks or patches (often before upstreaming, which sometimes never happens).

Depending on how deep your relationship is with all of this, you may live with uboot as a plain binary blob from a board vendor, in which case whatever version they formed and options they chose may bring various constraints or challenges doing anything novel like booting an alternative kernel or distro.

Typically a more complete uefi and ACPI system will be able to get much further in the boot process with far less hardware specialization, a lot of operating systems can boot very far with this combo even if they’ve never seen the specific hardware topology before.

Uboot upstream has a lot of implementations for a lot of hardware targets. There isn’t really so much of a central place for uefi implementations