Guoxudong.io
语言 / Language
简体中文
English
首页
博客
关于我
浏览所有文章
Omarchy · · 13 MIN READ

在 Omarchy 上修复 MacBookPro14,2 的 BCM43602 5GHz Wi-Fi

#Linux #Wi-Fi #Omarchy #MacBook Pro

写在最前

本人非常不推荐读者跟着本篇文章手动修复这个问题。本文内容更多的是给后来的 Agent 提供真实场景的参考，如果您一定要手动修复，请先设计好自动回滚和数据备份。

（下面是正文）

本文记录一台 2017 款 13 英寸 MacBook Pro（MacBookPro14,2）在 Omarchy/Arch Linux 下修复内置 Broadcom BCM43602 5GHz Wi-Fi 的全过程。

这不是一篇“下载一个 NVRAM 文件然后重启”的速成教程。真正的问题横跨四层：板级射频校准、BCM43602 老固件、Linux brcmfmac 的监管域通知，以及接入点广播的 Country IE。只解决其中一层，可能出现 Band 2 已经出现、却仍然看不到低信道 5GHz，甚至 2.4GHz 也无法关联的情况。

最终结果如下：

项目修复后结果
目标 SSIDChinaNet-xxxx-5G（已匿名化）
BSSIDbc:45:29:xx:xx:f4（已匿名化）
频率5240 MHz，信道 48
信号约 -38 至 -52 dBm
RX/TX最高约 780 / 866.6 Mbit/s
公网连通223.5.5.5 Ping 0% 丢包
HTTPS直连百度返回 HTTP 200
重启验证通过，自动回滚保护已解除

适用范围与风险

本文的已验证环境是：

1
2
3
4
5
6
7
8
9

Model:       MacBookPro14,2
Board ID:    Mac-CAD6701F7CEA0921
Wi-Fi:       Broadcom BCM43602
PCI ID:      14e4:43ba
Subsystem:   106b:0157
Kernel:      7.1.9-arch1-2
Driver:      brcmfmac
Firmware:    7.35.177.61, 2015-11-10
Omarchy:     Arch Linux / Limine UKI

不要把本文的定制模块直接复制到其他内核，也不要把某台机器的 NVRAM、MAC 地址或射频参数无差别复制到其他 Broadcom 芯片。

NVRAM 不只是“国家码配置”，还包含天线链、RF 开关、LNA/PA、功率表、TSSI/PAPD 和蓝牙共存参数。错误的文件可能造成：

  • Band 2 仍然消失；
  • 只出现部分 5GHz 信道；
  • 能扫描但不能关联；
  • 2.4GHz 退化或持续收到 status_code=16；
  • 发射功率、信号或蓝牙共存异常。

在远程机器上实验时，必须准备独立控制通道，并设置 systemd 自动回滚。不要在只有这一条 Wi-Fi SSH 链路时直接覆盖驱动后“观察看看”。

最初的症状

机器能够稳定连接 2.4GHz，但完全搜索不到 5GHz。基础检查如下：

1
2
3
4
5
6

cat /sys/devices/virtual/dmi/id/product_name
lspci -nn -d 14e4:
uname -r
iw dev
iw phy
iw dev wlp2s0 link

典型结果是：

1
2
3
4
5

MacBookPro14,2
Broadcom BCM43602 [14e4:43ba]
Connected to ...
SSID: ChinaNet-xxxx
freq: 2462.0

iw phy 只有 Band 1，没有 Band 2。内核日志同时显示：

1
2

journalctl -k -b --no-pager \
  | grep -E 'brcmfmac|clm_blob|txcap_blob|Firmware:'

1
2
3
4

brcmf_fw_alloc_request: using brcm/brcmfmac43602-pcie for chip BCM43602/2
brcmf_c_process_clm_blob: no clm_blob available, device may have limited channels available
brcmf_c_process_txcap_blob: no txcap_blob available
Firmware: BCM43602/2 wl0: Nov 10 2015 ... 7.35.177.61

