Slackware - ARM This forum is for the discussion of Slackware ARM. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
09-20-2022, 04:39 AM
|
#1
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Rep: 
|
20th Sept updates - Pi 400 no longer boots
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
Code:
i2c i2c-1: new device: Instantiated device ds1307 at 0x68
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.
|
|
|
09-20-2022, 06:45 AM
|
#2
|
Member
Registered: Jun 2007
Location: Australia
Distribution: Slackware
Posts: 81
Rep:
|
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.
|
09-20-2022, 07:17 AM
|
#3
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
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!
|
|
|
09-20-2022, 07:28 AM
|
#4
|
Member
Registered: Jun 2007
Location: Australia
Distribution: Slackware
Posts: 81
Rep:
|
Quote:
Originally Posted by pchristy
Does yours shut down OK with the SaRPI kernel?
|
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.
|
|
|
09-20-2022, 07:40 AM
|
#5
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
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...
|
|
|
09-20-2022, 12:22 PM
|
#6
|
Slackware Contributor
Registered: Apr 2008
Distribution: Slackware
Posts: 1,618
|
Quote:
Originally Posted by pchristy
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?
|
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!
|
|
|
09-20-2022, 03:01 PM
|
#7
|
Slackware Contributor
Registered: May 2015
Distribution: Slackware
Posts: 1,926
|
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:
Code:
vim /boot/extlinux/extlinux.conf
add to the bottom of the SLKOS section APPEND:
Code:
APPEND earlyprintk rootfstype=ext4 root=LABEL=SLKroot slkpbs
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:
Code:
modprobe -v sdhci-iproc
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:
Code:
vim /boot/local/load_kernel_modules.post
add:
Code:
modprobe -v sdhci-iproc
run:
Reset your Pi400 then report back here with your results. This is where I ran into trouble on my Pi 4.
|
|
|
09-20-2022, 03:33 PM
|
#8
|
Slackware Contributor
Registered: Apr 2008
Distribution: Slackware
Posts: 1,618
|
Quote:
Originally Posted by gsl
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.
|
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.
|
|
|
09-20-2022, 06:43 PM
|
#9
|
Member
Registered: Jan 2004
Location: British Columbia
Distribution: Slackware64-current, aarch64
Posts: 232
Rep: 
|
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.
|
|
|
09-20-2022, 08:16 PM
|
#10
|
Member
Registered: Jun 2007
Location: Australia
Distribution: Slackware
Posts: 81
Rep:
|
Quote:
Originally Posted by drmozes
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.
|
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:
Code:
[ 28.823489] sdhci-iproc fe300000.mmc: allocated mmc-pwrseq
[ 28.869202] mmc1: SDHCI controller on fe300000.mmc [fe300000.mmc] using PIO
[ 28.881873] mmc0: SDHCI controller on fe340000.mmc [fe340000.mmc] using ADMA
[ 28.914747] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[ 28.963805] mmc1: new high speed SDIO card at address 0001
[ 28.973392] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
[ 29.060218] irq 38: nobody cared (try booting with the "irqpoll" option)
[ 29.060239] CPU: 0 PID: 473 Comm: udevd Not tainted 5.19.10-armv8 #1
[ 29.060247] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 29.060251] Call trace:
[ 29.060253] dump_backtrace.part.0+0xc4/0xd0
... more stack trace stuff ...
[ 29.060420] Disabling IRQ #38
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.
|
|
|
09-20-2022, 11:49 PM
|
#11
|
Member
Registered: Jun 2007
Location: Australia
Distribution: Slackware
Posts: 81
Rep:
|
Quote:
Originally Posted by gsl
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 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.
|
|
|
09-21-2022, 04:11 AM
|
#12
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
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
Code:
Kernel starting ...
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
|
|
|
09-21-2022, 04:36 AM
|
#13
|
SARPi Maintainer
Registered: Nov 2012
Distribution: Slackware ARM, AArch64
Posts: 1,067
|
Quote:
Originally Posted by drmozes
If you want the RPi Kernel packages that are compatible, you can build your own using the HOWTO.
|
I could not agree more.
Quote:
Originally Posted by gsl
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.
|
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. 
Last edited by Exaga; 09-21-2022 at 04:37 AM.
Reason: mango
|
|
|
09-21-2022, 06:04 AM
|
#14
|
Slackware Contributor
Registered: Apr 2008
Distribution: Slackware
Posts: 1,618
|
Quote:
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.
|
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 ;-)
Last edited by drmozes; 09-21-2022 at 06:41 AM.
|
|
|
09-21-2022, 07:35 AM
|
#15
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
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
|
|
|
All times are GMT -5. The time now is 10:46 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|