New Raspberry Pi Kernels & Related Packages

Sorry, I should have been more specific. For the kernel @Strit built, linux-rc3. If he applies that patch, I believe he can then build the linux-rc3 kernel with v3d.

I see. Upstream used to have v3d support in the drivers/staging/ area but it is gone now due kernel changes they had made a couple of years ago. It would be a monumental task to patch in all of the needed patches as it will affect so many things.

ADDED:

When testing upstream last week I ran into issues with getting sound to work right with the 5.14 kernel. I found out that by uninstalling all pulseaudio packages and installing pipewire’s counterparts the audio seemed to be ok (including bluetooth). I have not tested with linux-rpi4-rc kernel yet using pulseaudio as pipewire is installed. I wonder if there is the same issue now in linux-rpi4-rc 5.14 kernel.

[ray@pi4 ~]$ pacman -Ss pipewire | grep installed
extra/pipewire 1:0.3.32-1 [installed: 1:0.3.31-1]
extra/pipewire-alsa 1:0.3.32-1 [installed: 1:0.3.31-1]
extra/pipewire-media-session 1:0.3.32-1 [installed: 1:0.3.31-1]
extra/pipewire-pulse 1:0.3.32-1 [installed: 1:0.3.31-1]

This install happens to be using Pulseaudio, sound is working fine. digital hdmi and headphones.

$ inxi -Fxz
System:    Kernel: 5.14.0-rc2-1-MANJARO-ARM aarch64 bits: 64 compiler: N/A Desktop: KDE Plasma 5.22.3 Distro: Manjaro ARM 
           base: Arch Linux 
Machine:   Type: Embedded-pc System: Raspberry Pi Foundation product: Raspberry Pi 4 Model B v: D03114 serial: <filter> 
           Mobo: Sony UK model: Raspberry Pi 4 Model B v: D03114 serial: <filter> UEFI: https://github.com/pftf/RPi4 
           v: UEFI Firmware v1.26 date: 04/16/2021 
CPU:       Info: Quad Core model: N/A variant: cortex-a72 bits: 64 type: MCP arch: ARMv8 rev: 3 
           features: Use -f option to see features bogomips: 432 
           Speed: 600 MHz min/max: 600/1800 MHz Core speeds (MHz): 1: 1000 2: 1000 3: 1000 4: 1000 
Graphics:  Device-1: bcm2711-hdmi0 driver: vc4_hdmi v: N/A bus-ID: N/A 
           Device-2: bcm2711-hdmi1 driver: vc4_hdmi v: N/A bus-ID: N/A 
           Device-3: bcm2711-vc5 driver: vc4_drm v: N/A bus-ID: N/A 
           Display: x11 server: X.Org 1.20.12 driver: loaded: modesetting s-res: 1920x1080 
           OpenGL: renderer: V3D 4.2 v: 2.1 Mesa 21.1.5 direct render: Yes 
Audio:     Device-1: bcm2711-hdmi0 driver: vc4_hdmi bus-ID: N/A 
           Device-2: bcm2711-hdmi1 driver: vc4_hdmi bus-ID: N/A 
           Device-3: bcm2835-audio driver: bcm2835_audio bus-ID: N/A 
           Sound Server-1: ALSA v: k5.14.0-rc2-1-MANJARO-ARM running: yes 
           Sound Server-2: JACK v: 0.125.0 running: no 
           Sound Server-3: PulseAudio v: 14.2 running: yes 
           Sound Server-4: PipeWire v: 0.3.32 running: no 
Network:   Device-1: bcm2835-mmc driver: mmc_bcm2835 v: N/A port: N/A bus-ID: N/A 
           IF: wlan0 state: up mac: <filter> 
           Device-2: bcm2711-genet-v5 driver: bcmgenet v: N/A port: N/A bus-ID: N/A 
           IF: eth0 state: down mac: <filter> 
