Slackware ARM on a Raspberry Pi

Exaga · 04-17-2020, 01:41 PM

First I'd like to take the opportunity to convey my most sincere best wishes to each and every one of you during this world-wide crisis and trust that you shall remain to be in the best of health throughout this coronavirus pandemic. These are the most difficult and challenging times in which we live.

I just want to give you a heads-up that the SARPi Project has updated its Slackware ARM -current installer, now running Linux kernel 5.4.32, along with quite a few other package updates. These are available from the SARPi downloads page:

https://sarpi.fatdog.eu/index.php?p=downloads

Along with the expected packages for the Raspberry Pi 2/3/4; kernel, kernel modules, and boot-firmware, you will also find updated packages for Nginx, Docker, Google-go-lang, rTorrent, and other supporting software. If you find yourself in the state of lockdown within your country [as I currently do] this may be an opportune time to roll your sleeves up and get stuck in to some productivity with Slackware ARM on the Raspberry Pi!

If you've never got to grips with portable, scalable, OS-level containers then Docker is a great way to start! Likewise, if you've ever wondered what "Apache on steroids" is like then give Nginx a try because it truly rocks! One of the advantages of Slackware ARM is that when things go awry with new (and perhaps, unfamiliar) software, or if/when you mess things up - like I do quite often

- it's very quick and easy to put the system back to the state it was, in a fully working order.

Please feel free to "knock yourselves out" with the above updates and be sure to share any relevant or fun things you find to do with them.

Most of all, be well and stay safe. <3

TheTKS · 04-19-2020, 10:26 PM

Everything is working well after updating RPi4 SlackwareARM -current and sarpi kernel packages to 5.4.32.

There are several new packages since I last updated. You continue to be busy bringing us new goodies for RPi4. Thanks for all of it!

I hope you are staying healthy and doing well.

TKS

Exaga · 04-21-2020, 06:27 AM

Quote:

Originally Posted by TheTKS

Everything is working well after updating RPi4 SlackwareARM -current and sarpi kernel packages to 5.4.32.

There are several new packages since I last updated. You continue to be busy bringing us new goodies for RPi4. Thanks for all of it!

I hope you are staying healthy and doing well.

TKS

Glad to hear everything is working as expected. That's down to MoZes' artistry much more than my own.

The new packages have existed for approx. a couple of months. I have not really been that busy, although it may appear to be otherwise. I've just been using and testing the new packages periodically with a specific goal in mind. Especially Docker. I had a brainstormed "Eureka!" moment that [for example] Raspbian users might like run Slackware ARM in a container to get a feel and idea of it without having to install it first. However, I've since learned that Docker on Raspbian isn't as assured or straight-forward as it certainly is under Slackware ARM, which somewhat kills my plans. As an alternative and consequence, I thought that others may like to have access to these new packages and may find a similar or different use for them, if they had time on their hands [as I do] due to the covid-19 pandemic.

Every thing here is all good with me. Health and welfare is being maintained. Hope yours is too TKS. <3

Exaga · 04-23-2020, 02:29 AM

Slackware ARM package nginx 1.18.0 is now available:

https://sarpi.fatdog.eu/index.php?p=downloads

akalinin · 05-03-2020, 10:52 AM

A big THANK YOU to the SARPi team for an awesome Slackware ARM tutorial. I run Slackware on my desktop and wanted a similar experience on a Raspberry Pi to run my little experimental website.

My Pi 4 fired up at 0230 Detroit time today and is running great.

Thanks again!
Albert

Johpin · 05-12-2020, 11:22 AM

Suggestion to add to sarpi4-hacks (for Raspberry Pi 4):

Commenting out 'Driver "fbturbo"' in /etc/X11/xorg.conf.d/xorg.conf

Reason: decreases cpu load

glxgears -info -fullscreen
gives:
GL_RENDERER = llvmpipe (LLVM 10.0.0, 128 bits)
GL_VERSION = 3.1 Mesa 20.0.5
216 frames in 5.0 seconds = 43.090 FPS
top: cpu 17% idle

glxgears -info
1845 frames in 5.0 seconds = 368.861 FPS
top: cpu 43% idle

After commenting out in xorg.conf: Driver "fbturbo"
glxgears -info -fullscreen

Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate
GL_RENDERER = V3D 4.2
GL_VERSION = 2.1 Mesa 20.0.5
247 frames in 5.0 seconds = 49.339 FPS
top: cpu 96% idle

glxgears -info
300 frames in 5.0 seconds = 59.998 FPS
top: cpu 99% idle

Exaga · 05-13-2020, 04:12 AM

Quote:

Originally Posted by Johpin

Suggestion to add to sarpi4-hacks (for Raspberry Pi 4):

Commenting out 'Driver "fbturbo"' in /etc/X11/xorg.conf.d/xorg.conf

Reason: decreases cpu load

Hi Johpin and thanks for your suggestion.

