Just updated my Pi 400 - interested to see the latest graphics driver updates - but it no longer boots.

It gets to 15 secs in and reports Then there is a 15 second wait until 31.7 seconds where it reports I think the i2c reference is to my DVT HAT and probably not relevant other than as a guide to where in the boot process we are. The second report suggests to me (and I know I'm probably wrong!) that it is cutting the power to the SD card - which would certainly explain why it hangs at that point!

The only thing it responds to from here is ctl-alt-delete, which causes it to reboot.

It was running fine (and up to date) until the latest upgrade.

I had the same thing. All my partitions are on the SD card. It looks like the mmcblk device doesn't show up with the stock 5.19 kernel. I tried booting the latest installer which starts up fine but once booted the mmcblk devices aren't available.

I've done a fresh install using the SaRPi current-armv8 packages, which uses the RPi 5.19.9 kernel, and it works fine.

Geoff.

1 members found this post helpful.

Yes, I know there was an issue with the stock 5.19 kernel, but when the changelog said that it booted OK on a RasPi 4, I assumed it had been fixed! Silly me! Perhaps the developers weren't booting from an sd card?

Does yours shut down OK with the SaRPI kernel? Mine shuts down properly in everything except Slackwareaarch64. Here it gets as far as "System Halted", but is still powered - the lights are on and the graphics are still running. All the other systems I run on it (PiOS, Libreelec-Kodi and slarm64) all shutdown correctly.

Grrr!

The lights stay on after the system is halted.

I made a brief attempt to revive the broken current system by manually installing the SaRPi kernel and modules but there wasn't anything worth preserving so I just did a fresh install. First time I've used SaRPi's current-armv8 packages for the RPi4.

Geoff.

Thanks for the info! I might try the manual install, rather than a full one - which seems to take forever, not to mention re-configuring everything the way I like it! I've got a busy few days ahead, but hopefully I'll get chance to dig into it within a week...

It works on the Raspberry Pi 4, but I don't have a 400.
If you have the Rpi connected to a serial console, what you could do is edit your /boot/extlinux/extlinux.conf and add 'slkpbs' to the Kernel command line.
This will drop you into the pre-boot shell where you can investigate.
Exit stage 1 (just quit the shell as usual), and in stage 2 do modprobe sdhci-iproc
This module was removed from the bcm2711 Kernel module loader because it crashed and took the SD subsystem with it. However, perhaps it's required (and maybe works) for the Rpi4. If it works, the module can probably be conditionally loaded on the rpi400.

I really hope the RPi people find themselves working more closely with the upstream ecosystem in which Slackware and all the other established distributions exists. If they did that, their hardware would work better in Linux, I guarantee it.
If you figure it out, let me know and let's get it fixed!

The sdhci-iproc driver doesn't play well with the Raspberry Pi 4. I do not own a Pi400. The following may or may not fix your Pi 400:

Raspberry Pi 4 users should not need to do any of these steps.

Mount your SD card on another machine and edit this file on your sd card:
add to the bottom of the SLKOS section APPEND:

Pop the sd card back into your rpi.

Now boot your system. As Stuart stated earlier you will have a slkpbs (slackware pre-boot shell) in two spots of the boot process.

Enter:
and then in the second shell:
If your sd card comes up and you do not see a bunch of errors in the console, mount your root partition read only. Then type "exit"

If you are successful and can boot your Pi 400:

add:

run:

Reset your Pi400 then report back here with your results. This is where I ran into trouble on my Pi 4.

The SARPi Kernel packages don't follow the same file system layout nor boot in the same way: you can't switch from Slackware's packages and vice versa. If you want the RPi Kernel packages that are compatible, you can build your own using the HOWTO.
If the Slackware Installer (not the spin SARPi provides) finds the Micro SD card, there's no reason it shouldn't when booting the OS because the boot code is shared. THat's not to say it *will* work, but it was designed this way for this type of purpose.

I got the same results as described by pchristy on a Pi4 4GB, I'm reinstalling a working image and will have another whack at it.

Yeah, I'm aware of that. That's why my thought was to install them manually: mount the SD card partitions on my PC, untar the SaRPi packages, copy the kernel & modules into place, edit extlinux.conf, config.txt, cmdline.txt, /etc/fstab, /etc/inittab, whatever is necessary. But there was nothing worth preserving so I didn't bother and did a fresh SaRPi install instead. Perhaps I should have persisted for science.

I've tried the latest 5.19.10 installer on my RPi4 and was going to report it still doesn't work for me. Failed first time I booted. Tried the "slkpbs" instructions: failed. Removed "slkpbs" and rebooted: success (mmcblk1 devices show up). I've now rebooted the installer 20 times for 12 successes and 8 failures.

When booting fails, it is when loading the sdhci-iproc module. I don't have to do any pre-boot stuff for this module to load which happens just after udevd is started. In dmesg I see:

It might be worth rebooting a few times to see if a system broken by the 5.19.9 update will randomly start up.

I've got a C0 stepping RPi4 which is the same chip as the RPi400 so it might only be an issue for the newer version and not for the older B0 version.

Geoff.

I don't think this will work. I went ahead and did a (mostly) full install to the SD card, once the installer found it, which completed with no problems. On reboot after installation, it failed with the error about rootdev not being found as there were no mmc devices found.

Following Brent's instructions for using slkpbs, I loaded the sdhci-iproc module at the 2nd step (wasn't already loaded) but it would give errors every time.

