Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
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.
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
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.
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
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.
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.
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).
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.
The "Setting up a wireless network connection on Slackware ARM on a Raspberry Pi" mini-project guide has been revised and updated with 'NetworkManager'...
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.
Last edited by Exaga; 08-10-2020 at 05:46 AM.
Reason: old age
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Slackware ARM on a Raspberry Pi - SARPi updates
- it's very quick and easy to put the system back to the state it was, in a fully working order. 