Drives:    Local Storage: total: 223.57 GiB used: 39.84 GiB (17.8%) 
           ID-1: /dev/sda type: USB vendor: Kingston model: SA400M8240G size: 223.57 GiB 
Partition: ID-1: / size: 55.38 GiB used: 39.76 GiB (71.8%) fs: btrfs dev: /dev/sda3 
           ID-2: /boot/efi size: 246.1 MiB used: 82.7 MiB (33.6%) fs: vfat dev: /dev/sda1 
           ID-3: /home size: 55.38 GiB used: 39.76 GiB (71.8%) fs: btrfs dev: /dev/sda3 
           ID-4: /var/log size: 55.38 GiB used: 39.76 GiB (71.8%) fs: btrfs dev: /dev/sda3 
Swap:      ID-1: swap-1 type: partition size: 4 GiB used: 0 KiB (0.0%) dev: /dev/sda2 
Sensors:   System Temperatures: cpu: 38.9 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 199 Uptime: 34m Memory: 7.69 GiB used: 1.43 GiB (18.6%) gpu: 76 MiB Init: systemd Compilers: gcc: 10.2.0 
           Packages: 974 Shell: Bash v: 5.1.8 inxi: 3.3.05
BOOT_IMAGE=(hd0,gpt3)/@/boot/kernel8.img root=/dev/sda3 rw rootwait snd-bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 console=serial0,115200 console=tty3 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 usbhid.mousepoll=8 audit=0

I was on -rc2 last week. Maybe they fixed it in -rc3.

Good news with linux-rpi4. They reverted a patch today and I can now boot either kms or fkms with V3D rendering. They have not done the same with 5.13 or 5.14 yet but will check tomorrow to see if they did the same with them. If they have not I will see if they can be reverted and see what happens with them since they have the same issue.

https://github.com/raspberrypi/linux/commit/9a22b00c1e40799b4014a96644d811307e7114d2

This kernel is still a WIP for them to convert VC4 to upstreams’s so if you are not totally happy with it try the 5.10.46-1 kernel link I posted above somewhere. It is the last kernel before all of the conversion process begin.

Pushed to the upstream branch when the mirrors sync. Also the 2 raspberrypi-bootloader packages in upstream also need to be installed with this kernel.

linux-rpi4 5.10.52-1
linux-rpi4-headers 5.10.52-1

I have yet to try this kernel, I will try to get to it this evening.

Did I understand you correctly? The linux-rc3 kernel supports the RPi4 (with the exception of v3d)?

Is my understanding correct? That the v3d support in the upstream kernel will not be updated with the work the RPi folks have been doing? That there are no plans for the upstream kernel to support v3d v4.2 as it does now with the RPI tree. And that it will be stuck at v3.3 for the foreseeable future?

Correct. Also if I remember right @Strit added configs for EFI like I have in the RPi kernel that needs to be tested. He can confirm this to be true or not. If you install the kernel the needed .dtb’s are under /boot/dtbs/. I never install the package. I just cherry pick the needed files from the package. I also do not use uboot; it is not needed to boot upstream kernel with the pi4. The onboard firmware knows what to do. Just needs some different lines in config.txt and cmdline.txt.

The water got more muddy today with RPi kernels.

It appears that RPi is planning to release a new “Stable Image” and do not want all of the related ongoing issues with their upstream patches to be in their new image so they released new raspberrypi-firmware. They have some normal fixes and new additions in their commits but the one that really caught my eye is one with a ton of reverts regarding their on going upstream patches. This appears to only affect the 5.10 kernel. It looks like they are still going forward with the upstream patches in the later kernels. So they are still a WIP and a lot of things are still flaky with them now until they get fixed.

Quote from their commit:

"It would be useful to get this out quickly for the next stable image.
When the upstream patches are fixed we can add them back in."

https://github.com/raspberrypi/linux/pull/4478