这里已经能排除一个常见误判：不是 NetworkManager 把 5GHz 隐藏了，而是固件初始化后根本没有向 cfg80211 注册 Band 2。

另一台正常工作的 macOS 设备确认，同一路由器的真正 5GHz SSID（文中匿名为 ChinaNet-xxxx-5G）工作在信道 48、5240 MHz。这个外部证据非常关键：如果只看 Linux 扫描结果，会误以为路由器根本没有 5GHz。

MAC 地址也是一条支线陷阱

这台机器最初显示的无线地址是 00:90:4c:*。这个 OUI 来自 Broadcom/Epigram，是固件缺少有效板级数据时常见的占位地址，不是可信的 Apple 永久 MAC。

由于机器已经只有 Omarchy，Internet Recovery 又在中途失败，无法回到 macOS 查看“系统信息”。最后是从 EFI 的 ROM 与 HW_ROM 两个独立变量中读取 6 字节 payload，并确认二者一致，才找回真实 Apple 地址。EFI variable 文件开头有 4 字节 attributes，不能把它们当作地址的一部分：

1
2
3
4
5

sudo find /sys/firmware/efi/efivars -maxdepth 1 \
  -type f \( -name 'ROM-*' -o -name 'HW_ROM-*' \)

# 对确认过的具体文件读取 attributes 之后的 6 字节；不要公开输出。
sudo xxd -s 4 -l 6 '/sys/firmware/efi/efivars/<变量文件>'

另一个误区是从 Internet Recovery 的 preferred-networks 二进制记录里搜索 Apple OUI。记录中确实可能出现看似 MAC 的 6 字节片段，但它们处在摘要/哈希区域，不能据此认定硬件地址。

MAC 并不是本次 5GHz 信道故障的根因，但错误 MAC 会干扰 AP 过滤、NetworkManager profile 和关联实验。排障时应先把“真实硬件地址”和“固件当前暴露的地址”分开记录。

为什么常规修复无效

在 Band 2 尚未注册时，下面这些设置都只能影响“如何使用已经存在的频段”，不能凭空补出板级射频能力：

  • 在 NetworkManager、wpa_supplicant 和 iwd 之间切换；
  • 关闭 Wi-Fi 省电；
  • 关闭扫描 MAC 随机化；
  • 调整 WPA2/WPA3、PMF、RSN 或 CCMP；
  • 单独执行 iw reg set CN；
  • 只添加 brcmfmac.feature_disable=0x82000；
  • 修改连接配置中的 band 或 BSSID。

feature_disable=0x82000 仍然有用，它处理的是 BCM43602 与现代 supplicant/AP 之间的另一类握手兼容问题；但它不能替代缺失的板级 NVRAM。Omarchy PR #7487 也明确把这两个问题区分开来。

三份社区 NVRAM 不是一回事

早期最大的误区，是把所有 brcmfmac43602-pcie.txt 都当成“同一份修复”。实际比对后，至少存在三类显著不同的射频数据。

来源boardtype/rev天线链country tupleboardflags3本机结果
Omarchy PR #7671 / Bugzilla 2905690x61b / 0x14213×3，700/2450xC0000303所有 Wi-Fi 关联失败
jsoyer/nohz donor0x61b / 0x14213×3，700/2450x00000300Band 2 出现，但低信道不可用，2.4GHz status 16
Omarchy PR #7487 / Boot Camp0x073e / 0x11012×2，30/10x40000108配合内核补丁后完整成功

PR #7671 的公开验证是在 MacBookPro14,3 的信道 149；它证明某份 BCM43602 NVRAM 可以恢复高信道 5GHz，却不能证明所有 MacBookPro14,x 都适用，更不能证明信道 48 可用。

