Thank you both for your very useful posts! (Hi again, Exaga! )

In particular thanks sndwvs for pointing out the ready-made image of slarm64! That will certainly make life a lot easier whilst I learn my way around! And thanks, Exaga, for your comments on building AlienBob's VLC. It is useful because it has everything built in. I dare say things like x264 and x265 will build successfully on ARM, but until I get up to speed its handy to have something "off the shelf"!

Exaga: Sarpi loaded reasonably easily on the 400, although there are a couple of typos in their guide. Luckily, I'm familiar enough with the stock Slackware system to sort these out without too many problems.

Although I wouldn't class myself as a programmer, I've been playing with computers since the days of the DEC PDP-8, so I can usually find my way around - eventually! Usually the biggest problem is tracking down documentation or other information. For instance, I have no idea if the Pi can be made to boot from something other than the SD card, in the same way that an Intel / AMD system can.

I have a lot of learning to do! Fortunately, Slackware is a very good system for self education - once you get it up and running!

Again, thank you both! I will probably be back with more stupid questions, but hopefully not too many!

--
Pete

Typos in the sarpi guide... please let me know which ones and I will correct them. Apologies for that. I corrected one this morning on the "getslack" page - an error with the URL to download the Slackware ARM current source media. Really not sure how that one crept in there!

Your knowledge and experience pre-dates mine. I started out on the ZX81 with Sinclair BASIC (1981/2) which then lead to the ZX Spectrum. Then; Commodore (CBM64) BASIC (1985), AmigaDOS (1988), MS DOS/Windows (1995/6), Redhat Linux (1999/2000), and eventually Slackware Linux (2004). Since then I've used a plethora of other Linux distributions for various purposes and testing but I'm always comparing them to Slackware. Nothing else is nearly as rewarding, or quite floats my boat like Slackware does, especially Slackware ARM.

In order to boot the RPi4 from a USB storage device the bootloader EEPROM version requires an update. I updated my RPi4 (4GB) EEPROM and it now boots from a SD card or any USB storage medium. NB: Apparently your RPi 400 is already capable! So, you might find no update is required. All I did was to install Slackware ARM on a SSD - using a SD card in the RPi4 with the SARPi installer on it, and connecting the SSD to one of the RPi4 USB ports using a SATA-USB adapter, and voila! It was ready to rock n roll. Take a look at this LQ thread for info on adapters: https://www.linuxquestions.org/quest...ce-4175682591/ - some are better suited than others. I've also installed Slackware ARM on USB memory sticks and it works great!

Ask away, whenever you feel the need. Share any and all info you find interesting and it will be very well received and appreciated. You'll find this Slackware ARM forum a lot different to most other places. I like to think of it here as being a little more civilised, even though I'm around these parts quite often. lol

Have fun, Pete. Good to have you here joining in.

I think you've found the one that I caught! It was a missing hyphen on one of the URLs, IIRC. I think the other one may have been my fingers getting used to a new keyboard!

Sorry I can't be more specific, I've been doing so much messing around today, I've forgotten what I've done!

I tried installing from the image file mentioned above, but it wouldn't boot! I'm currently trying to use sarpi64 to load slarm64, but for some reason, it doesn't want to recognise the pen-drive containing the system files. Still working on that!

I've started another thread for that problem, so perhaps see you over there?

Cheers,

--
Pete

1 members found this post helpful.

Thanks. That missing '-' in the Slackware ARM current URL was AWOL. I did not give it permission to go on vacation! All fixed now.

I make constant notes of what I've done because, like you, I do so much that I often forget as much. Too many times have I not made notes on how I achieved success and wasted lots of time as a result. That really sucks and usually happens at the most inconvenient moment. So now-a-days (pen and paper) notes is how I remind myself - once I'm happy I put it in a plain text file for posterity.

With regards to the bootloader EEPROM on the RPi 400 - https://www.raspberrypi.org/document...otmodes/msd.md - this page states that the device should already be updated with the latest bootloader version. So an update is not required. Without being able to test I couldn't accurately comment on why the device refused to boot as expected. I checked my own /boot dir and the device-tree blob for the RPi 400 is present so that's a bit of 'head-scratching' from me. If I'm getting the wrong end of the stick here and you attempted to boot into slarm64 and not Slackware ARM then please ignore me here.

On slarm64 - it's an unofficial Slackware [ARM] community-supported project just like SARPi is. Problems are to be expected from time to time but it's down to the individual(s) who maintains and develops, and distributes, any related software to keep on top of the bugs and niggles. There are fundamental differences between slarm64 and SARPi that I could enlighten you on if you're interested. However, suffice to say at this point that I represent, and only deal with, SARPi* shizzle and I do not get involved at development level with any other Slackware-[ARM]-based community-supported projects. I simply don't have the time for anything else.