So to get the best out of our linux-rpi4 kernel 5.10.52-1 in the unstable branch also install the 2 latest raspberrypi-bootloader packages with all of the needed reverts they released today when the mirrors sync.

raspberrypi-bootloader 20210727-1
raspberrypi-bootloader-x 20210727-1

Yes, this is true.

Good news, thank you. I will also try the linux-rc3 kernel. I previously checked the config file and noticed the vc4 and efi were supported, but I was not sure about all of the other various config settings required to support the RPi4.

I attempted the linux-rc3 kernel, but it did not boot for me on a USB SSD. Is it possible the config is missing USB support for the RPI4? Could not find /dev/sda5, which is the correct partition. The init runs, systemd basic target is reached and then the timeout waiting for /dev/sda5. Also no usb keyboard, the backlights are not illuminated.

Are you using uboot.

Not on that install, uses UEFI and grub.

5.10.52-1 boots for me with fkms.

Edit: This install uses u-boot.

Maybe a year ago when I was messing with uboot one had to have a couple of modules in the initrd for the msd boot to work other wise it would do like you are describing. Then things got bad where uboot would not work due to a bug in uboot. That is where arch-arm started providing a 64bit RPi kernel because people started using the manjaro kernel. Some used the RPi .dtb. It was a mess.

Try adding pcie_brcmstb into MODULES in /etc/mkinitcpio.conf and rebuild the initrd. Might also might have to add XHCI_HCD.
Also might try using PARTUUID= instead. When I was messing with it back then upstream had a different set of rules with drives.

https://archlinuxarm.org/forum/viewtopic.php?f=65&t=14672&hilit=54+bit+usb+boot

Agreed, likely a module that needs to be loaded, but it is not just pcie_brcmstb, because I did as suggested but had the same result, just the different root device name. I also tried it with udev, same timeout. The kernel is built with CONFIG_USB_XHCI_HCD=y.

I’ll keep messing around with it, maybe I can figure it out.

Keep messing with it. I just tested here and the latest upstream kernel will do a usb boot; just needs the right things adjusted for the way you are doing.

I do not know if it will help but here is my way I do configs.

cmdline.txt:

[ray@pi4 ~]$ cat /boot/cmdline.txt
root=PARTUUID=b75fdbb1-02 rw rootwait console=ttyS1,115200 console=tty0 usbhid.mousepoll=8 audit=0

With my config.txt I pretty much rem out everything including the initramfs line as I do not generate one. I also have my .dtb renamed in /boot so I reflect that in config.txt as well as the kernel as Image.

config.txt

over_voltage=5
arm_freq=2000
device_tree=bcm2711-rpi-4-b-upstream.dtb
#gpu_mem=64
initramfs initramfs-linux.img followkernel
kernel=Image
arm_64bit=1
disable_overscan=1

#PWM Fan control
#dtoverlay=gpio-fan,gpiopin=14,temp=80000

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

#enable vc4
#dtoverlay=vc4-kms-v3d,cma-512
#dtoverlay=vc4-kms-v3d
#dtoverlay=vc4-fkms-v3d,cma-512
#dtoverlay=vc4-fkms-v3d
#max_framebuffers=2
#dtoverlay=rpivid-v4l2
#disable_fw_kms_setup=1

#hdmi_force_edid_3d:0=1
#hdmi_mode:0=39
#hdmi_mode:0=16
#hdmi_mode:0=58 #gateway
#hdmi_drive:0=2
#hdmi_group:0=2 #gateway/vizio
#hdmi_force_mode:0=1
#hdmi_ignore_edid:0=0xa5000080

#disable_splash=1

Ah, so It booted without loading any modules? That will narrow it down.

Well my way it does. I know it plays by different rules if it uses uboot and probably the same with uefi. Probably expects and does different things when it hits those modes.

I’m getting sleepy but I will check my list o uefi modules against what is in linux-rc tomorrow. I believe today there was one that had a =m where I had a =y.