please see attached

Attached Thumbnails

 

New slackwarearm rpi4 install seems installed, off to play with it.

I can follow instructions to install slackwarearm on rpi* and bananapi but I'm not familiar with how the boot folder and related files are used, haven't had to mess with anything.

Does one of the /boot/READMEs explain how to make boot process follow slackwarearm kernel updates, I've been applying the "SARPi installer images and system packages" which works well.

Like what happens if you dump us for the new Mac or even worse archlinux?

for all you do Thank you

1 members found this post helpful.

Hi glorsplitz.

Please don't think I'm being flippant but, the obvious answer to your question would be, "MoZes would have to support the Raspberry Pi devices in his Slackware ARM distribution." Or an alternative and less desirable (3rd party method) answer might be, "You'd have to build your own kernel and modules to include support for Raspberry Pi hardware and rename the files to suit the official Slackware ARM pkgs." The former would be the preferred and ultimate solution, and the latter would be what SARPi already does without renaming the pkgs to suit official Slackware ARM pkgs.

So, unless the Raspberry Pi devices are officially supported in Slackware ARM it's not going to be possible unless you DIY or use SARPi shizzle. Official support may happen, as MoZes mentioned in one of the recent Slack Chat podcasts that he now has a Raspberry Pi device, and that would certainly be more than welcome - hopefully using Das U-boot universal boot-loader instead of the bespoke Raspberry Pi boot-firmware. Incidentally, anyone who is interested in doing it for themselves should take a look at the SARPi Sources webpage for pointers.

I cannot speak for the Banana Pi as I do not own or use one of these ARM devices. For more info on how the Raspberry Pi boot-firmware files work see this page: https://www.raspberrypi.org/document...boot_folder.md

The SARPi installer and pkgs work with Slackware ARM because that's exactly what they're designed to do. All based around Dave Spencer's excellent raspi-slackbuild original work.

Wait... what?

1 members found this post helpful.

What I meant was abandoning ship like what Niki Kovacs did with Microlinux Enterprise Desktop & Server.

1 members found this post helpful.

Slackware ARM (32bit armv7) will not have Direct Integration ("out of the box" support) for any Raspberry Pi - there's no point because the only useful RPi's (IMO) are 64bit and would be better running Slackware AArch64.

Slackware AArch64 will support the RPi if the community want to contribute support for it and if it meets the qualification criteria for Direct Integration.

I have a RPi4 8GB RAM version here that I'll look at later in the year if nobody steps up to contribute the required changes for Direct Integration.

2 members found this post helpful.

I assumed you were alluding to something like that. There will never be a good or bad time, or impertinent reason, to ask, "What happens if you pack it all in with the SARPi Project? Where does that leave the Slackware ARM on a Raspberry Pi community???" I will digress...

When the SARPi Project was formed in October 2012 I'd already been using Slackware x86 for approx. 8 years. Alas, there was no official support in the offing after the release of the Raspberry Pi and the only available options were pre-built images. So, I had a vision of creating a way to make it possible for users to install Slackware ARM on these devices in the only way it should be, as per the Slackware installer that we all know and are familiar with. I wasn't the first person to implement this idea - Dave Spencer was, afaik. After launching the SARPi Project, I imagined there'd be thousands of passionate Slackers (now that Slackware ARM was ridiculously easy to install on the device) flocking to get involved with a multitude of projects and concepts, all contributing to the well of knowledge and expertise. Boy, was I wrong! I have tried so hard and often to get people interested and motivated into being more than just end-users. Many years ago a wise man once said to me "Most Linux users don't want to do it themselves, they want you to do it for them!" and those words ring true to this day. Much to my chagrin. It wasn't my dream, my vision, my goal, or my desire, to be responsible for something that so many people depended on. I hoped others would take on the mantle and do what I have done, and hopefully do it better. But here we are and this is what I do with SARPi, and will continue to do, until there comes a time when it's no longer possible or needed.

