I've been a bit tied up on other unrelated things since Slackwareaarch64 got released, so I've only just got around to trying this. First, I suspect I'm in a minority of 1 when it comes to the Pi-400, and secondly, I don't have that much experience with arm architecture, so please forgive the dumb questions!

I am fairly experienced with Slackware x86_64, and have had my Pi-400 running slarm64 well for a while now. However, I'm finding the install instructions difficult to follow for the 400.

The instructions for the Pi 4 (closest relation) all relate to using a separate SSD for the OS, with only the /boot folder on the SD card. Further, the install procedure seems to rely on 3 separate drives - the SD card with the boot/install stuff, a pendrive for the Slackware tree, and a destination drive for the OS.

Whilst this might be possible on the 400, it is very unwieldy. The ideal solution is to have the /boot, swap and OS all on the SD card. (Yes, I know SD cards don't like being constantly re-written, but its worked fine for slarm64 and from what I hear also for Raspbian)

To achieve this, I've been trying something akin to AlienBob's approach to installing Slackware x86(_64), using a pendrive which contains the bootable installer, but also the Slackware "tree" on a separate partition of the pendrive. This works really well on Intel / AMD hardware.

I managed to produce a pendrive, which booted and also contained the Slackware tree (on a separate partition). Unfortunately, it refused to recognise the blank SD card onto which I was trying to install. This maybe related to this problem:
https://www.linuxquestions.org/quest...ds-4175708544/

The next problem is that, reading from the documentation, even if I overcome that issue, the /boot partition will end up on the pendrive, not the SD card - which is where it will need to be. From the documentation, there appears to be no option for the location of the final /boot partition.

One final question: Is the SLKhwm_bw partition necessary once the installation has been completed? Or is it only used during the installation?

If push comes to shove, I can probably do a 3-disk install, and then try and get everything where I want it afterwards, but it seems to be a very long way around for something that should be relatively simple.

Maybe I'm not reading things correctly, or maybe I'm over-thinking the issue, but if anyone has any advice, I'm all ears!



Cheers,

--
Pete

I don't have a 400, only a recent 4 ...

The installation document lists the recommended method but the other choices for the source of the Slackware assets should also work. You might try using ftp/http for your install source instead of a local pen drive (assuming you have another machine to host the slackware assets via http). That would get you down to two devices instead of three. You might be able to get that down to just the sd card (assuming it shows up -- see below). You could start with copying the installer img to a sd card to boot from instead of a pen drive and then try modifying the sd card by adding, say, a swap partition and a linux partition for your root filesys. Do that after booting the installer and before you run 'setup'. The setup scripts should recognize that you have partitions after the first partition on the sd card and then skip trying to expand it. Then during setup you could select your partitions on the sd card just as you might do with installing on x86. Note that there is some hard-coding going on in the setup scripts that pertain to mmcblk devices. Of course you will need to adjust how closely you follow the install instructions to accomodate these deviations.

When the installer has booted and you are looking at the '#' prompt, try running "fdisk -l". If the /dev/mmcblk* device(s) do not appear then you can stop because your hardware is not (yet) compatible. You might be able to work around this condition by working through the process noted in the above link (I have not tried that on my incompatible RPi4).

From my (failed) attempts, it would appear that partition 1 is mounted on the /boot/<whatever-i-dont-remember-dirname> and is required. I could be wrong but that's what it looked like to me when I was thrashing around trying to get the install to work on my device.

Good luck!

I installed Slackware Aarch64 on an SD card without problems. I've been using just 64 GB SD cards on my Pi 4 with Raspian, slarm64 and Sarpi for going on two years without problems. But they don't get real heavy use. "Your Mileage May Vary".

Following the instructions and getting the initial installation assets on the SD card, I created/formatted swap and ext4 partitions on it as well. With a USB stick loaded with the Slackware installation media I went through the regular Slackware Aarch64 install process with the Pi. Works fine here.

1 members found this post helpful.

My understanding is the Pi 400, Compute Module 4 (CM4) and newer RPi 4B all use the BCM2711C0 chip, not the original B0 chip, so will all have the emmc2 bus firmware problem.

I would give the extlinux.conf fix a try (comment out the FDTDIR line), at least to see if the mmc devices show up after booting the installer.

Geoff.

4 members found this post helpful.

That did the trick! Commented it out in the installer before moving the sd card to my RPi 4 (did not replace bcm2711-rpi-4-b.dtb). Installer ran without losing the mmc device and after 'setup' was finished, commented it out again before first boot. Still a little oddness during setup (like swap partition showing up multiple times in dialog panel and in fstab) but those easily worked around. End result was a bootable device with Slackware Aarch64. I had added a swap partition and linux partition (root filesys) to the sd card before running setup and used http to get the Slackware packages. At some point I will redo with a ssd for swap and root and just use the sd card for /boot stuff. Probably will wait for an official fix before doing that...

Yes! That did it! Many thanks!

All the error messages whilst booting disappeared, and the swap and root partitions that I'd prepared on the SD card were now visible and accessible. The setup then went very smoothly, and I now have a working slackwareaarch64 installation!

Many thanks to all for you assistance - and, of course, to Stuart for his work on this!

A couple of observations (not criticisms!):

1) There is a lot of wasted space in the SLKhwm_bw and SLKboot partitions. These are 2GB and 1.7GB respectively, yet only contain 300 or 400 MB. This could be important when using smaller SD cards. Is there any reason why they are so big?

