Use BCMDHD SDIO for Orange Pi 5 Pro AP6256 Wi-Fi

[cagedbird043]

Summary

• install bcmdhd-sdio-dkms for the Orange Pi 5 Pro AP6256 Wi-Fi module
• blacklist the brcmfmac / brcmutil path for this board and set the BCMDHD firmware / NVRAM / config paths explicitly
• replace the reboot-only brcmfmac unbind helper with a shutdown/reboot poweroff helper that cleanly powers down the SDIO Wi-Fi device

Why

On a real Orange Pi 5 Pro (AP6256 / BCM43456) running Ubuntu 24.04.1 with 6.1.0-1025-rockchip, the default brcmfmac path was unstable:

• sometimes brcmf_attach failed during boot
• sometimes 5 GHz came up briefly and then disappeared after boot
• the regression consistently reproduced on the same board / AP / image family

Switching the board to the BCMDHD SDIO path fixed the issue in repeated live tests.

Validation on hardware

Validated on an Orange Pi 5 Pro connected to an 80 MHz / channel 36 5 GHz AP:

• connected successfully to CMCC-201-5G on 5180 MHz
• remained connected past the previous failure window after cold boot
• remained connected past the previous failure window after warm reboot
• bcmdhd_sdio + dhd_static_buf_sdio were loaded instead of brcmfmac

One representative boot sequence from the fixed system:

• wl_android_wifi_on : Success
• Link UP with 48:81:d4:89:db:3f
• stable 5 GHz connection beyond 120 seconds (where the old path had already failed)

If you want, I can also open a follow-up issue with the full before/after logs and exact local reproduction details.

Fixes #1344
Related to #841

[cagedbird043]

Additional field result after the change landed on the test board:

• after switching the board from the unstable brcmfmac path to bcmdhd_sdio, the same system stayed connected even after the AP was later switched back from 80 MHz to 160 MHz operation on the 5 GHz radio
• that strongly suggests the root problem here is the board-side driver path, not just the AP channel-width configuration

To be precise: the original 80 MHz validation in the PR body was directly observed by command-line checks on the board, while this later 160 MHz result was reported by the board owner after applying the same fix on the same hardware.

If maintainers want, I can also add a compact before/after command log excerpt here for the failing brcmfmac path versus the working bcmdhd_sdio path.