I'm very aware that there's a great many Slackware ARM users who run it on Raspberry Pi and rely on SARPi to install the OS and keep their kernels updated periodically on their devices. Since the announcement of Slackware AArch64 the traffic and data throughput on the SARPi website has increased five-fold and it wasn't in any way quiet before then. So, there's still a shedload of interest out there for Slackware on the Raspberry Pi and it's mainly for that reason that I am prepared to maintain the project and support. I would hate to disappoint or perturb the Slackare ARM community by turning my back and/or walking away from it.

In my opinion, with regards to my personal goals and aspirations, there isn't a Linux distribution currently available that can supplant Slackware. That's not to say that everybody should feel the same. If Kinki Novacs wants to do other things then he should, without reservation and anyone else's blessing. Slackware is not an exclusive club, or cause, or religion, or right of passage, or ice-hockey team (Red Wings FTW!) that one must sell their soul in order to support, or join and take part in. If others want to move on and do their thing then existing users should be thankful for any input and contributions towards Slackware they'd made and wish them all the best in their future endeavours. Makes me giggle when I see Slackers treating other [Linux] users like black sheep or outcasts because they do not hold the same or similar opinions as them. The only thing that matters IMHO is following the right path because if other users don't then one has to subjectively evaluate what relevance there is in it for them personally. I try and aspire to follow the path. It's very important to me that Slackware equilibrium is maintained indefinitely.

4 members found this post helpful.

I'm set up for building 32-bit installers and system pkgs. So, for as long as you're distributing Slackware ARM in this capacity, I can offer support on the Raspberry Pi devices that are capable of running it, as I always have.

You are hopefully aware, as I am, that there are more Slackware ARM users running it on Raspberry Pis than any other SBC device. So, in my mind it's a no-brainer that the RPi 3 & 4 devices [c/w 64-bit architecture] are included and supported where possible.

You've previously asked me to compile a [Kernel Module Loader] '/load_kernel_modules.scr/platform/rpi4' file which I spent 8-10 hours fulfilling, and included the Raspberry Pi 3 which is also capable of 64-bit processing. I seem to remember you mentioning that certain plans had changed and you were thinking of implementing it a little differently. As a consequence, I assumed that because you haven't requested this file be sent to you that it was no longer required. Please advise.

Even so, I've read up on the "Hardware Model Custodian Development Model and Process" and have been playing around with u-boot on the Raspberry Pi 4 recently. Oh, what joys are in store! Spoiler: even with u-boot the closed-source RPi firmware binaries are still requried. The more I look into it, the more I realise why the RPi guys use their own boot-firmware shizzle.

Questions: Using the Raspberry Pi boot-firmware doesn't involve u-boot. So, when not using this new Kernel Module Loader method (and because SARPi already builds and includes the required modules and firmware for the RPi devices), is booting the Slackware AArch64 system reliant on it? Or, if everything is already in place ("à la SARPi") will the AArch64 system just load and run as expected? What (if any) are the additional prerequisites in order for things to just work?

Reason I'm asking is because I have already (re-)built the SARPi installers a few times with regards to Slackware AArch64 and am constantly testing them for efficacy. I'm trying to understand how the Kernel Module Loader fits in with the Raspberry Pi's non-u-boot features and am trying to ascertain if re-writing/re-building the installers again is anticipated.

1 members found this post helpful.

With last couple posts, this thread got really cool! Thank you both!

1 members found this post helpful.

This should take about 30 mins tops. This might be a good opportunity to lead a group who can help here?
That's the idea - anybody who wants to contribute fixes can do on the (to be created) mailing list, and I'll take them from there and reincorporate into the OS.

Oh great - I was waiting for you to finish it. Not top of the list though since I'm busy developing two ports of Slackware right now ;-)

The Kernel Module Loader has been finalised and there's a video of epic length that describes the module loading process.
Check that out. Everything is already in the source tree and has been for a month or so.

The loader scripts are now named after the SoC. Please check the format and send me the files when you're ready and I'll bundle them into the Kernel package for aarch64.

The ARM Trusted Firmware is already built for RPi3 and 4.
Any additional firmware is fine - you can figure out how to bundle it.
Even if we need to use a different branch of U-Boot or apply patches to the mainline version, that's fine. Each Hardware Model may have nuances, so I am not precious about it - the boot loader is built once and updated every now and then if necessary.
For example, once the 'pre' USB support is fixed in U-Boot for the RK3399 I'll build that and possibly not touch U-Boot again for years.

