Season 2, Ep. 19. Slackathon - Raspberry Pi4 & Pinebook Pro.

Summary:

Season 2, Episode 20 - Slackathon - Raspberry Pi 4.

We're finalising the RaspberryPi4 support in Slackware.

1 members found this post helpful.

Good episode.

What struck me was the amount of work involved in setting up the system to run the Slackware AArch64 installer. Although u-boot seems overly complicated you had it all worked out before you rebooted and loaded it, which was kind of impressive - but rather you than me, as I prefer the easy life. lol

Can't say I've had any problems with the Kingston SDCG3 "Canvas Go!" range of SD cards I currently use. I run Slackware ARM and build all the installers and pkgs on them repeatedly. Cheaper and lower quality SD cards do tend to fail more frequently, in my experience. I'll assume it'll be a similar affair with Slackware AArch64 but time will surely tell.

It's all looking really great Stu. Can't wait until you release it into the wild and I can put the fruits of your labour to very good use.

1 members found this post helpful.

What do you mean? There's not much work involved in dd'ing the installer image to an SD card, inserting the SD card into the RPi and powering it on.
That's all you do.
The Micro SD card is transformed into the Slackware OS /boot partition automatically.
You didn't see dding the installer in the video because I already had it on another SD card, so I just booted it.

It's feature rich. The U-Boot config for Slackware is essentially a few lines but is heavily commented.
What's more, the U-Boot config for the RockPro64/Pinebook Pro will boot the RPi without modification (assuming the same block device is used for the root fs).
You're going to love it!

3 members found this post helpful.

Hi Stuart, in your last video i saw at the end that the default's target block device is set to /dev/mmcblk1... Why not conserving the standard /dev/mmcblk0.. as in SARPi's installer?

I mean, the Raspberry Pi boot loader and firmware take care of everything and you're using u-boot. So, to me it looks like a lot of work that I've never had to be concerned with. It'll be interesting, and hopefully educational, to see how you've done it using u-boot.

That, I do not doubt whatsoever!

However Stuart has decided to implement support for 64-bit compatible devices is his prerogative. All that matters is that it works and is reliable, for which Slackware is irreproachable. So, don't worry about it.

Maybe the way in which people expect the SARPi installer to work is about to change. First we'll wait until Stuart releases Slackware AArch64. Then take it from there. Slackware leads and SARPi follows. That is the order of things.

Installer upgraded to 5.15.8

1 members found this post helpful.

Slackware ARM is running kernel 5.15.10...

The RPi is non-standard, where as U-Boot (and a few other boot loaders) are, so a portable and standard boot loader is always required if you're supporting Hardware Models in addition to the RPi.

Re the numbering of mmcblk --I did explain in the video about that. U-Boot has detected the single Micro SD card as number 1, as has Linux. However it also occasionally appears as 0. I don't know why at the moment and it's low importance. However, one benefit of it is that it highlighted a bug in /sbin/probe in the installer, which I fixed and is merged back into Slackware upstream.

2 members found this post helpful.

Sure thing. I was only referring to the RPi boot loader vs u-boot. When I worked on the Hummingboard many moons ago, and the Orange Pi just before you started to support it, it took a lot of time and effort for me to get u-boot configured successfully. The RPi boot loader just works and all the hard work is already done, even though it's proprietary, bespoke, and non-standard. I don't think either method for the RPi is more preferable, as whatever works and gets the devices booting is the objective.

That's one of the objectives.
The other is having a consistent approach across all Hardware Models that can be managed by the OS toolset without an array of exceptions.
That's my approach for Slackware anyway!

1 members found this post helpful.

I've been playing around with the RPi boot loader and it'll be very easy to support using it instead of U-Boot with seamless Kernel upgrades; as I can add a hook into the Kernel package's post installation script to call another within /boot/local which updates the Kernel, OS InitRD and DTBs on the RPI BL's FAT partition.
I won't do that now but it's a 30 minute job and straight forward to implement and document.

3 members found this post helpful.

Yes, I know you much prefer to use u-boot as we've discussed it previously a few times. For me the RPi boot loader/firmware was the easiest option to get Slackware ARM installed and running on the devices, and I don't have to spend time and effort building it, maintaining it, or fixing it.

I would seriously LMFAO if you did, but never say never. Right? lol (but seriously, I would probably disown you)

I fully understand why you've chosen u-boot and it makes perfect sense from an official Slackware perspective. All that closed-course RPi shizzle is undesirable when there are open-source alternatives available. I'm very happy that you're doing it the way you are and more than interested to see how you've put it all together. Also very glad you've decided to support the RPi devices, after constantly bugging you for years to do it. It makes perfect sense to include the most popular ARM device on the planet in your Slackware portfolio. With that, and the release of Slackware AArch64, these are very exciting times indeed.

I've already done it. I had a vision of you lying awake in a cold sweat and it broke my heart.

It won't be supported in the Installer but one can switch to it post installation.

HAHAHAHAHA! I know (i.e. without evidence but it's a fair guess) that you've done the same as I have on many occasions with Slackware, which tranlates to "things you'd never publicly admit to". Such things that we do behind closed doors stays there.