Raspberry Pi Kernels (2.0)

I started a new thread for the new RPi kernels and support/issues as the old one was just getting too big to scroll through.

The latest linux-rpi4-mainline and linux-rpi4-rc packages has been pushed to the unstable branch when the mirrors sync.

I decided to go ahead and push these to the repo as they seem to be getting close with stability. Having all sound devices to appear including headphones you still have to make a config change in /boot/cmdline.txt when switching between fkm and kms in config.txt.

fkms:

snd-bcm2835.enable_compat_alsa=1 snd_bcm2835.enable_headphones=1 audit=0

kms:

snd-bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_headphones=1 audit=0

linux-rpi4-mainline 5.14.9-1
linux-rpi4-mainline-headers 5.14.9-1
linux-rpi4-rc 5.15.rc3-1
linux-rpi4-rc-headers 5.15.rc3-1
6 Likes

does bold type replace thin?

Do not know what you mean. Bold type is the desired values.

fkms:

root=PARTUUID=#########-02 rw rootwait console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 usbhid.mousepoll=8 snd-bcm2835.enable_compat_alsa=1 snd_bcm2835.enable_headphones=1 audit=0

config.txt:

#gpu_mem=whatever
dtoverlay=vc4-fkms-v3d

kms:

root=PARTUUID=#########-02 rw rootwait console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 usbhid.mousepoll=8 snd-bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_headphones=1 audit=0

config.txt:

#gpu_mem=whatever
dtoverlay=vc4-kms-v3d

Note:

My cmdline.txt will be a little different as I disabled the bootsplash so I can see the messages with plymouth and removal of quiet and I think splash. console=tty1 could be different also. I just want to see what is going on with my system instead of looking at an arrow go in circles.

The argument snd_bcm2835.enable_headphones=1 is in both scenarios and will not change but snd-bcm2835.enable_compat_alsa=value will. kms uses VC4-hdmi for sound.

kms soundcards:

