RasPi 3B - WiFi Not Detected

[CentralWare]

With the exception of Pi-0W the rest of our RasPi racks are Ethernet based.
Since the Pi3B is supposed to have wireless onboard, I picked a few of those to run a wireless project on and immediately ran into a wall.

cpuinfo Model: Raspberry Pi 3 Model B Rev 1.2
version 15.x ArmHF
uname: 6.6.47-piCore-v7

Installed firmware-rpi-wifi, wireless-KERNEL and wifi

Code: [Select]

tc@box:~$ sudo wifi.sh
No wifi devices found!

I checked config/cmdline and didn't see anything that would disable wireless.
I'm formatting an SD card for Raspbian Full as we speak (Yawn...  36% Complete) just to test the 3B and make sure it's fully functional, which it likely is, but figured I'd stop in here and see if anything has changed in piCore over the years that could affect this?  (piCore isn't released the same as it used to be - so maybe things operate differently?  Or missing pieces, maybe?)

Thanks!

[Paul_123]

Did you apply the cmdline option from the release thread. https://forum.tinycorelinux.net/index.php/topic,27338.0.html

So now I know it affects the zeroW, Zero2W, 3B.   Pretty sure the 4 and 5’s are not affected.  Although normally it connects, and then crashes without the driver option.

[Paul_123]

The raspi WiFi is pretty verbose in dmesg.  What do you see in ther, does the firmware load?

[CentralWare]

Removed everything except mc.tcz from onboot.lst and rebooted.
(Created a script in /opt to load extensions and do a dmesg dump.  That dump is attached.)
The extensions (tce-) LOAD, no errors reported, no nothing in fact.  (...and no wlan0)

The MAC setting has been set in cmdline (as shown in dmesg) to no avail.

Code: [Select]

[    0.000000] Kernel command line: coherent_pool=1M ... brcmfmac.feature_disable=0x82000 zswap.compressor=lz4 ...
[    0.000000] Unknown kernel command line parameters "nortc noembed", will be passed to user space.
...there's no mention of BCM43438 (brcmfmac) in dmesg save for the command-line entry.

...