本机对 jsoyer/nohz 三串流文件的受控实验进一步说明：

  1. Band 2 可以被激活，说明 5GHz RF 硬件本身大概率没有损坏。
  2. 149、153、157、161 可以被扫描到。
  3. 36、40、44、48 仍被禁用。
  4. 2.4GHz 关联持续收到 AP 的 status_code=16。
  5. 改 PMF、CCMP、MAC、feature_disable、国家码和固件内 country tuple 均无法解决。

所以“iw phy 出现 Band 2”不能作为修复成功的标准。真正的验收必须包含目标信道扫描、WPA 关联、IP 获取和真实数据传输。

除此之外还有两次有价值的阴性实验：

  • vfontanela 的约 20 行最小 MacBookPro14,2 配置仍然只有 Band 1，证明仅补几个 board 字段不够；
  • animatek 的 MacBookPro14,3 二串流配置只在被动扫描中暴露高信道，仍不能满足本机信道 48 的目标。

这些结果共同指向一个结论：必须同时匹配板级 RF 参数和 BCM43602 的固件监管行为，不能只在 NVRAM 中反复试 country code。

突破点：问题不只在 NVRAM

1. 国家码矩阵实验

为了把射频校准问题与监管域问题拆开，在 NetworkManager 停止、AP 尚未参与扫描时，使用同一份完整 NVRAM，仅改变初始 country tuple，然后热加载驱动。

低信道结果如下：

固件初始 tuple36/40/44/48
CN/0全部 disabled
JP/0全部可用
00/245全部可用

这组结果把根因缩小到了 BCM43602 固件自己的国家表：这份 2015 年固件中的 CN/rev0 会禁用 5150–5250 MHz 的低信道。

为什么扫描 AP 后又变回 CN/0

wpa_supplicant 日志出现了：

1

CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=CN

接入点广播的 Country IE 告诉 Linux 当前国家是 CN。这个信息本身完全正确，问题发生在 brcmfmac 如何把它传给老固件。

Linux 7.1.9 的 brcmf_translate_country_code() 对 BCM43602 启用 ISO 3166 fallback。当设备没有专用 country map 时，它会把收到的 CN 转换为：

1
2

ccode=CN
rev=0

随后 brcmf_cfg80211_reg_notifier() 通过 firmware country iovar 把它写回 BCM43602。于是流程变成：

1
2
3
4
5
6
7
8
9

Boot Camp NVRAM 0/1
        ↓
低信道 36–48 可用
        ↓
Linux 或 AP 发出 CN regulatory request
        ↓
brcmfmac fallback 为 CN/0
        ↓
老固件重新禁用 36–48

这解释了几个此前互相矛盾的现象：

  • CN 监管域在法规上允许 36–48，但网卡仍显示 disabled；
  • 某些社区用户在高信道 149 成功，本机信道 48 却失败；
  • 强制 JP 似乎能“修好”低信道，但它不是合规、可靠的长期方案；
  • 只安装 NVRAM 或只设置 cfg80211.ieee80211_regdom=CN 都不够。

最终修复设计

最终方案坚持一个原则：

Linux 主机仍按 CN 监管域限制信道和发射行为，但不再让 BCM43602 把自己的工作 NVRAM 改写为有缺陷的 CN/0 表。

方案包含三部分：

  1. 使用 Apple Boot Camp lineage 的 2×2 BCM43602 NVRAM；
  2. 对 BCM43602 做窄范围 brcmfmac 补丁；
  3. 通过内核命令行让 cfg80211 的全局监管域保持 CN。

NVRAM 来源

本文使用 Omarchy PR #7487 中的 Boot Camp NVRAM。写作时该 PR 仍处于 open 状态；其 NVRAM 来自 Apple Windows/Boot Camp 驱动 lineage，属于 Broadcom 专有数据，不在 linux-firmware 的常规分发范围内。

本次验证文件的 SHA-256：

1

9111375d9552d096cd05ca2ee705e7866882d3bb81372df33b40813bd3a47117

下载固定提交，避免上游内容漂移：

1
2
3
4
5