Which Boot Loader you use has no bearing on the Kernel Module Loader. The Boot Loader is out of the picture once the Kernel boots.
As I said, check out the video - it's explained in there. I will document it at some point too, but it's pretty simple and the code has inline documentation.

The Kernel Module Loader has been in ARM already for a few weeks with only glorsplitz finding one issue with the identification of Banana Pro.

What are you building? I didn't release anything..

If you go the 'extra-Slackware' route:
1. Users won't be able to use os-initrd-mgr to manage the OS InitRD (man os-initrd-mgr)

2. You'll need to write your own code to handle the automatic configuration of the Boot Loader, unless users are expected to manually configure it as is the case for ARM.

3. Things will get broken without notice. I only know what I designed and how to move forwards and roll back.

It's best to wait until I have completed the Direct Integration Hardware Exposition so you can see how it's done.

Maybe it *should* take 30 minutes "tops" once the concept and what's required is fully realised and understood. Suffice to say, I spent more than 30 minutes just trying to discern which modules belonged under the appropriate section with some of them. Sure, I went into this somewhat blindfolded starting from scratch and had to work/seek out things as I went along that I'd never even considered before! lol

We've discussed this "Hardware Model Custodian development and maintenance model" already. Even with the offer of a sexy name to encourage people to get involved, I'm not in favour of taking on any more work or responsibilities on top of what I'm doing with the SARPi Project because that in itself is more than enough for lil' old me. Right now as things stand, I'm trying to plan, prepare, and formulate with the intention of building installers and pkgs for Slackware ARM and Slackware AArch64 on three Raspberry Pi devices [i.e. RPi 2,3,4]. If in future I feel motivated towards working on any ARM devices or hardware you don't officially support then this will be something to consider. If anyone should step up to lead a group who can help here with the Raspberry Pis, or in time you decide to DIY, then I would have no qualms over it.

I'm quite content with what I do in my current capacity as SARPi maintainer and the way I do it. I'd be happier with a little less recognition and a little more anonymity TBH, but I guess that comes with the territory.

Excellent. It means less work and jiggery-pokery involved.

What I'm building and testing is [classified] for [classified] eyes only, as it involves some non-Slackwaresque skullduggery that I really don't want alienBOB to hear about because the last confession of my Slackware sins did not favour well, which I am still doing penance for. So, we'll have to wait and see what the future holds this time around.

But seriously, you will appreciate more than most users how much dedication, time, and effort is involved in software development and testing it, and I'm trying to cut down on the meantime between when you do release Slackware AArch64 and I can have a SARPi64 installer ready to roll. There is going to be some delay, but I want to minimalise any as much as possible. That's it, in a nutshell!

Waiting for you to be happy with what you're creating is the best and only option IMHO. I know what I'd like to see, and what I want to make possible with SARPi, but it all hangs on what you're doing and how you're going about it with the end result.

1 members found this post helpful.

OK cool thanks for letting us know. If anybody else wants to step up and contribute RPi support into Slackware AArch64 when it's done, they can do so without stepping on your toes!

For me, my Pinebook Pro will be here soon and that's enough for the time being.
I'll pick up development again later in the year by which time more of the RPi4 support may be mainlined.

1 members found this post helpful.

Stu, you are already aware (or should be) as we've had several discussions regarding this matter where I thought I'd made my rationale very clear. Don't you remember "the timeline of events"? If you need to recap then check your logs.

With any luck you will succeed where I've failed in convincing Slackware ARM users on the Raspberry Pi devices to roll their sleeves up and get their hands dirty.

