Moving Linux Kernel to 5.4

[dickon]

Good. I had to ask.

Of course.

Anyway, I've just spent an hour or so with two virtually identical installations, doing some truely heinous things involving symlinks, and I've tracked it down to one thing: cma=512M in cmdline.txt. Without it, the kernel allocates 256M of it, and the thing boots with a wifi interface. With it, it doesn't.

I wasn't expecting *that*.

[dickon]

So with some testing this evening, vlc under 5.4.42-v8+ will play HEVC happily, and anything software-rendered, using 'dtoverlay=vc4-fkms-v3d'. You get audio out of H.264 streams, but no video. omxplayer just barfs. With the 32b 5.4.42-v7l+, both vlc and omxplayer do H.264, and vlc does HEVC and software-rendered MPEG 2 as well. Neither does 10b yet, but that I expected. All on the raw framebuffer, over ssh, no X / Wayland / whatever involved.

So aside from the CMA problem, the -v8+ kernel still isn't feature-compatible with the -v7l+, despite being notionally the same code.

This is all with the latest firmware and latest EEPROM image, mostly because I wanted to see what the new HDMI diagnostics display looked like, and I must admit, I really like what I see, when I see it.

Good work, though. I'm always slighly amazed any of this works at all.

[PhilE]

I'm glad you worked out the problem in the end, and slightly surprised that there were no error messages indicating the failure (and that it should be different on 64-bit) - I'll give it a try.

[Janson Hong]

Hi

I have a Pi 4 and have this

https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1

The support page is here

http://www.lcdwiki.com/MHS-3.5inch_RPi_Display

Getting ready for the Pi 4 to USB Boot I did an sudo rpi-update and rebooted. On reboot the LCD display no longer works. I used the scripts supplied to change the display back to HDMI and then tried the LCD script again. No luck!

Any suggestions

JH

[dom]

I have a Pi 4 and have this
http://www.lcdwiki.com/MHS-3.5inch_RPi_Display

Best bet is to contact the seller of the display and ask them for advice.
They may have already solved this problem and if not, will want to before this becomes the default kernel.

The display ships an out-of-tree device tree overlay (/boot/overlays/mhs35.dtbo) which very likely needs updating for the new kernel.
That's not something we can fix - it needs an update from the people who made it.

[wheat0r]

Hi I have set the new dtoverlay=vc4-kms-v3d-pi4

But now Im not getting a signal on my monitor.

When I go back to the previous dtoverlay I get a signal again.

So you get a signal with vc4-fkms-v3d?
What resolution/framerate does it use when working?

I have the same issue.
Connect RPi4 with Raspbian Desktop to my TV and power it up. It shows chromatogram and Raspbian Desktop welcome splash. Then TV tells no signal.
Meanwhile, RPi runs in a weird status. Top shows load average: 1.99, 2.11, 1.10, and four top processes always are sshd/bash/rcu_preempt/avahi-daemon.
I tried both 32bit and 64bit kernel, and both vc4-kms-v3d-pi4/vc4-kms-v3d. All same results.
My TV accepts a 1080p60fps signal normally.

[kpf]

Another minor data point: I just updated a test system (RPi 3B+ V1.3, headless) and it's working. It uses NFS root/boot and PoE, but is otherwise a simple configuration.

I did have to blacklist an addition bcm2835 module since I only use the GPU for console framebuffer (and then only in emergencies), and manually update the initramfs since the rpi-update process doesn't rebuild it, but otherwise it's in good shape. I needed to move to a newer kernel in order to fix some bugs/add some features to the driver for the RV-1805 RTC, so thanks for making this available!

[dickon]

Out of interest, why do you use an initrd?

[kpf]

It's the 'modern' way of handling NFS root, as it's much more capable/flexible than the built-in NFS root functionality in the kernel. On some of my systems, I also have a network bridge built on top of eth0 *before* the NFS root is mounted, and an initramfs is required to do that.

[dickon]

Yeah, I do the same thing.

Stick

Code: Select all

#!/bin/sh
# Example frobnication boot script

PREREQ=""
prereqs()
{
     echo "$PREREQ"
}

case $1 in
prereqs)
     prereqs
     exit 0
     ;;
esac

. /scripts/functions

log_begin_msg "Starting bridge nonsense"

# Change of plan.  Mount the root filesystem, chroot modprobe bridge, umount

for x in $(cat /proc/cmdline); do
        case $x in
        nfsroot=*)
                NFSROOT="${x#nfsroot=}"
                ;;
        esac
done

mount -t nfs $NFSROOT -overs=3,nolock /root
chroot /root /sbin/modprobe bridge
umount /root

brctl addbr br0

ifconfig eth0 0.0.0.0

brctl addif br0 eth0
ifconfig br0 up
ifconfig eth0 up
ifconfig -a

