Slackware Aarch64: Raspberry Pi 400 hardware support
Slackware - ARMThis 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.
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.
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.
They're different hardware models. They use the same SoC but have different IP cores (built-in peripherals), and different DTBs (hardware maps).
Code:
root@honey:/boot/dtb/broadcom# ls -la *rpi*4*
-rwxr-xr-x 1 root root 38069 Mar 7 16:13 bcm2711-rpi-4-b.dtb*
-rwxr-xr-x 1 root root 37989 Mar 7 16:13 bcm2711-rpi-400.dtb*
-rwxr-xr-x 1 root root 38076 Mar 7 16:13 bcm2711-rpi-cm4-io.dtb*
root@honey:/boot/dtb/broadcom#
Quote:
I'm pretty convinced its a u-boot problem.
Me too. There is a mention of the RPi400 in the U-Boot source's docs, but nothing in the DTS (the DTB source) file. You could look at the firmware that OpenBSD page links to. It's possibly similar to the HoneyComb LX2 setup, and you could use GRUB instead. Maybe offer Brent to buy a RPi4 for him and he'll make it work (actually, he'll probably not enjoy seeing another RPi, but you never know ;-) ).
I can actually make the Pi fork boot up to a point, as described in that earlier post, but it hangs after reporting that it failed to find a ds1307 RTC. I'm guessing that its the next stage that is crashing, rather than the RTC failure, but I need to stop - or try to spot on the fly - what that next stage is on the stock kernel.
The funny thing is that the earlier 6.1 series kernels you supplied worked just fine. It only started giving problems with 6.6 series. There do seem to be other files associated with u-boot (bootcode.bin? start.elf?) that may be relevant. I just wish I understood it better!
Anyway, I'll try not to distract you any further while I blunder around this. If I come up with anything useful, I'll let you know....!
The funny thing is that the earlier 6.1 series kernels you supplied worked just fine. It only started giving problems with 6.6 series. There do seem to be other files associated with u-boot (bootcode.bin? start.elf?) that may be relevant. I just wish I understood it better!
The only U-Boot object within /boot/platform/hwm_bw is slk_u-boot.bin
The rest of it is for the RPi native bootloader.
I don't see why it'd hang on detecting the i2c thing, but it may be that message was the last thing before it hung on the next step.
You could add slkrpinbl to the kernel cmdline parameters by editing the extlinux.conf file, as this will bypass the loading of the RTC module.
The only U-Boot object within /boot/platform/hwm_bw is slk_u-boot.bin
The rest of it is for the RPi native bootloader.
Thanks for the clarification!
Quote:
Originally Posted by drmozes
I don't see why it'd hang on detecting the i2c thing, but it may be that message was the last thing before it hung on the next step.
You could add slkrpinbl to the kernel cmdline parameters by editing the extlinux.conf file, as this will bypass the loading of the RTC module.
Yes, that is my thought, too. Thanks for the tip to bypass that step!
One last question: Is slk_u-boot.bin unique to the specific kernel? I recall reading somewhere that something was, and that may be it.
One last question: Is slk_u-boot.bin unique to the specific kernel? I recall reading somewhere that something was, and that may be it.
No, U-Boot is Hardware Model agnostic for the RPi- there's a single binary; but you cannot for example use the RockPro64's U-Boot binary on the RPi because they're compiled with specific hardware info.
I neglected to mention that despite my efforts, I was unable to successfully boot the Slackware kernel directly from the Raspberry Pi's native bootloader (the last effort was using Linux 5). I didn't explore the Raspberry Pi Kernel fork version. While I haven't verified, I presume that using the UEFI firmware OpenBSD refer to, this would replace the Raspberry Pi's native bootloader. This wouldn't necessarily be an issue, but it might make using DTBs more difficult if you need to do something custom (there's documentation aplenty for the RPi native BL).
This is why we opted to have the RPi native BL handle DTBs in Slackware (in addition to it not working properly when handled by U-Boot).
.
This is why we opted to have the RPi native BL handle DTBs in Slackware (in addition to it not working properly when handled by U-Boot).
Er, OK! Now I'm more confused! I thought the Pi fork *was* using u-boot? Or is it just the DTBs that are handled by the Pi BL and not the kernel itself?
Er, OK! Now I'm more confused! I thought the Pi fork *was* using u-boot? Or is it just the DTBs that are handled by the Pi BL and not the kernel itself?
The RPi kernel fork is just the standard Slackware Kernel package, but packaging a Kernel built from the RPi fork source. There are no boot loader components packaged within the Kernel packages. The a/hwm-bw-raspberrypi package contains and installs U-Boot on the RPi (although initially U-Boot is provided on the Installation SD card image that's re-purposed for the OS's /boot), and the a/grub package contains Grub.
On the RPi, the Rpi native BL loads the DTBs that are packaged in the Kernel package. On the other HWMs, U-boot or Grub handle loading the DTBs.
OK, thanks for the clarification. I've never heard of grub being used on Pis, though I use it on all my x86_64 machines. Maybe I'll have a look at that. I originally switched to grub to get around an x86_64 laptop that refused to boot using elilo, and ended up liking it to the extent I switched my other machines to it. Sounds like an area of investigation....
I decided to resurrect my RPi 400 last week, ordered a small monitor from Amazon, and while I waited for that, dded the Raspberry Pi OS and the Slackware ARM installer to microsds.
Installed Slackware ARM today, two minor problems: one with the ncurses setup being too big for the screen so I had to switch to using the TV. The other being the time. I ran ntpdate for that.
Otherwise OK. Fingers crossed. It's downloading updates at the moment. Have to see how it goes after all the upgrades.
It's OK. It survived all the upgrades (using slackpkg). I've still got the time to sort out, get ntp running.
Here's a screenshot of neofetch. It would have been but for this:
Quote:
Your submission could not be processed because a security token was missing.
):
Have to make do with a copy and paste from the terminal:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
