Wifi missing on Sarpi (32bit) with RazPi 4
 

Freshly installed Sarpi 32bit here. It's sitting up and booting. I did remove the initrd.gz, and the few lines at the end of /boot/config.txt that tell things to load an initrd.

wlan0 doesn't seem to be detected by the kernel AT ALL. I see no messages during boot, ifconfig shows me 'lo' & 'eth0', but no wlan0.

lspci shows me only 2 lines (PCI Bridge & usb-3.0 hub), lsusb has 4

ID 1d6b:0003 - a usb-3.0 root hub
1908:0226 - a GEMBIRD :-o??
046d:c534 - A Logitech Unifying Hub, a keyboard/mouse thing which works
1d6b:0002 - a usb-2.0 root hub

I don't see ethernet or wifi during bootup, but the eth0 at least shows up. Raspbian configures itself automagically with networkmanager, but has no more info. I'm trying to set up dhcp/wpa_supplicant with init scripts, so I don't need X to get wifi. I'm not exactly a novice with networking.

As previously stated; you haven't installed SARPi - you have installed SLACKWARE ARM. Nobody ever installs SARPi - because it's ONLY an installer for Slackware ARM! It's impossible to install, or run, the "SARPi" operating system as there's no such thing.

Raspberry Pi 4 wireless guide: https://www.linuxquestions.org/quest...ons-4175666921

Thx for the reply.
I appreciate you might want this called called Slackware Arm.
The one diagnostic line I took out of your reply was this:
Wifi on Slackware has always involved a bit of 'bending it straight' for me, with config files, but once there, it's dead reliable. That gave me a starting point.
As for firmware, I noted that the wifi appeared to come and go, but the solution appeared to be to update. Looking at the firmware, however, it seemed to change little. The one binary (brcmfmac43455-sdio.bin) seemingly capable of running things had the same md5 and size @477K.

When I checked with Raspbian (which had wifi out of the box, dead reliable & no complaints), they had a different setup. Now, knowing my luck, the wifi on the RazPi 4B might not be the brcmfmac43455, but no doubt you'll steer me straight on that. But the brcmfmac43455-sdio.bin file on Raspbian is over 100k bigger, and a second binary blob seems to be there. Why the difference exists would be interesting My x86_64 kernel (5.4.30) has your arrangement

Now that solves puzzles for me. One of the best kept secrets seemed to be what the identity of the wifi chip was. It's no longer a chip, of course, it's an IP core occupying some corner of the silicon wafer, but it still has compatibility with an IC design, and hardware features & specs. I'm very glad it isn't any of the bcm43xx family which I've duelled with previously in days gone by.

Then a little detective work informed me I had a 5.4.22 kernel in the boot image, and only 5.4.36 modules, which aren't going to work together any time soon. But I have things to prepare for, so this is going to have to wait until I have time. I'll try and run down the alternatives on the firmware. I have Arch here somewhere I'll get to look at also. I'll get to the bottomofit and post again for the record.

I don't use the onboard wireless on the Raspberry Pi 3 or 4. If and when I do use wireless it's via a USB adapter with a chip that's supported by Slackware. The only reason I bothered to spend time and effort getting the wireless working was because a Slacker using a Raspberry Pi alerted me that the onboard wireless had stopped working on the latest SARPi updates. Whenever that was I don't recall.

[EDIT] example of the sort of USB wireless adapter I'd use: https://sarpi.fatdog.eu/index.php?p=wireless-nic

Often you can borrow drivers from other distributions in order to get things working on Slackware ARM. In the case of the onboard wireless, mralk3 posted this little gem for the RPi3 that is very relevant to the RPi4 - https://www.linuxquestions.org/quest...7/#post5840054

I'm not very keen or willing to include things in SARPi which aren't already present in Slackware ARM proper. The RPi not being an officially supported device has some grey areas in that respect - the onboard wireless being one of them. One needs to look beyond established parameters when working outside of the box.

Thanks for the link.

Being a hardware guy, who raised his kids by fixing other people's problems (Mainly Industrial Electronics), a certain dogged determination sets in when pursuing things that should work but don't. I get it that Slackware Arm is not of the standard of an official release. But I have 2 sets of firmware, possibly a third in Arch, I still have to line up

Boot Kernel Version = Firmware version = kernel modules version

which is pretty elementary in getting things right. I know Firmware is pretty promiscuous as regards kernel versions, but significant changes to the module may result in a different sharing of tasks between module & kernel. The Raspbian kernel is 4.x.x and slaxckware is on 5.x.x, and probably patched. I've gathered also that the file ordering on /boot may be important, but it's not easy to discover what the correct ordering is, or to switch things around. I've actually achieved nothing since I last posted, as I was attending a meeting last night.