Update: Three (3) Raspberry Pi 3B v1.2 boards, all identical and purchased on the same date. None of these units have had GPIO related projects (thus the 40-pin is unused on all of them) and none of their history (projects) are out of the ordinary to where the boards could have been inadvertently damaged (they're DIN rack mounted,) however, TWO of the THREE boards don't even respond as to having the radio chip installed (though it's plain as day on the bottom of the boards!)  Unit number 3, however...  as soon as I launch my script loading firmware/drivers/wifi shows in dmesg instantly and ifconfig -a shows wlan0

Is there a kill switch (or enable switch) for brcmfmac that you know of ?
modprobe.conf is empty as expected (this is a clean 15.x install)

[Paul_123]

The only kill switch I know of would be if you manually added dtoverlay=disable-wifi to your config.txt   I would not expect anything in dmesg until you load the wifi drivers extension.  Obviously the firmware needs to be loaded first or in the same tce-load call.

The only thing I remember from back then is that these boards and wifi chips were extremely sensitive to not working without enough power.   This is about the time everyone started making 5.1v power supplies to be sure the pi was still getting enough voltage after the cable/connector power drop.

[Rich]

Hi CentralWare

... Is there a kill switch (or enable switch) for brcmfmac that you know of ? ...

util-linux has the  rfkill  program that might be worth checking out:

Code: [Select]

tc@E310:~/Scripting/AddressParser$ rfkill --help

Usage:
 rfkill [options] command [identifier ...]

Tool for enabling and disabling wireless devices.

Options:
 -J, --json             use JSON output format
 -n, --noheadings       don't print headings
 -o, --output <list>    define which output columns to use
 -r, --raw              use the raw output format

 -h, --help             display this help
 -V, --version          display version

Available output columns:
 DEVICE      kernel device name
 ID          device identifier value
 TYPE        device type name that can be used as identifier
 TYPE-DESC   device type description
 SOFT        status of software block
 HARD        status of hardware block

Commands:
 help
 event
 list   [identifier]
 block   identifier
 unblock identifier

For more details see rfkill(8).

[CentralWare]

Obviously the firmware needs to be loaded first or in the same tce-load call.

My make-shift wireless script does all four in one tce-load call.
The onboot listing was firmware, then wireless-KERNEL then tools.

...if you manually added dtoverlay=disable-wifi to your config.txt

Nah, everything's fresh/default and I looked for overlays before I posted just in case something was in config to en/disable wifi/bt and to familiarize myself with the 15.x layout

SD is a fresh 15.x where mmcblk0p1 is 1GB fat32 and tce resides on it just to make my life simpler.
onboot owns the show; wpa_supplicant is called via bootlocal with a wait loop allowing wireless to settle and wlan0 to become available; loads wpa_supplicant.conf - otherwise dmesg > logfile

Confirmed: RasPi 3B (A+/B+ untested thus far) does in fact go "wonky" without the broadcom entry in cmdline

Power supply is 90W 3.3/5/12 USB-C (supposedly regulated - but I never benched it to prove it) but will look into psu issues just in case.

** Sadly, I vaguely recall a board conversation (which I thought was here -- but can't be sure) regarding the Pi3 and the radios and a vague inkling that something ridiculous like I2C plus IPv6 or what have you being a prerequisite (back then) of getting wifi and/or bt to play nice...  but so much as changed since then it could only be hoped kernel patches/fixes went into the mix between then and now.  Then again, I also remember an overlay fix that was needed to create alias/range addresses on wireless (ie: wlan0:0) and a problem with bindings where if wlan0 was used as a fail-safe it would crash the driver when eth0 went down...  too many memory fragments...  no defrag!!!

Back in the day there was talk about 3A/B having the means to disable wifi/bt when Pi3B was still an infant -- haven't Googled to see if that's just something in config or a bit switch in what we'll nick-name RasBIOS.

@Rich: Yes, I vaguely remember the name!   Research notes updated for Manning and/or Googling as time permits.

Thanks guys; I appreciate the efforts!

[Juanito]

I'm not sure if it's helpful, but wifi works on this RPi:

Code: [Select]

cat /proc/cpuinfo | grep Model
Model: Raspberry Pi 3 Model B Rev 1.2
uname -a
Linux boxrpi3 6.6.47-piCore-v7 #20 SMP Sat Aug 31 14:54:55 EDT 2024 armv7l GNU/Linux
version
15.0
..using:

Code: [Select]

sudo cp /mnt/mmcblk0p2/conf/wpa_configure.conf /etc
#
tce-load -i firmware-rpi-wifi
tce-load -i wireless-KERNEL
tce-load -i wpa_supplicant
#
sleep 2
#
sudo wpa_supplicant -B -i wlan0 -c/etc/wpa_configure.conf
#
sudo udhcpc -b -i wlan0 -x hostname:boxrpi3 -p /var/run/udhcpc.wlan0.pid
..and:

Code: [Select]

cat wpa_configure.conf*

ctrl_interface=/var/run/wpa_supplicant

network={
        ssid="blah"
key_mgmt=WPA-PSK
proto=WPA2
pairwise=CCMP
group=CCMP
psk="blah-blah"
}

[CentralWare]

@Juanito: Thanks for dropping in!  3 Boards identical to yours, for completely unknown reasons, two of the three act as though the wifi/bt chip isn't even soldered on.

Code: [Select]

sudo cp /mnt/mmcblk0p2/conf/wpa_configure.conf /etcI do this from /opt but otherwise same process

Code: [Select]

tce-load -i firmware / wireless / wpaSame here - I even added iw, usbutils, pciutils, etc. the first time around and wireless just isn't there, either by chip number or brcm driver identifier.

It's possible (though I cannot imagine how!?) the boards were damaged...
okay, maybe not (see image attachment - wifi chip bottom left corner...  would be difficult to injure hiding along-side one of the DIN rail braces - while attached TO a DIN rail most of the time.)

[Juanito]

Maybe the RPi OS has a test program?

[Rich]

Hi CentralWare

... Since the Pi3B is supposed to have wireless onboard, I picked a few of those to run a wireless project on and immediately ran into a wall.

cpuinfo Model: Raspberry Pi 3 Model B Rev 1.2
version 15.x ArmHF
uname: 6.6.47-piCore-v7 ...

I'm not up on pi history, but that sounds like a model that's been around for a while.
Try with and older known version (TC14, TC13, etc) and see if you get the same result.
If you do, it's likely a hardware problem (broken board?).
If you don't, it's likely a software issue.

[Paul_123]

A bit more info.

Board info

Code: [Select]

tc@box:~$ cat /proc/device-tree/model
Raspberry Pi 3 Model B Rev 1.2tc@box:~$
tc@box:~$ cat /proc/cpuinfo | grep Revision
Revision        : a22082
tc@box:~$

With no wifi extensions mounted, you should see the following in dmesg.  This is the communication bus to the wifi chip.

Code: [Select]

tc@box:~$ dmesg | grep mmc1
[    2.250432] mmc1: new high speed SDIO card at address 0001

Loading driver

Code: [Select]

tc@box:~$ tce-load -i firmware-rpi-wifi
firmware-rpi-wifi.tcz: OK
tc@box:~$ tce-load -i wireless-KERNEL.tcz
regdb.tcz: OK
wireless-6.6.47-piCore-v7.tcz: OK
tc@box:~$ dmesg
.......
[  327.411774] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[  327.422081] Loaded X.509 cert 'benh@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[  327.431600] Loaded X.509 cert 'romain.perier@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[  327.433041] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[  327.434437] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[  327.477827] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[  327.485979] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[  327.486752] usbcore: registered new interface driver brcmfmac
[  327.724607] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[  327.725217] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Jul 19 2021 03:24:18 version 7.45.98 (TOB) (56df937 CY) FWID 01-8e14b897


[CentralWare]

Maybe the RPi OS has a test program?

My thoughts exactly...  Raspbian images are currently in the download queue but the download site is painfully slow from here, so it'll be a bit before I can create cards.

If you do, it's likely a hardware problem (broken board?).
If you don't, it's likely a software issue.

I have my home NAS dumping TCL onto a pair of piCore SD cards (2.x to 16.x) at the moment (partition 1 being 2GB Fat32 w/ piCore, partition 2 being the balance of 400GB) which was the point of the RasPi-3B units in the first place (to host the TCL repo on a pair of RasPi boards; one for the existing layout, the other for development on the new whilst working from home.)  I'll be taking the two faulty 3B boards back to the office Monday and have someone bench 'em and see exactly what you and @Juanito suggested.  I got these boards when 3B was just released (bought about a dozen in the first batch) so anything is possible - they sat in inventory for a bit as Raspbian and Pi Foundation released the hardware before it was ready to be released (firmware/software) but we'll see!

A bit more info.

Thank you for the data; I'll run it against the pair of "duds" Monday.  In fact, I'm going to have all of our Pi3 boards pulled from the rack and benched; wireless/btooth tested to see if there's a common problem with the boards we bought (not that there'd be a warranty left in them!! )  Mind you, we don't normally use Pi3 boards for wireless projects thus why this has gone unnoticed for so long.

So far, using the working 3B model I was able to create a pair of SD cards (plus kernel drivers for v6) which operated properly on the 3B so they could be transferred over to Pi-0W boards if needed.
On the first Pi-0W everything looks to have worked successfully, even with the brcmfmac feature disabled.  Speaking of which, this should verify the RasPi-3 models needing that kernel flag (it's listed for the 3A+ and my 3B needed it as well.)

Take care, my friends!

[Paul_123]

It’s only if you are using wpa_supplicant 2.11.  It should not affect drivers loading or being detected.

I know zero2W needs it.

[CentralWare]

LOL - since we're knee deep in 15.x, how about an extension request of mdadm.tcz for piCore??

I know zero2W needs it.

I'd need to read up on the problem more thoroughly but if I were to speculate, it sounds like a WPA2/3 packet problem where if we're telling the kernel to disable a feature specific to Broadcom's radios, MY guess would be this should be an issue for ANY model of RasPi with the same/similar onboard or USB based Broadcom chip.  Whether it's isolated just to WPA# Personal I can't say yet.