Yes, these are my settings:
# overclocking
over_voltage=6
arm_freq=1800
v3d_freq=600
#isp_freq=700
#h264_freq=700
hdmi_enable_4kp60=1
@Darksky Are you a bit bored with the lack of kernel activity? Maybe looking for a little project to keep you occupied?
How about this? It seems the 5.12 kernel brings a couple of important missing pieces of the puzzle. I might give this a try this weekend.
Edit: Ratsā¦ I forgot, still no 5.12 rpi kernel. Any guess as to when 5.12.0-rc2 will land?
I decided to mess around with this and I have managed to get the OpenSUSE kernel to boot on Manjaro minimal. Unfortunately the Manjaro kernel hangs at the point below:
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
I suspect a couple of EFI kernel configs would be needed to get the Manjaro kernel to boot.
So I have the experimental UEFI firmware in /boot, the tumbleweed rpi kernel and initramfs booting to a Manjaro minimal install via grub2. I load the grub.cfg via the grub shell and get a working grub menuā¦ with multiple kernels and initramfs in /boot. 
So I think the proof of concept passes.
Edit: It is also possible that I hit this bug when using the Manjaro kernel.
The latest kernel linux-rpi4 & headers and the 2 raspberrypi-bootloader packages have been pushed to the unstable branch when the mirrors sync.
linux-rpi4 5.10.23-1
linux-rpi4-headers 5.10.23-1
raspberrypi-bootloader 20210315-1
raspberrypi-bootloader-x 20210315-1Updated, and dmesg looks very good. Thank you
1 Like
In the event someone else uses the llvmpipe driver, a tipā¦ add vc4 to the MODULES= in mkinitcpio.conf and add a configuration to /etc/modules-load.d/. It seems that without loading the vc4 video dtoverlays, the vc4 kernel module is not loaded on boot.
Edit: Hmm, it seems that you still get the analog sound device rather than the digital sound device. Not sure it makes any real difference to load the vc4 driver for normal audio playback.
@Darksky The Tumbleweed kernel has the following EFI kernel config settings, a few more than is set for the current linux-rpi4. Would you consider making these changes? I would like to try to boot via EFI. The most notable one is CONFIG_EFI_STUB and it is already set, but no joy on boot. So maybe one or more of these other settings will do the trick?
$ zcat /proc/config.gz | grep EFI_
CONFIG_EFI_STUB=y
CONFIG_EFI_ESRT=y
CONFIG_EFI_VARS_PSTORE=m
# CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set
CONFIG_EFI_SOFT_RERESERVE=y
CONFIG_EFI_PARAMS_FROM_FDT=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_GENERIC_STUB=y
CONFIG_EFI_ARMSTUB_DTB_LOADER=y
CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y
CONFIG_EFI_BOOTLOADER_CONTROL=m
CONFIG_EFI_CAPSULE_LOADER=m
# CONFIG_EFI_TEST is not set
# CONFIG_EFI_DISABLE_PCI_DMA is not set
CONFIG_UEFI_CPER=y
CONFIG_UEFI_CPER_ARM=y
# CONFIG_EFI_DEV_PATH_PARSER is not set
CONFIG_EFI_EARLYCON=y
CONFIG_EFI_CUSTOM_SSDT_OVERLAYS=y
CONFIG_EFI_PARTITION=y
CONFIG_LOAD_UEFI_KEYS=y
- This is a typed list, there could be typos
Currently, linux-rpi4 has the following EFI configuration:
$ zcat /proc/config.gz | grep EFI_
CONFIG_EFI_STUB=y
CONFIG_EFI_ESRT=y
CONFIG_EFI_PARAMS_FROM_FDT=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_GENERIC_STUB=y
CONFIG_EFI_ARMSTUB_DTB_LOADER=y
CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y
# CONFIG_EFI_BOOTLOADER_CONTROL is not set
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
# CONFIG_EFI_DISABLE_PCI_DMA is not set
CONFIG_EFI_EARLYCON=y
CONFIG_EFI_PARTITION=y
And if you would prefer to try this just in arm-unstable with the 5.12 rc kernel, I can wait.
And if this EFI idea is not in the plans at all, maybe you could jot down the steps you use to build the kernel so I might compile one myself? Maybe it is as simple as cloning the RPI kernel repo and running make oldconfig with a kernel config from your repo?
Just started a compile on kernel 5.11 for you to test. I made the changes I could make but some of the modules options are not there.
Summary
CONFIG_EFI_STUB=y
CONFIG_EFI=y
#EFI (Extensible Firmware Interface) Support
CONFIG_EFI_ESRT=y
CONFIG_EFI_PARAMS_FROM_FDT=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_GENERIC_STUB=y
CONFIG_EFI_ARMSTUB_DTB_LOADER=y
CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y
CONFIG_EFI_BOOTLOADER_CONTROL=m
CONFIG_EFI_CAPSULE_LOADER=m
#CONFIG_EFI_TEST is not set
#CONFIG_EFI_DISABLE_PCI_DMA is not set
#end of EFI (Extensible Firmware Interface) Support
CONFIG_EFI_EARLYCON=y
CONFIG_EFI_PARTITION=y
#CONFIG_FB_EFI is not set
#CONFIG_RTC_DRV_EFI is not set
CONFIG_CACHEFILES=y
#CONFIG_CACHEFILES_DEBUG is not set
#CONFIG_CACHEFILES_HISTOGRAM is not set
CONFIG_EFIVAR_FS=m
1 Like
@0n0w1c The test kernel:
https://drive.google.com/file/d/111jfWltb9JbHeehueAsPE-41eFD9q41x/view?usp=sharing
1 Like
Heading home now so I can test it.
Unfortunately, I have not yet been successful. It still simply halts at the same point. No disk activity, no further console messages.
From the looks of their kernel they have a custom overlay that gets compiled.
Maybe 5.12 will pull something in. 5.11.6 hit but I am in the middle of something else.
Scratch that. Looks like they added something else in the Makefile.
Good news on the 5.11.6, hopefully 5.12 wonāt be too far off. I need the working wifi.
That is unfortunate, I was hoping there would be no secret sauce involved. The firmware does not indicate anything special required. To be honest, I thought CONFIG_EFI_STUB=y would be the only requirement to get something more happening on boot, than I get now.
Have you searched the overlays directory for something involving efi.
The only overlay on the disk is /overlays/miniuart-bt.dbto supplied by the firmware.
$ cat /boot/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
$ cat /boot/grub/grub.cfg
menuentry "Manjaro boot" {
echo "Manjaro booting..."
linux (hd0,msdos1)/kernel8.img.sav root=/dev/sda2 rw rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 usbhid.mousepoll=8 audit=0
initrd (hd0,msdos1)/initramfs-linux8.img.sav
boot
}
menuentry "Tumbleweed boot" {
echo "Tumbleweed booting..."
linux (hd0,msdos1)/kernel9.img.sav root=/dev/sda2 rw rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 usbhid.mousepoll=8 audit=0
initrd (hd0,msdos1)/initramfs-linux9.img.sav
boot
}
menuentry "System shutdown" {
echo "System shutting down..."
halt
}
menuentry "System restart" {
echo "System rebooting..."
reboot
}
$ ls -l /boot
total 124257
-rwxr-xr-x 1 root root 48794 Feb 26 19:24 bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root root 49090 Feb 26 19:24 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 49202 Feb 26 19:24 bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root root 211 Mar 16 16:43 config.txt
drwxr-xr-x 3 root root 512 Mar 14 12:28 EFI
-rwxr-xr-x 1 root root 5448 Feb 26 19:24 fixup4.dat
drwxr-xr-x 6 root root 512 Mar 14 13:15 grub
-rwxr-xr-x 1 root root 7211252 Mar 16 17:08 initramfs-linux8.img.sav
-rwxr-xr-x 1 root root 57979512 Mar 14 14:34 initramfs-linux9.img.sav
-rwxr-xr-x 1 root root 22501888 Mar 16 12:10 kernel8.img.sav
-rwxr-xr-x 1 root root 35123568 Mar 14 14:34 kernel9.img.sav
drwxr-xr-x 2 root root 512 Mar 13 20:38 overlays
-rwxr-xr-x 1 root root 5240 Feb 26 19:21 Readme.md
-rwxr-xr-x 1 root root 2031616 Feb 26 13:31 RPI_EFI.fd
-rwxr-xr-x 1 root root 2228800 Feb 26 19:24 start4.elf
From size alone, it would appear there is a significant difference in kernel builds.
Just to make sure, kernel8.img is not compressed, correct?