From my maintenance days, I know you're not beaten until you run out of ideas. I'm not out of ideas. I wanted to install a system that worked, but that isn't there. If I bend it straight and make it work, I'll share it. If you bought a good usb wifi with 802.11 b,g, & n support and using firmware/modules already present which sits up and works without hacking, I'd appreciate knowing what it is. I'll post again when ideas are low, or when wifi is up.

Also, the usb has 2×USB2.0 & 2×USB-3.0 ports, and if you know which is which, I'd like to know. I have an Amazon keyboard/mouse setup in one, and I'd like to make sure it's usb-2.0.

Right. With Slackware-Arm-current(32 bit only), I updated to

• kernel_sarpi4-5.4.40-armv7l-1_slackcurrent_13May20_sp1.txz
• kernel-modules-sarpi4-5.4.40-armv7l-1_slackcurrent_13May20_sp1.txz
• sarpi4-boot-firmware-armv7l-1_slackcurrent_13May20_sp1.txz

That was all 5.4.40 stuff, but lacked headers or firmware. So I downloaded the 5.4.40 kernel source, copied & unzipped the config, and from the RazPi 4, I ran
make headers_install
make firmware_install
I did use a $DESTDIR option to package them, but it was ignored.
After I rebooted, after making sure MY kernel was actually 5.4.40.
Wifi worked with little trouble. My usual fix on /etc/wpa_supplicant.conf using wpa_passphrase, and then one line brought things to life.

For posterity, despite the firmware install, I'm still on Raspbian firmware This arrangement works without issue - today. All the Raspbian version numbers are followed by a '+' so my guess in there's some patching going on. I favoured these, with 2 binaries and the bigger file size on brcmfmac43455-sdio.bin.
The standard kernel arrangement is That offers 2 unnecessary text files and only one smaller binary blob.
I'll fart about with the firmware and try to break it, but I haven't even added a single luser to this install or started X yet, so I'm not going to put the cart before the horse. But I want to retain a wifi connection without a battle. It's a basic minimum for me.

I've made some experiments on wifi, and I'll report them here.

The Raspbian/Noobs/Debian distro has little issue with wifi - it just works. Slackware Arm does have issues with wifi unreliability, I am informed. I know enough about firmware to ignore text files. Anyone writing firmware is not going to include all the palaver of text interpretation, Unicode, etc. Noobs/Raspbian/Debian has Whereas the standard kernel gives which is just one binary @477K, and three fairly useless text files. So taking the file 'brcmfmac43455-sdio.bin' in some form to be necessary, the text files as unnecessary, I set about experimenting.

• I started with the Noobs pairing of brcmfmac43455-sdio.bin @587K, & brcmfmac43455-sdio.clm_blob @14K, which AFAICT are reliable. and it seemed to give good debug output. Wifi worked.
• Removing the blob file brcmfmac43455-sdio.clm_blob @14K killed the wifi, but restoring it restored wifi. Therefore, it is necessary with the 587K brcmfmac43455-sdio.bin
• Using the kernel file brcmfmac43455-sdio.bin @477k didn't kill wifi.
• Removing the blob file with the kernel brcmfmac43455-sdio.bin @477K didn't kill it either, although this combination is apparently unreliable, as evidenced by the fact that some here have invested in usb wifi. This combination was highly under suspicion when I couldn't initially get wifi going.

I am led to the conclusion that the (probably patched) Debian/Noobs/Raspbian wifi firmware including the blob file is the safest way to go for reliable wifi. Maintainers who agree with me may make changes based on this information, but I'm not going to agitate for any.

I've been using the stock Slackware ARM kernel headers, even with newer versions of Sarpi kernel packages. In general, it's best to leave the kernel headers alone, even after a kernel update. Also, running Raspbian on my pi4, I had many issues with wifi. Wifi problems are not specific to sarpi project distributed modules or firmware packages. They exist in Raspbian too. You may have used firmware for the pi4 from the Debian guys that was working. There are not any "Sarpi" developed firmware and other packages sources. Exaga only packages what the Debian guys put out, so if you have problems with wifi, report it upstream as well.

I don't think I reported messing with headers. I reported updating them, but I agree, they can be left as a rule. I reported on firmware issues. As there is general acceptance that Slackware Arm wifi is unreliable, I am using Noobs/Raspbian/Debian firmware. That's my choice. But I wanted the latest firmware, and putting updating the headers gave me a fixed timeline for everything.

Both the RazPi with it's challenges and the nature of posting here are new experiences for me. There seems to be more focus on procedure here, and less of the 'your distro, your way' that exists in the Official X86 forum. I am definitely attempting 'my distro, my way.' In the X86 forum, people would weigh in with suggestions even if they thought I was crazy.I certainly did when I could.

