I noticed that also when I did a git pull on their PKGBUILD’s.
The latest linux-rpi4 kernel packages has been pushed to the unstable branch when the mirrors sync.
linux-rpi4 5.10.82-1
linux-rpi4-headers 5.10.82-1
Finally got a response to the uefi + new devicetrees issue, it is broke. At least I know it is not a configuration issue.
I received an email from the RPi folks informing me they had fixed the booting into a DE with kms/fkms I had informed them about. with kernel 5.16-rc. It seems to be working OK. I am seeing a bluetooth “Failed” lines with this I have never seen before. I do not know if this is something new the 5.16 kernel checks for or what. My BT headphones works good as always. I will mention to them when I give a response back to them in a little while.
[ray@pi4 ~]$ dmesg | grep Failed
[ 5.926637] Bluetooth: hci0: Failed to read codec capabilities (-56)
The latest linux-rpi4-rc kernel packages have been pushed to the unstable branch when the mirrors sync.
linux-rpi4-rc 5.16.rc3-1
linux-rpi4-rc-headers 5.16.rc3-1
ADDED:
I received a response back from the RPi on the “Failed” with bluetooth on the 5.16 kernel. It appears that it is now checking for codec capabilities. They backported a patch from linux-next and applied it already this mourning. I do not believe this is an issue as I think it is just checking as my bluetooth is working ok so I will not rebuild this kernel (just wait for the next upgrade for it to be pulled in) unless someone is having an issue with bluetooth.
https://github.com/raspberrypi/linux/commit/92f03c7d5bbb330fbf7865e2f42f428b3f6ba2a3
1 Like
Don’t know if it helps but there were new commits
and
They are all part of the rpi-5.16-rc3 branch
Hopefully the required fix is included in one of those commits… if not, I will likely have to start trying to modify the devicetree. Unfortunately that is not exactly my strong suit, but we do what we must.
Did you get it to work ? rpi5.16-rc4 and 5.15.6 kernels are out today with the same patches.
I don’t understand why they didn’t provide them upstream to not have to patch all the files each time…
Wait for @Darksky to release new kernels soon…
In the process of compiling all 3 kernels. Have 2 going right now. One here and one on CI.
I have been busy today. Just about everything upgraded. All 3 kernels, the 2 raspberrpi-bootloader packages and rpi-eeprom. They promoted pieeprom-2021-11-22 beta release to “stable” with rpi-eeprom.
All packages pushed to the unstable branch when the mirrors sync.
linux-rpi4 5.10.83-1
linux-rpi4-headers 5.10.83-1
linux-rpi4-mainline 5.15.6-1
linux-rpi4-mainline-headers 5.15.6-1
linux-rpi4-rc 5.16.rc4-1
linux-rpi4-rc-headers 5.16.rc4-1
raspberrypi-bootloader 20211207-1
raspberrypi-bootloader-x 20211207-1
rpi-eeprom 20211129-1
1 Like
I have not yet been able to test all of the combinations. I had some trouble with mainline + kms but that is not a surprise, likely something about the order of my config.txt file. uefi + rpi kernels still seems to still be broken, however, the linux + linux-rc kernels continue work well with the “older” .dtb. I have not yet tried with the newer .dtb.
The bootloader and eeprom update went smoothly and all seems good with them.
1 Like
After fixing a little glitch with lightdm after today’s update, I did more testing. Unfortunately, I have not yet been able to get kms working with the mainline and rc kernels. The hdmi signal dies (and the pi appears to hang) just as it is switching to lightdm.
The exact same configuration that fails, works for the linux-rpi4 kernel and kms. And the good news is, the graphical glitch with plasma seems to have been fixed. I had quit using kms due to the issue.
Edit: I would like to happily add that linux-rpi4 + kms + plasma + wayland is working very well, the hanging when the mouse pointer entered composted effects is fixed.
but, my case…linux-rpi4 + kms + plasma(kwin & kwinft) + sddm + wayland/session, not login (X11 work), does sddm matter?
I normally use lightdm, but I just tested with sddm, and it seems to work fine for me too.
The latest kernels and rpi-eeprom has been pushed to the unstable branch when the mirrors sync.
rpi-eeprom has another promotion to “stable”
linux-rpi4 5.10.85-1
linux-rpi4-headers 5.10.85-1
linux-rpi4-mainline 5.15.8-1
linux-rpi4-mainline-headers 5.15.8-1
linux-rpi4-rc 5.16.rc5-1
linux-rpi4-rc-headers 5.16.rc5-1
rpi-eeprom 20211213-1
1 Like
RPi is on a roll again today and upgraded 2 kernels that was upgraded yesterday. They are pushed to the unstable branch when the mirrors sync.
Being a FTA satellite enthusiast this commit caught my eye but have not had a chance to test yet on kodi-rpi (being that is where the gpu HW decoding is.)
https://github.com/raspberrypi/linux/commit/800c49fd1f53adf66739d384402b7a90441b023b
linux-rpi4 5.10.87-1
linux-rpi4-headers 5.10.87-1
linux-rpi4-mainline 5.15.10-1
linux-rpi4-mainline headers-5.15.10-1
1 Like
5.10.87 reboot fail, how to fallback?
Are you sure it is a kernel problem. I have no issue with 5.10.87 here rebooting with kms/fkms and kodi.
Depending on if you can ssh to it or not on reverting.
ssh to it and install the previous kernel.
You can extract the previous kernel package on another computer and:
Put kernel8.img on the sdcard in the fat32 partition
Put the module directory on the sdcard on the root partition under usr/lib/modules/
ok, fallback to testing .83, thanks.
linux-rpi4 5.10.87 is working for me, both kms and fkms.
I did have an issue that occurred once with kms, trying to switch between X11 and wayland sessions, but I can not recreate it.
@Rip2 In my experience kms can be “picky” as to the order of things in config.txt. And If you use a customized file, try rearranging the config.txt a bit. I have moved to a condensed file with minimal settings for my needs.
os_prefix=rpi4/
initramfs initramfs-linux.img followkernel
arm_64bit=1
arm_boost=1
dtparam=audio=on
dtparam=sd_poll_once
dtoverlay=vc4-kms-v3d
max_framebuffers=2
disable_overscan=1
dtoverlay=i2c-rtc,ds3231
dtoverlay=argonone,hysteresis=5
dtparam=fantemp0=35,fanspeed0=10
dtparam=fantemp1=40,fanspeed1=50
dtparam=fantemp2=45,fanspeed2=100
1 Like
One thing that comes to mind looking at @0n0w1c config is there has been an on and off issue with booting when any gpu_mem= value is set and using kms/fkms. Lately I have been disabling it:
#gpu_mem=64
dtoverlay=vc4-kms-v3d,cma-512
max_framebuffers=2