I added "irqpoll" to the extlinux.conf APPEND line, as suggested by the error message, and loading the sdhci-iproc module now worked at the 2nd pre-boot step and I could boot all the way to the login prompt, though it pauses for a while when starting the bluetooth services. I added sdhci-iproc to load_kernel_modules.post, ran os-initrd-mgr, removed slkpbs from extlinux.conf and rebooted. Worked fine.

If I remove irqpoll from extlinux.conf, the system fails to boot again. I tried 5 times without success so I don't know why the installer sometimes works and sometimes doesn't. I don't know if using irqpoll is much of a solution given the kernel docs says it is "Intended to get systems with badly broken firmware running." (which seems appropriate for the RPi4).

Geoff.

First of all, thanks to everyone for your assistance here, but I'm afraid, I still have an un-bootable system!

I added "slkpbs" to the append line in extlinux.conf, but this stopped the kernel from starting at all! I got a message and then everything froze!

I removed "slkpbs" and that got it to start again, but it still hung at the "vcc-sd" stage.

I've tried Geoff's trick of appending "irqpoll" to extlinux.conf and added "sdhci-iproc" to load_kernel_modules.post, but because I can't get as far as a working command prompt, I can't run os-initrd-mgr, so not surprisingly, this still fails at the "vcc-sd" stage.

I'm not sure where to go from here!

On a more general point about Stuart's comment about the RPI folk working more closely with the upstream people, I suspect there is an issue here. When the x86 PC was first designed, it was done by IBM, who nailed the specification pretty tightly. The result is that all x86(_64) systems have a common core specification. This doesn't appear to be true in the ARM world. I doubt if it will ever be possible to have a single kernel that supports all the different support infra-structure (SOCs or whatever) out there.

I hope I'm wrong, but with Apple now producing ARM hardware, I see the hardware issue diversifying even further. It may well end up being the case that different architectures within the ARM family will require different kernel sources.

--
Pete

I could not agree more.

The RPi4 and RPi400 use different DTBs for the SoCs so there's more than just the CPU to consider. The official Slackware AArch64 U-boot boot loader works totally different to the official Raspberry Pi boot-firmware that's designed for the device, the latter of which is what SARPi uses. "Swings and roundabouts." Building your own solution (DIY style) is highly recommended. The end result is running the official Slackware AArch64 OS either way.

Incidentally, I've been running and testing kernel 5.19.x on the RPi4 for the past couple of weeks and it's been 100% rock-solid throughout. I don't know how many RPi400 owners are using SARPi shizzle but I've not had any feedback regarding problems or issues with it.

When all's said and done, whatever works and gets the job done is usually preferable.

But we already do. Linus forced the ARM maintainers to sort the mess out years ago, and it worked very well.

However, my impression is that the RPi people are first and foremost focussed on their own hardware and software as an atomic unit. The RPi hardware is a platform upon which to run their own world (maintain their own distro, their own Kernel branch), and they would rather people didn't use any community-based OSS Linux distribution. I've gathered this by reading responses from them on the forums.

Other vendors have submitted code upstream to the global community ecosystem, and as such their hardware is supported in the 'mainline' Kernel.
It's a choice that RPi makes, which in my opinion means that if you want to run any other community-based OSS Linux distro on the ARM platform and have it work properly consistently, pick a vendor other than RPi.

If they contributed directly and more readily to the upstream, they could liberate themselves of the burden of making their own Linux distro: the maintainers of the community-baed ones would make it work for them!
They could partner with Red Hat or Canonical (Ubuntu) for example, where the required changes would be upstreamed which opens the doors for all. That's how the game has always worked and is supposed to work.
Their development model restricts the choice their customers have. As a guy using the global upstream community's code base, and as a consequence I have a very poor user experience of working with the RPi.

Feel free to pass on my suggestion to the RPi folks ;-)

Well, I'm not privy to the "office politics" of kernel development, I can only surmise as an outside observer! Nor would I class myself as a programmer - my skills in that direction probably peaked with the 6502, which I actually got pretty good with! (showing my age here!)

I have a copy of PiOS, which I update occasionally just to keep an eye on things, but I can't get on with the various 'Buntus, which it seems to be based on. And it doesn't fulfill my requirements particularly well anyway!

Getting back on topic, I'm going to be away from home for a couple of days, so I won't get much chance to pursue this further for the time being. When I get back, if there have been no further developments, I may give Sarpi a go - it is how I got Slackware to run on the 400 in the first place, a while ago! Alternatively, I may just stick with Slarm64, which I have on a separate SD card and which works well, until kernel 6 is released. Hopefully 6 will resolve a lot of these issues..... (Well, we can live in hope, can't we?)



--
Pete