Having watched the latest Youtube video on installing Slackware aarch64 on the RPi4, I notice the install guide says that Samsung EVO SD cards can be problematic. If this is based on my experience when trying the RPi4 aarch64 installer, I'm pretty sure the SD card isn't the problem. I think the problem is that my RPi4 4GB, which I bought in January 2022, is the newer 'C0' stepping which has differences from older 'B0' RPi4s (see here). Unfortunately I've got a heatsink stuck on so can't confirm the model number of the CPU but using the dma-ranges check described in that blog post, I get the result for a C0 RPi4.

I think the problem is related the U-Boot somehow as booting a non-U-Boot image (Sarpi, RPiOS 32-bit or 64-bit) works fine. The symptom is that, after booting the installer off the SD card, the mmcblk device, which it just booted off, no longer shows up and syslog gets a continuous stream of mmc-related error messages.

I found people experiencing the same problem with Arch Linux ARM as described here. I gave installing Arch Linux ARM a try and experienced the same problem. I applied the U-Boot fix described in that forum thread (Arch uses boot.scr instead of extlinux.conf) and that fixed things.

I also tried sndwvs' RPi4 slarm64 image from December 2021, which uses U-Boot with a boot.scr similar-ish to the 'fixed' Arch boot.scr, and it boots fine out of the box.

