P.S. Should have added: This is only a problem with the stock kernel. The Pi-fork still has wifi fine after running the os-initrd-mgr.

Thanks for the report. It's fixed in the latest batch of updates.
I doubt there are any gains to using -S with the RPi fork because it's small enough anyway and a good deal of the required modules are compiled in.

I make the OS for the Hardware Models that interest me and that are well supported upstream.
Others are welcome to submit changes to make new Hardware Models work or improve support for existing.

Yes. Most if not all of it will be related to the mainline Linux Kernel - especially if stuff works with the RPi Kernel fork.
There's nothing I can do about it apart from sit back, relax and wait until the changes appear in the mainline Kernel.

Cheers, Stuart!

Speaking of upstream, have you seen this: https://www.phoronix.com/news/Linux-...lat-Image-Tree

The Slackware Kernel is generic, so the Device Tree needs to remain separate as it is now.
When Device Tree first appeared and the Boot Loaders didn't support it, you had to append it to the Kernel.

Hello

Can I confirm that the RPi400 works by following the RPi 4 install guide please? I'm planning on adding RPi5 support later this year (I think the marketing in all the Linux mags I see in the news agent has won me over), so I'm thinking of making this a generic RPi installation guide.

Basically, yes. There are a couple of caveats, but nothing that should cause problems to someone reasonably experienced. They may apply to the Pi-4 as well. I don't know, as my Pi-4 is running OpenMediaVault as a NAS server, and I don't want to mess with it!

Things to watch out for:

1) It doesn't play nicely with the stock kernel, due to graphics issues. You are OK as long as you stick to a maximum screen resolution of 1920x1080, though KDE and XFCE are both somewhat clunky. Forget 4K! It is possible to force the frame-buffer (via config.txt) and KDE/XFCE (via xrandr) into 1920x1080 if you have a 4K monitor. Haven't figured out KMS yet! (used during the boot process) It is OK as a CLI environment. Its only the GUIs that are affected. (So you are OK to do a basic install, and then upgrade to the Pi-fork if you need the GUIs)

2) You will still need an in-line power switch with the stock kernel, as it doesn't fully shut down. (CPU shuts down, but not GPU or any peripherals connected to the GPIO connector.) Also you can't restart it from the software switch once it is in this semi-shutdown state. Only removing the power works.

3) The Pi-kernel fork works well, but can cause peculiarities when used with 4K monitors. Mine suddenly stopped displaying any output at all, and I had no way of telling if it was booting or not. Temporarily connecting it to a native 1920x1080 monitor restored the output, and after that it worked perfectly on the 4K monitor! And no, I can't explain that either! It is a very cheap monitor, which may or may not be relevant! The Pi-fork does shutdown correctly, and can be restarted from the software switch.

4) The last time I tried, I couldn't do a totally default install onto an SSD. It always wanted the boot folders to be on an SD card. However, doing a full install onto an SD card, and then cloning that to the SSD worked like a charm. I remember mentioning this some time ago. IIRC it was something to do with the installer, which was hard programmed to install the boot stuff onto SD, rather than whatever device it was running from.

Other than that, I can't think of anything else at the moment. If I do, I will get back to you.

Hope this helps! Any queries, you know where to find me! ;)

P.S. The stock kernel doesn't seem to have the module for the CXD2880 DTV chip, used by the "official" Pi-HAT TV tuner. The Pi-fork kernel does have it, and it works well.

--
Pete

Yes, I followed those instructions, and apart from the minor resolution problem during installation, it installed and works perfectly. It's installed to a cheap (£15 approx.) Yucun 60 GB SSD, connected via a USB3 to SATA cable. I've only used the stock kernel, with updates. No problems, whatsoever.

Hi guys, thanks for the responses. I've updated the install guide to link to this thread re. the RPi400.

Something strange has happened. Recently upgraded my monitor to a 15.6" 1920x1080 model (changed in system settings to 1600x900). XFCE is still OK, but Plasma X11 is no longer usable, applications flicker on and off, Konsole full of zig-zag lines, a real mess. But Plasma full Wayland works perfectly - so far, touch wood.
Again, it's not a Slackware problem. It's hardware related, and can be sorted out by trying different options.