curl -fL \
  'https://raw.githubusercontent.com/basecamp/omarchy/eb8c83e8b5f7931e883adcada3f8eab38f650a93/default/firmware/apple/brcmfmac43602-pcie.txt' \
  -o brcmfmac43602-pcie.txt

sha256sum brcmfmac43602-pcie.txt

不要直接沿用文件中的示例 MAC，更不要使用本文案例中的 MAC。先检查永久地址：

1
2
3

IFACE=$(iw dev | awk '$1 == "Interface" { print $2; exit }')
nmcli -g GENERAL.HWADDR,GENERAL.PERM-HWADDR device show "$IFACE"
ethtool -P "$IFACE"

如果得到的是 00:90:4c:*，它很可能是 Broadcom/Epigram 占位地址，不应当作唯一硬件身份。应从本机 Apple/EFI 信息可靠取得真实地址，或者按照 PR #7487 的安装逻辑删除 macaddr= 行，让固件尝试 OTP fallback。不要猜一个地址。

内核补丁

补丁只处理 BRCM_CC_43602_CHIP_ID，不改变其他 Broadcom 芯片。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@
 	brcmf_dbg(TRACE, "Enter: initiator=%d, alpha=%c%c\n", req->initiator,
 		  req->alpha2[0], req->alpha2[1]);

+	/* Keep the working board tuple; cfg80211 still enforces CN on host. */
+	if (drvr->bus_if->chip == BRCM_CC_43602_CHIP_ID &&
+	    req->alpha2[0] == 'C' && req->alpha2[1] == 'N') {
+		brcmf_dbg(INFO, "Keeping BCM43602 firmware country for CN request\n");
+		return;
+	}

 	err = brcmf_fil_iovar_data_get(ifp, "country", &ccreq, sizeof(ccreq));
@@
 	wiphy->reg_notifier = brcmf_cfg80211_reg_notifier;
 	wiphy->regulatory_flags |= REGULATORY_CUSTOM_REG;
+	if (drvr->bus_if->chip == BRCM_CC_43602_CHIP_ID)
+		wiphy->regulatory_flags |= REGULATORY_COUNTRY_IE_IGNORE;
 	wiphy_apply_custom_regulatory(wiphy, &brcmf_regdom);

两个改动缺一不可：

  • REGULATORY_COUNTRY_IE_IGNORE 阻止 AP Country IE 再次驱动这张网卡的固件国家切换；
  • notifier 中的 BCM43602/CN 特判处理开机时由全局 CN 监管域触发的请求，否则即使忽略 AP Country IE，启动阶段仍可能把固件改成 CN/0。

Linux 主机侧仍使用 CN，所以这不是伪装成 JP，也不是关闭监管。

在 Omarchy 上构建匹配当前内核的模块

1. 安装构建依赖

1

sudo pacman -S --needed base-devel git linux-headers zstd

确保 headers 与正在运行的内核完全一致：

1
2

uname -r
test -e "/usr/lib/modules/$(uname -r)/build/Makefile"

2. 获取精确源码

本次运行的是 7.1.9-arch1-2，对应实验使用 gregkh 的 v7.1.9，提交：

1

ffc82ed665314ccf141abc4710830f3f424d98ea

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

git clone --filter=blob:none --no-checkout \
  https://github.com/gregkh/linux.git linux-v7.1.9
cd linux-v7.1.9
git sparse-checkout init --cone
git sparse-checkout set \
  drivers/net/wireless/broadcom/brcm80211/brcmfmac \
  drivers/net/wireless/broadcom/brcm80211/brcmutil \
  drivers/net/wireless/broadcom/brcm80211/include
git checkout v7.1.9
git rev-parse HEAD

对 cfg80211.c 应用上面的补丁后先运行：

1

git diff --check

3. 外部模块构建的一个坑

Omarchy 当前内核启用了：

1
2

CONFIG_BRCMDBG=y
CONFIG_BRCM_TRACING=y

