Trying to install UEFI on a Pi 4 and install Gentoo

[jgaz]

I'm trying to install Gentoo on an 8GB model Raspberry Pi 4 with UEFI. There is a project that will allow Pi users to deploy working UEFI firmware to the Pi, here: https://github.com/pftf/RPi4. It seems to work for others, notably those attempting to install ESXi to the Raspberry Pi 4. I'm trying to get that working under Gentoo for three reasons:

1. It's a nice feature to have.
2. If I can the process can work reliably, I can document it in the Gentoo wiki.
3. The RPi3 / RPi4 UEFI firmware can be added as an ebuild improving Gentoo's Raspberry Pi 3/4 support.

I started by installing Raspberry Pi OS to an SD card and running an apt-get update and apt-get upgrade as a quick way to be 100% sure I had the latest version of rpi-eeprom. With that out of the way, I proceeded to partition my micro SD card. I created a 1GB partition for simplicity sake. This is where the Pi's native on-disk firmware is going to live as well as the third-party UEFI components. On various attempts, I've used either MBR (msdos) style partition tables or modern GPT partition tables. Theoretically, this should not matter as newer versions of the rpi-eeprom firmware support both. The 1GB partition was formatted as vfat, which as -F forced to FAT32. The esp and boot flags were set.

As I understand it, the RPi4 code UEFI only needs two things: the RPi4 code itself and a copy of sys-boot/raspberrypi-firmware in order to bring the system itself up prior to loading an OS kernel. The binary /efi/boot/bootaa64.efi, if present, will hand off execution to the OS kernel and continue the boot process. I haven't gotten that far. I'm just trying to prove out that the firmware is present and working before proceeding through the Gentoo install process which -- on a Pi -- will take many hours just to compile the kernel.

So, at this point, with the contents of the sys-boot/raspberrypi-firmware (pulled from upstream) dropped into the 1GB FAT32 partition and then RPi4 dropped into the same partition — in that order — I unmount the file system, pull the micro SD card, place it in the Pi, and cross my fingers. So far, no luck.

I get an error screen with a QR code and errors to the effect of "can't find the boot partition" or "start.elf [and friends] missing" etc. This really has me scratching my head because it's just a FAT32 partition and, as I understand it, all of the files required to bring the system up are present. Again, I have tried it with an MBR partition table and a GPT partition table —neither seem to work.

Has anyone else here deployed UEFI firmware to the Raspberry Pi 3/4 successfully? I am I stopping to check my work too early in the installation process? Have I missed a step? Is there something subtle I'm missing? I'm really confused at this point, because I thought I had a decent understanding of how the Pi boots and brings up the system. Any help would be greatly appreciated. If I can get this to work I will document it for others.

NB: I did see the note in RPi4's README about requiring kernel 5.12 or greater for some features. When I get that far, I'll go with kernel 5.15.32 even if I have to unmask it.

[fedeliallalinea]

Moved from Installing Gentoo to Gentoo on ARM.

[NeddySeagoon]

jgaz,

My understanding is that the Pi4 EFI firmware is loaded by the normal startup process in place of the kernel.
The GPU needs the Pi 4 version of the firmware ... that's all the start and fixup files with 4 in their names.

When it reads /boot/config.txt, it will need at least a kernel line that points to the EFI file to be loaded, unless its called kernel8.img, which is the default 64 bit kernel name.

The default kernel takes about an hour to build on a Pi4 with adequate cooling.

I've not done EFI on PI 4 yet. Its well down my TODO list as its an extra step in the boot process which does not appear to add anything.

The PI boot process is that the ARM CPU is held reset, while the GPU runs bootcode.bin and he required start/fixup files.
On the Pi4, bootcode.bin is replaced with the onboard SPI ROM.
Once everything to start the ARM CPU is in RAM, the CPU is released from reset.

[pingtoo]

NeddySeagoon,

This config use armstub=RPI_EFI.fd to start EFI bootloader.

jgaz,

I am interesting in this topic, I don't use EFI for myself, however I am playing u-boot on my RPI 1b, so I know a little bit of boot sequence.

I think to debug this, we need to first know what is content of SD card, We also want to see SD card partition table information. So if you can share,

Code: Select all

ls -l <sdcard mountpoint>

and

Code: Select all

fdisk -l /dev/<sdcard device>

For now, once we have these information we can better in sync to talk about what else is needed.

[jgaz]

NeddySeagoon,

This config use armstub=RPI_EFI.fd to start EFI bootloader.

jgaz,

I am interesting in this topic, I don't use EFI for myself, however I am playing u-boot on my RPI 1b, so I know a little bit of boot sequence.

I think to debug this, we need to first know what is content of SD card, We also want to see SD card partition table information. So if you can share,

Code: Select all

ls -l <sdcard mountpoint>

and

Code: Select all

fdisk -l /dev/<sdcard device>

For now, once we have these information we can better in sync to talk about what else is needed.

Sure, here are the contents of my SD card's ROOT directory.

Code: Select all