With that being said, 'sndwvs' is your man for all things slarm64. He is the maintainer of that project and any issues you may encounter should be addressed with him. I couldn't possibly comment on slarm64 as I've never installed it or ran it, even for testing. I may read the thread you have alluded to but I will leave the diagnostics and support/advice up to the experts on that score.

Thanks for your response, again! I think we're on the track of the failure to boot. Sndwvs asked me to try a couple of things, which got slarm64 going, but his latest "fix" broke it again.

I appreciate that its always difficult to diagnose when you don't have the same hardware in front of you! I used to do a lot of dappling with RF (transmitters, receivers and the like), mostly at VHF and UHF frequencies. However, things have moved on in that area, and a lot of equipment these days is SDR (Software Defined Radio). Doesn't stop people asking me for help, even though it bears no relation to the stuff I used to do! At least here we are talking about something similar, so any help I can give to make life easier for others following on, I am more than happy to give.

Anyway, I've spent far too long staring at monitors today! I'm going to give my eyes a rest!



--
Pete

I had a CB radio back in the 1980s and that's pretty much all I know about transmitters/receivers and the like. I guess that sort of thing might be the very basic lower-end of your experience. I also used to work with a guy that was into HAM radio and would often say or hum (quietly to himself) "dah dit dah dit. dah dah dit dah." repeatedly - which I never understood why, but I think it was something to do with Morse Code. When I'd ask him what it meant he'd just repeat the same thing again (lol). Funny how, after all these years, I still remember his strange chants.

Although, I do have a GPS module for the Raspberry Pi that I've been meaning/planning (for quite a few months) to connect up and get running. I use one of my RPi3's as a NTP server for my home network and my intention is to sync the system time with satellites instead of other Internet-based NTP servers. I have many questions about doing this, the answers to which I have not fully investigated or even begun to understand. I'm sure (as with everything else) I'll get around to doing it, eventually.

Last night I downloaded alien's VLC build scripts and delved into the code. That stuff is some serious hardcore Slacking. I'm going to stock up on Jaffa cakes before I even start to attempt to build any of it. Without a doubt I will need them for such a task.

I probably ought to start a new thread for this, but while we're here...

As I'm not getting anywhere (yet!) with sndwvs img files, I thought I'd try and load slarm64-current using sarpi64. Sarpi64 boots and runs fine. I've created a pen-drive with the slarm64 files on it (similar to AlienBob's usbimg2disk pendrive, but without the bootloader), but when I get to the "setup" stage sarpi64 can't find the "repository" on the pendrive. I've tried mounting the pendrive rather than let setup find it, and that doesn't work either. I'm guessing its looking for something that's missing - or has a different name - on the "repository" drive, but I can't figure out what that might be. Sarpi32 worked fine, but kde4 was very buggy!

I'm not sure if you are connected with sarpi64 or not, but I see its in your signature, so I'm hoping you can point me in the right direction!

Re: transmitters - my other hobby is building and flying RC model aircraft. I've been doing that for over 50 years now, and for a number of years I designed and built my own RC systems - perhaps the ultimate case of putting your money where your mouth is!

These days, I can't even buy the components for the cost of a ready made system, but I still restore and carry out repairs on the older generations of equipment!

--
Pete

Hi Pete. Yes I created the SARPi64 shizzle which is a side-issue and by-product of the SARPi Project and a personal forced-attempt at cajoling the Slackware ARM community into using their time, efforts, knowledge, intellect and experience towards creating/building, or working on, an Aarch64 port some years ago. It's not really what you're looking for, BUT... [WARNING!: massive outlandish assertion about to take place in the next few lines]:

I bet you could install the SARPi64 shizzle on an installation of slarm64 and it would boot on the RPi4. NB: You _MUST_ comment-out the line(s) in the /boot/config.txt file that loads the initrd.gz or else you will skip loading slarm64. Remove (or comment-out) these lines from /boot/config.txt file before you boot it:
Then, depending on the way slarm64 is structured it might work as expected. My only guarantee is that the boot-firmware will load the kernel and after that it's a lottery, but it would be interesting to know if it works for you.

SARPi64 at this time is an ARMv8 kernel and modules and RPi3/4 boot-firmware that has no 64-bit OS to accompany it. So it is more than possible to boot into Slackware ARM with it (i.e. 32-bit ARMv7) as I've done that 100s of times in the past. I reckon it might boot into slarm64 too. Right now it includes a version of the Slackware ARM initrd (that is initially stolen from MoZes - which is updated with the latest version for each SARPi build) which conveniently includes the Slackware ARM installer. I bastardise this initrd to suit the Raspberry Pi hardware by removing any existing kernel modules and replacing them with the latest ones I've compiled. That's the major difference(s) between the SARPi/SARPi64 initrd and the official unblemished version that MoZes creates and makes available.

