I wonder if someone could post an "Idiot's Guide" to upgrading the kernel in slarm64?

I do it all the time in x86_64 systems using a script I wrote:

(followed by mkinitrd and linking the various bits and bobs to the generic names, finally re-running lilo or grub-mkconfig)

However, I'm confused by the slarm64 boot system. There appear to be two parallel systems available, selected by changing the line in the /boot/config.txt file between u-boot.bin and Image.

I usually run the Image file, as in the early days with my Pi-400 I had a few issues I was trying to nail down! Either version now seems to work OK, but "Image" gives me a display of four raspberries during the initial part of boot (one for each core, like the penguins on x86_64))

In my boot partition are several files that appear to be associated with the kernel - boot process. There is a vmlinuz-5.10.9 file, which speaks for itself, along with a uInitrd-5.10.9 file and a uInitrd file, both of which appear to be identical (why?). There is also an Image file, which is much larger than the vmlinuz file, and is the file I assume is called by config.txt

My question is how are all these files related, and - in the case of the Image file - how is it created?

I would like to upgrade to the 5.12 series kernel, but my lack of familiarity with Arm64 is holding me back. I can see hints of what is happening, but don't know how to proceed.

Any advice gratefully accepted!

--
Pete

you can use the distribution's kernel to update the kernel, but the kernel may not work without additional patches.
therefore, to upgrade to a working kernel, you need to download the latter for a specific board (for example, kernel-bcm2711-5.12.4) and update via after which you can update initrd regarding files, since in raspberry pi 4 boot files are located on fat32, symlinks cannot be installed, but the creation of the structure is the same as for any other board.
vmlinuz-5.12.4 = Image <-- kernel
config-5.12.4 = config <-- kernel config
uInitrd-5.12.4 = uInitrd <-- initrd u-boot format

in config.txt an entry is left to quickly switch to boot by changing u-boot.

Thanks for the quick response! I'm still a little confused, though!

I'm currently running kernel 5.10.9. My boot partition has a uInitrd and a uInitrd-5.10.9 file, both of 9.7MiB (so probably the same. Yes, I understand about symlinks on FAT ) However, I'm booting the Image file directly (I think!) rather than use u-boot, so I assume the system must still recognise the different files name. I would have expected it to look for either initrd or initrd-5.10.9, but neither are present and none of the .txt files points to uInitrd.

On x86_64 I always keep at least one "old" kernel in case things go pear shaped! There doesn't seem to be any option for this at present - unless I can install lilo/elilo/grub? Do any of these work here?

I can also create an initrd for one kernel from another older one under x86_64. I just tell it the kernel number, and it will make an initrd regardless of whether that is the running kernel or not. Indeed, without an initrd, I can't boot the kernel under x86_64, so I have to create the initrd from "outside" the desired kernel. Is this not possible under the arm boot system?

Sorry if I'm being a bit dense here, but I'd like to be clear in my head as to what I'm doing before I start! (Always a good plan! )

I have copied my SD card to another, so I do have a fall back!

TIA,

--
Pete

when using kernel=Image
settings from cmdline.txt are used for loading, so uInitrd is not used in this case.

you can rename before updating

initrd is unnecessary in most cases, script /boot/rebuild-initrd.sh can also do for any kernel.

OK, thanks for the guidance. I'll have a go and see what happens! Probably not until tomorrow, though!

Cheers,

--
Pete

I finally got around to upgrading the kernel yesterday, following the links and instructions you kindly supplied. It all went smoothly, except that it killed WiFi!

Bluetooth still worked, but WiFi was dead. Again, it appears to be a firmware issue. I notice that you've linked from the /firmware/brcm folder to the /firmware/ap6256 folder - presumably to get around the duplication of file names that I discovered some time ago. Unfortunately, it doesn't work for the 400!

I've tried substituting the various brcmfmac43456-sdio files individually, to try and locate the culprit, but to no avail. The only thing that has worked is removing the ap6256 folder, and replacing the brcm folder with one from raspbian.

Interestingly, when it all works, I find this in dmesg:

So despite the error for the 400.txt file, it ll works fine. I don't know if this gives you a clue or not (this is using the raspbian brcm folder).

I've got backups of all three folders stored locally, so its relatively easy for me to substitute and try fault-finding, if you want me to try something different. I've run out of ideas, but you may have a suggestion or two.

In the meantime, I'm back up and running, but using the raspbian firmware files.

Cheers,

--
Pete

I've been trying to upgrade to the 5.14.1 kernel, but unfortunately, it doesn't work on the Pi-400!

I followed the instructions above, using the BCM-2711 kernel from your post here: http://dl.slarm64.org/slackware/imag...y_pi_4/kernel/

The system boots initially (I see the 4 raspberries), but then goes to a black screen and the keyboard becomes unresponsive. I've tried this twice - just in case I made an error the first time - but with the same result.

I know there are minor differences between the Pi 4 and 400, but in the past this has only meant fiddling with the firmware to get WiFi to work. This time, its a total bork!

Not sure how much help I can be here, as when the system crashes, all I can do is remove the power! I'll try putting the sd card in my desktop and see if there's anything in the logs, but I'm not holding my breath.

Cheers,

--
Pete

yes the problem is in the graphics driver. change in /boot/config.txt

That makes sense!

I'll make the changes and have another go. May have to wait until tomorrow though, as we're going out shortly!

Thanks for your prompt fix!



--
Pete

OK, that has got it running again, but has also re-introduced an issue I had forgotten about!

Despite setting the default run level to 4 in inittab, sddm no longer starts. I am dropped to a command prompt.

Not the end of the world, as logging in at the command prompt and issuing "startx" gets Plasma up and running, but clearly something is unhappy there for some reason. Any ideas?

Oh, and Wifi has stopped working again, but I think I know the fix for that (the good old firmware problem...!)

<sigh!> Every time I think I'm starting to get a handle on ARM, I find that I'm still missing a lot of knowledge...!

--
Pete

Further update: Switching graphics drivers has also had a severely detrimental effect on the graphics performance. KDE animations are now very jerky (I know, turn them off! But they were OK previously), and video playback is now jerky as well.

Thinking back I seem to recall switching to the firmware(?) driver because it improved performance. Switching back seems to confirm this.

Is there anything I can do to fix this, other than revert to the older kernels? I'm happy to work on it, but need some pointers to help with my inexperience on ARM.

--
Pete

A bit more digging...

It appears that hardware graphics acceleration is only available with vc4-fkms-v3d. The kms version does not support it.

I can check by:
and
Under kernel 5.12.4 and fkms, both these return "okay", indicating that hardware acceleration is working. Under 5.14.1 and kms (fkms doesn't work), the first returns "disabled", and the second that the location doesn't exist.

This is a showstopper for me, so for the moment, I'm back on 5.12.4.

--
Pete

1 members found this post helpful.

Just tried 5.14.7 and normal service has been resumed!

The fkms driver now works, and all is well in Pi 400 land!

Still no wifi unless I do my usual bodge with the /lib/firmware folders, deleting ap6256 and replacing brcm with the one from raspbian.

--
Pete

ok i haven't gotten to reboot yet to test.