Install BCM43602 NVRAM so 2017 Touch Bar Macs see 5 GHz Wi-Fi - #7671
Install BCM43602 NVRAM so 2017 Touch Bar Macs see 5 GHz Wi-Fi#7671shawnyeager wants to merge 6 commits into
Conversation
linux-firmware-broadcom ships the chip firmware but no board calibration, so brcmfmac only advertises 2.4 GHz. Install a calibrated NVRAM under firmware/updates on Apple machines with PCI 14e4:43ba, and migrate existing installs.
There was a problem hiding this comment.
Pull request overview
Adds BCM43602 NVRAM calibration to restore 5 GHz Wi-Fi on affected Intel Macs.
Changes:
- Detects eligible Apple BCM43602 hardware and installs generic/DMI-specific NVRAM.
- Migrates existing installations and requests a reboot.
- Adds documentation and shell coverage.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
install/hardware/apple/brcmfmac-43602.sh |
Implements detection and NVRAM installation. |
install/hardware/apple/brcmfmac43602-pcie.txt |
Adds calibrated BCM43602 NVRAM data. |
install/hardware/apple/fix-brcmfmac-5ghz.sh |
Adds the installation leaf. |
install/hardware/all.sh |
Runs the new hardware fix. |
migrations/1787312531.sh |
Applies the fix to existing installations. |
manual/44-mac-support.md |
Documents BCM43602 5 GHz support. |
test/shell.d/brcmfmac-5ghz-test.sh |
Tests detection, installation, MAC handling, and migration. |
test/shell.d/unowned-system-paths-test.sh |
Allows the firmware override destination. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Reviewed here, with an independent second opinion from What actually ran. 1. The gate is chip-wide; the calibration is board-specific. That is not hypothetical on two counts. Your own test asserts a 2015 Worth connecting: the kernel log in #7672 quotes Gating 2. With no wireless interface visible, the donor's MAC ships as the machine's MAC. brcmfmac-43602.sh:118-123 substitutes the live address only inside Codex added the part that makes this sharp, and my own check of this machine's Deleting the 3. The completeness check clobbers, shadows, and never refreshes. 4. A failed install reports success, and the migration then marks itself done. 5. The clobber assertion is vacuous, and I proved it. brcmfmac-5ghz-test.sh:181-186 writes a placeholder NVRAM and then calls Two smaller test notes. The leaf test invokes with 6. Provenance and licence. brcmfmac-43602.sh:9-12 names bugzilla attachment 290569; the data file itself starts straight into data with no header, and brcmfmac's parser ignores What is right, since a review that lists only problems misleads. On the allowlist entry. test/shell.d/unowned-system-paths-test.sh:33-36 records Overlap you should know about. #7487 by @csvenke fixes the same defect on the same chip, verified on the same MacBookPro14,3, with a different NVRAM (bugzilla 193121, Boot Camp lineage, Where the second opinion stands. Codex agreed with findings 1 through 4, which I had already reached — its independence is not currently guaranteed, since it runs as the same user and could read this machine, though I grepped its log and found no transcript reads. What it contributed on its own terms stands regardless: the per-model subsystem IDs, the MacBookPro13,3 degradation report, the kernel's duplicate-MAC guard covering a different placeholder than yours, the vacuous clobber assertion, and the licence statement in the upstream gist. I verified each of those against the source or fetched the page before repeating it here. Waiting on: the maintainer, for the licence question and for the choice between this and #7487; and on you, for findings 1 through 5. Nothing needs another pass from me until the branch moves. |
Gate on the 2017 Touch Bar models this dump has actually been seen to work on. Resolve the NIC through its PCI BDF, strip macaddr= when none is found, never overwrite an existing board file, and stop wrapping install in `if` so a failed write cannot mark the migration done.
|
Addressed the review on the branch. 1. Gate. 2. MAC. Live address comes from 3. Completeness / clobber / shadow. Three-marker check is gone. If a generic or DMI-specific board file already exists in 4. Failed install looking like success. 5. Vacuous clobber test. The existing-file case now uses 6. Provenance. The data file now starts with vs #7487. Kept |
Arch ships everything under /usr/lib/firmware zstd-compressed — all 118 files in /usr/lib/firmware/brcm on a current install, including NVRAM board files for other chips such as `brcmfmac43241b4-sdio.Intel Corp.-VALLEYVIEW C0 PLATFORM.txt.zst`. The existence check looked only for the uncompressed name, so the rule that a packaged linux-firmware board file outranks this copy could never fire on Arch: the day linux-firmware ships one for the BCM43602, the check would miss it and write the override on top, shadowing it for good. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com>
|
Re-reviewed at f81f4d5. All five findings from the last pass are closed, and I proved each one by breaking the code it guards rather than by reading it. Three new things, one of which I fixed on your branch. What ran. The five.
Pushed to your branch: f81f4d5, "See a packaged board file that arrives compressed". Still open, and yours to decide how: a failed install strands a half-done state that the skip guard then makes permanent.
Your test at Smaller. Two things the move made non-obvious, both fine. The data file now lives in Neighbours. #7644 still conflicts with this textually — Second opinion. Waiting on: you, for the half-install and lost-reboot-prompt question; the maintainer, for the licence on the vendored dump and for the choice between this and #7487. |
|
Test report from an Omarchy 4.0.2-1 system. This was a manual NVRAM test, not a checkout of this PR branch. Hardware/software:
Before installing NVRAM:
Manual change:
After:
This validates that a calibrated NVRAM restores 5 GHz on One concern: before NVRAM, the interface reported |
|
Re-reviewed at f81f4d5. The branch has not moved since the last pass, so this is about what the thread learned rather than about new code. Nothing pushed. The second opinion is Housekeeping first, so nothing gets re-litigated. Copilot's review and its four inline comments are dated 21 Aug 11:54, before your 14:09 rewrite, and all four describe code you deleted in 53796d7: What ran. Both things I left open last time are still open, and I re-proved them at this head rather than assuming. Driving the migration with an @caueguerra's report, read against this branch. It is a MacBookPro13,3, which line 61 excludes, and it installs a different file, so it is not a test of this PR. It is corroboration of your design rather than a counter-example, and you should read it that way: the file that worked there is The one part of that report that does land on this branch, and it is new. Before any NVRAM, that card reported A second, separate MAC problem codex found that I had not reasoned about. On the gate, which is the part I want to be careful about. Codex rates Something worth deciding before this merges. The body says Smaller, and both from codex. Neighbours. #7644 still conflicts textually — Waiting on: you, for the partial-install state and the lost reboot prompt, and for whether |
A write that failed part-way could leave a truncated or half-written NVRAM pair under the name the driver loads, where the skip guard then kept it forever and the migration never asked for the reboot. Stage both names under temporary names and rename them into place together, rolling back on failure. Read the MAC from the wiphy's permanent address rather than the netdev's current one, which NetworkManager randomises while scanning, and treat the Broadcom 00:90:4c placeholder as no address so it is never persisted. Give the leaf and the migration the positive if that the other hardware leaves use, and log the install after it succeeds. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QH9zheAn7LKZeTzgwpHqBF
|
Pushed 21b1f92, which closes the items still open from the last two passes and @caueguerra's report.
Fixed by staging.
Agreed, and fixed.
Fixed. The lookup now prefers
Both the leaf and the migration now use the positive
Reworded to say that. Still deciding whether |
Changed the body to |
|
Hardware validation data for the MacBookPro13,3 case that this PR intentionally leaves out:
Important: this does not validate this PR's attachment 290569 on 13,3. We used the separate community calibration from kernel.org Bugzilla attachment 285753, so 13,3 needs model-specific source selection rather than widening the existing 290569 model gate. Before:
Tested installation:
After reboot:
I am preparing a dependent branch that adds the 13,3 calibration as a separate fixture/path and preserves this PR's 14,2/14,3 gate. |
|
Re-reviewed at 21b1f92. Everything left open from the last pass is closed, and each fix is proved by mutation on a disposable VM rather than by the suite passing: reverting the atomic staging fails Three things are new. The An interrupted rename leaves a state the skip guard makes permanent. brcmfmac-43602.sh:161-166 renames the generic name before the DMI-specific name. A kill between the two renames leaves the generic file final and the DMI file as The rename rollback at :162-165 is not covered by the suite. Making the second On the four Copilot comments: all four are moot or wrong at 21b1f92, and your replies are accurate — each was checked against the source rather than taken from either side. One caveat for anyone reading the thread cold: GitHub has re-anchored the Two smaller things. The title still says "2016–2017 Macs" while the gate is Unchanged and still the maintainer's: the licence on a dump whose own header says it is "not provided or licensed by Broadcom or Apple", and the overlap with #7487, which vendors a genuinely different calibration to the same path ( Reviewed here by Claude Opus 5, with a second opinion from codex (gpt-5.6-sol) at xhigh reasoning; the interrupted rename and the uncovered rename rollback are its findings, and its independence is not guaranteed, since read-only sandboxing restricts writes and not reads. Nothing pushed to your branch. |
shawnyeager
changed the title
|
Re-reviewed at 21b1f92. No code change. The The kill between the two Title updated to match the gate ( |
|
Thanks for considering #10141. Our MacBookPro13,3 requirement is a stable per-machine fallback when the firmware exposes the Broadcom placeholder. We generate that address explicitly; we don't require accepting arbitrary kernel- or NetworkManager-randomized addresses as permanent hardware identity. Stricter validation of discovered addresses could therefore coexist with our explicit 13,3 fallback. Please don't treat the stacked branch as a reason to defer the rename-rollback test either; we can adapt/rebase #10141. Our hardware validation remains specific to attachment 285753 on MacBookPro13,3, not attachment 290569 or a wider model gate. |
On MacBookPro14,3, an NVRAM file with no macaddr= key makes brcmfmac time out on cur_etheraddr and fail dongle setup. OTP does not answer. Keep the source line when the 43ba wiphy has no real permanent address; still substitute a live address when it does.
|
Follow-up: stripping |
|
Thanks for the concrete reboot/reload result. We do not have MacBookPro14,3 evidence that contradicts it. A required On our MacBookPro13,3, attachment 285753 plus an explicitly generated stable locally administered address brought up 5 GHz: 5600 MHz/channel 120, 866.6 Mbit/s reported RX, and 20/20 gateway pings without loss on the tested custom 7.2.2 kernel. That is positive evidence for a populated key with a per-installation value on 13,3; it does not validate attachment 290569, the same approach on 14,3, or removal of the key. Our draft fallback derives an address from the local machine-id instead of preserving A useful next hardware test on 14,3 would be a populated, unique locally administered MAC in the same calibration, with recovery access available, checking firmware startup, association and identity after reboot. This is a proposed test, not a completed one. We can adapt #10141 to the updated shared installer; its older stripping fallback should not be treated as overriding your new hardware finding. Additional 13,3 follow-up: custom |
|
Re-reviewed at ffda5d4. One commit since the last pass, and it reverses the previous one's MAC handling, so this is about that. What the delta does. At 21b1f92 the installer stripped The thing that settles most of the thread, and I do not think either of you has it yet. That address is compiled into the chip firmware. On a current worker running One match in the whole blob. So it is not a donor's board address that leaked into attachment 290569 — it is the default the BCM43602 firmware itself carries. That is why @caueguerra and @monomyth both saw exactly that address on a 13,3 with no board file, and it is the mechanism behind "OTP does not answer here" on your 14,3. Two consequences:
Where it does take something away, and this is the finding. That branch is reachable in the ordering So the disagreement is narrower than the thread reads. @monomyth's 6 Sep comment already separates the two questions, and that separation is right: the key must exist (your evidence), and the value should be per-machine (his). #10141's One thing only you can answer, and it decides how much of the above is theoretical: on the 14,3 you verified, what does Prior findings. All three from the last pass are untouched by this delta and still open, and all three remain notes rather than blockers: the What ran. On a disposable worker with no BCM43602 in it: Second opinion. Reviewed here by Claude Opus 5, with a second opinion from codex (gpt-5.6-sol) at xhigh reasoning, pinned to ffda5d4 and checked against the tree. It contributed two things I did not have: it disassembled the Neighbours. #7487, #7644, #10211, #10306, #10314 and #10332 all merge-tree clean against this head today; #10141 conflicts by design, since it rewrites this same shared installer to add a 13,3 source and widen the gate. #10332 reloads brcmfmac around every suspend on 43ba/43bb/43bc, which would pick this NVRAM up without waiting for a reboot — and equally would reapply a wrong address at every wake. #10306 is the ordering interaction above. Waiting on: you, for the |
|
Re-reviewed at ffda5d4. The last comment on this thread was written against 21b1f92, so this answers only the new commit, "Keep macaddr= in BCM43602 NVRAM; stripping it crashes the dongle". What ran, on a disposable worker VM with no BCM43602 in it. The four findings closed at 21b1f92 are still closed at ffda5d4, and I re-proved each by breaking the code it guards rather than by reading it. Installing straight to The fifth one is reversed on purpose, and that is the whole of this review. At 21b1f92 the strip branch meant Two things worth saying plainly about how much that is worth. It is not a duplicate this PR creates: @caueguerra and @monomyth each reported a card presenting exactly The @monomyth's distinction is the one I would put to the maintainer: "a required One item from the second opinion that I checked and can bound. The three rewritten assertions ( Neighbours. #7487 still adds the same Unchanged and still the maintainer's: the licence on a dump whose own header says it is not provided or licensed by Broadcom or Apple, and the choice between this and #7487. Reviewed here by Claude Opus 5, with a second opinion from codex (gpt-5.6-sol) at xhigh reasoning pinned to ffda5d4 and checked against this tree. The |
|
Housekeeping, and the last from me on this pass: the two comments above are both ours, three minutes apart, from one triage run that reviewed this branch twice by mistake. The second one says the previous comment was written against Read them as one review. They agree on the verdict and on the substance: the Nothing was pushed to your branch. |
Keep the macaddr= key (stripping it crashes the dongle). Never write the dump's shared 00:90:4c:0d:f4:3e. When the 43ba wiphy has no real permanent address, substitute a locally-administered MAC from machine-id so install with no interface up still works. Tests fail if the donor is written.
|
c0fea4e keeps the When the 43ba wiphy has a real permanent address, that is what is written. When it does not — no sysfs address, or any Tests now fail if that donor is written. They also cover two machine-ids producing two addresses, and the inverted-guard case where a card's own Licence and overlap with #7487 stay a maintainer call. #10141 remains the 13,3 stack; this does not take its dump, widen this gate, or reuse its |
Refs #7672
This covers MacBookPro14,2 and MacBookPro14,3 only, the two models where this dump has field reports. #7672 stays open to track the other BCM43602 boards reported there (MacBookPro12,1, MacBookPro13,3), which need their own calibration.
Why
2017 Touch Bar MacBook Pros (MacBookPro14,2 and MacBookPro14,3) with Broadcom BCM43602 (
14e4:43ba) get 2.4 GHz Wi-Fi out of the box underbrcmfmac, but never see 5 GHz networks.linux-firmware-broadcomships the chip firmware and no board calibration file, so the driver loads with placeholder 5 GHz values (aa5g=1, no per-channel tx-power tables).Verified end-to-end on a MacBookPro14,3 after reboot:
The 5 GHz band is advertised (
iw phyBand 2) and dual-band APs show both frequencies innmcli.Field recipe this follows: csk-grit42/OmarchyOnMacBookPro14.2-2017---A1706- HOWTO-wifi.md. Credit to @csk-grit42 for documenting the BCM43602 NVRAM + regulatory-domain path that unlocked 5 GHz on the 2017 13" Touch Bar MacBook Pro. The NVRAM is the community BCM43602 dump from kernel.org bugzilla attachment 290569 (
ccode=00/regrev=245defers channel legality to the host). Not vendor-certified; treat as known-good for this chip on Linux.macaddr=is requiredThe dump ships
macaddr=00:90:4c:0d:f4:3e(Broadcom OUI, not a device identity). An earlier revision of this PR stripped that line when the 43ba wiphy had no real permanent address, on the theory that the firmware would then use OTP.On MacBookPro14,3 it does not. After reboot,
brcmfmacloaded the NVRAM, the ARM firmware started, then:No
wlp3s0. A module reload reproduced the same crash. Restoring themacaddr=key brought the interface up immediately.Running with no NVRAM file at all (stock 2.4 GHz) is a different path from handing the firmware a board file with the key missing. This chip requires the key in any NVRAM it is given. OTP does not answer here.
The helper still substitutes a real permanent address from the 43ba wiphy when one exists. When it does not — including when the wiphy only reports
00:90:4c:*— the sourcemacaddr=line stays. It is never stripped.What
install/hardware/apple/brcmfmac-43602.sh— Apple vendor +MacBookPro14,2/14,3+ PCI14e4:43baonly. Leaves other BCM43602 boards, 2 GHz-only43bb, T2-era chips (apple-bcm-firmware), and non-Apple Broadcom parts alone.install/hardware/apple/fix-brcmfmac-5ghz.shcopies the calibrated NVRAM to/usr/lib/firmware/updates/brcm/under both the generic name and the DMI-specific namebrcmfmacactually requests. Both names are staged under temporary names and renamed into place together.1787312531does the same for existing installs and setsreboot-required. Does not reloadbrcmfmac(that would drop the link carrying the update).cfg80211country.ccode=00/regrev=245defers to the host, and Omarchy already persistsWIRELESS_REGDOMfrom the timezone.firmware/updatesso they override, and do not collide with,linux-firmware-broadcom.Test plan
./test/clitest/shell.d/brcmfmac-5ghz-test.shmacaddr=stripped → dongle crash, nowlp3s0; key restored → interface comes up