log_end_msg

exit 0

in /etc/initramfs-tools/scripts/nfs-premount/bridge, set 'MODULES=list' in /etc/initramfs-tools/initramfs.conf, and empty /etc/initramfs-tools/modules, rebuild the thing, and never worry about having to rebuild it on a kernel change again. Does require the root details to be supplied on the commandline, but it wouldn't be much work to change it to use dhcp-supplied details instead if you wanted.

I use this on all my Pis these days.

[kpf]

Interesting idea... I hadn't really connected the fact that I'm not loading any modules from the initramfs, so it doesn't need to match the kernel version. Thanks!

[dickon]

It only occurred to me fairly recently, after yet another failed kernel upgrade because I'd forgotten to rebuild the damned thing. Came up with that as a workaround, and haven't looked back.

[kpf]

Another minor data point: I just updated a test system (RPi 3B+ V1.3, headless) and it's working. It uses NFS root/boot and PoE, but is otherwise a simple configuration.

I did have to blacklist an addition bcm2835 module since I only use the GPU for console framebuffer (and then only in emergencies), and manually update the initramfs since the rpi-update process doesn't rebuild it, but otherwise it's in good shape. I needed to move to a newer kernel in order to fix some bugs/add some features to the driver for the RV-1805 RTC, so thanks for making this available!

Hmm... now another issue. The kernel I installed via rpi-update was fine, but I upgraded to this kernel so I could work on some patches for an RTC driver. I cloned the raspberrypi/linux repo, checked out the rpi-5.4.y branch, and built it using the standard instructions (using bcm2709_defconfig, for an RPI 3B+).

That kernel works, but the board is very slow. BogoMIPS are 59 instead of 89 on identical boards with the 4.19 kernel. I haven't reverted to the pre-built rpi-update kernel yet, but will do that and see if the CPU speed returns to normal.

This is the tip of the branch I built:

commit 5e5024f643caa53ff59a6e00f40a9b55f7fc4e17 (upstream/rpi-5.4.y, rpi-5.4.y)
Author: Phil Elwell <phil@raspberrypi.com>
Date: Mon May 25 21:52:40 2020 +0100

[dom]

That kernel works, but the board is very slow. BogoMIPS are 59 instead of 89 on identical boards with the 4.19 kernel. I haven't reverted to the pre-built rpi-update kernel yet, but will do that and see if the CPU speed returns to normal.

BogoMIPS have no correlation to processor speed (in fact in recent kernels just depend on the timer frequency).
They may have changed the exact definition between 4.19 and 5.4. Is it actually slower in operation?

Edit: See https://en.wikipedia.org/wiki/BogoMips# ... sed_delays

[kpf]

ugh.... sorry, I'm going back to my cave now. There was a runaway process on the NFS server which was generating massive amounts of I/O, and this board's root filesystem is served from that NFS server. Oops.

[chrisy]

I updated to 5.4 and it has appeared to be working fine.

However, today I was trying to watch some Facebook live video. I hate Facebook but I've watched live streams on there many times recently on the Pi without issue.

Since the 5.4 update it works for a bit (a minute maybe), and then the screen goes blank, the speakers click and everything is dead.

I tried it several times with the same result.

edit hmm, OK, I rolled back to 4.19 and it still does it, so must be something else

[talraash]

I updated to 5.4 and it has appeared to be working fine.

However, today I was trying to watch some Facebook live video. I hate Facebook but I've watched live streams on there many times recently on the Pi without issue.

Since the 5.4 update it works for a bit (a minute maybe), and then the screen goes blank, the speakers click and everything is dead.

I tried it several times with the same result.

edit hmm, OK, I rolled back to 4.19 and it still does it, so must be something else

I have same problem on new raspberry pi os with kernel 4.19.118 and 5.4.x... All ok with old image based on kernel 4.19.97. But it's not kernel related issue. I try update all except kernel from old image and issue still there...

[Eideen]

Hi
When using "rpi-update", not all support files get installed. I think i am using the wrong apt source, to get all support files for 5.4

Code: Select all

$sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
Error: Unknown device type.
Unable to access interface: Protocol not supported
[#] ip link delete dev wg0
Cannot find device "wg0"

Code: Select all

$modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/5.4.42-v7+

[Kendek]

When using "rpi-update", not all support files get installed. I think i am using the wrong apt source, to get all support files for 5.4
...

Code: Select all

$modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/5.4.42-v7+

The WireGuard has been introduced in the Linux kernel since 5.6. So you need to upgrade your kernel (see the commit 862b0ea on branch rpi-5.6.y), or recompile with patch wireguard-linux-compat (kernel module backport for Linux 3.10 - 5.5).

[Bluestang]

So with some testing this evening, vlc under 5.4.42-v8+ will play HEVC happily, and anything software-rendered, using 'dtoverlay=vc4-fkms-v3d'. You get audio out of H.264 streams, but no video. omxplayer just barfs. With the 32b 5.4.42-v7l+, both vlc and omxplayer do H.264, and vlc does HEVC and software-rendered MPEG 2 as well. Neither does 10b yet, but that I expected. All on the raw framebuffer, over ssh, no X / Wayland / whatever involved.

So aside from the CMA problem, the -v8+ kernel still isn't feature-compatible with the -v7l+, despite being notionally the same code.

This is all with the latest firmware and latest EEPROM image, mostly because I wanted to see what the new HDMI diagnostics display looked like, and I must admit, I really like what I see, when I see it.

Good work, though. I'm always slighly amazed any of this works at all.

Is there any fix to this? I'm running a custom retropie image and I can confirm the video snaps are only playing audio and no video. The snaps are x264 encoded. I used handbrake to make an x265 encode from the source with no luck either.

If I switch the kernel to 32b they play just fine - both video and audio.

I am using the vc4-fkms-v3d driver for both 64b and 32b. The vc4-kms-v3d driver does not play any videos.

[Bluestang]

So with some testing this evening, vlc under 5.4.42-v8+ will play HEVC happily, and anything software-rendered, using 'dtoverlay=vc4-fkms-v3d'. You get audio out of H.264 streams, but no video. omxplayer just barfs. With the 32b 5.4.42-v7l+, both vlc and omxplayer do H.264, and vlc does HEVC and software-rendered MPEG 2 as well. Neither does 10b yet, but that I expected. All on the raw framebuffer, over ssh, no X / Wayland / whatever involved.

So aside from the CMA problem, the -v8+ kernel still isn't feature-compatible with the -v7l+, despite being notionally the same code.

This is all with the latest firmware and latest EEPROM image, mostly because I wanted to see what the new HDMI diagnostics display looked like, and I must admit, I really like what I see, when I see it.

Good work, though. I'm always slighly amazed any of this works at all.

I am seeing this same issue but on a custom retropie image. 32b works fine, 64b I only get audio and no video with vlc player. Any fixes for this?

[Bluestang]

So with some testing this evening, vlc under 5.4.42-v8+ will play HEVC happily, and anything software-rendered, using 'dtoverlay=vc4-fkms-v3d'. You get audio out of H.264 streams, but no video. omxplayer just barfs. With the 32b 5.4.42-v7l+, both vlc and omxplayer do H.264, and vlc does HEVC and software-rendered MPEG 2 as well. Neither does 10b yet, but that I expected. All on the raw framebuffer, over ssh, no X / Wayland / whatever involved.

So aside from the CMA problem, the -v8+ kernel still isn't feature-compatible with the -v7l+, despite being notionally the same code.

This is all with the latest firmware and latest EEPROM image, mostly because I wanted to see what the new HDMI diagnostics display looked like, and I must admit, I really like what I see, when I see it.

Good work, though. I'm always slighly amazed any of this works at all.

Update: using the 4.9.118 64bit kernel has no issues for me. 64b kernel is playing videos just fine with vlc and omxplayer.

[dg1sek]

Thanks! That did it!

Can you explain what exactly "did it" ?

I also observe the broadcom wifi driver load problem with the latest (rpi-update) kernel, log below doesn't look right, and Wi-Fi isn't coming up. Did you manage to get the WiFi to work?

I observe on my machine that /lib/firmware/brcm doesn't contain a file brcmfmac43455-sdio.raspberrypi,4-model-b.txt but only brcmfmac43455-sdio.txt .

I then manually created that file (found it via google) and the dmesg message disappeared. However I still have issues, the association with the access point only happens after quite a number of failed attempts.

Do I need to reinstall raspbian ? (I hate to do that, I prefer to understand from bottom up why it's not working and fix it.)

Code: Select all

[    5.829047] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2
[    6.053290] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    6.068379] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[    6.295636] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

[dickon]

Update: using the 4.9.118 64bit kernel has no issues for me. 64b kernel is playing videos just fine with vlc and omxplayer.

As of yesterday evening, I've had Linux pi4 5.4.44-v8+ #1320 SMP PREEMPT Wed Jun 3 16:20:05 BST 2020 aarch64 GNU/Linux with fkms playing H.264 and HEVC quite happily, albeit with the usual 1080p max. for H.264, and 8b display for HEVC. Just not as root, as detailed in the 64b kernel thread.

[dickon]

I also observe the broadcom wifi driver load problem with the latest (rpi-update) kernel, log below doesn't look right, and Wi-Fi isn't coming up. Did you manage to get the WiFi to work?

cma > 256M stopped it for me. Can you paste the output of 'dmesg | grep -i cma' and your cmdline.txt?