Thanks for maintaining this tracker — the ESP firmware note is what saved my install. Two
status corrections for MacBookPro14,2, both currently marked not_working.
Audio — working
Working with davidjo/snd_hda_macbookpro
via DKMS on kernel 7.1.8: speakers, headphones and the internal microphone.
One gotcha worth adding to that section: the internal mic ships muted, which reads as
broken hardware until you check wpctl status and see [vol: 1.00 MUTED].
I suspect the current status traces to the driver's own quirk table, where the line for this
machine is commented out while 14,3 is enabled:
//SND_PCI_QUIRK(0x106b, 0x3600, "MacBookPro 14,2", CS8409_MBP143), // disabled
SND_PCI_QUIRK(0x106b, 0x3900, "MacBookPro 14,3", CS8409_MBP143), // enabled
It works regardless, because the runtime code has explicit branches for subsystem
0x106b3600 with their own GPIO mask. Uncommenting the quirk was not necessary.
Wi-Fi — working, including 5 GHz
brcmfmac loads no NVRAM for the BCM43602. The diagnostic is the MAC address:
00:90:4c:* is Broadcom's generic OUI, meaning no board configuration was loaded at all.
macOS reported the real Apple MAC for the same adapter.
Supplying /lib/firmware/brcm/brcmfmac43602-pcie.txt with the real MAC, then rebooting:
|
Without NVRAM |
With NVRAM |
| MAC |
00:90:4c:* placeholder |
real Apple MAC |
| Bands |
Band 1 only |
Band 1 + Band 2 |
| Signal, same position |
-74 dBm |
-42 dBm |
| Link rate |
2.4 GHz rates |
324 Mbit/s |
The 26 dB gain is worth flagging separately from the band question. That file carries the
TX power tables and RF calibration, not just band enablement, so an adapter running without it
is band-limited and deaf. Before the fix a scan often saw only one AP and scp failed
repeatedly; both looked like distance problems. That may explain the weak-signal reports on
these models generally.
Two practical notes:
- The driver cannot be reloaded live — NetworkManager holds it, so
modprobe -r brcmfmac
returns "Module brcmfmac is in use" and the NVRAM is never re-read. Only a fresh boot picks
it up.
brcmf_c_process_clm_blob: no clm_blob available (err=-2) is a red herring. For
linux-firmware builds the regulatory data is compiled into the .bin; the message appears
on healthy systems too.
Since the missing NVRAM isn't model-specific, this may also apply to the other models you have
marked not_working for Wi-Fi (13,2, 13,3, 14,3).
Details
Files and full writeup: https://github.com/nohzafk/omarchy-macbookpro-t1
Caveat: single machine, MacBookPro14,2 13-inch 2017, kernel 7.1.8-arch1-3. The NVRAM's
boardtype=0x61b / boardrev=0x1421 come from a community dump that looks like a 15-inch
board — it works on this 13-inch one, but I can't say that generalises. Happy to run any
checks that would help you verify before changing a badge.
Thanks for maintaining this tracker — the ESP firmware note is what saved my install. Two
status corrections for
MacBookPro14,2, both currently markednot_working.Audio — working
Working with
davidjo/snd_hda_macbookprovia DKMS on kernel 7.1.8: speakers, headphones and the internal microphone.
One gotcha worth adding to that section: the internal mic ships muted, which reads as
broken hardware until you check
wpctl statusand see[vol: 1.00 MUTED].I suspect the current status traces to the driver's own quirk table, where the line for this
machine is commented out while
14,3is enabled:It works regardless, because the runtime code has explicit branches for subsystem
0x106b3600with their own GPIO mask. Uncommenting the quirk was not necessary.Wi-Fi — working, including 5 GHz
brcmfmacloads no NVRAM for the BCM43602. The diagnostic is the MAC address:00:90:4c:*is Broadcom's generic OUI, meaning no board configuration was loaded at all.macOS reported the real Apple MAC for the same adapter.
Supplying
/lib/firmware/brcm/brcmfmac43602-pcie.txtwith the real MAC, then rebooting:00:90:4c:*placeholderBand 1onlyBand 1+Band 2The 26 dB gain is worth flagging separately from the band question. That file carries the
TX power tables and RF calibration, not just band enablement, so an adapter running without it
is band-limited and deaf. Before the fix a scan often saw only one AP and
scpfailedrepeatedly; both looked like distance problems. That may explain the weak-signal reports on
these models generally.
Two practical notes:
modprobe -r brcmfmacreturns "Module brcmfmac is in use" and the NVRAM is never re-read. Only a fresh boot picks
it up.
brcmf_c_process_clm_blob: no clm_blob available (err=-2)is a red herring. Forlinux-firmwarebuilds the regulatory data is compiled into the.bin; the message appearson healthy systems too.
Since the missing NVRAM isn't model-specific, this may also apply to the other models you have
marked
not_workingfor Wi-Fi (13,2,13,3,14,3).Details
Files and full writeup: https://github.com/nohzafk/omarchy-macbookpro-t1
Caveat: single machine,
MacBookPro14,213-inch 2017, kernel 7.1.8-arch1-3. The NVRAM'sboardtype=0x61b/boardrev=0x1421come from a community dump that looks like a 15-inchboard — it works on this 13-inch one, but I can't say that generalises. Happy to run any
checks that would help you verify before changing a badge.