Hello

To bridge the the bug fixes and feature disparity gap between the official Linux Kernel and the Raspberry Pi's fork, Slackware packages are now available.

I've had the new Kernel packages in testing here for the last couple of weeks whilst I ironed out the transition/rollback process, and the RPi works great. Hopefully these packages won't be required in the future, as the fixes/updates are merged upstream.

Follow this guide to transition to them.

There are some technical limitations, so read the caveats first.

The serial port stuff can probably be fixed easily: if you figure it out, please report back to this thread and I'll update the document.

If you want to build your own packages from the RPi Kernel fork, you can do that too!
At the moment the build tool uses the default RPi Kernel config, but I can easily update the tool to handle building with a custom config (i.e. you maintain your own Kernel .config with the options you want, and rebuild using the tool) if there's demand.

Enjoy!
S.

I haven’t looked at this yet, but it sounds like I could use this to build a Asahi Linux kernel in Slackware. I’ll have to take a look when I have some time in a few days and see what I can get cooking since I’ve avoided the asahi kernel building thus far and just use their official arch-based kernel. Would be nice to have native built packages since it’s not all upstreamed yet.

Downloaded and installed today, and it is a huge improvement over the stock kernel! KDE now works as expected, as does SDDM. Xfce now also works as expected. It worked sort of on the stock kernel, but was very buggy (panels kept disappearing). Also the Pi 400 now shuts down properly. Previously the processor shut down, but the gpu and any USB or GPIO devices were still powered, and it couldn't be restarted without removing the power.

Initially the graphics were still a but clunky, but I've turned off the compositor in KDE and everything now runs much smoother. Video play back at any sort of HD level was clunky until I increased the gpu memory to 128MB. I might try 256, as I recall reading somewhere that this is necessary for 4K, though I think there are other factors at work here as well! I can play 1080 OK, and watch HD TV off air without too much stress on the processor, though at present 4K wont play at all (VLC and MPV). The warnings about the machine not being fast enough for 4K have now disappeared when booting, so clearly the graphics driver is much improved over the stock kernel, but still not up to Libreelec / Kodi levels.

Is it still necessary / advisable to repack the initrd with the PiFork kernel (os-initrd-mgr)? I didn't see any mention of this in the documentation, but might have missed it.

Yes, this is a very worthwhile upgrade. I think I still have some tweaks to apply, but already it is very close to the performance I get on sarpi and slarm64. A bit more fine tuning will hopefully get it to the same level (I've had plenty of time to experiment on the others!).

Many thanks for your hard work on this!

--
Pete

os-initrd-mgr is executed from the 'a/kernel' package's post installation script, so you don't need to do anything manually apart from use upgradepkg, as described in the doc.

Thanks for the reply, Stuart! I've written a small bash script which does the kernel upgrades for me when required, using upgradepkg, so I should be good to go!

I've been doing something similar for years with Slackware x86_64 and more recently slarm64.

Cheers,

--
Pete

Good, glad to see it works.

I just discovered this in the RPi Kernel fork config:
No wonder it doesn't work with ttyS0.

I will play around with the serial setting soon once I upgrade to the latest RPi Kernel fork, as I'd quite like to have the serial console working as it does with the proper Kernel.

Is your shell script re-usable for the masses? I can include it in the docs.

Its very basic, and is tailored to my individual setup, but could easily be "tweaked" for others.

I have a local repository on a NAS (Raspberry Pi4b running OpenMediaVault) on which I keep a local copy of all the systems I use - mostly x86-64, as I have quite a few machines running Slackware-current, and doing it this way, I only have to download any updates once, which reduces the load on SlackwareUK! Its not so important, or as complex, for my Pi400 so I've never bothered to post it anywhere. But if you're interested, here it is (automatic kernel updates are blacklisted in slackpkg on all my systems):
The x86-64 version is more complex as I always keep the existing kernel as a "spare" kernel when upgrading, just in case , so some components need installpkg rather than upgradepkg. Also, not all the components are in the same directories on x86_64.

Being lazy, I just copied and simplified the x86_64 version for the Pi.

As I said, not complicated, but it saves me some typing!

I also use a variation of it - but using slackpkg+ - for doing non-kernel upgrades:

I'm not going to pretend its anything clever - just convenient! And I'm lazy, and not a very good typist!

Feel free to use it as you see fit, if you think its worth it.

--
Pete

P.S. One other thing while I think about it. Have you had a look at the Libreelec kernel fork? I believe it is based on the Raspberry fork, but they seem to have thoroughly cracked the graphics problem. Not sure how, but Libreelec / Kodi is the only system I've found that plays 4K video without issue on the Pi400! I think they are still only on kernel 5.10, but I've read that they are working on 6 for their next release. I've had a look there, but its all a bit above my pay-grade...!



--
Pete

1 members found this post helpful.

I don't look at Kernel forks. The Rpi is an exception, but the only good thing to come from it is that the work I've done can be used for other vendors whose support hasn't yet been merged upstream.
You can try building your own Kernel using the document.

I was thinking you were comparing the current running Kernel with what's available or something like that :-)
I might write such a script if I'm bored on a call some time.

Btw you don't need to run ldconfig after running upgradepkg because it's done as part of the package installation process, and at boot; plus the Kernel packages contain no shared libraries so nothing changed.

Thanks for the comments, Stuart! My kernel update script was a modified version of my generic update script. I wasn't sure if ldconfig was necessary or not, but its quick and does no harm, so I left it in. Did I mention that I'm lazy?

Yes, I understand that there's a lot of forks out there, and I can't expect you (or me!) to keep track. I'm just curious to know how Libreelec seem to have cracked the graphics issue the even the Pi developers don't seem to have fully managed! Weird!

Cheers,

--
Pete

I haven't noticed anyone else reporting a solution for this serial console issue with the RPi fork kernel on an RPi4 but I've got it working (mostly) for me with the kernel_armv8-6.6.22-aarch64-1_rpi kernel. My /boot/extlinux/extlinux.conf APPEND line is:

I then also have to change /etc/inittab to use ttyS0 instead of ttyS1 for the 's0' serial line:

The critical bit seems to be the "8250.nr_uarts=1" parameter. Without it, I don't get any /dev/ttyS* devices. If I set it to 2, I get ttyS0 and ttyS1. Looking at /boot/config, the kernel is configured with "CONFIG_SERIAL_8250_NR_UARTS=5" so I don't know why it needs to be passed as a kernel parameter.

The serial console behaviour isn't quite the same as using the proper aarch64 kernel: you get the kernel boot messages but don't see the services being started so there is a pause before the login prompt appears.

Geoff.

1 members found this post helpful.

Thanks for the info, Geoff! I'll have a look at this over the week-end...

--
Pete