Broadcom 父目录 Makefile 原本通过 subdir-ccflags 添加 -DDEBUG。直接把 brcmfmac 子目录作为外部模块构建时，这个父级 flag 不会自动继承，结果会出现 brcmf_debug_create_memdump 等符号重定义。

本次构建命令因此是：

1
2
3
4
5
6
7
8
9

KVER=$(uname -r)
SRC="$PWD/drivers/net/wireless/broadcom/brcm80211/brcmfmac"

make -C "/usr/lib/modules/$KVER/build" M="$SRC" clean
make -j"$(nproc)" \
  -C "/usr/lib/modules/$KVER/build" \
  M="$SRC" \
  KCFLAGS=-DDEBUG \
  modules

只有在当前内核确实是 CONFIG_BRCMDBG=y 时才照搬 KCFLAGS=-DDEBUG。其他内核配置应按自己的 Kbuild 条件调整。

验证模块：

1
2
3
4

modinfo -F vermagic "$SRC/brcmfmac.ko"
modinfo -F depends "$SRC/brcmfmac.ko"
strings "$SRC/brcmfmac.ko" \
  | grep 'Keeping BCM43602 firmware country'

vermagic 必须匹配当前 uname -r。本案例结果是：

1

7.1.9-arch1-2 SMP preempt mod_unload

先做非持久化验证

不要把第一次尝试直接写进启动路径。推荐流程：

  1. 停止 NetworkManager；
  2. 备份并临时安装 generic 与 DMI-specific NVRAM；
  3. 卸载 brcmfmac_wcc 和 brcmfmac；
  4. iw reg set CN；
  5. 用 insmod /path/to/brcmfmac.ko feature_disable=0x82000 roamoff=1 加载补丁模块；
  6. 检查信道 36–48；
  7. 扫描并连接目标 AP；
  8. 验证公网和 HTTPS；
  9. 无论成功失败都恢复原模块和 NVRAM。

临时 NVRAM 文件名应同时覆盖 generic 与 DMI-specific 请求：

1
2

/usr/lib/firmware/brcm/brcmfmac43602-pcie.txt
/usr/lib/firmware/brcm/brcmfmac43602-pcie.Apple Inc.-MacBookPro14,2.txt

先检查低信道：

1
2
3

PHY=$(basename "$(readlink -f /sys/class/net/wlp2s0/phy80211)")
iw phy "$PHY" info \
  | grep -E '\* (5180|5200|5220|5240)(\.0)? MHz'

期望：

1
2
3
4

* 5180.0 MHz [36] (20.0 dBm)
* 5200.0 MHz [40] (20.0 dBm)
* 5220.0 MHz [44] (20.0 dBm)
* 5240.0 MHz [48] (20.0 dBm)

再扫描目标：

1
2

sudo iw dev wlp2s0 scan \
  | grep -A8 -B3 'SSID: ChinaNet-xxxx-5G'

本次非持久化测试第一次就找到：

1
2
3

SSID: ChinaNet-xxxx-5G
BSSID: bc:45:29:xx:xx:f4
freq: 5240

然后从同一路由器的 2.4GHz profile 克隆凭据，只修改 SSID、band 和 BSSID。不要在日志中打印 PSK：

1
2
3
4
5
6
7

nmcli connection clone '<2.4GHz-连接名>' '<5GHz-连接名>'
nmcli connection modify '<5GHz-连接名>' \
  connection.autoconnect yes \
  connection.autoconnect-priority 50 \
  802-11-wireless.ssid 'ChinaNet-xxxx-5G' \
  802-11-wireless.band a \
  802-11-wireless.bssid '<5GHz-BSSID>'

持久化配置

1. 安装模块

不要覆盖发行版原文件，把模块放到 updates：

1
2
3
4
5

KVER=$(uname -r)
sudo install -Dm0644 brcmfmac.ko \
  "/usr/lib/modules/$KVER/updates/brcmfmac.ko"
sudo depmod -a "$KVER"
modinfo -n brcmfmac

期望选中：

1

