Correct. For a long time it had to be un-compressed. A while back I saw where they said the had it where one could use compressed “If you feel lucky” but I never tried it. To be honest I forgot about it.
I have pushed linux-rpi4-mainline 5.11.6 to the unstable branch when the mirrors sync.
linux-rpi4-mainline 5.11.6-1
linux-rpi4-mainline-headers 5.11.6-1
Updated and dmesg looks clean.
Thanks again for trying the EFI changes, I am sort of stumped at the moment on what to try next. I may try systemd-boot or direct boot from efi.
Sorry, I don’t have the test kernel with me but maybe we missed this one.
CONFIG_FB_EFI=y
Maybe this is why I do not see any kernel output?
Edit: And I think there should be a CONFIG_EFI_VARS=y per this link
I saw that but it was not in what the other kernel had you posted above. I have an appointment to get my a/c fixed on my new truck so will not be able to recompile until later on today.
This is not an option in the 5.11 kernel. The latest linux-rpi4-mainline I pushed has the same modules enabled as in the test kernel.
My grep missed it, I looked for EFI_ so it would have missed the _EFI configs. I’ll do a better grep later this afternoon.
Good luck with the truck repair… I recently had to replace the turbo charger in my truck… $3K down the drain. 
Edit: I think UEFI booting also depends on ACPI, and on my 5.10.22 kernel, # CONFIG_ACPI is not set
I have a working manjaro arm over uefi on Hc.
I will update the grub pkg.
Efi stub needs efi partition and /boot contents in the same partition.
I had tried multiple times until I had success.
Sorry didn’t read the whole thread. Am i right to think that you want to try over Uefi?
Update I see my grub update might not work work rpi as they use the img name differently damn.
@darksky
Maybe we should unify the file naming so we can create our own grub pkg.
My goal is to be able to use grub2 with the RPi4. With the UEFI firmware for RPi4, this should be possible. But currently, uefi → grub2 → linux is only working with the Tumbleweed kernel. Maybe I will need to change to uefi → u-boot → grub2 → linux?
@Darksky I have now tried the Ubuntu and Manjaro VIM3 kernels, and they both halt in the same manner. So until I have a proven method of successfully booting other kernels, no sense making further changes.
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.
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.
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?