Slackware ARM celebrates its 22nd birthday on 20th January.

This milestone not only underlines the enduring legacy of Slackware ARM but also signifies its commitment to staying current and providing users with enhanced features and improvements. Cheers to two decades of excellence, and here's to another chapter of innovation and reliability in the Slackware ARM journey!

The Installers have also been updated for the supported Hardware Models.

Regarding the Raspberry Pi 5, if any of you are keen on contributing support for it to Slackware, benefiting the entire Slackware ARM community, feel free to inquire on the forum. We are more than willing to assist and guide you in getting started with the process. Your contributions would be highly valued and appreciated.

I haven't verified the extent of Linux 6.6 support for the Raspberry Pi 5. However, if you find that the mainline 6.6 is not yet suitable, you may consider experimenting with the Raspberry Pi Kernel fork packages.

Cheers
Stuart

Oh dear! I now have two completely unusable Slackwareaarch64 systems!

Hardware RPi 400

System-1: Slackwareaarch64 on SD card. Was working until update. I decided to give the "vanilla" kernel a try as, although it has been somewhat problematic in the past, that has mainly been due to a failure to shutdown properly, plus some oddities around wifi and bluetooth.

The upgrade seemed to go OK, no errors reported, but now it won't boot. I get the initial messages up until it tries to boot the kernel. At that stage the screen goes blank, with a flashing cursor in the top left corner. After a few seconds it stops flashing and the screen goes very black. A few moments later, the flashing cursor re-appears, and that's it.

I've tried SSHing into it, but no response.

The computer is totally unresponsive to the keyboard, and the only way to shut it down is to pull the power lead. Even this only leads to a partial shutdown, as the lights are still flickering, and I need to remove the HDMI lead as well to completely kill it!

System-2: Slackwareaarch64 entirely on an SSD (connected via USB-3). Again, this was working perfectly until the upgrade. This time I was more cautious! I upgraded just the system first, not the kernel, and rebooted. Everything came up fine. I then upgraded the kernel, but using the RaspberryPI version.

This is even worse! I don't even get any messages at all! The screen flcikers on power up and then remains resolutely black. No sign of life at all. Again, I can't SSH in to it, and I have to disconnect not only the power, but also the HDMI lead to completely remove all power from the system.

I do have a Sarpi64 SD card, which has an almost up-to-date Slackwareaarch64 running with the Sarpi 6.6 kernel, which works fine. I also have a Slarm64 SD card using an early 6.6 kernel. This mostly works, but it is one of the kernels that had the "NVidia Glitch" which stops my TV card from working. Slarm64 hasn't been updated for a while, and I suspect it may be dormant.

Not sure how to proceed from here. Ideally I should re-install one of the 6.1 Pi kernels, but I don't have one to hand. Even if I did, I'm not sure how I could install it on a non running system.

Any suggestions gratefully received!

--
Pete

Only the RPi4 is officially supported; the RPi 400 is a distinct model. If it happened to work previously, it was likely a stroke of luck, as it isn't within the supported configurations.

To assess the situation, I might recommended to attempt booting the Slackware Installer. This will help determine if it detects the storage and other essential components, providing a potential avenue for recovery.

I will add a prominent note in the installation guide to emphasise that only the specified model is officially supported, and any attempts on other models may result in unforeseen issues.

OK, starting to get somewhere this morning...

Initial conclusions: Its not the main packages. Everything was working fine UNTIL the kernel was updated. I don't think its the kernel itself. I think something went wrong with the update procedure.

I've re-made installation media, and it booted using the new 6.6.12 (stock) kernel. I've done a test install on a micro-sd card (I know, but its a TEST!) and that boots OK. I've upgraded it to the Pi-fork kernel and it still boots OK - BUT...

Following the update to the Pi-fork, the last line of the initialisation screen before the login prompt announces 6.6.12 (stock kernel), but after login, uname reports 6.6.11 (Pi-fork). Also some of the quirks that the stock kernel suffers from are still there (failure to shutdown properly).

The upgrade was done the traditional way, using upgradepkg for modules, kernel and source (in that order).

Another issue is that I can't locate the config.txt file to properly set options for the Pi400. These usually don't have a big effect, but do sort out some of the oddities. Maybe I can find it by mounting the SD card on my x86_64 machine and editing it there.

If I could figure out how to re-install the Pi-fork on my SSD disk, I would. Maybe try chroot from the SD card?

Onwards and upwards...

--
Pete

I would see if I can help, but after the tirade of abuse I received yesterday, my heart has gone out of it. I'm going offline for a while whilst I reassess whether I want to continue.

Tirade of abuse? I hope I didn't come across like that! I was trying to be as clinical as possible in describing the issues I had - as requested in the changelog.

I now think I can see a way forward, but it will take time and I do have other things needing my attention.