/lib/modules/7.1.9-arch1-2/updates/brcmfmac.ko

2. 安装 NVRAM

先对现有同名文件做带时间戳备份，然后安装已经完成 MAC 处理的文件：

1
2
3
4
5

sudo install -m 0644 brcmfmac43602-pcie.txt \
  '/usr/lib/firmware/brcm/brcmfmac43602-pcie.txt'

sudo install -m 0644 brcmfmac43602-pcie.txt \
  '/usr/lib/firmware/brcm/brcmfmac43602-pcie.Apple Inc.-MacBookPro14,2.txt'

3. 模块参数

/etc/modprobe.d/brcmfmac.conf：

1

options brcmfmac feature_disable=0x82000 roamoff=1

4. Limine 内核参数

/etc/limine-entry-tool.d/90-brcmfmac.conf：

1

KERNEL_CMDLINE[default]+=" brcmfmac.feature_disable=0x82000 brcmfmac.roamoff=1 cfg80211.ieee80211_regdom=CN"

重建 UKI：

1

sudo limine-mkinitcpio

重启后确认：

1

cat /proc/cmdline

应包含：

1
2
3

brcmfmac.feature_disable=0x82000
brcmfmac.roamoff=1
cfg80211.ieee80211_regdom=CN

如何设计自动回滚

本次所有会断开 Wi-Fi 的实验都由 root systemd oneshot 服务执行，而不是依赖 SSH 进程继续存活。持久化前，状态目录保存以下内容：

  • 原 updates/brcmfmac.ko 是否存在及其备份；
  • generic 与 DMI-specific NVRAM 备份；
  • Limine、modprobe、NetworkManager 配置备份；
  • 是否由本次实验新建 5GHz connection；
  • 一个 armed 标记。

开机 validator 的成功条件应同时满足：

1
2
3
4
5

SSID == 目标 5GHz SSID
频率 >= 5000 MHz
存在默认路由
公共 IPv4 可达
直接 HTTPS 成功

本案例最终使用：

1
2
3
4

ping -c 3 -W 3 223.5.5.5
curl --noproxy '*' -4 -fsSI \
  --connect-timeout 5 --max-time 12 \
  https://www.baidu.com >/dev/null

验证失败时，rollback 应恢复备份、删除或停用 custom module、执行 depmod 与 limine-mkinitcpio，再重启回原 2.4GHz 配置。验证成功时则删除 armed，并禁用 validator 服务。

一个真实的假阴性

第一次持久化验证错误地使用了：

1

ping 192.168.1.1

5GHz 已经关联成功并取得 192.168.0.x/23，但网关 Ping 100% 丢包，回滚逻辑因此取消了重启。后来回到完全正常的 2.4GHz 再测，网关仍然 100% 丢包，而公共 IP 和 HTTPS 正常。

结论是：这个路由器不回应 ICMP echo。Ping 网关在这里不是链路健康检查，而是稳定的假阴性来源。

重启后的最终验证

1. 模块与命令行

1
2

modinfo -n brcmfmac
cat /proc/cmdline

1
2

/lib/modules/7.1.9-arch1-2/updates/brcmfmac.ko
... cfg80211.ieee80211_regdom=CN

2. 监管域

1

iw reg get

全局应为 CN。phy#N 可能仍显示 country 99，这是 brcmfmac 自定义 wiphy regdom 的标识，不等于机器真的被设置到了某个“99 国家”。关键是全局 CN 与实际可用信道的交集仍由 cfg80211 执行。

3. 5GHz 链路

1

iw dev wlp2s0 link

最终记录：

1
2
3
4
5
6

Connected to bc:45:29:xx:xx:f4
SSID: ChinaNet-xxxx-5G
freq: 5240.0
signal: -51 dBm
rx bitrate: 780.0 MBit/s
tx bitrate: 866.6 MBit/s

4. 真实网络

1
2
3
4

