Slackware ARM YouTube channel
 

Hello!

The first episode of Season 2 of SlackChat is now available.

Enjoy!

Thanks MoZes! :thumbsup:

Official Slackware ARM YouTube Channel - everybody should bookmark it because this is going to be really interesting!

Episode S02E02 is up, and we're doing a show and tell about maintaining Slackware ARM 14.2

Remember to like & subscribe and all that jazz.

Episode S02E03 is up, and we're merging in changes and queuing them for build.

Hello!

Episode S02E04 - Testing Linux 5.10 in Slackware ARM current is up, and this time we're testing the (at the time) new Linux 5.10 kernel on the Banana Pi, and talking a little about the boot process and U-Boot.

Hello.

Prior to pushing out an ARM change set, we need to perform a few tests.
Episode S02E05 - Reinstalling a Slackware ARM build machine is up, which is a show & tell involving performing a fresh installation and running a SIT (System Integration Test).

The installation to the Orange Pi Plus2E with SSD storage took 1hr 6 mins.

Hello.

Episode S02E06 - Let's talk about the size of your swap file, shaggy dog stories and Slackware AArch64 is up, and we're talking about AArch64, swap sizes and some shaggy dog stories.

Hello.

Episode S02E07 - Publishing Big Merge is up, and we're publishing the mammoth update from January: Big Merge - KDE, XFCE and hundreds of other updates.

Hello!

In this final episode of the Big Merge, Stuart talks about the importance of waiting a grace period after a large update so as to act quickly to fix any issues. We perform a final package batch ingest for -current and build a Security update for 14.2.

Hello!

S02E09 is up, and Brent Earl joins us again for an impromptu hackathon on Slackware AArch64. We get intimate with the initrd and finally boot a fresh installation of Slackware AArch64!

Hello

Episode S02E10 is up, and Brent Earl from the Slackware community is helping work through fixing one of the RockPro64s that's used to test the Kernel and installer, which became unbootable.

Enjoy !

There is a new episode available. Season 2 episode 11, Kernel module loader part 1. This episode should be interesting for community members who wish to develop support for additional hardware.

And the 2nd part is also up where we dig deeper.

Hello

Season 2 Episode 17 shows the os-initrd-mgr tool in action, with a quick demo of how to use it to add Kernel modules to the OS Initial RAM Disk.

Hello again,

Season 2, ep. 18. Shooting the September breeze with, well, ME.

Summary: Stuart and Brent catch up after the summer hiatus of 2021, and discuss moving forward with Slackware AArch64.

I hope everyone enjoys this episode as much as I did. -Brent

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.

Good episode. :thumbsup:

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 :D

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. :cool:

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!

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! :p

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. :D

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 :thumbsup: :D

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.

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!

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.

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? :D :p 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. :thumbsup:

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. :D

Hello!

Slackchat S02E23: We talk about the new root file system and swap labeling within the Slackware Installer on ARM, and the rationale behind it. We hack on the RTC detection code and discuss the integration for the Raspberry Pi 3 & 4.

Damned good episode. :thumbsup:

So, allow me to add some clarity to the 3.3v vs 5v RTC conundrum. It's got nothing to do with the DS3231 RTC controller, as this operates on anything from 2.8-5.5v, but it has everything to do with the button battery. Some RTCs are designed to run from the 5v power but do not put any of it into the 3v button cell battery. Other RTCs that are designed to accommodate a rechargeable battery you will generally find that there is an in-line resistor on the 5v supply. This is because you need to supply more power to a rechargeable button cell than it outputs in order for it to 'trickle charge'. Putting 5v into a 3v lithium button battery is not recommended (it could ultimately be dangerous) whereas rechargeable button batteries are designed to handle it. Not all RTCs are designed to accommodate rechargeable button batteries. That's it, in a nutshell.

