Slackware Aarch64: Raspberry Pi 400 hardware support
From a previous thread where the Raspberry Pi 400 hardware support is discussed.
(https://www.linuxquestions.org/quest...ml) Quote:
If you are still feeling adventurous, the Slackware source code has a file to edit. Here is my source tree and the location of what you need to edit: Code:
/home/x/PRIVATE_slackwareaarch64-current/source/k/SlkOS-initrd-overlay/load_kernel_modules.scr/platform/aarch64 It contains the file bcm2711, which is the SoC for the Raspberry Pi 400. Assuming the slk-hwm-discover output is "Raspberry Pi 400", the following adjustments need to be made: Code:
--- bcm2711.orig 2024-01-21 04:44:51.275481398 -0700 Now you can rebuild the raspberry pi kernel fork and the bcm2711 file will be included automatically. This is the fully edited version of bcm2711. Code:
################################################################################ |
Hi Brent,
Apologies for the delayed reply. I decided to re-create the initial Slackwareaarch64-current install yet again to ensure I got a clean system to try. As I'm sure you are aware, this takes a while! Yes, slk-hwm-discover reports "Raspberry Pi 400 Rev 1.0". And yes, I have the full Slackwareaarch64-current tree, though this does not include the Pi-fork kernel, which is supplied seperately. (I have that too, but in a separate folder.) A couple of questions: The first file you have offered above looks like a patch file, and the second looks like the bcm2711 after its been patched. Is this correct? If so, that implies that I should just be able to replace the current bcm2711 with your second example from above? Looking at that file does explain one thing - I kept wondering why my system kept trying to install a ds1307 RTC, when my system has a ds3231! Now I know! Perhaps I should comment that bit out, or amend it, for tidiness. But then that also suggests that the file I have is already patched to the level described above. I'll do a diff and check. Its early evening here in the UK, so some of this will have to wait until tomorrow, now. Also, we have visitors coming tomorrow, so my time will be more restricted until Tuesday. Watch this space.... -- Pete |
One more question (and sorry if this sounds dumb!): I've applied the diff to the bc2711 file, but this is all living in the stock Slackwareaarch64 kernel tree. You say
Quote:
Cheers, -- Pete |
I am looking at the source tree that both Stuart and I work on. We haven't added support for it in the way I mentioned above. The second example is what your system needs. The Rev 1.0 is not necessary to include in the file. The script will take care of that. Just make sure to add the asterisks. All revisions of the Pi 400 should be found with those changes.
The first example is a diff. The second example should be (more or less) what is necessary to get your Pi 400 up and running with Slackware Aarch64. The kernel packages built using the RPi kernel fork scripts will include the "bcm2711" within the initial ramdisk embedded in the kernel_armv8 package. Which is why you will not see it in your boot partition. If you extract the initial ramdisk (NOT initrd-armv8.img) you can edit stuff and reboot your system after repacking it up. The "os-initrd-mgr" utility that is present in Slackware Aarch64, can be configured to unpack the initial ramdisk, to make changes within it's directory. Once you exit the script, it will repack the ramdisk. The build scripts are designed this way so that multiple hardware models can be supported with drivers compiled as modules in the kernel. That way all Stuart and I have to do for various devices is edit a text file. This lowers the RAM requirement for the installer and systems that have been installed. It is important to note: To the best of my knowledge, Slarm64 and Sarpi do not include these utilities or scripts. If they do, they likely do not make use of them. Mixing your system with slarm64 packages and sarpi kernels is a recipe for disaster- just like mixing ubuntu with debian. It's best to install Slackware Aarch64, to use the RPi kernel scripts provided by Stuart, and to build a better integrated system. If something is broken, let us know as soon as you can. In some cases it will likely be broken for Stuart and I, we just haven't noticed it yet. My honeycomb workstation can build all the kernel packages and the installer in about 2 hours or so. Stuart recently purchased a honeycomb as well, so the turn around time to fix stuff is much less. |
OK, so here's what I've tried, and the results:
1) Clean install of Slackwareaarch64 on SD card, stock kernel, init3 (command line). Use "os-initrd-mgr -M" to open the initrd. Open a second terminal (alt+F2). Use mc to copy the new bcm2711 file into the initrd, deleting the original. Check ownership and permissions of new file. Go back to the original terminal and press enter to re-pack the initrd. Reboot. Xfce now works reasonably well. KDE still crashes. All ancillaries seem to be working (wifi, sound & blutooth) or at least are present (didn't test everything). 2) Existing installation on SSD, Pi-fork kernel. (Boots, but KDE and XFCE broken) Repeat above procedure, but have to use "os-initrd-mgr -FM" to force unpacking. Reboot. Boots OK, but KDE and XFCE still broken. 3) Back to the SD card. Upgrade to Pi-fork kernel. Unpack initrd using "os-initrd-mgr -FM" (had to force, as otherwise it wouldn't unpack). Open second terminal and replace bcm2711, check ownership and permissions. Back to terminal one, press enter to repack. Reboot Nothing! Screen goes blank and computer is unresponsive. The fact that somehow I've got the SSD install to boot implies that the Pi-fork kernel may have an issue, but is basically capable of booting. I'm sure the issue that prevents booting is right at the start of the boot process. When running the stock kernel I see messages about reading extlinux.conf and unpacking the kernel and intrd. When running the Pi-fork, I don't see anything at all. Nada. Zip. Nothing. This makes it quite difficult to diagnose! I don't know if any of the above helps at all. The new bcm2711 does show an improvement with the stock kernel, but not with the Pi-fork. Cheers, -- Pete |
Did you check the serial console output while booting the Rpi kernel fork? Did you try enabling sshd and connecting in a secure shell? Is the screen off or is it just "black" without output?
This part could be wrong but I am trying to exhaust all possibilities. I've had issues with the Rpi 4 (before mine burned up) and having the boot text output to the wrong video devices. Sometimes this is indicated in the u-boot console prior to selecting the boot option menu. SSH is the easiest way to diagnose the scenario without messing with U-boot or a serial console. |
Yes, I know what you are suggesting. I tried ssh-ing into the machine, but no response. I'm not sure how to "read" the serial output (suggestions welcome!). It never gets as far as the boot option menu. Once you reboot, the machine shuts down, and never comes back up. The lights are on, indicating it has power, the monitor comes out of standby, indicating the GPU has power, but absolutely nothing else. There is no response from the keyboard. Ctl-alt-delete does nothing, neither does Fn-F10 (the power switch on the 400). Nether the Slackware logo screen, nor any of the text that accompanies it appears. It looks as if it never gets as far as even retrieving the kernel, let alone booting it.
If you can advise how to read the serial output (the 400 only has HDMI and USB ports) I will happily give it a try, but I don't think it gets that far! As an aside - which may (or may not!) offer a clue, here's what I did to get the 6.6 Pifork to boot on the SSD. This install had been running perfectly with the 6.1 PiFork kernels, but stopped after upgrading to 6.6. I did the upgrade in two stages, doing all the other packages first, rebooting to check for problems. I didn't find any, so I upgraded the kernel and everything stopped booting completely. In an attempt to get it running by any available means, I copied the contents of the SLKboot and SLKhwm_bw partitions from a freshly (stock kernel) prepared SD card. That got it to boot, although with the stock kernel wifi doesn't work, and KDE and Xfce only partly work. After messing around with it for a bit, I re-installed the PiFork 6.6 kernel, and to my amazement, it booted! Wifi works, but kde and xfce are still mostly broken. I haven't messed with it since, as its the only working 6.6 PiFork I've achieved. I haven't persuaded it to boot - or even start to boot - on an SD card at all. Now I think about it, way back when I started trying to get Slackware running on the Pi-400, I do remember running into an issue that might be relevant. I think it might have been on Slarm64, but the boot would hang just after it tried to initialise the SD card (probing for the right voltage?). It seemed as if instead of selecting the correct voltage, it was switching it off altogether. This caused an immediate stall of the boot process. This was a long time ago, so my memory is hazy. I don't think slarm64 was using u-boot at this time. Is there anything in that early part of the u-boot process that tries to detect parameters for the SD card, and set things like voltage? If so, that could be the culprit! I have to go out shortly for an hour or so, but when I get back, I'll have a trawl through the archives and see what I can find. Also, I will be away from home tomorrow, not returning until late on Friday, so I may not be able to do much more in the short term. Normal service should be restored by the week-end, though. Cheers, -- Pete |
From what I can tell here: https://www.raspberrypi.com/products...pecifications/
It looks like connecting the serial console is the same process as the other raspberry pi models. The Rpi 400 GPIO pins on the back of the keyboard, a set of 3 dupont cables, and a serial to usb adapter for another machine are what you will need. Unfortunately I cannot find the directions to do so on the raspberry pi site. So again, I reference the SA64 install docs:https://docs.slackware.com/slackware...l_uart_adapter You may need a GPIO adapter for the 400, like this one: https://thepihut.com/products/gpio-a...spberry-pi-400 Down the page a little on the same site, they show advertisements for dupont cables. Here is a site to determine your GPIO pinout configuration: https://pinout.xyz/pinout/uart I bought my serial adapter from amazon.com: https://www.amazon.com/gp/product/B075N82CDL/ I found it to be very frustrating to debug new hardware without a serial adapter. If for some reason the video driver or hdmi driver or sd card driver... do not work, you will see it on a serial console. You will know why it's missing or broken as well. |
OK, thanks for that Brent! Naturally, I don't have any of that hardware, and even if I order today, with the state of the postal service here in the UK, I'm unlikely to see anything until next week!
In the meantime, I did find that reference to the sd card having its power removed, and it was slackwareaarch64, not slarm64 as I incorrectly remembered! Indeed, you contributed to the thread! https://www.linuxquestions.org/quest...7/#post6381339 Check post #7. I've just tried some of the suggestions from there, but unfortunately it still all fails at the first hurdle. The stock kernel on an SD card hangs if I append slkpbs to the extlinux.conf file - just as it did back then. In fact, the situation now is even worse, because back then, I at least got some initial messages on the screen, so I could see where it appeared to be failing. Now I get nothing at all. It is getting late in the day here now, and there are other things I must attend to. It will be a couple of days before I can back to this (as I explained earlier). Perhaps sleeping on it for a bit might give me a flash of inspiration..... Thanks for your continued support and advice! -- Pete |
That post #7 was from 2022 and does not apply to the current status of the Aarch64 port. It was an unrelated bug and was fixed long ago.
The slkpbs boot flag is best used with a serial console adapter. It is mentioned in the installation docs, in the 2022 thread, and in this very thread that a serial adapter will save your efforts. You can of course configure the Pi 400 during installation to output all of the boot messages to an external monitor. By default Slackware Aarch64 outputs only part (if any) of the boot messages to an external screen and debugging output to the serial device. During the installation process there is a dialog window that mentions just that. See here Quote:
|
Brent: PM sent.
|
1 Attachment(s)
Seeing a new version of the Pi-fork kernel, I thought I would give it a try. No joy, exactly the same symptoms. The only thing different that I did notice was a load of missing modules when upgrading the stock kernel to the Pi-fork (screenshot attached).
Does this help? I don't recall seeing it previously. |
Hi Brent,
Sorry for the long delay in following this up, but I've had other things that required my attention that kept getting in the way! Digging through my Arduino box, I found an FTDI adapter and a crossover cable that I'd used for another project ages ago, and forgotten about! Thus armed, I set about having yet another go at getting the Pi kernel to load. All to no avail! It never even tries to boot, and there is no output at all to/from the UART - much as I expected! Here's what I tried: 1) Create a new SD card installation, update to the current status (as of the 12th March) and get it running on the stock kernel. As expected, it loads and runs, but both KDE and XFCE are virtually unuseable. CLI is fine. 2) Clone the SD card, and check it out. Connect the FTDI and monitor the UART on my desktop machine, as described in the instructions. Yes, I see the same boot messages as I see on the HDMI output up until the login prompt. This proves my hardware connection is fine. 3) Upgrade to the Pi kernel fork and reboot. 4) Nothing on either the UART or HDMI. It doesn't even attempt to boot anything. No error messages, nothing at all - just blank screens. One thing I did notice is that following the recommended installation procedure, you end up with two bootable partitions - SLKboot and SLKroot. I'm sure this isn't right, and other Pi systems only have the boot partition marked bootable. Although it works fine with the stock kernel, I did wonder if it was confusing the Pi kernel, so I tried unsetting the boot flag on the SLKroot partition. The stock kernel still booted fine, but the Pi fork is as dead as ever, so its not that. I'm now even more stumped than I was previously! Fortunately the slaarch64 packages work perfectly on top of the SARPI kernels, so that's what I'm currently using. I'm going to send Stuart a copy of this as well, as I know he doesn't visit the forum often any more. I don't think there's anything more I can do from my end. It appears that the Pi fork is just completely broken - at least as far as the Pi-400 is concerned. I would be surprised if its any different on a 4, as the differences seem minor, but if anyone has tried it and got it to work, I would like to hear. Cheers, -- Pete |
Quote:
The picture of the modprobe errors provided above is also described in that document. There should be a display on the HDMI though, at least on the RPi4. Quote:
Quote:
Quote:
Neither Brent nor I have any RPi400, so I suggest you use SARPi - it's great for unsupported RPi models. |
Hi Stuart, and thanks for the response!
I appreciate that you don't have a 400, but I would have expected anything that works on a 4 to work on a 400. What I find puzzling is that it never even gets out of the gate! I'm pretty convinced its a u-boot problem. None of the "working" installs I've tried use it, and it boots just fine. I did try to modify config.txt to by-pass u-boot with partial success (https://www.linuxquestions.org/quest...0/), but never got any further. Maybe I need to revisit that. What I really don't understand is why everything grinds to a halt instantly, without a single message appearing anywhere. Whatever it is, it must be happening right at the very start of the boot process. -- Pete |
All times are GMT -5. The time now is 07:37 AM. |