# ls -l /mnt/microsd/
total 64
-rwxr-xr-x 1 root root 2057 Jan 23 17:06 0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch
-rwxr-xr-x 1 root root 2426 Jan 23 17:06 0002-Check-for-Boot-Discovery-Policy-change.patch
-rwxr-xr-x 1 root root 2736 Jan 23 17:06 License.txt
-rwxr-xr-x 1 root root 5065 Jan 23 17:06 README.md
drwxr-xr-x 3 root root 4096 Jan 23 17:06 boot
-rwxr-xr-x 1 root root  230 Jan 23 17:06 config.txt
drwxr-xr-x 3 root root 4096 Jan 23 17:06 documentation
drwxr-xr-x 2 root root 4096 Jan 23 17:06 edk2
drwxr-xr-x 2 root root 4096 Jan 23 17:06 edk2-non-osi
drwxr-xr-x 2 root root 4096 Jan 23 17:06 edk2-platforms
drwxr-xr-x 2 root root 4096 Jan 23 17:06 extra
drwxr-xr-x 3 root root 4096 Jan 23 17:06 firmware
drwxr-xr-x 3 root root 4096 Jan 23 17:06 hardfp
drwxr-xr-x 6 root root 4096 Jan 23 17:06 modules
drwxr-xr-x 3 root root 4096 Jan 23 17:06 opt

Here are the contents of my SD card's BOOT directory:

Code: Select all

# ls -l /mnt/microsd/boot/
total 49924
-rwxr-xr-x 1 root root   18693 Jan 23 17:06 COPYING.linux
-rwxr-xr-x 1 root root    1594 Jan 23 17:06 LICENCE.broadcom
-rwxr-xr-x 1 root root   28418 Jan 23 17:06 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root   27790 Jan 23 17:06 bcm2708-rpi-b-rev1.dtb
-rwxr-xr-x 1 root root   28111 Jan 23 17:06 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root   28032 Jan 23 17:06 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root   29267 Jan 23 17:06 bcm2708-rpi-zero-w.dtb
-rwxr-xr-x 1 root root   27856 Jan 23 17:06 bcm2708-rpi-zero.dtb
-rwxr-xr-x 1 root root   29305 Jan 23 17:06 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root   29304 Jan 23 17:06 bcm2709-rpi-cm2.dtb
-rwxr-xr-x 1 root root   30170 Jan 23 17:06 bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root   32533 Jan 23 17:06 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root   31922 Jan 23 17:06 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root   30157 Jan 23 17:06 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root   31230 Jan 23 17:06 bcm2710-rpi-zero-2-w.dtb
-rwxr-xr-x 1 root root   31230 Jan 23 17:06 bcm2710-rpi-zero-2.dtb
-rwxr-xr-x 1 root root   52325 Jan 23 17:06 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root   52457 Jan 23 17:06 bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root root   52910 Jan 23 17:06 bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root root   50224 Jan 23 17:06 bcm2711-rpi-cm4s.dtb
-rwxr-xr-x 1 root root   52476 Jan 23 17:06 bootcode.bin
-rwxr-xr-x 1 root root    7265 Jan 23 17:06 fixup.dat
-rwxr-xr-x 1 root root    5400 Jan 23 17:06 fixup4.dat
-rwxr-xr-x 1 root root    3170 Jan 23 17:06 fixup4cd.dat
-rwxr-xr-x 1 root root    8382 Jan 23 17:06 fixup4db.dat
-rwxr-xr-x 1 root root    8386 Jan 23 17:06 fixup4x.dat
-rwxr-xr-x 1 root root    3170 Jan 23 17:06 fixup_cd.dat
-rwxr-xr-x 1 root root   10229 Jan 23 17:06 fixup_db.dat
-rwxr-xr-x 1 root root   10227 Jan 23 17:06 fixup_x.dat
-rwxr-xr-x 1 root root 6272904 Jan 23 17:06 kernel.img
-rwxr-xr-x 1 root root 6635232 Jan 23 17:06 kernel7.img
-rwxr-xr-x 1 root root 7045464 Jan 23 17:06 kernel7l.img
-rwxr-xr-x 1 root root 8197595 Jan 23 17:06 kernel8.img
drwxr-xr-x 2 root root   24576 Jan 23 17:06 overlays
-rwxr-xr-x 1 root root 2974880 Jan 23 17:06 start.elf
-rwxr-xr-x 1 root root 2250656 Jan 23 17:06 start4.elf
-rwxr-xr-x 1 root root  805084 Jan 23 17:06 start4cd.elf
-rwxr-xr-x 1 root root 3746856 Jan 23 17:06 start4db.elf
-rwxr-xr-x 1 root root 2998120 Jan 23 17:06 start4x.elf
-rwxr-xr-x 1 root root  805084 Jan 23 17:06 start_cd.elf
-rwxr-xr-x 1 root root 4818728 Jan 23 17:06 start_db.elf
-rwxr-xr-x 1 root root 3721800 Jan 23 17:06 start_x.elf

Here is the output of fdsik -l for the SD card:

Code: Select all

# fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 119.08 GiB, 127865454592 bytes, 249737216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x40b2a0ce