I have to say, the problems did catch me entirely by surprise as up this point, all the updates had applied totally painlessly. Also some of the other Slackware based arm distros have been using 6.6 for a while without issues, so I was very surprised when this didn't "just work".

But that is what -current is for, and its not unreasonable for there to be the occasional hiccup. The main thing is to find the fix!

I do hope you are not too discouraged. I'll continue to update my findings as and when I find anything interesting.

--
Pete

My bad. Not from you! Check the other recent posts.

Phew! I know I can sometimes come across a bit angry when I get frustrated with something. I try and keep things clinical, though.

Think I've found the issue! Watch this space...

Well, I've found *an* issue, but its not the universal panacea that I'd hoped...

My config.txt file has a number of tweaks to better support the Pi400. For example, there is a "bcm2711-rpi-400.dtb" file, which I use as a device_tree instead of "bcm2711-rpi-4-b.dtb", for obvious reasons. I also have a RTC, so I add the parameters for that. But, looking down the rest of the file, I notice this section:
Since I sometimes use BT headphones, I usually have this disabled. That was what was stopping the SD card from booting!!! As soon as I re-enabled the UART, the system booted again!

I went through all the other changes I had made, one at a time, but that was definitely the one that stopped everything from booting!

Thinking I was on a winner, I looked at my SSD drive. Sadly, on that the UART was enabled, so I still have no idea why that one is refusing to boot.

I have no idea why this is happening! I cannot for the life of me think why disabling that UART should stop the whole system from booting! When it fails, I don't get any messages from the BIOS (?) as I sometimes do if a card isn't inserted correctly. It knows there is a device there, but it just won't boot it! Or if it does, it stalls well before completion, with just a blank screen.

I will keep digging, but may not be able to do much more today.

--
Pete

No, I was wrong! The UART thing was just a coincidence.

I've rebuilt the install media several times now, and still can't get a decent running system. The stock kernel does seem to boot reliably, but has big issues with KDE and some of the Pi hardware. The latter may be fixable - haven't had time to play with it that much, the KDE issue is a showstopper for me.

The PiFork - when I can get it to boot, does get KDE working, but seems to stop booting at random. Once it has stopped once, it will never boot again!

I don't even get any initial screens - not even the "Pi Rainbow" thing that sometimes flashes up. There is no indication that the machine is doing anything at all, which makes bug chasing very difficult!

I *think* it may be something to do with the u-boot system. It has to be something right at the start. I've tried by-passing u-boot and booting the kernel directly using "kernel=slk_image-armv8" instead of "kernel=slk_u-boot.bin". That DOES show signs of life. The kernel does start to boot, but then stops in a kernel panic because it can't find the root partition. I'm guessing this is because the initrd isn't getting loaded.

I have no idea what the syntax is to load the initrd. I took a blind guess and added "initrd=slk_initrd-armv8" to the config.txt file, but it didn't work.

Interestingly, neither my Sarpi nor Slarm64 sd cards use u-boot to boot, both boot the kernel directly. I seem to remember from a year or so back that when I did try to use u-boot with them, it caused problems.

Question 1: Is the slk_u-boot.bin file different between the Pi fork kernel and the stock one?
Question 2: What is the correct syntax to load the kernel directly with the initrd?
Question 3: Is anyone else having these issues, or is it just me?

Slackwareaarch64 was working perfectly with the 6.1 series PiFork kernels, but stupidly, I didn't keep a copy of the last one. Is there an archive anywhere?

--
Pete

1 members found this post helpful.

enable_uart=1 will send all boot text to the serial console. HDMI will be blank. You will experience better hardware support with the Pi kernel fork. Slackware Aarch64 does not support the Pi 400. Some kernel modules may not load due to how Slackware support is implemented. Adding "slkpbs" to the installer extlinux.conf at the end of the APPEND line will boot your Pi 400 into a development shell. From there check out the tools directory.

This is documented and more across several hardware models here:

https://docs.slackware.com/slackwarearm:development

It may seem complicated but will make perfect sense once you read the docs. If a kernel module is missing, let myself or MoZes know and we can accommodate you further.

Hi Brent, and thanks for chipping in! I think Stuart is a bit upset at the moment, not with me necessarily, but it does leave me a bit high and dry at present!

A bit of background: I've been using the Pi-fork kernels since Stuart first published them, and yes, they do fix all the issues with the "stock" kernel on the Pi. These include non-working wifi and very poor graphics performance - to the point where none of the GUIs (KDE or XFCE) are usable. With the stock kernel my Pi400 is really only a CLI device.

The Pi kernel has only been problematic since the 6.6 version. All the previous versions worked perfectly, which is why I am so puzzled here.

You say This is not my experience, which is that this may send the boot text to the serial console, but it also goes to HDMI. At least this is the case with the stock kernel. The only time I got the 6.6 Pi kernel to boot, I also saw the usual boot text with the uart set to 1. The text in the config.txt file does suggest setting this to zero, but this advice is now contradicted by the latest installation instructions which says this is only necessary on the Pi-3.