To my knowledge Slackware Arm puts out what the kernel supplies as firmware. This has been unchanged over many versions, but Debian have apparently modified it as I reported. You can check that by exploding a few packages if you don't believe what I wrote. That's why I wrote it. Unlike many others, I have not yet had wifi failures. But I had to choose, and reported what I chose. This isn't actually my first RPi. I had an RPi 0(?) some time back. Maybe an RPi 1 - I just don't remember.

As an ex-hardware guy, I know the chip market. Broadcomm sales policy is to make agreements with manufacturers to use Broadcomm chips in exchange for discounts & tech support. Raspbian no doubt have deals with Debian, and with Broadcomm. Of the Linux distros out there, only Debian have access to tech support from Broadcomm (Through Raspbian). They may have had to sign confidentiality agreements; hardware companies are incredibly paranoid that way. Broadcomm are no friends of Linux, and the B43xx stuff had to be reverse engineered back in the day.

I've not noted any instability or unreliability with Slackware ARM "wifi". The culprit (if there is one) on the Raspberry Pi 3/4 would be the Cypress wireless shizzle. This is just one reason why I prefer to use a plug-in USB adapter if/when I have to use a wireless Internet connection. Otherwise I stick with a trusty Ethernet cable.

Whatever works is usually best. If it works as expected it's all good.

Really? Enlighten me, please. I'd love data. The part number is enough. I find hardware spec totally unavailable for the RazPi 4.Broadcomm think they can do wifi, but I didn't know Cypress did.

I've had a stroke, snd 2 fractured hips led to 2 replacements. The 2nd had some super-difficult-to-dislocate socket which restricted movement, so reaching the ground is a huge deal for me. For that reason, wifi is pretty essential for me also.

I was somehow convinced that wifi on the RazPi 4 was an IP core for the BCM43455, in some corner of the 2711 APU. The WiFi specs are excellent: 2.4Ghz & 5Ghz ranges (the 2,4 Ghz range is only 12 channels and quite crowded). Also 802.11 b,g, & n (the fast one). I find it necessary occasionally to do a wifi scan, and switch channel to the least occupied one. The thing is, after so long out of the game, Cypress would have to put considerable effort into R & D to enter a new market area to compete against developed technologies of companies like Qualcomm, Realtek, Intel & Broadcomm. There is also the issue of having to circumvent existing hardware patents. Even there, I still think Intel is playing catch-up like they're doing with their sucky graphics.

From here, that link resolves to an autoplaying Rick Astley video :(. LA Times have obviously changed their content. Nevertheless, I got some interesting links. The RazPi 3 has the CYW43455 wifi chip, and apparently has a problem with
doing full duplex, and is vulnerable to the KrOOK(?) bug. I would agree it was a poor choice. The search hits on Cypress or CYW43455 seem to be lacking with the RazPi 4. Was it just a RazPi 3 problem.

Full duplex is a big one, because you have to stop a download to say "OK, I got that - carry on." Worst of all, of course, if the CYW43455 doesn't know that. I'm inclined to ignore security bugs, because I'm below the radar for hackers really. About the worst they can do is hose the system, which I usually have backed up. If they download my disk, they'll get nothing.

/Much Later

I'm going to leave this for the moment. I want to take the time to thank you (Mozes, Exega & the team)for your prolific work in bringing Slackware to Arm. This, I presume is rewarded solely by the output. It's a worthwhile cause and an interesting challenge that I unfortunately cannot get involved in, as my health does not permit it.

Despite many ups and downs here, your OS installed like a regular Slackware OS. On X86_64, Slackware will probably change a bit next release, if Alien Bob's repo is anything to go by. I think mine is a different and minority use case to Slackware Arm and the folks you're mainly catering for, so I've reluctantly made a break from Slackware, and undertaken duelling the demons of systemd & NetworkManager with a debian based 32 & 64 bit os. They're on different sdcards and from different re-badgers, but if I need outside software I can stick it on 32bit, the rest of the time I'll use 64 bits.

So folks can stop leaving quiet jabs or flames because I won't be around:). I do need retraining occasionally, but I'm sure I'll get it elsewhere.

business_kid, it sounds like you’ve had an interesting ride.

About wifi on RPi 4 with SlackwareARM -current, there was a short time (two SlackwareARM and Sarpi kernel updates, during which also there was a bunch of my messing around) when it could see the router wifi but couldn’t connect to the internet via wifi whereas wired it could connect to the internet, but I never did sort out why - after a 3rd update and a bunch more of my messing around, the “problem” went away (in quotes because I use wired almost always.)

Mostly I’ve used my RPi for everyday desktop stuff and for weekend playing with my Arduino Uno (I adapted the 14.2 Slackbuild for ARM -current.) For that SlackwareARM with Sarpi packages has worked great.

I hope your health picks up, and if SlackwareARM isn’t working for your use case, that you find what you need elsewhere.

TKS