BCM4331 802.11n seems tantalisingly close on mid-2011 Mac mini, using bhnd and if_bwn_pci.ko on FreeBSD 11.2-BETA1

V

VanNorden

My ageing Mac mini running macOS High Sierra 10.13.4 was finally hosed by Apple's Security Update 2018-001 (the one for the debug exception). Both 10.13.4 Recovery and 10.13.4 Internet Recovery failed to boot, but the 'D' built-in hardware test seemed to give the machine a clean bill of health. Apple support said the machine was no longer supported. :rolleyes:

I was left with a machine that could at least boot single-user, albeit with no means to mount msdos because SIP claimed mount_msdos had an incorrect signature. SIP can be removed... but only from within Recovery Boot, not single-user mode.

FreeBSD to the rescue, then. };o)

After quite a lot of fiddling about, reading and re-reading the [FONT=Courier New]bwn()[/FONT] man page, I found the insightful material at: Landon Fuller's site.

This led me to some more experiments with kldload / kldstat, culminating in:

[FONT=Courier New]11.2-BETA1
FreeBSD monkeycup 11.2-BETA1 FreeBSD 11.2-BETA1 #0 r333761: Fri May 18 00:31:34 BST 2018[/FONT]

[FONT=Courier New]/boot/loader.conf:[/FONT]
Code: 
bhnd_load="YES"
bwn_v4_ucode="YES"
bwn_v4_n_ucode="YES"
if_bwn_pci_load="YES"
wlan_wep_load="YES"
wlan_ccmp_load="YES"
wlan_tkip_load="YES"

[FONT=Courier New]/etc/rc.conf:[/FONT]
Code: 
wlans_bwn0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"

[FONT=Courier New]dmesg[/FONT]
[FONT=Courier New]pcib4: <ACPI PCI-PCI bridge> at device 28.1 on pci0
pci4: <ACPI PCI bus> on pcib4
bwn_pci0: <Broadcom BCM4331 802.11n Dual-Band Wireless> mem 0xa8600000-0xa8603fff at device 0.0 on pci4
bhndb0: <PCI-BHND bridge> on bwn_pci0
bhnd0: <BCMA BHND bus> on bhndb0
bhnd_chipc0: <Broadcom ChipCommon I/O Controller, rev 37> mem 0x18000000-0x18000fff,0x18100000-0x18100fff at core 0 on bhnd0
bhnd_hostb0: <Broadcom PCIe-G1 Host-PCI bridge, rev 19> mem 0x18002000-0x18002fff,0x8000000-0xfffffff,0x8000000000000000-0xffffffffffffffff,0x18102000-0x18102fff,0x18103000-0x18103fff at core 2 on bhnd0
bwn0: <802.11 MAC/PHY/Radio> mem 0x18001000-0x18001fff,0x18101000-0x18101fff at core 1 on bhnd0
bwn0: got rid=0 res=0xfffff800045baaf0
bwn0: got macaddr 28:37:37:12:70:b3[/FONT]

...but:
[FONT=Courier New]# [/FONT] sysctl net.wlan.devices
[FONT=Courier New]
net.wlan.devices:

# [/FONT] ifconfig wlan0 create wlandev bwn0
[FONT=Courier New]
ifconfig: SIOCIFCREATE2: Device not configured [/FONT]

[FONT=Arial]Since the driver is able to drag the MAC address out of the hardware, it feels like it's on the cusp of working(!)[/FONT]

[FONT=Arial]Thank you, Landon Fuller et. al.[/FONT]

[FONT=Arial]Question: Does anyone out there already have the BCM4331 taking traffic on FreeBSD, or am I going to have to dig into the driver source code next?[/FONT]
 
I have also old HP Mini with BCM4312 on FreeBSD 11.2-BETA2 without any issue.
I have my /boot/loader.conf
Code: 
if_bwn_load="YES"           # Broadcom BCM43xx IEEE 802.11 wireless NICs
bwn_v4_lp_ucode_load="YES"  # Broadcom BC43XX firmware
and installed net/bwn-firmware-kmod. On this does not spit error messages.
 
trev said:
You might want to check out 12-CURRENT - my late 2009 MacMini is now happily running the BCM4321 chipset in the 5GHz band - see https://forums.freebsd.org/threads/late-2009-macmini-broadcom-bcm4321-wireless.64644/
Click to expand...