Moving on, I'm not convinced that the problem is actually the kernel. I don't think it ever gets as far as loading either the kernel or the initrd. I think its something broken in the u-boot section.

As I understand it (please correct me if I'm wrong!), the first thing that gets called is u-boot, which examines extlinux.conf to find out where the kernel and initrd are (as well as setting up a few other things). I can usually see this happening on the opening screen - the one with the Slackware logo in the top RH corner. With the Pi 6.6 kernel I never see this. The screen goes immediately blank and stays that way, no matter how long I wait. After some seconds the monitor goes into standby, indicating no output from the graphics section.

In other words, I don't believe the kernel is ever getting loaded. The system falls over at the first hurdle.

As an aside, both slarm64 and Sarpi64 have been using 6.6 kernels for a while without issue, but neither use u-boot. They boot the kernel directly, somehow.

Which brings me to the next point. Looking inside the Pi kernel package (/boot/platform/aarch64/helper/), I find a readme.txt file which says: I think the next stage in debugging this is to stop using u-boot and use the RPi native bootloader, but I have no idea how to do this on Slackwareaarch64.

I do remember having to do this with slarm64 way back before Slackwareaarch64 was available to get around boot issues, but that was simply a matter of using "kernel=WhateverImage" instead of "kernel=u-boot.bin". If I do this in Slackwareaaarch64, the kernel boots, but then stops with a panic when it can't find the root partition. Presumably the initrd (which appears to load before the kernel in the stock system) mounts all the necessary partitions and modules before booting the kernel. This isn't happening if the kernel is called directly.

So what is the magic incantation necessary to call the kernel directly?

I will have a look at the documentation to which you have kindly pointed me. Perhaps there will be a clue in there...

Thanks for your help!

--
Pete

Further update: I can definitely confirm that it is "enable_uart=0" that inhibits boot messages going to HDMI, not "enable_uart=1" as suggested.

I've also found a way of at least partially booting the kernel without using u-boot, from this link: https://waldorf.waveform.org.uk/2021...oot-first.html

I made these changes to config.txt: This got both the stock kernel on an SD card, and the Pi fork kernel on a USB-SSD drive to boot up to a point. All the necessary partitions seemed to be mounted OK, but both stopped at the point where I believe it tried to switch from the framebuffer to the kernel driver. On the Pi fork kernel, the raspberries were still on the screen at the point when the system froze. There is no comparable indication on the stock kernel, but it seemed to be at the same point.

On both kernels a further indication may be that it tried to enable a non-existent RTC on the i2c bus (ds1307) despite this being commented out in the config.txt file. It also ignored the uncommented, actual RTC - a ds3231. This indicates to me that it was getting stray configuration info from somewhere, but where?

That's as far as I've got at the moment. Currently, the stock 6.6 kernel boots and runs, but is seriously broken on the Pi400 hardware. The Pi-fork won't even boot via u-boot. Both only partially boot when booted directly. This maybe something to do with my "magic incantation"!

Cheers,

--
Pete

Neither myself or Stuart own a Pi 400. I do not have plans to purchase one either. You should consider reading the development documentation. Then try to add support for your Pi 400. Also, be aware that the Raspberry Pi kernel is a fork of Linus Torvalds Linux kernel. As time moves on raspberry pi kernels will diverge further from main line Linux.

I do not speak for Stuart or Slackware ARM in any way. Recent conversation, my experience, and opinion have lead me to the loss of all interest in the Raspberry Pi hardware.

Generally, if are not willing to or are unable to add support for your hardware, use a supported hardware model.

The differences between the 400 and 4b seem to be trivial, and can usually be accommodated by tweaks to the config files, in my experience. I do actually have a 4b, but it is doing sterling work as a NAS/MediaServer under OpenMediaVault. I rarely have to touch it, and certainly don't want to mess with a device doing a fairly important function whilst it is still working. I'm an old-fashioned engineer - "If it ain't broke, don't fix it!".

Slackwareaarch64 with the Pi kernel was working perfectly throughout the 6.1 series kernels. It is only the change to 6.6 that has broken it. I have diagnosed the issue as far as possible with my limited programming abilities. I have read the development documentation, but its not very helpful. The only thing that seems to be relevant in there is the bit I already found elsewhere about by-passing u-boot - which I believe (rightly or wrongly!) to be the villain of the piece here. Even then, the syntax of the various commands and options is barely touched upon.

I don't know about the rest of the world, but here in the UK, Pies are everywhere. Schools are full of them! I have never seen the "other hardware models" even advertised! Actually, that's not quite right, I have seen Orange Pies advertised, but my experience with other Orange products has led me to steer well clear of them! It will be a real shame if Slackware support for the Pi hardware is abandoned, especially as they are so popular in education.

Anyway, enough philosophising. I have a workshop to clear up today...

--
Pete