The Pi kernel fork has better support for the Pi's graphics stack. I know Stuart hates it ;) but the Pi does run much better on it.

Since I followed your lead and ran it on a lower resolution monitor (1920x1080 instead of 4K), I haven't had any more issues. I'm absolutely baffled as to what broke the graphics to the extent I couldn't even see any initial boot messages. And why it subsequently worked fine when reconnected to the 4K is yet another head-scratcher!

The Pi does indeed work in mysterious ways!

:)

--
Pete

I am experiencing the same issues when my Lenovo ThinkPad X13s (arm64 Snapdragon SoC) is logged into an X11 session. The same thing with my HoneyComb LX2k (arm64 Freescale LX2160A SoM). Full "Plasma Wayland" sessions work fine on both those systems.

I see small amounts of screen tearing. Specifically in the Gimp. I'm not sure what causes it though- it could be mesa, firmware, drivers, or some combination.

pchristy, I did see your PM. I think my response will be helpful for anyone else following this thread too. It is related to recovery options when things break.

You mentioned broken wifi after running "os-initrd-mgr -S". Keep a good known set of the kernel packages handy on your Pi 400. The os-initrd-mgr can help you fix missing wifi firmware by running:

It will allow you to crack open the initrd and take a look at whats going on more easily other than rebooting with fingers crossed.

Open a second shell on your system and then "chroot" to enter your initrd environment. Add or remove kernel modules , firmware, kernels:
Useful directories: load_kernel_modules.scr, lib/firmware, lib/modules, and tools/

Keeping a known working copy of your initrd handy is important before making changes. Then you can share with us a bit more information. For example, missing firmware or kernel modules. Or the kernel module loader needs another driver (load_kernel_modules.scr directory).

You can use explodepkg to replace your broken lib/modules/ and lib/firmware/ within the chroot environment.

Within the chrooted environment you need to make sure you also run:

Go back to the first terminal after your finish. Press enter. This same process can be useful if you boot your Pi 4/400 using the installer and chroot into your installed system. From there the above steps can be completed. Stuart mentioned in an episode of the Slackware arm podcast that I like to leave the installer in place for later during a fresh installation. I do this because the kernel, modules, and headers are all in sync in the event I need to chroot into my system from the installer to repair/change something.

In the case of the WiFi not working, it was because when slimming the OS InitRD to include only the active Kernel modules, the WiFi module was included and loaded from within the OS InitRD (where as it's not present within the generic OS InitRD's, so couldn't be loaded). The module won't light up the WiFi within that environment even if the firmware's available (IIRC), and since we don't need WiFi at that stage anyway, I've blacklisted it in the OS InitRD's modprobe.conf. This way it'll load once the OS Proper boots and works correctly.
I black listed it for the rk3399 as well since it uses the same WiFi hardware.

Thanks for that, Brent, and I'll keep a copy of that in my Pi-docs folder on my NAS! I know you guided me through some of that a while back, when I was having another issue.

And yes, the Wifi issue was os-initrd-mgr not picking up something necessary for the Pi, which Stuart has now fixed.

As I've said higher up this thread, the stock kernel does work, with some limitations, but everything does run much better with the Pi-fork. We can only hope that as time progresses more Pi related stuff finds its way into the mainstream kernel.

On a slightly different topic, I'm still scratching my head over why Librelec/Kodi is the only distro that seems able to play 4K video smoothly. I'm beginning to suspect that its not to do with 4K per se, but more likely X265 decoding. The Pi is supposed to have hardware decoding for X265, but I'm not sure how to access it. I've read somewhere that /dev/video19 is the device needed, but I haven't discovered how you force VLC or MPV to use that yet. I think X264 is pure software, its only X265 that has hardware decoding (from what I've read), so converting an X265 file to X264 won't help.

If I keep scratching around long enough, I'll find the answer, I'm sure. At the moment I just feel like one of the infinite number of monkeys trying to write Shakespeare....! :)

--
Pete