2) On the Pi400, the KDE graphics are very slow and clunky. I had the same problem on slarm64, and had to use the "dtoverlay=vc4-fkms-v3d" command in the config.txt file to get things working smoothly. On slackwareaarch64, the config.txt file contains what appear to be dire warnings against using vc4-kms drivers, but makes no mention of the vc4-fkms drivers. Any comments, anyone?

3) WiFi and bluetooth have worked "out of the box". I always had to do a bit of faffing around to get them working under slarm64, but here they "just work"!

Please do not take any of these comments as criticisms of either slacwareaarch64 or slarm64. They are just my observations of the initial differences I've found with the two systems.

Cheers,

--
Pete

Yes, it's to accommodate retention of the installer and the OS initrd and test versions of both, in addition to enabling growth (additional modules, etc.) of both in the future.
I wanted to ensure that nobody ran out of space and had the system enter a 'bad state'.

Storage is large and cheap.

Experiment with the settings. The warnings are because those drivers are experimental and came with warnings. I merely passed them down.
I still don't have my RPi4 with anything close to a usable (speedwise) X session. Fixes are welcome.

1 members found this post helpful.

Hi Stuart, and thanks for the reply!

Yes, up to a point! I'm actually using a 128GB SD card, so there is plenty of space. However, running on a smaller SD card might prove problematic! Not a big issue, though.

Agreed! Its very clunky! Strangely, its perfectly smooth on slarm64 (not trying to start a turf war here, just pointing out that it is possible on the same hardware!)

I often use the 400 as a PVR, using Kaffeine. On slarm64 I can play back videos of 1080 resolution perfectly smoothly, though all the cpu cores are running around 80%. On slackwareaarch64, I can just about play 720 (all four cores over 90%), but it won't even attempt 1080 - it just freezes! I have yet to find out how to enable the hardware decoding on any OS, which is supposed to be possible! The device even claims to be 4K capable, but I've not managed to get it to play back 4K under any OS yet!

As I said earlier, the trick on slarm64 is to use the vc4-fkms overlay, but this doesn't work on slackwareaarch64. I have no idea why not. Maybe I have the syntax wrong? I have put this in the config.txt file:(I have tried both vc4-fkms-v3d and vc4-fkms-v3d-pi4, to no avail. Also enabling and disabling 4K.)

I also can't compile VLC on slackwareaarch64 (it complains that I'm trying to cross-compile?!?), while the same slackbuild works on slarm64.

The last bug that I have yet to solve is that it won't shut down properly under slackwareaarch64. Shutting down from either sddm, or the command line (halt or shutdown -h now) goes through the motions, but hangs when it gets to the line: The lights have gone out, but there is still someone home! Keyboard is unresponsive, but the graphics are still outputting to the monitor. Only removing the power finally kills it!

Sorry if this sounds like a moaning session. It isn't meant to be! I dearly want to get this working smoothly, but I'm not familiar enough with arm to fumble my way around it too well yet! I'm happy to experiment with any suggestions you may have, and report the results.

Cheers,

--
Pete

The minimum SD card is required to be 8GB, so it's not a problem.

Perhaps start a new thread with it and someone can help you.

I've not seen that one.

Not at all - I didn't expect everything to work - especially on the Raspberry Pi. One of the main problems with the Raspberry Pi is that they focus on their own ecosystem, which means that the driver support is slow to be upstreamed. At one point I wasn't even going to add RPi support because it almost seems as if RPi don't want anyone using anything but their OS, and that's not how we roll around here. I'm interested in hardware where the vendor is engaged with the open source community to drive the master project (Linux Kernel in this case) forwards - because this way it works better for everyone.

One of the golden rules from the outset of porting Slackware (because I figured out at my expense) is that the Hardware Model needed all core functionality (SoC support,ethernet,video (where applicable), boot loader support) , or had to have a publicised plan (or an agreement statement) by the vendor to upstream support. Basically the problem is that if the vendor closes shop or just stops supporting patch maintenance your hardware hits an evolutionary dead-end. Where as if it's merged upstream it *tends* to continue working for quite some time. Fortunately the RPi support in mainline looks pretty complete, and it's just this video stuff that's still waiting.

On the video front: as the VC4 driver is working in Slarm64, check if it's using a patch for mainline (Linux 5.17) and I'll review it. However, if it's working because it uses the RPi Kernel branch, VC4 driver support in Slackware will have to wait until the support is merged into mainline.