New Raspberry Pi Kernels & Related Packages

I am in search of a way to select which .dtb is loaded by start4.elf. That is why I was trying to load it via grub… which works, sort of anyway. Still messing with it.

Edit: I wonder if there is a way to create a .dtb from a running system? That way I could “make” a .dtb for each kernel and load it via grub. The DT is incomplete when simply loading the bcm2711-rpi-4-b.dtb file.

Edit 2: Getting warmer

dtc -I fs -O dtb -o base.dtb /proc/device-tree

Edit 3: Wow, I think it worked.

Edit 4: I created the “custom” .dtb from a running setup. I then edited my config.txt and commented out the loading of the vc4-kms-v3d-pi4 overlay and modified grub.cfg to load the custom .dtb. I then rebooted and vc4-kms-v3d-pi4 was loaded and lightdm fired right up. :smiley:

For a concrete example, here are two of my grub menu options.

This is the “standard” way, with the DTB loaded by start4.elf on the FAT partition:

menuentry "Manjaro RC5-2 on sda5" {
          echo "Manjaro RC5-2 on sda5 booting..."
          insmod part_gpt
          insmod btrfs
          linux (hd0,gpt5)/@/boot/kernel-linux-rpi4-rc-5.12.rc5-2.efi root=/dev/sda5 rw rootwait snd_bcm2835.enable_hdmi=1 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,gpt5)/@/boot/initramfs-linux-rpi4-rc-5.12.rc5-2.img
          boot
}

And this is the entry with a custom DTB loaded by grub2 on partition 5:

menuentry "Manjaro RC5-2 DTB on sda5" {
          echo "Manjaro RC5-2 DTB on sda5 booting..."
          insmod part_gpt
          insmod btrfs
          linux (hd0,gpt5)/@/boot/kernel-linux-rpi4-rc-5.12.rc5-2.efi root=/dev/sda5 rw rootwait snd_bcm2835.enable_hdmi=1 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
          devicetree (hd0,gpt5)/@/boot/bcm2711-linux-rpi4-rc-5.12.rc5-2.dtb
          initrd (hd0,gpt5)/@/boot/initramfs-linux-rpi4-rc-5.12.rc5-2.img
          boot
}

This will allow storing the kernel, initramfs and DTB on an arbitrary partition… such partitions could be completely different OS versions.

Edit: I used DTB to denote that it is the fully resolved device tree, unlike the bcm2711-rpi-4-b.dtb file. Maybe I can incorporate versioned overlays directories and config.txt files, which will be really nice to have.

1 Like

I finally found a work-around for my systemd-timesyncd issue of timeouts to the ntp pool servers. I am unsure of the cause, it could simply be my poor internet service. I tried ntpd and it too would not sync with the servers. However, I just installed chronyd and it works great, no issues.

I have found an issue with the booting via the DTB, for some reason /dev/vcio is not created. I compared the devices in /dev and it is the only missing device. It is the vc4 mailbox and I noticed it when my argononed failed to read the CPU temp. Not sure what else it effects.

@Darksky On the next RC kernel build, would you consider trying CONFIG_BCM_VCIO=m? Maybe it will load once the system is up, it is a userspace device. The kernel code looks to do checks on the existence of raspberry firmware, I am concerned it is something uniquely setup with start4.elf.

Edit: I don’t want to wait that long, I’ll build it.

Edit 2: I have not been able to resolve the /dev/vcio yet. As a work-around for my fan, I reverted to using the normal argonone package that uses python, the fan works.

Edit 3: I modified the source to print some messages. There were exit points without messages and I wanted to see where this is failing. Interestingly, this is very similar to the missing /dev/gpiomem issue. It turns out, the code for both are in the same directory and are linked back to back. They load back to back, as seen below:

[    0.559886] vc-mem: phys_addr:0x00000000 mem_base=0x00000000 mem_size:0x00000000(0 MiB)
[    0.560016] vcio: failed entered vcio_init
[    0.560317] gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000

That is my nonsensical error message for the vcio, as it entered the device init function in vcio.c. Notice no other error messages, as if it runs through the device init function but does not generate an error or the device. Notice the vc_mem and the gpiomem, both of those I investigated due to the gpiomem issue. Coincidence? Or maybe a bug in device generation or a linker issue?

Edit 4: This is where the device creation fails in vcio.c:

vcio.fw = rpi_firmware_get(np);
if (!vcio.fw)
        return -ENODEV;

It is also possible that the previous function call:

np = of_find_compatible_node(NULL, NULL,
                             "raspberrypi,bcm2835-firmware");

returns an invalid/incorrect struct.

Edit 5: I found this patch, seems they are making related changes.

Edit 6: I tried booting with start4.elf (both manjaro and uefi) with device_tree set to be my custom DTB in config.txt, and it does not boot, hangs after the rainbow. Interesting.

Edit 7: I can not find any mention of vcio in the DTB, that is unexpected. Even on a system which successfully creates /dev/vcio. However, it may be called mailbox in the DTB.

All 3 pi kernel/headers packages have been upgraded and pushed to the unstable branch when the mirrors sync.