See also this FreeBSD bug report which describes a similar issue. (I haven't gone so far as to try and install FreeBSD.)

Based on this RedHat bug report I tried deleting the dtb directory & symlink on the Slackware aarch64 installer which worked in so far that /dev/mmcblk0 now showed up but who knows what else I'd broken.

Should mention that the working Arch and slarm64 installs are both on Samsung EVO SD cards as is my Slackware ARM 32-bit Sarpi install.

I've only tested with the Slackware aarch64 installer I downloaded on 3 February. Things may well be fixed now. But if the warning about Samsung EVO cards is based on my experience, I suspect it is wrong.

Geoff

OK thanks for the feedback and for the research in your post here. I'll change the docs later on.
The latest version of U-Boot now works with the RPi4 (at least on mine) so that one can be tested first.

I'm off the Slackware treadmill for a while now until the new glibc is proven stable and Linux 5.17 is out.

1 members found this post helpful.

With some minor changes, Slackware Aarch64 current seems to install and run fine on my 'late model' RPi 4B.

If I run the installer as is, I get the mmc0 error as expected. This time it is the 'unrecognised SCR structure' error and the SD card doesn't show up after the installer has finished booting.

Next I edited the /extlinux/extlinux.conf on the 2nd partition of the installer and commented out the 'FDTDIR /dtb/' line. Rebooted the installer and everything appears to work fine with the SD card showing up. I carried on with installing aarch64 current with the root directory on a USB3 flash drive. Rebooting after the install failed because the FDTDIR line had been reinstated in the extlinux.conf file. After I commented it out again and rebooted, everything seemed to work OK.

Reading this thread on the RPi forums, it seems perhaps you don't need U-Boot to load the DTB (see this comment) because it will already have been loaded by the firmware. Just messing around, I tried removing bcm2711-rpi-4-b.dtb on the first partition of the SD card (that becomes /boot/platform/hwm_bw/) and when rebooting, the RPi hung on the rainbow screen so evidently, it is required by the first-stage loader.

According to this comment, the problem is that the C0 RPi4 has a different dma-ranges value for the emmc2 bus from the original B0 RPi4. Somehow this must be taken care of in the official firmware (start4.elf or somewhere, who knows?) because the bcm2711-rpi-4-b.dtb on the 1st partition (used by the RPi boot loader) and the bcm2711-rpi-4-b.dtb in the /dtb/broadcom/ directory on the 2nd partition (used by U-Boot) are identical and as far as I can tell apply to the original RPi4.

I guess my next thing to try is to recompile the U-Boot /dtb/broadcom/bcm2711-rpi-4-b.dtb file with the C0 dma-ranges to see if that works.

Geoff.

1 members found this post helpful.

I have given recompiling bcm2711-rpi-4-b.dtb with the C0 dma-ranges a try and it seems to work fine. I did this on a completed install, not using the Slackware aarch64 RPi4 installer.

Decompile the dtb:

Edit the dts, find the emmc2bus section, and change the dma-ranges value as per these instructions.

Recompile the dtb (have a backup of the original dtb):

Edit /boot/extlinux/extlinux.conf and uncomment out the 'FDTDIR /dtb/' directory line so U-Boot loads the dtb. Rebooted and everything worked OK: no mmc errors, SD card showed up and its partitions were mounted as normal.

Not sure what all this means for Slackware aarch64. Perhaps it is simply a matter of not (re)loading the dtb from U-Boot and rely on the first-stage RPi bootloader for that.

Geoff.

1 members found this post helpful.

Thanks for fixing this, Geoff. I was driving home today and it occurred to me why the DTB and DTOs set from the RPi native boot loader work - and you have just confirmed it for me.

I'll have a look at patching the supplied version and test it on my older RPi4. If it works on mine, it'll also work on yours and we can keep the configuration as-is.

I'm pleased about this because it means that the Device Tree Overlays can be configured from within the RPi4 native boot loader, for which there is ample documentation available on the web.

Just to be clear, I only recompiled the dtb out of curiosity to see if I could get a dtb that works on my newer RPi4 when loaded via U-boot. I would hope the extlinux.conf change works for all variants (old & new RPi4, Pi400, CM4) and is the way to go.

Geoff.

Yep, that's what I decided to do - assign all the Flattened Device Tree (and DTO) handling to the RPi's native first stage loader (by disabling the U-Boot config directive). This is the well-tested route and actually the least friction.
I'll push out the new Kernel packages and Installers early this week, and if you have time to re-test it that'd be great.

I'll send a note here when they're out.

1 members found this post helpful.

The updates are out.

1 members found this post helpful.

Thanks very much, Stuart. I've given the latest rpi4 installer a try and it boots up perfectly without any modifications: no mmc related errors in the log, and the mmc partitions on the SD card show up fine. I shall have a go at completing a fresh install after work. Thanks again.

Geoff.

Ditto from me!

Just for future reference, what is the correct procedure for updating kernels here? Under x86_64, I always keep a copy of the older kernel, just in case anything goes wrong! (I have a piece of hardware that requires special modules to be built, and sometimes they haven't caught up with the newer kernel release!) Instead of using "upgradepkg", I use "installpkg" (except for the headers). I then delete the oldest kernel and its associated modules, source, etc, so that I always have two options available. On slarm64, I don't use u-boot (had issues with it on the Pi400 - probably through lack of understanding on my part!)), and boot the kernel directly. This works well, there is a supplied script for rebuilding the initrd, and so far it has just been a case of using "upgradepkg" instead of "installpkg", followed by running the initrd script.

However, slawareaarch64 seems to have yet another boot method which relies on u-boot. Am I correct in assuming that if I don't blacklist the kernel packages, slackpkg will do all that is necessary, or are there other steps that need to be taken? I'm thinking in terms of initrd, and the fact that there seem to be similar (identical?) files, but with different names, in the SLKboot and SLKhwm_bw folders.

Apologies if these seem dumb questions, but the boot system seems very convoluted to me. I'm guessing its a result of having to be generic for different hardware models, but that doesn't make it easy to understand what is going on!

Cheers,

--
Pete

The boot is only complicated on the RPi.

The Kernel, DTB and OS InitRD within /boot/platform/hwm_bw is in sync with the version in /boot because I wanted to enable booting Linux directly from the RPi native boot loader (rather than booted via a chainloaded U-boot). However, it doesn't presently work and there's no point now that the DTB and DTOs are handled directly by the RPi BL. I won't remove the duplicated files though since if someone does want to boot Linux directly, they'll need them there.
That said - if nobody wants to ever try and boot Linux directly from the RPi BL, I'll stop the kernel package from duplicating them. This way we can reduce the size requirements for the RPi boot loader fat partition. I can't see any reason to not boot Linux via U-Boot - there's no benefit from using the RPi boot loader's cmdline.txt file over the extlinux.conf configuration, and it means you can use U-Boot to switch between Kernels or Kernel boot options (if you're experimenting with cmdline= settings) from within the U-Boot menu.
Let me know.

/boot/platform/hwm_bw only exists on the RPi presently - the RockPro64 and Pinebook Pro have only /boot.

For your question about managing Kernel upgrades, you can ignore everything in /boot/platform/hwm_bw.

As for upgrading kernels, you should use upgradepkg (or let slackpkg do it)
The Kernels are tested on the Hardware Models that they support, so they ought to work when you receive them. If there's something in particular which is causing you problems, let me know so I can fix it in the distribution since it'll also likely break for others.

To support multiple Kernel versions, what you could do is:
* within /boot, copy the System.map, Kernel, initrd and DTBs into another dir within /boot
* within /boot/extlinux/extlinux.conf create a new LABEL stanza (copy the default) and set LINUX and INITRD directives to the appropriate dir.
# cd /lib/modules ; cp -fa 5.17.2-armv8 5.17.2-armv8.copy

then upgradepkg a/kernel_armv8

# cd /lib/modules ; mv -fv 5.17.2-armv8.copy 5.17.2-armv8

The only thing I didn't mention was about the DTBs within /boot/platform/hwm_bw since these are managed by the a/kernel_armv8 package.
I wouldn't worry too much about those as they infrequently change, and if there really is a problem you can restore the older version (that you stored in /boot somewhere).

I haven't tried any of the above, but it'll probably work.

Just to finish my feedback on the latest installer: I completed a full-ish install (minus kde, emacs) with swap and root on the SD card and everything went smoothly. Simply rebooted when setup was finished and had a working Slackware.

I did give my Adafruit speaker bonnet a quick try to see if I could get a config.txt dtoverlay to work but it needs the hifiberry-dac module which I am guessing isn't part of the mainline Linux kernel, only the RPiOS kernel. Getting that to work is left as an exercise for the reader (me).

Geoff.

1 members found this post helpful.

Thanks - once you get it working, I am happy to include (commented out) the DTO settings you have for it within the supplied config.txt. The idea is to have some useful hardware there ready to uncomment.

I upgraded to the latest RPi bootware the other day and the VC4 driver messages look more promising, but still no speed increase for X (despite using the vc4 settings in config.txt). I'll upload the latest batch this week or early next.

1 members found this post helpful.

I've tried quite a few things in the config.txt file to try and improve the gfx performance - to no avail, alas! It must be do-able, because it is silky smooth in Pi OS, and more than adequate in slarm64. I can live with the graphics being clunky, but not the video performance.

In slarm64, I can play 1080 videos OK, though the cpu is around 90% on all cores. 720 video plays with around 20% on all cores. On Slackwareaarch64, 720 is slightly stuttery with around 85-90% on all cores, but 1080 refuses to play at all. It just freezes solid.

I did find this thread on accelerated video, which has lots of useful info: https://forums.raspberrypi.com/viewtopic.php?t=317511

Most of it is above my pay grade, however!

There is also some useful information at https://www.raspberrypi.com/document...ml#file-format

though I suspect Stuart knows all this already! (I found it informative, though!)

I've found some useful hints on how to compile VLC using the Pi's hardware acceleration. Unfortunately, at the moment, I can't even get it to do a basic compile, never mind anything adventurous. VLC is notoriously finicky to compile, but I managed it - with @sndwvs assistance - on slarm64. Same build script doesn't work here, unfortunately!

<sigh!> Onwards and upwards - hopefully!



--
Pete

Indeed, it is do-able. The kernel module was compiled and available on our systems all along. I just had not thought to load it in the boot scripts. The v3d module is not built into the kernel, but as a module. This is as it should be, seeing as the kernel is meant to support more than just the Rpi 4. I tried black listing the vc4 driver and loading the v3d driver. Seeing as my system does not have working vc4, this seemed benign. What was helpful is that now, video falls back to a modesetting with v3d gpu scheduling, *I think*. The performance seems improved enough to watch youtube videos on my Pi 4.

*This is for the Raspberry Pi 4, not for the Pi 3 models.*
---
You can wait for Stuart's changes to take effect, or do the following:

1. Create and add to /boot/local/load_kernel_modules.post configruation file as root:
2. Run as root:
3. Edit the config.txt and enable a few vars. I'm not sure this matters, we will see when the vc4 stuff is updated.
4. Reboot && Profit.

Soon there should be new kernel fixes for the vc4 and vc4-drm modules.