New Raspberry Pi Kernels & Related Packages

Darksky · 30 November 2020 18:08

Here are the new 5.4 and 5.9 kernels I pushed to the unstable branch when the mirrors sync.

As of this post the 5.10 kernel has not been upgraded in the RPi tree. Also the raspberrypi-bootloader has not been upgraded to the new 5.4 kernel. Sometimes they are a little slow upgrading raspberrypi-bootloader and sometimes they hold off to another kernel upgrade.

linux-rpi4 5.4.80-1
linux-rpi4-headers 5.4.80-1
linux-rpi4-mainline 5.9.11-1
linux-rpi4-mainline-headers 5.9.11-1

Dulbi · 30 November 2020 18:53

Reboot ok for my rpi4 4G & rpi4 8G

Dulbi · 30 November 2020 19:46

I have one question regarding the rpivid driver :
According to staging: media: Add Raspberry Pi V4L2 H265 decoder · raspberrypi/linux@a44b0f8 · GitHub

there is a h265 driver. I think that former kernels (in that branch) were already compiled with such option… but anyway, do you konw how to test it if it is used ?

Darksky · 30 November 2020 19:57

One way is to install the kodi 19 HEVC test packages I posted in the forums and try it out on kernel 5.9 and see if it is doing HW decoding. The instructions to compile the new kodi was to compile with kernel 5.10 headers so I do not know how it will do.

I know it is working with kodi in the repo on the 32 bit os.

I can not test until tonight as I have to go to town.

Darksky · 1 December 2020 00:47

One possible explanation is that the RPi kernel is leagues above upstream as they have only one mission in developing for the pi. Lots of their work is submitted upstream. The arch-arm only does upstream for their 64 bit kernel and this is where I got the PKGBUILD for Kodi 19. It is based off the work of a member of the Rpi team who is also a contributor to Kodi.

I just tested HEVC (h265) with the 5.9.11kernel and yes it will play using HW decoding with the test kodi 19 package I made.

UPDATE:

I tested the 5.4.80 kernel and it will not do h265 HW decoding.

Darksky · 1 December 2020 23:56

Just pushed the new linux-rpi4-rc 5.10.rc6 kernel/headers to the unstable branch when the mirrors sync.

linux-rpi4-rc 5.10.rc6-1
linux-rpi4-rc-headers 5.10.rc6-1

0n0w1c · 2 December 2020 01:11

The kernel upgrade went smoothly, thank you.

Dulbi · 2 December 2020 10:15

THX, we’re closed to the released I will give a try.

gofree · 3 December 2020 15:03

anybody got cec working on rpi4 64bit OS ? or can try it out ? seems cec client ( eg. TV remote ) is not working …

Darksky · 3 December 2020 16:26

I have all cec modules that arch-arm has enabled and more in the kernel.

I have no way to test but when I was building the kodi 19 packages I noticed on the arch-arm forum one guy said his cec did not work until he built and installed the armv7 libcec package. I see there is a diff in the way it is compiled:

It will not let me do bold in the next section for some reason. Just rem out the next 6 lines after the arch= line.

arch=(‘x86_64’ ‘aarch64’)

#if [[ $CARCH == ‘armv7h’ ]]; then
#CONFIG=’-DHAVE_EXYNOS_API=1’
#fi

#if [[ $CARCH == ‘aarch64’ ]]; then
#CONFIG=’-DHAVE_AOCEC_API=1’
#fi

cmake …
-DCMAKE_BUILD_TYPE=Release
-DBUILD_SHARED_LIBS=1
-DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_INSTALL_LIBDIR=/usr/lib
-DCMAKE_INSTALL_LIBDIR_NOARCH=/usr/lib
#${CONFIG}
-DHAVE_EXYNOS_API=1’

https://archlinuxarm.org/packages/armv7h/libcec

gofree · 4 December 2020 08:25

Hi

I tried to build the way you suggested, wasnt lucky but I use BT keyboard to control kodi ( kinda workaround ) and I must say the progress and performance is very good with 5.10 rc6 and kodi 19a on aarm64. I use it as a daily driver now.

Normally I have installed alarm/libcec-rpi to 6.0.2-2 · graysky2/PKGBUILDs@e359e22 · GitHub

I know graysky opened a bug on libcec - apparently something is broken and one more bug on ubuntu arm 64 bit ( dont see much activity on the project so I guess It will take a while )

github.com/Pulse-Eight/libcec

Problems using cec-client on 64-bit installation on RPi4

opened 12:49PM - 29 Nov 20 UTC

graysky2