linux-rpi4 5.10.27-1
linux-rpi4-headers 5.10.27-1
linux-rpi4-mainline 5.11.11-1
linux-rpi4-mainline-headers 5.11.11-1
linux-rpi4-rc 5.12.rc6-1
linux-rpi4-rc-headers 5.12.rc6-1

They finally got around today updating their firmware tree. The 2 new raspberrypi-bootloader packages have been pushed to the unstable branch when the mirrors sync:

raspberrypi-bootloader 20210407-1
raspberrypi-bootloader-x 20210407-1

Quite a few changes:

https://github.com/raspberrypi/firmware/commit/8c7c52466505df5d420a5cb9131ec29205bcecf8

I finally got around to compiling 5.12 LTO kernel. Give your feed back if one decides to test it on your pi.

5.12-rc6-2 LTO kernel

1 Like

hmm, this is strange… did anyone else’s vc4-kms-v3d-pi4 and vc4-kms-v3d die ? After a recent update on my pi 400 my manjaro kde (which was using vc4-kms-v3d-pi4 the config) started experiencing visual glitching and lockups. Switched through the two VC4 drivers mentioned above and finally back to vc4-fkms-v3d and everything started working fine again. Strangely enough, after switching back to fkms the performance is exactly as I would expect, as if hardware acceleration is still working (hires video playback, youtube performance, emulation through retroarch).

You did not say which kernel you are using. But you should check to make sure you have a /boot/overlays/overlay_map.dtb file. If not, upgrade your kernel.

yes, overlay_map.dtb in there all 3 kernel.
switch fkms all good, kms doing just fine with sway but not kde.

Ah, yes, of course, sorry for leaving that out.

I’m experiencing this issue on 5.12.0-rc6-1-MANJARO-ARM and /boot/overlays/overlay_map.dtb is present

I use kms and plasma seems fine on x11, but terrible on wayland.

Edit: After more use, yes. I do have some system hangs and occasional artifacts even with x11.

found ‘linux-manjaro-rpi4-cacule-mainline’ in archlinux(not alarm), whats that?

Looks like they patched the 5.11 kernel with the cacule cpu scheduler but why 5.11. I wonder if it was just compatible with 5.11 and they just grabbed my PKGBUILD. I may even patch our 5.11 and try it out today.

AUR

cacule project

On current unstable and rc kernel, a new behavior. Or if iirc, a behavior that has returned.
On this installation, I have xf86-video-fbturbo-git installed and fkms set in config.txt.

Login via lightdm with a plasma X11 session, rendering by llvmpipe.
Login via lightdm with a plasma wayland session, rendering by v3d.

Both sessions seem to work well and without significant issue.

Edit: Bah, I spoke too soon. After switching back from wayland to x11, the llvmpipe session has issues. Even after rebooting, the System Settings window appears with totally black contents and the window shading is wonky. It may be resolvable, if I could get to the Compositor Settings.

This is what I would expect with a X11 session. If you disable xf86-video-fbturbo-git by renaming /etc/Xorg/xorg.conf.d/99-fbturbo.conf to /etc/Xorg/xorg.conf.d/99-fbturbo~ and reboot you should have V3D.

This is not I would expect so I have no clue why this is happening with a wayland session with fbturbo enabled. I do not have plasma installed here.

After the big kwin update that changed the compositor code, plasma on wayland would immediately hang if llvmpipe was the compositor. Now it seems to successfully load v3d instead.

For my next multi-booting OS, I will try to get Raspberry PI OS 64 bit working. I stumbled upon this build. Not exactly what I want, but the pkgbuild seems well constructed, and maybe has a few bits of interest.

Edit: As it turns out, once I brought my Raspberry Pi OS up to date, the 5.10.17-v8+ kernel is UEFI bootable and wifi works.

Edit 2: I am not sure how it is booting… I thought ACPI was a requirement.

CONFIG_ARCH_SUPPORTS_ACPI=y
# CONFIG_ACPI is not set

Edit 3: acpi must not be a requirement. I compiled the default RPi OS 5.12 kernel and it boots via uefi. And it also lacks acpi support.

On the lastest update my headless Pi 4b I got the following messages when upgrading linux-rpi4-mainline:

===> Keeping old cmdline.txt file...
===> Keeping old config.txt file...

Is this analogous to the creation of a *.pacnew file? Are there some options I should be changing in these files? My current file contents are as follows:

cat /boot/config.txt
# See /boot/overlays/README for all available options

gpu_mem=64
initramfs initramfs-linux.img followkernel
kernel=kernel8.img
arm_64bit=1
disable_overscan=1

#enable sound
dtparam=audio=on
#hdmi_drive=2

#enable vc4
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
cat /boot/cmdline.txt
root=LABEL=ROOT_MNJRO rw rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 elevator=noop usbhid.mousepoll=8 snd-bcm2835.enable_compat_alsa=0 audit=0

A few months ago I stopped having the config files from being replaced with each kernel install. So many folks have their own custom configs. The .install file checks if the config files exist and keeps them if they do otherwise it will create ones with default settings.