xm530: bring up the AltoBeam ATBM6032 USB WiFi chip

[yatotoshka]

Problem

Some XM530 boards (e.g. IPC-RB-BLK530AI-0235P-AB0 V1.03) carry an AltoBeam
ATBM6032 USB WiFi (007a:8888) with a power-down gpio. The stock xm530 image has
neither the driver nor a /etc/wireless/usb case for it, so WiFi is not usable
on these boards.

What this change does

• Enables the existing atbm60xx package in xm530_lite_defconfig (603x model,
  USB interface) — the same three-line pattern as t31_ultimate_defconfig — and
  pins ATBM60XX_VERSION to a full 40-character SHA instead of moving HEAD.
• Adds the atbm603x-xm530-usb case to /etc/wireless/usb: modprobe dwc_otg,
  then modprobe wifi_pdn value="$pdn" where the PDN gpio is read from the
  per-board wifipdn env (set e.g. by a builder profile's customizer), then
  modprobe atbm603x_wifi_usb. S40network then applies the MAC and runs
  ifup wlan0 exactly as for every other wlandev. The case is purely
  additive and follows the file's established per-board pattern.
• Re-runs depmod in xiongmai-osdrv-xm530's target-finalize: the vendor
  kernel ships a modules.dep that lists only its own modules, leaving
  dwc_otg, wifi_pdn and the atbm module invisible to modprobe (same
  pattern as hisilicon-opensdk).
• Installs the vendor cfg80211 rewrite as cfg80211_xm711.ko instead of over
  the in-tree cfg80211 (CONFIG_CFG80211=m) at the canonical module path, and
  loads it from there in the wifi xm711 helper. atbm60xx — and the
  kernel-built mac80211 — build against the in-tree module, so both WiFi stacks
  stay usable in one image.

Companion profile in OpenIPC/builder#130
(xm530_lite_anbiux-a8b-3mp): on first boot sets wlandev=atbm603x-xm530-usb,
wifipdn to the board's PDN gpio and the upgrade url to this device's builder
release, so the camera works and keeps updating out of the box. This PR is the
fallback: with it merged, any xm530 with the chip works via fw_setenv wlandev=atbm603x-xm530-usb wifipdn=<gpio> wlanssid=... wlanpass=... wlanmac=... even without the builder profile.

Status (2026-09-06)

• Rebased on the current upstream master (317b443d); the branch now sits on
  top of the merged SD-card autoload fix (xm530: autoload the SD card driver at boot #2315), so an image built from it also
  carries the sdio0_sd autoload.
• Re-verified on the camera from a factory-clean state (env wiped) on the
  latest nightly (master+4c34a66): the radio associates and takes a DHCP
  lease — see Evidence.

Hardware tested on

XM530AI (marking 30WX1), board IPC-RB-BLK530AI-0235P-AB0 V1.03, SmartSens
SC3335, AltoBeam ATBM6032 USB WiFi (007a:8888), PDN on gpio 96

Evidence

The chip, the PDN gpio and the exact load order used by the new case
(dwc_otg → wifi_pdn → atbm603x) are proven on this hardware — the camera is
currently associated:

Before (stock image, no driver for the chip at all):

# dmesg — no atbm driver registered, wlan0 never appears
ls /sys/class/net/
eth0  lo

After (radio driven, wlan0 up):

wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether f4:b1:9c:a8:ca:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.243/24 brd 192.168.1.255 scope global wlan0
[atbm_log]:wlan0: authenticated
[atbm_log]:wlan0: associated
default via 192.168.1.1 dev wlan0

The Web UI is reachable both over the wlan0 address (192.168.1.243) and the
Ethernet address (192.168.1.242).

Honest status: the running camera currently loads the driver from a prebuilt
blob (built from the same atbm_60xx revision this PR pins) plus a local init
script, not from the clean-build path of this patch (compiled atbm60xx +
wlandev + S40network + the wireless/usb case). That path is still
unverified on-device; CI confirms atbm60xx compiles against the xm530 kernel,
and the size report says whether the 5M rootfs still fits (the image now also
carries the #2315 SD module). To close the gap: build an image from this branch
— possible today via builder#130's build-one with firmware_repo pointed at
this fork and firmware_ref=xiongmai-atbm60xx-wifi, or right after this PR is
merged — flash it and verify.

Known trade-off: enabling atbm60xx in the shared defconfig grows every xm530
image by the driver module. The cfg80211 rename leaves stock images carrying
the vendor rewrite as cfg80211_xm711.ko alongside the in-tree cfg80211
(previously it overwrote it), with the wifi xm711 helper loading the renamed
copy, so xm711/lynx boards keep working at the cost of one extra module file.
The only xm530 profile proposed in OpenIPC/builder today ([builder#130]) is
this ATBM board; no xm711-equipped xm530 is registered or known to be
deployed. Both hunks stand alone and can be dropped or split if reviewers
disagree.

Scope

• No kernel patches under general/package/all-patches/linux/ (those go to OpenIPC/linux)
• No files specific to a single retail camera model (those go to OpenIPC/builder)
• No probing or bring-up tooling (that goes to OpenIPC/ipctool)
• Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a value specific to my board
• Package sources come from an OpenIPC repository, and any version bump keeps at least the specificity of the pin it replaces (a new package should pin a full 40-character SHA)
• No LD_PRELOAD, and no binaries that cannot be rebuilt from source
• New code is selected by a defconfig, so CI actually builds it

Note on the overlay checkbox: the new wireless/usb case is purely additive
and matches the file's established per-board pattern (driver, SoC, board
bring-up — like the ~40 existing cases); it changes no existing board's
behaviour and only runs when wlandev is set to atbm603x-xm530-usb. The PDN
gpio is read from the per-board wifipdn env at run time — set by the builder
profile's customizer or the user, not hardcoded in the shared script.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Enable AltoBeam ATBM6032 USB WiFi on XM530

✨ Enhancement 🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Enables ATBM6032 USB WiFi on XM530 with a runtime-configured PDN GPIO.
• Regenerates module dependencies so modprobe resolves the complete USB WiFi stack.
• Isolates XM711 cfg80211 and pins ATBM60XX sources for reproducible coexistence.

Diagram

graph TD
  DEF["XM530 defconfig"] --> ATBM["ATBM60XX package"] --> IMG["XM530 image"] --> NET["Network startup"] --> USB["USB selector"] --> MOD["WiFi module stack"] --> WLAN["wlan0"]
  OSDRV["XM530 osdrv"] --> IMG

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Board-specific XM530 firmware variant

• ➕ Avoids increasing every XM530 image with the ATBM driver.
• ➕ Limits ATBM-specific behavior to confirmed hardware profiles.
• ➖ Fragments XM530 firmware builds and release maintenance.
• ➖ Removes the environment-driven fallback for unregistered ATBM boards.
• ➖ Requires reliable board identification before image selection.

2. Load modules through absolute insmod paths

• ➕ Avoids adding a second depmod finalization pass.
• ➕ Can explicitly control module loading order.
• ➖ Hardcodes kernel paths and transitive dependencies into startup scripts.
• ➖ Does not repair module discovery for other modprobe consumers.
• ➖ Becomes fragile when module names or dependencies change.

Recommendation: Keep the PR's shared-image and depmod-based approach. It follows existing wireless selection conventions, preserves a manual environment-based fallback, and fixes module discovery globally rather than encoding brittle paths. The shared-image size increase is the main trade-off and should be accepted only after CI confirms the 5 MB root filesystem still fits; a board-specific variant is preferable if that budget is exceeded.

Files changed (5) +33 / -4

Enhancement (1) +10 / -0

usbAdd runtime ATBM6032 USB bring-up for XM530 +10/-0

Add runtime ATBM6032 USB bring-up for XM530

• Adds an environment-selected XM530 case that loads the DWC OTG controller, optionally powers the radio through the wifipdn GPIO, and loads the ATBM603x USB driver. The existing network startup flow subsequently assigns the MAC address and brings up wlan0.

general/overlay/etc/wireless/usb

Bug fix (2) +17 / -3

wifiLoad the isolated XM711 cfg80211 module +1/-1

Load the isolated XM711 cfg80211 module

• Changes the XM711 helper to load cfg80211_xm711 through modprobe rather than inserting a vendor rewrite from the canonical in-tree cfg80211 path. This preserves XM711 support while allowing ATBM60XX and mac80211 to use the kernel-built cfg80211 module.

general/package/xiongmai-osdrv-xm530/files/script/wifi

xiongmai-osdrv-xm530.mkSeparate XM711 cfg80211 and rebuild module dependencies +16/-2

Separate XM711 cfg80211 and rebuild module dependencies

• Installs the vendor cfg80211 rewrite as cfg80211_xm711.ko instead of overwriting the in-tree module. It also reruns depmod during target finalization so modprobe can resolve vendor USB, PDN, compatibility, and ATBM modules in the completed image.

general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk

Other (2) +6 / -1

xm530_lite_defconfigSelect the ATBM603x USB driver for XM530 Lite +5/-0

Select the ATBM603x USB driver for XM530 Lite

• Enables the existing ATBM60XX package with the 603x model and USB transport. This adds the driver to all images built from the shared XM530 Lite configuration.

br-ext-chip-xiongmai/configs/xm530_lite_defconfig

atbm60xx.mkPin ATBM60XX to an immutable source revision +1/-1

Pin ATBM60XX to an immutable source revision

• Replaces the moving HEAD reference with a full commit SHA, making ATBM60XX builds reproducible and preventing unreviewed upstream changes from entering firmware images.

general/package/atbm60xx/atbm60xx.mk

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (5) 📜 Skill insights (0)

1. Other cameras ship unusable WiFi logic 📘 Rule violation ⚙ Maintainability ⭐ New

Description

general/overlay/etc/wireless/usb installs the new atbm603x-xm530-usb branch unconditionally
instead of keying it to BR2_PACKAGE_ATBM60XX through a late overlay or hook. On an image where
that optional package is disabled, selecting this shipped branch still reaches the dwc_otg,
wifi_pdn, and atbm603x_wifi_usb loads even though the driver is not part of that build.

Code

general/overlay/etc/wireless/usb[R329-332]

+if [ "$1" = "atbm603x-xm530-usb" ]; then
+	modprobe dwc_otg
+	pdn=$(fw_printenv -n wifipdn)
+	[ -n "$pdn" ] && modprobe wifi_pdn value="$pdn"

Evidence

Compliance rule 27 requires files and actions associated with optional packages to be included
conditionally through the late-overlay or late-hook mechanisms. The added ATBM6032 actions reside in
the shared overlay, while ATBM60XX remains an optional Kconfig package and no corresponding
conditional entry exists in the late-overlay list.

CLAUDE.md: Use Conditional Late Overlays and Hooks for Package-Specific Files
general/overlay/etc/wireless/usb[327-335]
general/package/atbm60xx/Config.in[1-7]
general/scripts/late-overlays.list[1-7]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ATBM6032-specific branch is shipped through the unconditional shared overlay, including in images that do not enable the ATBM60XX package.

## Issue Context
Relocate or generate this branch through a configuration-keyed late overlay or post-build hook so it is present only in applicable XM530 builds with ATBM60XX enabled.

## Fix Focus Areas
- general/overlay/etc/wireless/usb[327-335]
- general/scripts/late-post-build-hooks.list[1-4]
- general/package/atbm60xx/atbm60xx.mk[10-13]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Camera WiFi can miss dependencies 📘 Rule violation ☼ Reliability

Description

The modified wifi helper invokes insmod for cfg80211_xm711.ko instead of the tree's
dependency-aware modprobe convention. When the xm711 branch runs, dependencies are not resolved
from the regenerated module metadata, so an unmet prerequisite prevents that WiFi stack from
loading.

Code

general/package/xiongmai-osdrv-xm530/files/script/wifi[10]

+    insmod /lib/modules/3.10.103+/kernel/net/wireless/cfg80211_xm711.ko     # vendor rewrite, kept off the in-tree cfg80211 path

Evidence

The changed shipped-script line directly invokes insmod. Compliance rules 10 and 51 require
shipped scripts to use dependency-aware modprobe where this tree follows that convention.

Rule 10: Shipped scripts follow tree conventions
general/package/xiongmai-osdrv-xm530/files/script/wifi[10-10]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The modified shipped WiFi helper loads `cfg80211_xm711.ko` directly with `insmod`, bypassing dependency-aware module loading.
## Issue Context
The package now regenerates module dependency metadata, so the renamed module should be loaded by module name through `modprobe`.
## Fix Focus Areas
- general/package/xiongmai-osdrv-xm530/files/script/wifi[10-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. atbm60xx path remains untested 📘 Rule violation ☼ Reliability

Description

The PR enables the clean-built atbm60xx path globally, but the description explicitly says the
demonstrated camera used a prebuilt blob and local init script and that an image built from this
patch has not yet been flashed. The supplied before/after output therefore does not verify the
behavior-changing path introduced here, contrary to the hardware-evidence requirement.

Code

br-ext-chip-xiongmai/configs/xm530_lite_defconfig[R70-72]

+BR2_PACKAGE_ATBM60XX=y
+BR2_PACKAGE_ATBM60XX_MODEL_603X=y
+BR2_PACKAGE_ATBM60XX_INTERFACE_USB=y

Evidence

Compliance ID 1 treats an explicit statement that the change was not tested on hardware as a
failure. The cited defconfig lines activate the driver path for xm530_lite images, while the PR
description states that this exact compiled-driver and wlandev path has not yet been flashed and
verified.

Rule 1: Hardware evidence is present and honest
br-ext-chip-xiongmai/configs/xm530_lite_defconfig[70-72]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly enabled `atbm60xx` clean-build and startup path lacks hardware verification from an image produced by this PR.
## Issue Context
The existing evidence comes from a prebuilt driver blob and local init script, while Compliance ID 1 requires board output proving the behavior-changing implementation under review.
## Fix Focus Areas
- br-ext-chip-xiongmai/configs/xm530_lite_defconfig[70-72]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View action required (5)

4. PDN module is missing 🐞 Bug ≡ Correctness

Description

The new ATBM6032 path runs modprobe wifi_pdn when wifipdn is configured, but the XM530 package
installs no wifi_pdn.ko, so the required PDN GPIO is never asserted and the USB radio may not
enumerate. The script ignores the failed modprobe and continues, leaving boot to report success from
this case even though wlan0 cannot appear on the tested hardware path.

Code

general/overlay/etc/wireless/usb[332]

+	[ -n "$pdn" ] && modprobe wifi_pdn value="$pdn"

Evidence

The changed case conditionally requires wifi_pdn before loading ATBM. The XM530 installation
commands only copy module globs from files/kmod, files/kmod/usb, and files/kmod/xm711, while
the repository's USB module directory contains only dwc_common_port_lib.ko and dwc_otg.ko; the
existing XM711 loader also references the same absent target path, corroborating that the package
does not currently supply this module.

general/overlay/etc/wireless/usb[329-334]
general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk[19-22]
general/package/xiongmai-osdrv-xm530/files/script/wifi[7-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new ATBM6032 USB initialization invokes `wifi_pdn`, but no `wifi_pdn.ko` is installed into the XM530 image. Supply the required driver from rebuildable source and make initialization fail when the mandatory PDN setup fails.
## Issue Context
The XM530 package currently installs top-level, `usb`, and `xm711` module globs. The `usb` directory contains only `dwc_common_port_lib.ko` and `dwc_otg.ko`; do not solve this by importing an unrebuildable factory binary.
## Fix Focus Areas
- general/overlay/etc/wireless/usb[331-333]
- general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk[19-22]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. GPIO 96 enters shared overlay 📘 Rule violation ☼ Reliability

Description

The new shared /etc/wireless/usb case hardcodes board-specific PDN GPIO 96. Because
general/overlay/ ships broadly, this board value violates the overlay blast-radius rules and
should be supplied through board-specific configuration instead.

Code

general/overlay/etc/wireless/usb[331]

+	insmod /lib/modules/3.10.103+/xiongmai/wifi_pdn.ko value=96 2>/dev/null

Evidence

Rules 5 and 13 explicitly prohibit adding a board-specific GPIO number under general/overlay/. The
added wifi_pdn.ko value=96 command introduces exactly such a value in the shared USB wireless
script.

Rule 5: No device-specific values in generic configuration
general/overlay/etc/wireless/usb[331-331]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The shared wireless overlay hardcodes the board-specific PDN GPIO value `96`.
## Issue Context
Shared overlay files must remain board-agnostic; board-specific GPIO selection must come from per-board configuration or builder integration.
## Fix Focus Areas
- general/overlay/etc/wireless/usb[331-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. USB stack uses insmod 📘 Rule violation ⚙ Maintainability

Description

The new shipped script loads dwc_common_port_lib, dwc_otg, and wifi_pdn with direct-path
insmod calls even though repository policy requires dependency-aware modprobe. This bypasses the
standardized module-loading convention for on-device scripts.

Code

general/overlay/etc/wireless/usb[R329-331]

+	insmod /lib/modules/3.10.103+/xiongmai/dwc_common_port_lib.ko 2>/dev/null
+	insmod /lib/modules/3.10.103+/xiongmai/dwc_otg.ko 2>/dev/null
+	insmod /lib/modules/3.10.103+/xiongmai/wifi_pdn.ko value=96 2>/dev/null

Evidence

Rules 10 and 28 require shipped scripts to use modprobe where the tree follows that convention.
Lines 329-331 add three insmod calls, while the same case and surrounding wireless cases use
modprobe for WiFi modules.

Rule 10: Shipped scripts follow tree conventions
general/overlay/etc/wireless/usb[329-332]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new on-device wireless case loads three kernel modules using direct-path `insmod` commands.
## Issue Context
Shipped scripts must use dependency-aware `modprobe` according to the repository's kernel-module loading convention.
## Fix Focus Areas
- general/overlay/etc/wireless/usb[329-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. XM711 WiFi path breaks 🐞 Bug ≡ Correctness

Description

Because xm530_lite now enables ATBM60XX globally, this condition stops replacing the in-tree
cfg80211.ko even though the same image still installs the xm711 driver and a helper that loads
that exact path as xm711's required vendor cfg80211. Any xm711-equipped XM530 using the shared lite
image will therefore load the incompatible in-tree module and lose WiFi after upgrade.

Code

general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk[R27-29]

+	@if [ "$(BR2_PACKAGE_ATBM60XX)" != "y" ]; then \
+		$(INSTALL) -m 755 -d $(TARGET_DIR)/lib/modules/3.10.103+/kernel/net/wireless; \
+		$(INSTALL) -m 644 -t $(TARGET_DIR)/lib/modules/3.10.103+/kernel/net/wireless $(XIONGMAI_OSDRV_XM530_PKGDIR)/files/kmod/rewrite/cfg80211.ko; \

Evidence

The shared defconfig simultaneously selects the XM530 OS-driver package and ATBM60XX. The changed
package rule then withholds the vendor rewrite that its own comment says xm711 needs, while still
installing xm711 modules and the wifi helper; that helper explicitly insmods cfg80211 from the
rewritten path before xm711. The XM530 kernel config provides CONFIG_CFG80211=m, so after the skip
that path contains the in-tree implementation intended for ATBM rather than the vendor
implementation required by xm711.

br-ext-chip-xiongmai/configs/xm530_lite_defconfig[66-72]
general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk[20-30]
general/package/xiongmai-osdrv-xm530/files/script/wifi[5-12]
br-ext-chip-xiongmai/board/xm530/xm530.generic.config[1054-1059]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Enabling ATBM60XX for the shared XM530 image prevents installation of the vendor cfg80211 required by the still-bundled xm711 WiFi stack, breaking that existing device path.
## Issue Context
The kernel already supplies its modular cfg80211 for ATBM, while `/usr/bin/wifi xm711` explicitly expects the vendor replacement at the same path. Keep both boot-time choices viable, or avoid enabling ATBM60XX in the shared defconfig and select it only for the applicable device profile.
## Fix Focus Areas
- general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk[24-30]
- general/package/xiongmai-osdrv-xm530/files/script/wifi[5-12]
- br-ext-chip-xiongmai/configs/xm530_lite_defconfig[69-72]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

8. Driver source tracks HEAD 🐞 Bug ☼ Reliability

Description

The new BR2_PACKAGE_ATBM60XX=y selection makes every xm530_lite build fetch openipc/atbm_60xx at
the package's moving HEAD revision. Identical firmware commits can therefore compile different,
unreviewed kernel-driver sources or stop building when that branch changes, so this addition is not
reproducible.

Code

br-ext-chip-xiongmai/configs/xm530_lite_defconfig[70]

+BR2_PACKAGE_ATBM60XX=y

Evidence

The added defconfig line activates ATBM60XX for xm530_lite, and the package definition constructs
its GitHub source URL using ATBM60XX_VERSION = HEAD; no stable source revision is recorded for the
driver now entering this image.

br-ext-chip-xiongmai/configs/xm530_lite_defconfig[69-72]
general/package/atbm60xx/atbm60xx.mk[7-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly selected ATBM60XX package uses a moving HEAD revision, making XM530 images non-reproducible and allowing later upstream changes to enter builds without a firmware review.
## Issue Context
The SITE is an OpenIPC repository, but `ATBM60XX_VERSION` must be a stable tag or full 40-character commit SHA before another shared board configuration depends on it.
## Fix Focus Areas
- br-ext-chip-xiongmai/configs/xm530_lite_defconfig[69-72]
- general/package/atbm60xx/atbm60xx.mk[7-8]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: ⚖️ Balanced: Downgraded extended -> standard: change is below the extended eligibility bar (hunks 6/18, lines 37/200; both must reach the floor). Router rationale: This behavior-changing PR spans shared configuration, USB initialization, kernel-module packaging/dependency resolution, and two WiFi stacks, with multiple independent high-blast-radius failure modes and an explicitly unverified clean-build path.

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. atbm60xx path remains untested 📘 Rule violation ☼ Reliability

The PR enables the clean-built atbm60xx path globally, but the description explicitly says the
demonstrated camera used a prebuilt blob and local init script and that an image built from this
patch has not yet been flashed. The supplied before/after output therefore does not verify the
behavior-changing path introduced here, contrary to the hardware-evidence requirement.

Agent Prompt

## Issue description
The newly enabled `atbm60xx` clean-build and startup path lacks hardware verification from an image produced by this PR.

## Issue Context
The existing evidence comes from a prebuilt driver blob and local init script, while Compliance ID 1 requires board output proving the behavior-changing implementation under review.

## Fix Focus Areas
- br-ext-chip-xiongmai/configs/xm530_lite_defconfig[70-72]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

2. Pdn module is missing 🐞 Bug ≡ Correctness

The new ATBM6032 path runs modprobe wifi_pdn when wifipdn is configured, but the XM530 package
installs no wifi_pdn.ko, so the required PDN GPIO is never asserted and the USB radio may not
enumerate. The script ignores the failed modprobe and continues, leaving boot to report success from
this case even though wlan0 cannot appear on the tested hardware path.

Agent Prompt

## Issue description
The new ATBM6032 USB initialization invokes `wifi_pdn`, but no `wifi_pdn.ko` is installed into the XM530 image. Supply the required driver from rebuildable source and make initialization fail when the mandatory PDN setup fails.

## Issue Context
The XM530 package currently installs top-level, `usb`, and `xm711` module globs. The `usb` directory contains only `dwc_common_port_lib.ko` and `dwc_otg.ko`; do not solve this by importing an unrebuildable factory binary.

## Fix Focus Areas
- general/overlay/etc/wireless/usb[331-333]
- general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk[19-22]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit e46f92f

[flyrouter]

Good afternoon
Thank you for your interest in our project and the PR you sent.
Unfortunately, we won't be able to accept it because we have a separate repository for board customisation - Builder. Please take a look at it and create your model profile there, that would be the right approach.
Thanks.

[flyrouter]

By the way, I found a few patches in Builder that I haven't sent yet, and I'll try to upload them tomorrow or at the latest in the next few days. And maybe this will help us create a stable solution together. Thanks.

[qodo-free-for-open-source-projects]

1. Camera wifi can miss dependencies 📘 Rule violation ☼ Reliability

The modified wifi helper invokes insmod for cfg80211_xm711.ko instead of the tree's
dependency-aware modprobe convention. When the xm711 branch runs, dependencies are not resolved
from the regenerated module metadata, so an unmet prerequisite prevents that WiFi stack from
loading.

Agent Prompt

## Issue description
The modified shipped WiFi helper loads `cfg80211_xm711.ko` directly with `insmod`, bypassing dependency-aware module loading.

## Issue Context
The package now regenerates module dependency metadata, so the renamed module should be loaded by module name through `modprobe`.

## Fix Focus Areas
- general/package/xiongmai-osdrv-xm530/files/script/wifi[10-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit d8ca418

[qodo-free-for-open-source-projects]

1. Other cameras ship unusable wifi logic 📘 Rule violation ⚙ Maintainability

general/overlay/etc/wireless/usb installs the new atbm603x-xm530-usb branch unconditionally
instead of keying it to BR2_PACKAGE_ATBM60XX through a late overlay or hook. On an image where
that optional package is disabled, selecting this shipped branch still reaches the dwc_otg,
wifi_pdn, and atbm603x_wifi_usb loads even though the driver is not part of that build.

Agent Prompt

## Issue description
The ATBM6032-specific branch is shipped through the unconditional shared overlay, including in images that do not enable the ATBM60XX package.

## Issue Context
Relocate or generate this branch through a configuration-keyed late overlay or post-build hook so it is present only in applicable XM530 builds with ATBM60XX enabled.

## Fix Focus Areas
- general/overlay/etc/wireless/usb[327-335]
- general/scripts/late-post-build-hooks.list[1-4]
- general/package/atbm60xx/atbm60xx.mk[10-13]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 406f923