ping -c 3 -W 3 223.5.5.5
curl --noproxy '*' -4 -I \
  --connect-timeout 5 --max-time 12 \
  https://www.baidu.com

最终结果：公网 Ping 0% 丢包，HTTPS 200，开机 validator 写入 RESULT=SUCCESS 并解除回滚保护。

哪些方法不要再重复

只改 regdom

无 NVRAM 时连 Band 2 都不存在；有 NVRAM 后，未补丁的驱动又会把 CN 写成固件的 CN/0。单独改 regdom 不能覆盖这两层问题。

强制 JP

JP/0 在实验中确实开放了低信道，但物理位置在中国，长期伪装其他监管域不是正确方案。最终修复保留了主机侧 CN。

看见 Band 2 就宣布成功

三串流 donor 已经证明 Band 2 可以出现，但 2.4GHz 会关联失败，信道 48 仍然不可用。验收必须做到实际关联和数据传输。

反复换 NetworkManager 后端

当 iw phy 没有目标频段或信道 disabled 时，问题在 supplicant 之下。换 iwd/wpa_supplicant 只会制造更多变量。

覆盖发行版原模块

把自定义模块安装到 updates，保留发行版 .ko.zst。这样回滚只需撤销 override，不必从包缓存恢复原文件。

回滚方法

如果重启后无法联网，使用有线网络、USB 网卡或本地终端进入系统，恢复安装前备份。若没有旧的同名文件，可先把 custom 文件移动到隔离目录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

KVER=$(uname -r)
sudo mkdir -p /var/lib/brcmfmac-disabled

sudo mv "/usr/lib/modules/$KVER/updates/brcmfmac.ko" \
  /var/lib/brcmfmac-disabled/ 2>/dev/null || true

sudo mv '/usr/lib/firmware/brcm/brcmfmac43602-pcie.txt' \
  /var/lib/brcmfmac-disabled/ 2>/dev/null || true

sudo mv '/usr/lib/firmware/brcm/brcmfmac43602-pcie.Apple Inc.-MacBookPro14,2.txt' \
  /var/lib/brcmfmac-disabled/ 2>/dev/null || true

再恢复原 Limine/modprobe 配置，执行：

1
2
3

sudo depmod -a "$KVER"
sudo limine-mkinitcpio
sudo reboot

如果这些路径在实验前已有文件，应恢复备份，而不是简单删除。

内核升级后的维护

这个 brcmfmac.ko 与 7.1.9-arch1-2 的 ABI/vermagic 绑定。升级内核后：

  • 新内核不会自动使用旧目录中的模块；
  • 不能强制加载旧 .ko；
  • 应获取与新内核匹配的源码，重新应用同一窄补丁并构建；
  • 构建后重新检查 modinfo -F vermagic；
  • 再走一次非持久化验证和开机回滚流程。

在补丁被上游或发行版正式接纳前，最好把“内核升级后检查 5GHz custom module”加入维护清单，而不是建立一个盲目对所有未来内核自动编译的 DKMS 包。

结论

这次排障最重要的不是得到了一个能工作的 .ko，而是把两个互相叠加的问题拆开了：

  1. BCM43602 缺少板级 NVRAM，所以最初只有 2.4GHz；
  2. NVRAM 恢复 Band 2 后，Linux 7.1.9 的国家码 fallback 又会把 AP/主机的 CN 请求写成老固件有缺陷的 CN/rev0，重新禁用目标信道 48。

Boot Camp 2×2 NVRAM 解决板级校准，BCM43602 专用内核补丁解决 CN/0 回写，cfg80211 全局 CN 则保留合法监管。三者组合后，机器才能在真实重启后稳定连接信道 48。

如果面对另一台 Mac，最值得复用的是排障方法，而不是直接复制结果：先确认硬件与目标信道，再区分 Band 注册、固件 country table、Linux regdom 和 Wi-Fi 关联四个层次；每一步都设置可自动执行的回滚，并用真实数据面而不是单一 Ping 作为成功标准。

参考资料