enine, thank you, intended topic was just a joke but turned into something better, I appreciate all the comments.

2 members found this post helpful.

[...]

I am the sole maintainer and developer of Slackware ARM. For example, if you look at one of the recent episodes of the SlackChat podcast you'll see "pepa" laid to rest. Slackware ARM -current was built on that machine.
Whether you're using Slackware ARM directly with one of the supported Hardware Models, it's my hobby project. If you're using SARpi you're using my hobby project with a different kernel, some extra firmware binaries and a repack of the OS InitRD and installer.

I have no personal interest in any particular Hardware Model apart from the original machines (and that's really only because I spent years using them learning about Operating Systems and ARM using their native OS). I am interested in Operating System Architecture and I find ARM hardware that has support for the main subsystems in the mainline Kernel.
If you look at some of the early episodes of Slackchat Season 2, you see me testing the Kernel on the Banana Pi. For every Hardware Model supported, I personally have to test it. This and maintaining and developing the entire OS on my own takes rather a lot of time so there's a very finite limit on what's possible.

To me, I find little difference between the Hardware Models - sure, some have more RAM, others have no eSATA and others have better spec video and so on, but at the level I am interested in, it's not too important.
The Pinebook Pro on the other hand, is far more interesting because it's a reasonably powerful 64bit ARM laptop that I can use directly to develop the ARM and AArch64 ports, rather than work on an x86 frontend.

The RPi is not obscure to the outside person, and this is purely because they are good at marketing. However, you might wonder: why is there no Debian Proper on it? Why is there Raspbian? ARMbian? The RPi for _developers_ of the main Linux distros _is_ obscure because the support for RPis has been kept within the RPi's own source tree. So whilst it's available, it's not been merged into the mainline Kernel and other packages. This makes it a _far_ less interesting prospect for a developer - especially a single person like me - to even entertain the idea of making accomodations for it, when all other vendors of Hardware Models publish their code to the mainline Kernel and other projects.

Raspbian exists because the original RPi was released with an older generation of ARM CPU - and nobody in their right mind would rebuild an entire distribution to accommodate an already old and under spec'd board, and so the RPI people had to rebuild one.

The confusion is purely due to the way that the ARM platform works: there's no BIOS to query, so this means that a 'map of the territory' (Flattened Device Tree blob) needs to be supplied, which necessitates different artifacts (e.g. a different copy of the _same_ boot loader, where the only difference is the compile-time options).

As it happens, Slackware's moving to Linux 5.12 now and I *think* there's been some gains towards direct support for the RPi (4 at least).

The vision is pretty clear and I think it's been well defined here (you will need to read the linked documents too).

Perhaps I'll do a podcast episode on this particular subject too to summarise it, as you're not the only one who seems confused by it.
For those of you with the skills, time and interest, we can include support for your device directly into Slackware ARM/AArch64.
It's generally pretty easy now I've made many of the required changes to the OS to support it.

3 members found this post helpful.

Contrary to general public consensus, the "Raspberry Pi OS" (a.k.a Raspbian) is not affiliated with the Raspberry Pi Foundation. It's actually a community project that's been developed and is maintained by avid supporters of the Raspberry Pi device(s) and the Debian Project, with the ideals and goals of the Raspberry Pi Foundation very much in mind. More information can be found here and here.

1 members found this post helpful.

I spent 0 minutes rebuilding the installer or writing shell scripts. I did not compile a kernel or edit firmware. The installer works out of the box with a default u-boot.bin. All that is needed is some of the firmware for /boot from the raspberry pi foundation.

By complete accident I discovered that I can use the same u-boot.bin on all Raspberry Pi's that support arm64.

I spent a few minutes researching if the Raspberry Pi 3 and 4 have SPI flash to use to store U-boot. The Eeprom looks to be written to the board in SPI Flash. So for now I am going to store everything on the SD card that is boot related. No need for SPI Flash. (start*.elf, fixup*.dat, bootcode.bin, config.txt)

I created an extremely minimal config.txt that enables UART, arm64 bit, and points to the u-boot.bin binary in /boot. Three lines of text. I probably won't be fleshing out the config.txt any further.

The boot sequence for the installer looks like so:
I am booting from SD and storing the rest of the file system on a USB disk.

Currently the Raspberry Pi 3 and 3 B+ are a work in progress. I have the 3B+ is installing at the moment. My Raspberry Pi 4 is off to the side, as a Aarch64 build host for distcc, with a Ethernet cable, and a power cord attached on my LAN. All three of my Pis boot the Slackware Aarch64-current installer over a serial. The Rpi 4 runs Xfce with the fbturbo driver over HDMI as expected.

There were a few issues with the Slackware installer finding my sd card (mounted at /boot) on the Raspberry Pi 4 as /dev/mmcblk1p1, and I think it only looks for /dev/mmcblk0p1. Due to the design of Slackware ARM, it gracefully installs everything to my USB thumb drive. All I had to do was copy contents of /boot on /dev/sda2, to /dev/mmcblk1p1, then edit one line in /etc/fstab, reboot.

After that, it was just a matter of adding the right kernel modules to the ram disk. This can easily be done using the new utility that Stuart Winter created, os-initrd-mgr.

So in the end, I found a bug for Stuart to mull over for a few days. Since my raspberry pi 3 sd card is in fact found by the installer at mmcblk0p1, while the Pi 4 sd card is found, but at mmcblk1p1.

After the installer finishes doing its thing:

I added the kernel modules I thought were necessary to boot the Raspberry Pi 4 to /boot/local/load_kernel_modules.post. The sample file in that directory contains a brief explanation, essentially add to it:

Once those are added to that file, run os-initrd-mgr.

All of this process can also be applied to arm boards, doing exactly what I did, using the framework laid out by Stuart. In about an hour, if you are also watching TV and not paying attention, you can do it too! Probably less time if you do pay attention.



P.S. I apologize for the wall of text.

Not trying to be a smart-alec by stating the obvious, but that's totally expected and how it should be. Imagine if users had to write their own installation scripts or rebuild u-boot or a kernel themselves in order to get Slackware installed. Officially supported devices need to work "out of the box" by default.

What exactly is needed from the Rasbperry Pi boot files (start*.elf, fixup*.dat, bootcode.bin, config.txt, etc.)? I thought the whole idea of not relying on the Raspberry Pi Foundation closed-source boot-firmware, or other boot files, was the reason why Slackware AArch64 was implementing the open-source Das U-boot universal boot loader. Otherwise, why fix something that's not broken?

There's no EEPROM on the Raspberry Pi 3, so the boot loader (i.e. bootcode.bin) must be located on a SD card. The Raspberry Pi 3 can use the 'bootcode.bin-only' method to enable USB host boot.

RPi3 can boot from USB if you set the OTP bit.

1 members found this post helpful.

Sure. That's always an option which end-users may decide to implement once their OS is installed and verified. Certainly not something I'd recommend to do beforehand. This also comes with the caveat that not all USB thumb drives are guaranteed to work as some have very specific protocol requirements that aren't supported by the bootcode, which renders them incompatible. So, users should ensure that their test-case setup is suitable before going ahead with it. The bootcode.bin-only method is pretty much assured with all USB thumb drives and doesn't make any irreversible changes to the one-time programmable bit.

1 members found this post helpful.

As I finally has some time on my hands and found another sd card, out of curiosity, I took out first install sd card, prepared other one, installed OS to ssd, using one of these, instead of sd card, system seems a little faster.

2 members found this post helpful.

It's exactly what I've been using on one of my RPi4 setups with Slackware ARM installed on a SSD, and for me it's been flawless. The StarTech USB3S2SAT3CB is more expensive than some other SATA-USB adapter alternatives but offers assured compatibility.

1 members found this post helpful.

I like startech stuffs, still installed and running!

and reliability too it seems.

1 members found this post helpful.