New Raspberry Pi Kernels & Related Packages

You need the following:
GPT Partition Table.
500MB Partition with type EFI which will have efi and boot files.
Rest rootfs ext4 partition.

You will have to boot into uefi and manually load the rpi kernel and start Manjaro ARM. once kernel detects the uefi then only you can install grub and efibootmgr.

Can you share the UEFI file you are using ? I can try to test the theory that I can tell you, I have got SolidRun Honeycomb to work the same way.
I can try to many a working sd card over UEFI and share it with you for testing. I have RPI4 - 8GB version.

Hmm, I am using MBR, I will try changing to GPT.

/boot is FAT32
/ is ext4 with Manjaro minimal

I have successfully used both external SD and USB flash drives. (Due to my case, I can not access the RPI SD drive)

I boot the Manjaro minimal image and remove all files (except for kernel and initramfs) from /boot.

Then I place this uefi firmware in /boot and copy other kernels and initramfs.

Then I install grub2 and make the grub image with --removable, it recognizes aarch64 without passing a parameter and places the bootaa64.efi in /boot/EFI/BOOT/

When it boots, it does not load the grub.cfg. I think may be due to how I made the grub image? It boots to a grub prompt, so I then run configfile (hd0,msdos1)/grub/grub.cfg

This simple grub.cfg menu:

menuentry "Ubuntu boot" {
          echo "Ubuntu booting..."
          linux (hd0,msdos1)/kernel6.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-linux6.img.sav
          boot
}

menuentry "VIM3 boot" {
          echo "VIM3 booting..."
          linux (hd0,msdos1)/kernel7.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-linux7.img.sav
          boot
}

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
}

The tumbleweed kernel and initramfs I copied from their rpi4 image and it boots. So far other kernels do not. They freeze after the EFI stub loads the kernel (see post 425 above). The VIM3 kernel does produce some disk activity, however it never progresses.

Kernel 5.12-rc3 hit the RPi repo. I just got home and will compile it after I rest and eat.

1 Like

I tried using the UEFI shell to directly load the kernels…

The good new is… I got the same results.
The bad news is… I got the same results.

So grub2 seems to be equally viable, if only I knew the secret sauce of the Tumbleweed kernel.

I pushed the long awaited linux-rpi4-rc 5.12.rc3-1to the unstable branch when the mirrors sync.

@0n0w1c There was nothing new in the kernel config concerning UEFI but I did set CONFIG_FB_EFI=y. I just saw your edit above so I did nothing with CONFIG_ACPI

linux-rpi4-rc 5.12.rc3-1
linux-rpi4-rc-headers 5.12.rc3-1

EDIT:

I am going to remove this from the repo. It has a kernel taint shutting down.

@0n0w1c This should be ok for you to test to see if anything is different with the EFI but let me know when you get it so I can remove it from the repo. It boots ok but will not do a complete shutdown.

Hello. I’m getting ready to try experimenting with the 2.5GbE adapter again later this week, assuming the NVME drive remains stable with other USB devices plugged in using the latest firmware.

A couple of questions:

This is what I see now for the 5.10.y kernel on the unstable/beta branch. Is this what I need to switch to?

❯ pacman -sS linux-rpi4
core/linux-rpi4 5.10.23-1
    The Linux Kernel and modules - Raspberry Pi 4 64-bit kernel
core/linux-rpi4-headers 5.10.23-1
    Header files and scripts for building modules for linux kernel - Raspberry Pi 4 64-bit kernel

Am I good to go with the latest bootloader packages? After installing the latest beta firmware, mine are newer than the ones you mentioned before.

After switching kernels, do I just follow the same instructions you provided in the other thread, but using the version number of the latest unstable branch kernel (today: 5.10.23-1)? Specifically: Sabrent USB 2.5G Ethernet Adapter: Realtek 8152 Chipset Drivers from AUR? - #17 by Darksky

How do patches like this migrate? I notice we’re using 5.10.y for testing. Will this eventually move to 5.11.y, or go straight to 5.12, once it’s considered stable?

what ever kernel / bootloader / eeprom packages you install in the unstale branch are the latest at the time you install them.

RPi and a lot of other distro’s use what upstream considers Long Term Service for their main kernels. Right now that is 5.10 and the RPi considers it to be their Stable kernel and most of their work is focused on it so it will be around for a while. 5.11 and 5.12 will at some point reach End Of Line and will go away but they give an insight of new features being add along the way which they will improve on until upstream reaches their next kernel that will be LTS.

1 Like

That makes sense. I admit I had not been thinking in terms of LTS since I knew Manjaro is a rolling release.

Does having the Ethernet driver in the beta kernel change your instructions in the other thread at all? Do I still need to separately install the driver file, or is it just included in the latest beta kernel now?

The update to the RC kernel was uneventful, no issues noticed in dmesg. Thank you.

Unfortunately it does not boot via uefi, no change noticed.

In related news, a cohort has

Linux test 5.11.2-1-MANJARO-ARM #1 SMP PREEMPT Thu Mar 4 21:51:36 +03 2021 aarch64 GNU/Linux

which is vim3 running in a KVM VM with 8 CPU on a x86_64 machine, and it is booting via uefi… although it is using u-boot.

All I asked you to do was upgrade your eeprom and install the 2 bootloader files in the unstable branch and test the dkms module on the test kernel I gave you and see if it helped any.

I tried the Fedora 33 kernel and after decompressing the kernel, it also boots via the UEFI shell. So maybe there is some secret sauce the RPM based distros have figured out?

I noticed that but figured it had to do with my messing around. Yes, go ahead and remove it from the repo. I don’t want my fooling around to cause others issues.

I tested more today and the issue is networkmanager not shutting down. If I disable
networkmanager it will reboot just fine.

Can you post a kernel config where I can get to it. What kernel version is it?

Unfortunately it is 5.8.15-301

https://drive.google.com/file/d/1fJ9ZrNSkni6bVyNqC3B6Oor3C2UDhLQX/view?usp=sharing

Oh. So I can just use the exact instructions you gave me before? Excellent. Will try that tonight.

linux-rpi4-5.10.23-1 seems to break fkms with my 4K monitor and lightdm. I get the dreaded blinking cursor in the upper left that xorg is not running properly. Changing my config.txt to use kms gives the same result. So I guess EDID is broken again. I rolled back to 5.10-22 to get it working again.

I have been messing with the kernel configs and got some more kernel configs to show up. I am re-compiling 5.10.23 for you to test. Seems like you were using a minimal install to test uefi with aren’t you.

Yes, I am using the minimal install image, minus the /boot of course. I replaced it with what the uefi firmware provided.

@0n0w1c Try this kernel on your uefi minimal test image.

https://drive.google.com/file/d/1ISFmx7tMmnAOSFJ652oz4dv-d65FDMKx/view?usp=sharing