[ray@pi4 ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

fkms soundcards:

[ray@pi4 ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 3/3
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
card 2: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1

With the 5.15-rc3 kernel + uefi, kms locks up for me, fkms seems to run fine. Everything else seems to be working.

Edit: kms with bcm2835.enable_compat_alsa=0

Thanks for testing. kms does not lock up here with xfce and regular image. Seems like a couple of days ago there was an issue locking up with the older kernel using uefi, kms and turning off compositing fixed it.

Ah, yes. Disabling kwin’s compositor seems to resolve the issue. I was getting those “page flip” errors and gpu timeouts. Which is interesting, as that was the issue I was having with kms and wayland.

Edit: I switched to rpi firmware and experience the same behavior.

1 Like

Thanks for updating rpi4 kernel !
I haven’t touch/change my cmdline or my config.txt but for now it seems to work.
I have a small issue/question about entropy: it seems very low (around 700 at boot when it used to be at 2000 before) is it normal ?

Edit: I use mainline

Edit2: I think I’ve got the suspect

$ systemctl status haveged
â—‹ haveged.service - Entropy Daemon based on the HAVEGE algorithm
Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled)
Active: inactive (dead)
Condition: start condition failed at Tue 2021-08-31 15:11:18 CEST; 1 month 1 day ago
└─ ConditionKernelVersion=<5.6 was not met
Docs: man:haveged(8)
haveged - a simple entropy daemon

Strange I hadn’t seen it before today but it looks older than this update.

Edit3: If I’m not wrong, I have to wait for the 1.9.15-1 haveged version which is in the pipeline. https://github.com/archlinux/svntogit-packages/commits/packages/haveged/trunk

Seems to be working here:

[ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail
2044
[ray@pi4 ~]$ 
[ray@pi4 ~]$ systemctl status haveged
â—Ź haveged.service - Entropy Daemon based on the HAVEGE algorithm
     Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled)
     Active: active (running) since Tue 2021-08-31 08:11:18 CDT; 1 month 1 day ago
       Docs: man:haveged(8)
             http://www.issihosts.com/haveged/
   Main PID: 154 (haveged)
      Tasks: 1 (limit: 8982)
        CPU: 1.863s
     CGroup: /system.slice/haveged.service
             └─154 /usr/bin/haveged -w 1024 -v 1 --Foreground

Notice: journal has been rotated since unit was started, output may be incomplete.
[ray@pi4 ~]$  
[ray@pi4 ~]$ uname -a
Linux pi4 5.15.0-rc3-1-MANJARO-ARM #1 SMP PREEMPT Fri Oct 1 11:33:31 CDT 2021 aarch64 GNU/Linux
[ray@pi4 ~]$  
[ray@pi4 ~]$ pacman -Ss haveged
extra/haveged 1.9.14-1 [installed]
    Entropy harvesting daemon using CPU timings

you don’t have 1.9.14-2.

They introduce some kernel condition in this version (due to x86 discussions) but remove then in the 1.9.15-1 (which is updated for x86 but not for arm).

I just built 1.9.15-1 and it also gives the error. The problem is the kernel version check is not working that they added. Remove the line ConditionKernelVersion=<5.6 from /usr/lib/systemd/system/haveged.service

[ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail
472
[ray@pi4 ~]$ systemctl status haveged
â—‹ haveged.service - Entropy Daemon based on the HAVEGE algorithm
     Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled)
     Active: inactive (dead)
  Condition: start condition failed at Tue 2021-08-31 08:11:20 CDT; 1 month 1 day ago
             └─ ConditionKernelVersion=<5.6 was not met
       Docs: man:haveged(8)
             http://www.issihosts.com/haveged/
[ray@pi4 ~]$  
[ray@pi4 ~]$ pacman -Ss haveged
extra/haveged 1.9.14-1 [installed: 1.9.15-1]
    Entropy harvesting daemon using CPU timings

After removal of the line:

[ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail
2459
[ray@pi4 ~]$ systemctl status haveged
â—Ź haveged.service - Entropy Daemon based on the HAVEGE algorithm
     Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled)
     Active: active (running) since Tue 2021-08-31 08:11:18 CDT; 1 month 1 day ago
       Docs: man:haveged(8)
             http://www.issihosts.com/haveged/
   Main PID: 153 (haveged)
      Tasks: 1 (limit: 8982)
        CPU: 418ms
     CGroup: /system.slice/haveged.service
             └─153 /usr/bin/haveged -w 1024 -v 1 --Foreground

Notice: journal has been rotated since unit was started, output may be incomplete.
[ray@pi4 ~]$ pacman -Ss haveged
extra/haveged 1.9.14-1 [installed: 1.9.15-1]
    Entropy harvesting daemon using CPU timings

ConditionKernelVersion<=5.6 is the proper test, this works.

Edit: At least I think it is what was intended. :slight_smile:
Otherwise I believe the comparison is based on “=” with “<” as part of the version string.

Nope, I was incorrect.

It was intended for the x86 part https://gitlab.archlinux.org/archlinux/arch-boxes/-/merge_requests/167

they were supposed to remove the patch for the haveged.service… the one which introduces the kernel condition. Maybe I didn’t see correctly.

The haveged.service failed on my x86 with the kernel check but on it the available entropy is much higher than with the pi4 when the service fails.

[ray@ray-pc ~]$ cat /proc/sys/kernel/random/entropy_avail
3578

472 available entropy when the .service fails on the pi seems to be too low to me but I do not know at the moment what is recommended.

I know it’s too low and that’s why I asked at my first post.
It is not related to your new kernel release finally.
I have opened a request for updating this package on another post because I thought that this kernel condition was removed in the new package version.
Maybe we can merge that discussion to this post https://forum.manjaro.org/t/havaged-1-9-15-1/84957 ?

On hackaday post it says it needs to be some where around 3000 with the pi.

It vaguely has to do with the kernel. It is appearing that kernel 5.6 and greater the kernel provides the entropy but it looks like to me it is not doing much for the arm side.

RC kernel, kms with bold type setup can not logon plasma, fkms work.

I do not use plasma but all modes work here on XFCE.

Use fkms to boot into plasma, change config.txt to kms and then disable the compositor at startup and reboot.

its kwin & wayland issue, should we have kwin-git in testing?