Device         Boot Start     End Sectors Size Id Type
/dev/mmcblk0p1       2048 2099199 2097152   1G  c W95 FAT32 (LBA)

You didn't ask for it, but in case it's useful, here is the content of my Pi's config.txt:

Code: Select all

# cat config.txt 
arm_64bit=1
enable_uart=1
uart_2ndstage=1
enable_gic=1
armstub=RPI_EFI.fd
disable_commandline_tags=1
disable_overscan=1
device_tree_address=0x1f0000
device_tree_end=0x200000
dtoverlay=miniuart-bt
dtoverlay=upstream-pi4

[NeddySeagoon]

jgaz,

You have

Code: Select all

armstub=RPI_EFI.fd

so the boot loader will try to load the file /mnt/microsd/boot/RPI_EFI.fd and run it before passing control to the kernel.
If RPI_EFI.fd never returns, it won't do that.

I don't see your /mnt/microsd/boot/RPI_EFI.fd file.

[jgaz]

jgaz,

You have

Code: Select all

armstub=RPI_EFI.fd

so the boot loader will try to load the file /mnt/microsd/boot/RPI_EFI.fd and run it before passing control to the kernel.
If RPI_EFI.fd never returns, it won't do that.

I don't see your /mnt/microsd/boot/RPI_EFI.fd file.

Well, I'm an idiot.

It looks like this is a source repository and that I (shocker) need to build the binary first. The proof is in the GitHub workflow YAML: https://github.com/pftf/RPi4/blob/maste ... x_edk2.yml which can clearly be seen building RPI_EFI.fd as a test but RPI_EFI.fd isn't actually in the tar archive. The RPi4_UEFI_Firmware_v1.34.zip file contains the built file that I actually need, if I want to use the pre-built binary, which I probably will for testing.

I'll try the right file and see how it goes.

[jgaz]

I can confirm I was able to boot the Pi into UEFI mode now that I grabbed the archive with the pre-built binary. From this point, I'm not sure if I need a boot loader to bring up the Linux kernel or not.

[pingtoo]

The RPi4_UEFI_Firmware_v1.34.zip only provide you EFI bootloader, no kernel or anything else.

You will need to go into shell to see what was default setup and either put stuff to match the default setup or modify default to match your boot partition.

You can try to press <F1> to launch UEFI shell.

You can try "help" as command to see what this firmware offer.

[NeddySeagoon]

jgaz,

... At this stage, you can press Esc to enter the firmware setup, F1 to launch the UEFI Shell, or, provided you also have an UEFI bootloader on the SD card or on a USB drive in efi/boot/bootaa64.efi, you can let the UEFI system run that (which will be the default if no action is taken). ...

Eww ... grub on a Pi4 ... if you are not careful :)

efi/boot/bootaa64.efi can be grub or any other EFI compliant program, e.g. a stub kernel.
If its a stub kernel, the kernel command line may need to be built it.

I use the arm64 edk2 UEFI firmware for KVMs on my arm64 server but being lazy, I use grub.

Different implementations of EFI firmware vary in what else they can load besides efi/boot/bootaa64.efi.
The next step is to install an EFI compliant program at efi/boot/bootaa64.efi. That's /boot/EFI/boot/bootaa64.efi to give it its full path.

[jgaz]

The RPi4_UEFI_Firmware_v1.34.zip only provide you EFI bootloader, no kernel or anything else.

You will need to go into shell to see what was default setup and either put stuff to match the default setup or modify default to match your boot partition.

You can try to press <F1> to launch UEFI shell.

You can try "help" as command to see what this firmware offer.

Pingtoo, yeah, I'll definitely poke around the UEFI shell and have a look around.

I have found basic instructions for deploying the GRUB bootloader to the Pi in order to bring up an OS kernel here: https://forums.raspberrypi.com/viewtopic.php?t=306511. I'll try those instructions in a bit. I'll also test the arm64 bootable Gentoo ISO and see if it plays nice with that setup. It has EFI support, so fingers-crossed.

[pingtoo]

I have found basic instructions for deploying the GRUB bootloader to the Pi in order to bring up an OS kernel here: https://forums.raspberrypi.com/viewtopic.php?t=306511. I'll try those instructions in a bit. I'll also test the arm64 bootable Gentoo ISO and see if it plays nice with that setup. It has EFI support, so fingers-crossed.

Not sure what you want EFI for? if you want to boot linux (or any other EFI application) you can just setup EFI var to find the EFI application (Linux kernel can be one). Adding GRUB is just another layer of boot loader which I think is unnecessary.

This remind me of thinking use u-boot to boot into EFI than boot into GRUB then boot into kernel. The definition of "bootstrapping"

[NeddySeagoon]

jgaz,

I would cross compile a Pi kernel, as an EFI stub kernel, with an embedded kernel command line ad put that at efi/boot/bootaa64.efi.
It would boot that directly that the EFI firmware had done its thing. That's my get out of jail free card.

Once it was up, install grub and play with efibootmgr in the normal amd64 handbook way.

Without a chroot, how do you use the grub autoblackmagic to write grub.cfg?
Well, you can use QEMU to run an arm64 chroot on any random host but that's a lot of work.