Idea: use UEFI to boot and initialize hardware

[dns53]

To use some hardware such as graphics cards you most likely need to change the way you are booting your raspberry pi. From what I can see you are compiling and booting the kernel directly. What you most likely need to do is to load a uefi and have this initialize the pci connected hardware in to a known state. You then can boot a linux kernel and talk to a video card and the video card firmware is ready to talk back.

From what I can see from your video's you are booting directly to a linux kernel so the process is: uboot (chip) > uboot (sd card) > linux kernel

The proposed boot would be: uboot(chip) > uefi firmware > linux kernel (compiled as an uefi binary)

Take a look at the efi project for raspberry pi 4, the change log suggests there is some initial support for compute module. https://github.com/pftf/RPi4/tree/v1.26

Trying this out would involve using a sd card with a fat 32 partition and thair firmware images and a linux kernel compiled with efi support. You should be able to boot a generic server installer such as debian, suse, ubuntu built for aarch64 instead of an os build specifically for the raspberry pi.

[paulwratt]

the WOR windows 10 arm on RPi4 uses an UEFI bootloader, as does the VMware ESXi-Arm for RPi4. if someone is interested in persuing UEFI, it maybe worth checking out the following, a demonstration of flashing the AMD aarch64 UEFI bios to a Saphire RX270 (UEFI enabled) PCIe graphics card: https://www.youtube.com/watch?v=3cYJdw3Y9_Y According to that poster, the uboot UEFI part is a bit flimsey, but if it can get iron out for RPi4/CM4 then that would definitely help other ARM SBC's too (ie UEFI bootloader is possible on RPi3, even without physical PCIe interface)

[Arjdroid]

This is a good idea, in addition to UEFI, using aarch64 that will eliminate the other driver problems as well. UEFI and 64-Bit are the two things that I currently see to be missing from the tests Jeff has been doing and I think those two would help make the card work...

[paulwratt]

UEFI stems from x86, and all cards are sold with x86 BIOS, weather they are UEFI enable cards or not. The reason uboot is not "useful" is because (like most SBC linux kernels) it uses devicetree, mapping UEFI to the device tree is "fraught with challanges", as both are completely different approches to hardware bringup. Even though you can reflash an aarch64 UEFI BIOS, it does not change the fact that it knows nothing about "device tree" (the .dtb files on an RPi sd-image).

A device tree is a "feature list" with "allocation and initialization details", while (any) BIOS is a binary blob for a specific architecture with entry points and registers. The U in UEFI is "unifying/unified", unlike previous (eg. VGA) BIOS which change from card to card.

If UEFI were truely useful, they would make a UEFI BIOS that was a device tree, not a binary blob, ie. what about ARM32 and RISC5 devices. Why should you have to have emulation layers and CPU architecture specific code in any card? This is another reason why Apple moved to x86 & x86_64, because then they dont have to deal with issues.

[rtreffer]

Hrhr, mentioned CM4 support is partly from me :-P At least 1 or 2 patches.... You can build that EDK2 with x86/x86_64 emulation support to load the x86 UEFI drivers from the option ROM.

I got an Intel card to run PXE firmware blobs on the CM4. I also booted from a hardware raid. I had to configure the disks on a x86 board but I could boot the array from a CM4.

I wasn't that interested in pure UEFI boot. UEFI + dtb from EDK2 works great if you only care about linux :upside_down_face:

I also tried to boot graphics cards but failed miserably. The BAR space is just too low. But I think that if anything then this UEFI setup could work. It seems like newer BCM chips fixed the 3GB limit for PCIe address space so 4GB of BAR space could work and that might unlock some cards..... Not sure if those are available in CM4 form factor yet.....

[geerlingguy]

@rtreffer - All CM4 varieties since launch have shipped with the C0 stepping of the BCM2711, so they've all supported the expanded BAR space. Note that in software, it was still limited until early this year. Now the 64-bit Pi OS kernel (at least... haven't tested with 32-bit kernel) supports 4 GB BAR space by default (I believe... I don't think it was raised further) but can be expanded more to 8 GB.

[mi-hol]

hardware raid ... had to configure the disks on a x86 board

@rtreffer did the RAID controller you tried have a UEFI BIOS? I'm currently investigating the benefits of "ARM System Ready" certification that includes UEFI for booting. I found so far only one SATA HW RAID controller that mentions a UEFI BIOS, but have not had access to test it yet. I've started a conversation on this topic on openmediavault forum here

[rtreffer]

@mi-hol ok, from the top of my head.....

• You can flash an UEFI option rom to the raid controller (see e.g. this post - you will most likely need a x86 machine for this) - old LSI SAS cards are the gold standard for home re-use.
• This will provide the UEFI with a driver to use the RAID as a boot device - on x86!
• You will need an UEFI compiled with DEFINE X64EMU_ENABLE = TRUE (add it to the rpi dsc file)
• This will add a Qemu to your UEFI. Loading these drivers will be slow, borderline slow, but it will work
• You will need a x86 machine with the controller and all disks to initialize the RAID. I didn't get the classic POST to run
• Plug the flashed + configured RAID controller + disks into an CM4 carrier, boot with UEFI and choose the RAID boot device.

I would call this an academic exercise as using a x86 for flashing and raid setup is cheating at best. The only advantage I can see is support for backup batteries. Everything else should be betterin IT mode with a modern filesystem (read: btrfs, zfs).

[mi-hol]

using a x86 for flashing and raid setup is cheating at best.

I fully support this view, hence the question is: will using UEFI on aarch64 avoid the need for x86 to configure RAID setup?

[rtreffer]

@mi-hol no, because that tool runs as part of the POST, not as a UEFI driver (unless I am mixing something up). AFAIK some Dell machines have full UEFI support, but that's very custom. I couldn't get the common raid tools to run on aarch64 either (no megacli).

[mi-hol]

@rtreffer re "with a modern filesystem (read: btrfs, zfs)" Would I understand this statement correctly as: With a modern filesystem (read: btrfs, zfs) instead of using vendor specific HW RAID, more benefits are achievable?

In case yes, are you aware of any benchmarks comparing IO performance of HW RAID versus any of the mentioned modern file systems on an SBC like Broadcom BCM2711, Pine64 RockPro64 or Rockchip RK3399?

[mi-hol]

will using UEFI on aarch64 avoid the need for x86 to configure RAID setup?

Still searching for answers and got links to these blog post: Revolutionizing ARM Technology: x86_64 Option ROM on AArch64 AArch64 option ROMs for AMD GPUs

Preliminary conclusion from reading is: it should be feasible. Next step is to get my hands on hardware with a UEFI-BIOS to test it. My Broadcom / LSI SAS2008 card doesn't seem to have that :(

[mi-hol]

finally I had some progress with compiling RPi4 UEFI-BIOS (see https://github.com/pftf/RPi4/issues/209 for the detailed instructions). Next goal is to enable x86 emulation in this RPi4 UEFI-BIOS

[mi-hol]

• You will need an UEFI compiled with DEFINE X64EMU_ENABLE = TRUE

build with X64EMU_ENABLE was successful. Next step boot a CM4 with it.

gCommandLineDefines: {'X64EMU_ENABLE': 'TRUE', 'NETWORK_ISCSI_ENABLE': 'TRUE', 'SMC_PCI_SUPPORT': '1', 'ARCH': 'AARCH64'} BuildOptionPcd: [('gEfiMdeModulePkgTokenSpaceGuid', 'PcdFirmwareVersionString', '', 'L"RPi4 UEFI 1.33 Test Firmware (mi-hol)"', ('build command options', 1))]