Well, having bitten the bullet and moved to 12-CURRENT:
[FONT=Courier New]$ [/FONT] freebsd-version ; uname -a
[FONT=Courier New]12.0-CURRENT
FreeBSD monkeycup 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r333924: Sun May 20 18:22:57 BST 2018[/FONT]

/boot/loader.conf:
[FONT=Courier New]#bhnd_load="YES"
bwn_v4_ucode="YES"
bwn_v4_n_ucode="YES"
#if_bwn_pci_load="YES"
if_bwn_load="YES"
wlan_wep_load="YES"
wlan_ccmp_load="YES"
wlan_tkip_load="YES"[/FONT]

dmesg:
[FONT=Courier New]pci4: <ACPI PCI bus> on pcib4
bwn_pci0: <Broadcom BCM4331 802.11n Dual-Band Wireless> mem 0xa8600000-0xa8603fff at device 0.0 on pci4
bhndb0: <PCI-BHND bridge> on bwn_pci0
bhndb0: Using MSI interrupts on bwn_pci0
bhnd0: <BCM4331 BCMA bus> on bhndb0
bhnd_chipc0: <Broadcom ChipCommon I/O Controller, rev 37> mem 0x18000000-0x18000fff,0x18100000-0x18100fff irq 0 at core 0 on bhnd0
bhnd_nvram0: <SPROM/OTP> mem 0x18000800-0x18000bff on bhnd_chipc0
bhnd_pmu0: <Broadcom ChipCommon PMU, rev 10> on bhnd_chipc0
gpio0: <Broadcom ChipCommon GPIO> mem 0x18000000-0x18000fff on bhnd_chipc0
bhnd_hostb0: <Broadcom PCIe-G1 Host-PCI bridge, rev 19> mem 0x18002000-0x18002fff,0x8000000-0xfffffff,0x8000000000000000-0xffffffffffffffff,0x18102000-0x18102fff,0x18103000-0x18103fff irq 2 at core 2 on bhnd0
bhnd0: <Broadcom 802.11 MAC/PHY/Radio, rev 29> mem 0x18001000-0x18001fff,0x18101000-0x18101fff irq 1 at core 1 (no driver attached)[/FONT]

[FONT=Courier New]# [/FONT] sysctl net.wlan.devices
[FONT=Courier New]net.wlan.devices:
[root@monkeycup ]#[/FONT]

Observations:
  1. Under 12.0-CURRENT, it seems if_bwn_pci.ko has vanished, presumably because that was just a test module present in 11.x(?)
  2. The bwn_v4_* microcode isn't getting loaded automatically now. Adding it after boot with kldload and a subsequent reload of if_bwn.ko fails to produce the results I had seen in 11.2-BETA1. There is no indication that the MAC address has been retrieved from the hardware.
  3. dmesg output states quite clearly that no driver is attached.
  4. I also note that trev and gnath seem to be using a slightly older chipset(s) [BCM4321 / BCM4312], which may explain the different level of success I'm seeing out of the starting gate on 12.0-CURRENT with BCM4331:
    1. Table "Broadcom PHY Types" at Landon's BRCM Wi-Fi page does mention the BCM4321 (PHY N) and BCM4312 (PHY LP). gnath is clearly using the LP variant of the ucode, so that correlates well. However, the BCM4331 is listed as a PHY HT "Tri-stream" type...
    2. The same table has a noticeable green tick against the BCM4331 in the Linux b43 column
My options therefore seem to be:
a) Try the LP ucode, on the off-chance. Easy to do, so will be my next port of call.
b) Poke through the b43 code to see what I might be able to glean in terms of a potential patch to 12.0-CURRENT
c) Try to contact Landon, to see whether I ^w my machine can be his guinea-pig...

Will keep you posted.
 
VN mused:
> a) Try the LP ucode, on the off-chance. Easy to do, so will be my next port of call.

[FONT=Courier New]12.0-CURRENT
FreeBSD monkeycup 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r333924: Sun May 20 18:22:57 BST 2018