Specifying the split between system and GPU RAM on the Raspberry Pi devices is a config setting passed on to the boot loader (usually within the /boot/config.txt file) and I'm not sure if U-boot supports any of them. The dtoverlays can be called via commands and settings/parameters can be specified in the same way. U-boot doesn't handle (any?) dtoverlays so it might be tricky to invoke them without using the RPi bespoke boot-firmware. Other distros seem to have managed it by various means and methods in some degree.

Fun times! It's always a pleasure to record with Stuart. :)

The config variable that dictates how much memory to put where is gpu_mem=. I read that the rpi will pick the default memory allocation if nothing is in config.txt. The Raspberry Pi foundation ships a config.txt with gpu_mem=16 for the Pi 4. I will have to look that up how that works later on for the Pi 3. Anyway, one can only assume it will do the same with U-Boot because the boot rom reads all the files then hands off kernel / ramdisk / dtb loading to extlinux.

I'm sure it is. :D For me it was always about why we were doing the slack chat podcast rather than who I was doing it with. On that note, it might be prudent for you to rearrange your setup or consider using a different microphone. Stu comes through crystal clear but you are difficult to hear at the best of times. That's not your voice or accent, it's the quality that's the issue. Like you're using a built-in condenser mic on a laptop that makes you sound muffled with some small degree of background noise/interference.

I don't know how much of the RPi memory options is relevant (if at all) when using U-boot. The Raspberry Pi Documentation offers much information and guidance - although it's not always accurate or 100% reliable. Therefore testing, testing, and more testing, is always required. The available config.txt settings is a list longer than your arm and a veritable mindfield (sic) of information.

I agree. I was using the Pinebook Pro built in microphone. I ordered a headset that should fix the muffling, background noise, and it will be here today.

Started watching Season 2 of the podcast yesterday evening and have 12 episodes left too watch

I've never heard of anyone binging on the Slackchat podcasts before.
I'd send you a t-shirt if I had one :-)

No worries, if you ever make t-shirts or stickers put me on the list ;)
i take chocolate oranges too *joking*

almost watched it all now in three-four days, have a half episode left

The latest episode is a demonstration of what I do each day while testing any changes Stuart pushes out to me. Sometimes I have to improvise. I probably could have added some commentary or text to the video. It was recorded and edited on the RockPro64. Rendering the video took 2 hours. However, editing it took about 4 hours in Kdenlive.

Hello!

The latest Slackware ARM podcast episode is a status update for Slackware AArch64.
In summary, it's almost baked and will be released to the supporters first as a 'thank you' for paying for the hardware.

As a follow up to the video regarding Raspberry Pi 3 support.. My raspberry pi 3 will start Xfce - both with and without the xorg.conf in /etc/X11. With compositing disabled, the removal of the xorg.conf, the video is more reliable and snappy. Xfce reports that VC4 V3D 2.1 driver is in use. Youtube loads in firefox and does not freeze like the Pi 4. I made no changes to config.txt in /boot.
KDE will not load in either run level 3 or 4 with the display manager (sddm).

Watching now

Thanks, x11-skel won't install a config for the RPi3 now.

One more follow up from one of the previous videos. Suspend to RAM (Sleep mode) will work in KDE, Xfce, and from a console. However, I'm not sure there is support for hibernation in U-boot or the ARM Trusted Firmware just yet.

EDIT: *For the pinebook pro*

New video out a tutorial how to install Slackware on the Pinebook Pro: https://www.youtube.com/watch?v=QKs_RnFqLO8

Excellent news!!! Looking forward to it. :)

A excellent video :thumbsup:

Got some of the Slackware swag i bought today a mousepad and a t-shirt, and watching the last episode of the Slackchat Videopodcast Season 2 now

https://www.youtube.com/watch?v=E0HBsmBbKIw&

New video about Installing Slackware ARM on a RPI4

Season 3 of the Podcast started last week: https://www.youtube.com/watch?v=EGtWe8F-p54
and Slackware Current 15.1 is out for ARM64 *listening now*