Try it. Install SARPi64 kernel, kernel-modules,and boot-firmware. See if it boots. Make sure to get rid of any u-boot shizzle and ensure it doesn't interfere! The boot-firmware SARPi* uses is the proprietary software from the RPi Github repository - https://github.com/raspberrypi - and the /boot/config.txt file contains all the instructions to start the RPi4 SoC in 64-bit mode. Once the kernel is running it'll go off looking for a filesystem that contains an OS. This might just work for you, and please let me know how it goes, either way.

EDIT - you should also copy the 'bcm2711-rpi-400.dtb' file from your existing /boot/ dir into the SARPi64 /boot dir before booting the system. I just checked and SARPi64 does NOT include the DTB for the RPi 400!

I have had a few cars in my time. Never planes or boats. Once had a *remote* control tank with a control box and a cable to the vehicle but not radio controlled. My interest is in hovercraft and when I win the lottery that is a pipe-dream I will be looking to fulfill. Sadly I haven't had the opportunity to get hold of a radio controlled one, even though it's on my Christmas and birthday wish-list as a permanent fixture.

I watched a YouTube video earlier this year of a radio controlled Thunderbolt (A10?) with JET powered engines. Another jet powered one I watched was a radio controlled BAC Concorde. Very impressive indeed.

Here's a link to me winning the scale event at the Scottish National Championships a few years ago: https://youtu.be/-Md_kSNh6Tw , and here's another where I'm using a home designed and built radio system: https://youtu.be/nBQiixDB0ws

If you have a look at my youtube channel, you'll find lots of other stuff too! But back to the topic....

I wasn't sure if the Pi 400 could boot from USB or not, but yes it can! I took my usb-key with the slarm64-current tree on it, added the sarpi64 files to the root folder, and it boots! So far, so good!

If I comment out the initramfs in the config.txt file, as you suggested, it hangs before it gets to a command prompt. Re-instating the initramfs gets me to a prompt, and I can run "setup". Unfortunately, setup refuses to acknowledge the slarm64-current tree, even if I mount it and point to it manually. Clearly there is something missing somewhere, and I don't know what it is!

If this could be made to work, it would be a much neater way of installing. Very similar to AlienBob's "usbimg2disk", which works a treat for stock Slackware!

Cheers,

--
Pete

OK. Dammit. I was so hoping this would be easy. More unorthodox and outlandish suggestions...

How much of a source-tree does slarm64 have available? Also, is the slarm64 source tree available in the same format as Slackware? If so you could use the repository URL to the slarm64 source media instead of Slackware ARM current and it *should* install the same. Otherwise, without major modifications to SARPi you are up the creek without a paddle, sir.

SARPi shizzle is designed exclusively to install the official Slackware ARM port. Always has been and always will be. What we're attempting to do here is well within the realms of a fictional Frankenstein story. As you know, Slackware [ARM] will do exactly what you tell it to do with little or no restrictions. However, that being said, SARPi was never created with illicit purposes in mind. Its explicit purpose is to facilitate the installation of Slackware ARM on the Raspberry Pi devices.

If I have any further unconventional suggestions I'll post back here.

I know what you mean! It would help if I knew how the "setup" program worked - or even where it is located. I suspect its in the initrd somewhere or other as I can find no trace of it anywhere else!
Anyway, thanks for your efforts!

Its interesting that sndsvs boot method looks very different from yours. I can get that version to work, but only by avoiding the u-boot system.

This is something of a culture shock after intel/amd!

--
Pete

Have a look at /usr/lib/setup/setup in the initrd. This may be what you're looking for.

I use the RPi repository boot-firmware, and not u-boot, because it's proprietary software designed specifically for the RPi family of devices, and (even though it's closed-source) is virtually guaranteed to just work as expected. Well, 99.999...% of the time it does, quite flawlessly. The Raspberry Pi developers are very good at solving any issues, impressively quickly might I add. So, should anything go awry it's usually fixed within hours, not days or more.

The boot method is not so important when it works. All I'm interested in, as far as Slackware ARM on a Raspberry Pi (a.k.a. SARPi) is concerned, is that it installs Slackware ARM on the RPi device(s) using the exact same means and methods intended by the developers and works perfectly as a result.

Anything less would disrespect and diminish the Slackware brand and its reputation as the most unwavering, reliable, and unabridged Linux operating system available.

I can get sndwvs system to boot, mount a drive containing the slarm64-current tree and install it, but only by not using the u-boot.bin file. I'm not sure if this gets over-written when doing the upgrade from the tree yet, as I managed to stop the keyboard from working when trying to get it to use the UK keymap! Using the US one is a royal pain, as many of the more useful symbols are in completely different places, and I can never remember where they are on a US layout!

So its currently re-installing!

I will open up the initrd and see if I can figure out why SARPI64 doesn't like the slarm64-current tree. Sarpi(32) worked fine with the slackwarearm-current tree!

--
Pete