I've always wondered about the why's of the preferred hardware. One person likes the Pi's, others prefer something else, but it always seems like there is a little bit of something going on between the maintainers and contributors. I seem to be always the last one to know/understand the behind the scenes stuff and perhaps those answers may be better suited for discord or IRC (which one is Slackware discussed on now with all the big company buy outs). I started out with a Pi running Slackware arm because I had a specific need (wanted some kind of small server to sync my phone data to replace google's back end) and ended up setting up Owncloud on a pi running Slackware ARM around the beginning 2014 (that's the oldest documentation I can find that I've written down) and later a BeagleBoneBlack then a Pi2, and later 3, etc. So I didn't go out a buy an ArmSBC just to have an ArmSBC, I used it to fulfill a need which I like to think is a similar philosophy as Pat building a dsitro, not to build a distro but to fulfill his need to distribute software. Anyway I've been trying to figure out why ARM was supported on some obscure hardware and not more popular like the Raspberry and BeagleBone. (I actually got a BeagleBoneBlack to run Slackware once when I was apparently able to focus for more than a minute). I keep trying to think of ways I could help out but have been having a hard time understanding the overall vision for ARM, Exaga noticed when I requested a feature that rasbian had but wasn't in his SARPi list for example. Maybe more of a high level why we are going this direction and not that direction might help, but then maybe I'm the only one confused, but then again its Slackware after all so you don't own anyone any explanations

enine, I could seriously keep you bored stiff for hours on my personal opinion(s) and permutations in addressing the above, and so might many other people who are involved in developing and distributing software on various hardware platforms. Everyone does things and makes choices for their own reasons and purposes. There's no easy way to simplify or explain these things when there are an infinite number of variables and subjectivity involved.

There's always something going on between the developers, and any contributors. That's not really important or relevant to anyone else, because it's the end results of what's being distributed that matter in that respect. Basically, it boils down to matching the purpose and requirements of any given software. With SARPi, I have personally chosen to follow Stuart's work precisely and I did so with a mentality that did not, and will not, deviate unless it is absolutely essential for the operation(s) of the Raspberry Pi hardware. Many, many people have come to me over the years (some with really good ideas) and suggested additions or changes to the Slackware ARM installer. I'd always think about it, and sometimes discuss it with the revelant people, and if changes were implemented as a result then it was achieved for the right reason(s). Once I start to include things in SARPi that do not feature in Slackware ARM then it becomes a question of "Why did you include <ABC> idea from <that-user> and you won't include <XYZ> suggestion from <this-user>?" and it has the likely potential of spiraling downwards and becoming very messy from therein. IMHO it's not only better to vehemently stick to what Slackware distributes as closely as possible, it's essential.

In general, knowing/understanding what goes on behind the scenes is only relevant if it's not just to satisfy curiosity, or be nosey. The Slack Chat Podcast includes a hell of a lot of Slackware ARM workshop information that any software devs and interested parties may find motivational and enlightening. For any additional insight on that score ask Stuart.

Your vision is your own affair and dream to realise. It's usually how much of other people's conceptualisations you incorporate into your own vision that dictates how you will, or might, proceed. These are generally very personal considerations with fluidic parameters. How accurately you may decide to follow any given path in order to realise your goal(s) is your prerogative alone.

My advice to those who want to get involved in any venture is to find a reason, or purpose, or a hole, and then fulfil it. Something that's not been done, or has already been done and take it to a higher level/standard. There are things in other distros that I think might be cool to include in Slackware but that's not my decision. Usually if I want something I'll build it but I won't include that in any SARPi batches.

Slackware has never been in competition with other Linux distributions and it's ultimately Patrick who dictates what should be done and why. It's his brand and he's the head honcho, big cheese, El Jefe, of the entire project. Stuart follows that explicitly with Slackware ARM and does a supreme job with it. I follow Slackware ARM with SARPi shizzle to the best of my abilities. That is the order of things.

2 members found this post helpful.

glorsplitz, apologies if I took your thread too far off of your intended topic.

Exaga, that helps knowing your following Stuart's work precisely, my (wrong) expectation was all the tools to use the GPIO and such would be there, that it would have the same functionality of Rasbian. Now it makes sense why it doesn't. I'm reading more of your documentation, found the youtube channel and will look up the podcast. Looks like a lot of what I want should be in Slackbuilds anyway.

FWIW the reason I want to use the PiZero is I have one of these https://en.wikipedia.org/wiki/HP_200LX and want to put a zero in it to run Slackware. But mine has a bad display, so that project has been on hold for a while.