Similar to https://github.com/Pulse-Eight/libcec/issues/540, I get failures on a… 64-bit install of Arch ARM on RPi4. Latest kernel from rpi-5.10.y branch/firmware. ``` % echo "scan" | cec-client -s -d 1 opening a connection to the CEC adapter... ERROR: [ 11] Open - vc_cec could not be initialised ERROR: [ 11] could not open a connection (try 1) ERROR: [ 1011] Open - vc_cec could not be initialised ERROR: [ 1011] could not open a connection (try 2) ERROR: [ 2012] Open - vc_cec could not be initialised ERROR: [ 2012] could not open a connection (try 3) ERROR: [ 3012] Open - vc_cec could not be initialised ERROR: [ 3012] could not open a connection (try 4) ERROR: [ 4013] Open - vc_cec could not be initialised ERROR: [ 4013] could not open a connection (try 5) ERROR: [ 5013] Open - vc_cec could not be initialised ERROR: [ 5013] could not open a connection (try 6) ERROR: [ 6014] Open - vc_cec could not be initialised ERROR: [ 6014] could not open a connection (try 7) ERROR: [ 7014] Open - vc_cec could not be initialised ERROR: [ 7014] could not open a connection (try 8) ERROR: [ 8015] Open - vc_cec could not be initialised ERROR: [ 8015] could not open a connection (try 9) ERROR: [ 9015] Open - vc_cec could not be initialised ERROR: [ 9015] could not open a connection (try 10) unable to open the device on port RPI ERROR: [ 10016] could not start CEC communications ``` This is in contrast to the 32-bit version of the Distro, armv7h, again with the latest kernel from rpi-5.10.y: ``` % echo 'scan' | cec-client -s -d 1 opening a connection to the CEC adapter... requesting CEC bus information ... CEC bus information =================== device #1: Recorder 1 address: 1.0.0.0 active source: no vendor: Pulse Eight osd string: CECTester CEC version: 1.4 power status: on language: eng currently active source: unknown (-1) ``` Note that on aarch64, I can add `hdmi_force_hotplug=1` to `/boot/config.txt` and I can get `cec-client` to connect but doing so ends in a core dump after a significant delay: ``` % echo 'scan' | cec-client -s -d 1 opening a connection to the CEC adapter... requesting CEC bus information ... CEC bus information =================== device #1: Recorder 1 address: 1.0.0.0 active source: no vendor: Pulse Eight osd string: CECTester CEC version: 1.4 power status: on language: eng currently active source: unknown (-1) [1] 288 done echo 'scan' | 289 segmentation fault (core dumped) cec-client -s -d 1 ``` Here is the info on the core dump. ``` % coredumpctl dump --output=dump PID: 346 (cec-client) UID: 1000 (facade) GID: 985 (users) Signal: 11 (SEGV) Timestamp: Sun 2020-11-29 07:31:32 EST (50s ago) Command Line: cec-client -s -d 1 Executable: /usr/bin/cec-client-6.0.2 Control Group: /user.slice/user-1000.slice/session-3.scope Unit: session-3.scope Slice: user-1000.slice Session: 3 Owner UID: 1000 (facade) Boot ID: f037c05e68814ecf8112246aa79b4c18 Machine ID: ef6412950137417eb861dad2ace857f9 Hostname: workbench Storage: /var/lib/systemd/coredump/core.cec-client.1000.f037c05e68814ecf8112246aa79b4c18.346.1606653092000000.zst Message: Process 346 (cec-client) of user 1000 dumped core. Stack trace of thread 353: #0 0x0000007f86eb1e48 _ZN3CEC26CRPiCECAdapterMessageQueue15MessageReceivedENS_10cec_opcodeENS_19cec_logical_addressES2_j (libcec.so.6 + 0x58e48) #1 0x0000007f86c45c04 cecservice_notify_func (libbcm_host.so + 0x10c04) #2 0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760) #3 0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44) #4 0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c) Stack trace of thread 351: #0 0x0000007f87434430 do_futex_wait.constprop.0 (libpthread.so.0 + 0x11430) #1 0x0000007f8743455c __new_sem_wait_slow.constprop.0 (libpthread.so.0 + 0x1155c) #2 0x0000007f86c49ff0 dispmanx_notify_func (libbcm_host.so + 0x14ff0) #3 0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760) #4 0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44) #5 0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c) Stack trace of thread 350: #0 0x0000007f86ff6b50 ioctl (libc.so.6 + 0xcbb50) #1 0x0000007f86c685f0 completion_thread (libvchiq_arm.so + 0x25f0) #2 0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760) #3 0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44) #4 0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c) Stack trace of thread 352: #0 0x0000007f87434430 do_futex_wait.constprop.0 (libpthread.so.0 + 0x11430) #1 0x0000007f8743455c __new_sem_wait_slow.constprop.0 (libpthread.so.0 + 0x1155c) #2 0x0000007f86c43648 tvservice_notify_func (libbcm_host.so + 0xe648) #3 0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760) #4 0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44) #5 0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c) Stack trace of thread 346: #0 0x0000007f8743174c pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0 + 0xe74c) #1 0x0000007f86eb0010 _ZN3CEC27CRPiCECAdapterCommunication24UnregisterLogicalAddressEv (libcec.so.6 + 0x57010) #2 0x0000007f86eb02c8 _ZN3CEC27CRPiCECAdapterCommunicationD1Ev (libcec.so.6 + 0x572c8) #3 0x0000007f86eb052c _ZN3CEC27CRPiCECAdapterCommunicationD0Ev (libcec.so.6 + 0x5752c) #4 0x0000007f86e9e990 _ZN3CEC13CCECProcessor5CloseEv (libcec.so.6 + 0x45990) #5 0x000000555c5d2f48 n/a (cec-client-6.0.2 + 0x2f48) #6 0x0000007f86f4f538 __libc_start_main (libc.so.6 + 0x24538) #7 0x000000555c5d3c98 n/a (cec-client-6.0.2 + 0x3c98) #8 0x000000555c5d3c98 n/a (cec-client-6.0.2 + 0x3c98) ``` I have a 58M coredump I can share if needed.