pcib4: <ACPI PCI-PCI bridge> at device 28.1 on pci0
pci4: <ACPI PCI bus> on pcib4
bwn_pci0: <Broadcom BCM4331 802.11n Dual-Band Wireless> mem 0xa8600000-0xa8603fff at device 0.0 on pci4
bhndb0: <PCI-BHND bridge> on bwn_pci0
bhndb0: Using MSI interrupts on bwn_pci0
bhnd0: <BCM4331 BCMA bus> on bhndb0
bhnd_chipc0: <Broadcom ChipCommon I/O Controller, rev 37> mem 0x18000000-0x18000fff,0x18100000-0x18100fff irq 0 at core 0 on bhnd0
bhnd_nvram0: <SPROM/OTP> mem 0x18000800-0x18000bff on bhnd_chipc0
bhnd_pmu0: <Broadcom ChipCommon PMU, rev 10> on bhnd_chipc0
gpio0: <Broadcom ChipCommon GPIO> mem 0x18000000-0x18000fff on bhnd_chipc0
bhnd_hostb0: <Broadcom PCIe-G1 Host-PCI bridge, rev 19> mem 0x18002000-0x18002fff,0x8000000-0xfffffff,0x8000000000000000-0xffffffffffffffff,0x18102000-0x18102fff,0x18103000-0x18103fff irq 2 at core 2 on bhnd0
bhnd0: <Broadcom 802.11 MAC/PHY/Radio, rev 29> mem 0x18001000-0x18001fff,0x18101000-0x18101fff irq 1 at core 1 (no driver attached)[/FONT]

kldstat indicates that no firmware is getting loaded. This suggests that the BCM4331 does indeed need an alternate PHY firmware implementation before it will spring into life. It now seems clear that whatever 11.2-BETA1 thought it was reading in terms of a MAC was most likely a random sequence of 6 octets from a location which would have yielded a valid MAC on one or more of the chips that are actually supported.

It is beginning to feel like I am going to end up needing to cut the firmware for the 4331 out of an existing driver for another OS. Seems like the best option at this point is to try to reach Landon Fuller.
 
I await the next instalment with interest ... I also have a mid-2011 Mac Mini currently using a cheap Chinese pocket WiFi N router (USB pwr, plus eth) for connectivity.
 
How old is your Mac Mini? macOS 10.13.4 still supports devices dating back to 2010 - 2012. Your hardware isn't supported for service, but it still falls under the compatibility list for macOS.
 
Beastie7 said:
How old is your Mac Mini? macOS 10.13.4 still supports devices dating back to 2010 - 2012. Your hardware isn't supported for service, but it still falls under the compatibility list for macOS.
Click to expand...
Mid-2011, as per the OP.
Apple apparently end-of-lifed that model in Dec 2017. This probably means they are no longer regression testing their updates on it...?
 
VanNorden said:
Mid-2011, as per the OP.
Apple apparently end-of-lifed that model in Dec 2017. This probably means they are no longer regression testing their updates on it...?
Click to expand...

I don't see why they would need to; it's all x86 after all. I have an old 2008 Unibody MacBook running macOS Sierra.

I did have to apply a patch hack for mine because Apple isn't officially supporting it; otherwise i'd be locked to El Capitan.

But because yours is newer you shouldn't have any problems installing macOS Sierra with a bootable installer. Assuming internet recovery is still screwed.
 
I've been playing around with this as well, but for a BCM43228. I thought Landon's support table means that more BCM devices (including my BCM43228) are supported by bhnd(4) which "Denotes only interconnect bridge and platform device support." Then, some additional BCM device support was added to bwn(4) Wi-Fi driver from the GPL b43 driver for BCM4321, BCM4322, and BCM43224 / BCM43225.

In my case, if_bwn and bhnd all load per kldstat, but I get no messages in dmesg from either driver. pciconf recognizes the device, but lists no driver attached.

Code: 
none2@pci0:3:0:0:       class=0x028000 card=0x060714e4 chip=0x435914e4 rev=0x00 hdr=0x00
    vendor     = 'Broadcom Limited'
    device     = 'BCM43228 802.11a/b/g/n'
    class      = network

This matches my interpretation of the support table.
 
No response from Landon.

On the offchance, I looked at the b43 code, then hacked on bwn-firmware-kmod to turn
ucode29_mimo, ht0initvals29 and ht0bsinitvals29 into a bwn_v4_ht_ucode.ko

I can load the resultant .ko, but perhaps unsurprisingly the driver does not magically spring into life. Looking at the contents of /usr/src/sys/gnu/dev/bwn/phy_n I am guessing that what would be needed next is actual HT driver support code for the various bits of the radio. Without any test equipment or programmers manual for the HT hardware, I guess this is about as far as I can take things on my own.
 
You must log in or register to reply here.
Back
Top