The more I read into disabling fbturbo the more I realise that it has the potential of being a 'can of worms'. In some end-user cases it's required in order to get certain touchscreens working, but not all. In other cases it messes with display settings on a level that may be headache inducing. This is not specific to the RPi4 as I've read about issues with having fbturbo enabled/disabled on the RPi3 which also appear to be troublesome in some cases. It's going to be down to each individual user, whether or not disabling fbturbo is beneficial. For example, in my situation it means no benefit at all because I work remotely 99.9% of the time and do not use the X desktop.

Therefore I don't think it's wise to make this change across the board for all RPi4 users by including it in sarpi4-hacks. Mainly because it's specific to requirements. So, this effectively means if the end-user wants to disable fbturbo themselves then it's up to them, either by choice or necessity. I'd rather not make that decision for all users in the event that it causes any problems.

business_kid · 05-22-2020, 05:02 AM

Just on the subject of suitable GPU tests, I was in constant communication with AMD devs after they restarted Linux support around 2007. ~I had real issues, and quoted glxgears at them. They replied that glxgears only uses one or two OpenGL commands, so was not a suitable test. The result on a lousy card could probably be rigged.
Many good tests are out there, the Phoronix Test Suite among them.

Exaga · 05-27-2020, 05:13 PM

FYI and those who may be interested...

A few Slackware ARM -current pkgs have been rebuilt:

docker-ce-19.03.8 updated to 19.03.9
goaccess-1.3 updated to 1.4
nginx-1.18.0 updated to 1.19.0

Available to download from the SARPi website: https://sarpi.fatdog.eu/index.php?p=...ads#currentpkg

louigi600 · 05-28-2020, 03:38 AM

Anyone that may need, for whatever reason, to run slackwareARM 14.2 on a RPi4 here's a workaround (that I've tested so far only on a text console environment, not sure if GUI could start rasing troubles but theoretically it should not):

The slackwareARM 14.2 softfloat userland will just never ask the kernel to perform hardfloat operations, so, as long as the kernel is able to do everything else (no reason why a hardfloat kernel specifically configured for RPi4 shouldn't be capable of supporting everything else) using softfloat userland with hardfloat kernel should be fine.

Just use the SARPI RPi4 packages for slackwareARM-current kernel, kernel modules, kernel firmware, hacks and boot firware with slackwareARM 14.2 userland (wheather it be the SARPI installer for RPi3 or a miniroot from Mozes).

Exaga · 08-09-2020, 04:24 PM

The "Setting up a wireless network connection on Slackware ARM on a Raspberry Pi" mini-project guide has been revised and updated with 'NetworkManager'. Previously it was using 'wicd' which is no longer included in Slackware. Thanks to TheTKS for suggesting the changes to the SARPi website.

SARPi wireless network connection mini-project URL: https://sarpi.fatdog.eu/index.php?p=wireless-nic

TheTKS · 08-09-2020, 08:37 PM

Quote:

Originally Posted by Exaga

The "Setting up a wireless network connection on Slackware ARM on a Raspberry Pi" mini-project guide has been revised and updated with 'NetworkManager'...

SARPi wireless network connection mini-project URL: https://sarpi.fatdog.eu/index.php?p=wireless-nic

Great to see that done so fast. Thanks, Exaga!

TKS

Exaga · 08-10-2020, 05:39 AM

Quote:

Originally Posted by TheTKS

Great to see that done so fast. Thanks, Exaga!

One thing's for sure... 'NetworkManager' is a lot more user-friendly than 'wicd' ever was.

Hint: Disabling the RPi WNIC, if you're not going to use it, is advised. Having it enabled gave me a few problems when it came to addressing the udev persistent network rules.

If you plan on using the on-board wireless then good luck with it! I put this line in the /boot/config.txt to disable the on-board WNIC at boot time:

Code:

dtoverlay=disable-wifi

NetworkManager is working really great on Slackware ARM -current on the RPi4 for me. Right now I'm using a Ralink RT5370 USB2 adapter. Been connected via wireless on my test setup for almost 20 hours. Hammered the bandwidth throughout. Connectivity is flawless. Data transfer speeds are near maximum for this test setup. Not a glitch, niggle, or concern, to speak of.

business_kid · 08-10-2020, 06:14 AM

Quote:

Originally Posted by Exaga

Right now I'm using a Ralink RT5370 USB2 adapter.

That Ralink 5370 seems to be turning up in a lot of 2.4Ghz/5.8Ghz wifi dongles. The only linux driver I found was from 2012 and evidently was tested against a 2.6.1-2 RHEL kernel. I imagined the includes needing 'bending straight', to put it mildly. There's been no security fixes to the firmware in 8 years, I suppose. You have it updated in the current kernel? It certainly solves the 'metal case' issues. Personally I'd never have bothered if the fans didn't sound like an aeroplane engine.

Exaga · 08-10-2020, 06:55 AM

Quote:

Originally Posted by business_kid

You have it updated in the current kernel?

I'm using whichever modules MoZes includes within Slackware ARM for the RT5370 device.

Code:

root@torq:~# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=rt2800usb, 480M

rt2800usb module needed loading and then it all just works perfectly.