github.com/Pulse-Eight/libcec

ubuntu on Raspberry PI 4 [ARM64] : autodetect failed

opened 03:15PM - 18 Nov 20 UTC

mihaiav

I have Ubuntu installed on a Raspberry PI4 and CEC fails to work. The HDMI port…/TV surely supports CEC b/c it's the same HDMI port used by an Apple TV that works with the TV remote. Is this a bug or Ubuntu/Raspberry PI4 is not supported? The error is: ``` $sudo cec-client No device type given. Using 'recoding device' CEC Parser created - libCEC version 6.0.2 no serial port given. trying autodetect: FAILED ``` uname ``` Linux 5.8.0-1007-raspi \#10-Ubuntu SMP PREEMPT aarch64 aarch64 aarch64 GNU/Linux ```

Darksky · 8 December 2020 04:52

Here is the latest kernels pushed to the unstable branch when the mirrors sync. They have not upgraded the raspberrypi-bootloader to the latest kernel yet. It is still sitting on kernel 5.4.79 but they did make one little commit so I built the 2 raspberrypi-bootloader packages so it will be up to date with their tree.

linux-rpi4 5.4.81-1
linux-rpi4-headers 5.4.81-1
linux-rpi4-mainline 5.9.12-1
linux-rpi4-mainline-headers 5.9.12-1
linux-rpi4-rc 5.10.rc7-1
linux-rpi4-rc-headers 5.10.rc7-1
raspberrypi-bootloader 20201130-1
raspberrypi-bootloader-x 20201130-1

Rip2 · 8 December 2020 07:40

rc7, anyone try FULL-kms work?

Dulbi · 8 December 2020 11:47

v5.9.12-1 works fine for my rpi4 4Go and my rpi4 8 go

Jtyle6 · 8 December 2020 11:59

I’ve been using on and off a while now. It’s running ok but it’s little bit hot in the heat of Australia.

Linux ManPi 5.10.0-rc7-1-MANJARO-ARM #1 SMP PREEMPT Mon Dec 7 21:25:58 CST 2020 aarch64 GNU/Linux

21:53:48 up  4:04,  1 user,  load average: 3.02, 2.26, 0.98

0n0w1c · 8 December 2020 12:50

Yes, kms works.

Rip2 · 8 December 2020 13:00

forgot to mention, X or wayland?
im use wayland/sway, and it asked kms to load and halted.

0n0w1c · 8 December 2020 13:06

I am running Wayland on mesa-git with Plasma. I plan to switch back to mesa 20.3 this evening, I think it is in arm-unstable now. The only issue I have, is when switching over to X11, kwin’s compositor crashes on load.

BRX7 · 8 December 2020 22:49

I am also using wayland and kms wont work
i am using kernel 5.10 rc 7
Xfce lightdm
Mesa-git install

0n0w1c · 9 December 2020 01:28

Unfortunately, today’s update breaks my system. I know it is not the mesa-git package… so either the kernel and/or the bootloader update.

I rolled back the updates and rebooted which restored my system.

And I know sddm hangs before it is displayed, no errors noticed in strace… but I forgot to check the Xorg log. It is more than likely an issue with X11 not starting properly.