[widgetii]

Problem

#2611. On XM510 and XM530/XM550 the only watchdog driver was the vendor xm_wdt.ko:

• Non-standard interface: /dev/wdt with private ioctls (_IO('W', 2) to feed), no write() and no magic close. busybox watchdog and sysupgrade's RAM-phase keeper couldn't drive it. sysupgrade looked for /dev/watchdog, found nothing, and reported Watchdog: none.
• Counted from load: it started counting at insmod, not at open (XM530 reboots after ~ 1 minute  #743).
• Not loaded on XM510: load_xiongmai has it commented out, so XM510 cameras ran with no watchdog at all.

Change

The watchdog is an ARM SP805 at 0x20060000 (ID 0x00141805, read on both lab boards). OpenIPC/linux now registers it on both kernels (OpenIPC/linux#128 for xm530, #129 for xm510).

• Kernel configs: br-ext-chip-xiongmai/board/xm530/xm530.generic.config and xm510/xm510.generic.config enable CONFIG_WATCHDOG and CONFIG_ARM_SP805_WATCHDOG (plus CONFIG_WATCHDOG_CORE on 3.10). The block is copied from the kernel's resolved .config. The stock sp805_wdt then gives /dev/watchdog with write() feeding, WDIOC_* and magic close, idle until opened.
• xm_wdt.ko: removed from both osdrv packages, along with its insmod/rmmod in load_xiongmai (xm530, xm510) and loadxm510_64M. It registers the same misc minor (130), so it can't load beside sp805_wdt anyway.
• sysupgrade: unchanged. Its WDOG=/dev/watchdog default now exists on XM, so the pre-flash report and the keeper work there.

Order with majestic. majestic reaches an image as the majestic.<family>.<variant>.master tarball current at build time, so the two changes must land in this order, both before the same nightly:

1. This PR first.
2. majestic's XM watchdog moving to /dev/watchdog (the follow-up PR) right after it.

The reverse order would be unsafe: that majestic in an image that still loads xm_wdt.ko (counting from insmod, 60 s) would leave it unfed, and XM530 would reboot in a loop.

Between the two: current majestic opens /dev/wdt on XM. On an image with this change it logs Watchdog device (/dev/wdt) not found and runs with no watchdog until majestic's XM watchdog code switches to /dev/watchdog (follow-up PR in majestic). The SP805 stays idle until opened, so nothing resets the camera in between. Mixed updates are safe too:

• new kernel, old rootfs: xm_wdt.ko fails to load (minor taken), and the SP805 stays idle;
• new rootfs, old kernel: there is no watchdog driver at all.

Hardware tested on

• XM550 (XM530 die) + IMX335. This branch's xm530_lite image (the camera runs an xm530 build), installed with sysupgrade -z --kernel=... --rootfs=..., overlay kept. The pre-upgrade kernel and rootfs partitions are backed up.
• XM510 + JX-H62. Kernel from this branch's xm510_lite build (uImage.xm510, from the merged OpenIPC/linux tarball), TFTP-booted into RAM from U-Boot with the board's flashed rootfs. Nothing was written to flash.

Evidence

XM550, before (its previous xm530 build):

crw-rw----  1 root root 10, 130  /dev/wdt
xm_wdt                  1536  1
ls: /dev/watchdog: No such file or directory
majestic: Watchdog armed: asked 300 s, assuming 300 s, fed every 10.000s, magic close NOT supported by this driver

XM550, after (this branch's image):

sp805-wdt sp805-wdt: registration successful
crw-rw----  1 root root 10, 130  /dev/watchdog
ls: /dev/wdt: No such file or directory          (xm_wdt not loaded)
majestic: Watchdog device (/dev/wdt) not found   (current majestic; see "Order with majestic")
idle: LOAD=0xFFFFFFFF CONTROL=0x00000000

fed, watchdog -T 10 -t 1:       LOAD=0x00039381 (46875/2*10-1) CONTROL=0x3, uptime 39.27 -> 69.52 over 30 s, no reset
magic close, killall watchdog:  CONTROL=0x0, uptime 71.07 -> 101.33 over 30 s, no reset
unfed, watchdog -T 10 -t 1000:  CONTROL=0x3, stopped answering ping 11.3 s after arming, rebooted into the same image

XM510, before (stock kernel):

ls: /dev/watchdog: No such file or directory
LOAD=0xFFFFFFFF CONTROL=0x00000000   (no driver, nothing running)

XM510, after (this build's kernel):

sp805-wdt sp805-wdt: registration successful
crw-rw----  1 root root 10, 130  /dev/watchdog

watchdog -T 10 -t 1000 /dev/watchdog   (armed, never fed again)
  LOAD=0x0007270D CONTROL=0x00000003
  U-Boot banner on the UART 10.6 s after arming; the camera came back on its flash kernel

Earlier, on the same kernel change (OpenIPC/linux#129), on the same board:

fed, watchdog -T 10 -t 1:          uptime 35.29 -> 65.82 over 30 s, no reset
magic close, killall watchdog:     LOAD=0 CONTROL=0, uptime 68.61 -> 99.13 over 30 s, no reset

Images:

xm530_lite: uImage 1175KB/2048KB, rootfs.squashfs 3832KB/5120KB
xm510_lite: uImage 1304KB/2048KB, rootfs.squashfs 2876KB/5120KB
xm_wdt.ko in either target: none

Checks:

• STRICT=1 test_shell_parse.sh: clean.
• STRICT=1 test_strip_shell_comments.sh: clean.
• ci-matrix.py --self-test: ok.
• ci-matrix.py --stdin selects xm510_lite and xm530_lite.

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

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

PR Summary by Qodo

Use the kernel SP805 watchdog on XM510 and XM530

🐞 Bug fix ✨ Enhancement 🕐 10-20 Minutes

AI Description

• Enable the kernel SP805 driver on XM510 and XM530 to provide a standard /dev/watchdog.
• Remove the conflicting vendor module and its loader commands from both platforms.
• Let sysupgrade use its existing watchdog keeper without changes.

Diagram

graph TD
  CFG["XM kernel configs"] --> SP(["SP805 driver"]) --> DEV["/dev/watchdog"] --> SYS["sysupgrade keeper"]
  DEV --> BUSY["BusyBox watchdog"]
  PKG["OSDRV packages"] -. "omit xm_wdt" .-> SP

Loading

High-Level Assessment

Use the existing kernel SP805 driver rather than adapting the vendor module: it provides the standard interface without maintaining a second driver for the same hardware. Coordinate the separate majestic change to /dev/watchdog; this PR does not make majestic use the new device.

Files changed (6) +33 / -10

Bug fix (3) +6 / -6

load_xiongmaiStop unloading the XM510 vendor watchdog +2/-2

Stop unloading the XM510 vendor watchdog

• Removes the xm_wdt unload command and replaces the already-commented load command with a note identifying the kernel driver.

general/package/xiongmai-osdrv-xm510/files/script/load_xiongmai

loadxm510_64MRemove vendor watchdog handling from the XM510 64M loader +2/-2

Remove vendor watchdog handling from the XM510 64M loader

• Stops loading and unloading xm_wdt in the 64M variant, leaving watchdog ownership with the kernel.

general/package/xiongmai-osdrv-xm510/files/script/loadxm510_64M

load_xiongmaiStop loading the XM530 vendor watchdog +2/-2

Stop loading the XM530 vendor watchdog

• Removes xm_wdt load and unload commands and documents that the kernel SP805 driver provides /dev/watchdog.

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

Documentation (1) +1 / -2

Readme.txtRemove xm_wdt from the XM530 module inventory +1/-2

Remove xm_wdt from the XM530 module inventory

• Updates the documented module tree to reflect removal of the vendor watchdog binary.

general/package/xiongmai-osdrv-xm530/files/kmod/Readme.txt

Other (2) +26 / -2

xm510.generic.configEnable SP805 watchdog support for XM510 +9/-1

Enable SP805 watchdog support for XM510

• Enables kernel watchdog support and the ARM SP805 driver, replacing the disabled watchdog configuration.

br-ext-chip-xiongmai/board/xm510/xm510.generic.config

xm530.generic.configEnable SP805 watchdog support for XM530 +17/-1

Enable SP805 watchdog support for XM530

• Enables the watchdog subsystem, watchdog core, and ARM SP805 driver for the XM530 kernel.

br-ext-chip-xiongmai/board/xm530/xm530.generic.config

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

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. XM530 watchdog lacks hardware proof 📘 Rule violation ☼ Reliability

Description

The XM530 defconfig enables the SP805 watchdog, but the PR provides no real-camera validation for
that image. The description says XM530/XM550 hardware was not tested and substitutes QEMU evidence,
so the changed XM530 firmware behavior remains unverified on the affected hardware.

Code

br-ext-chip-xiongmai/board/xm530/xm530.generic.config[R982-990]

+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+# CONFIG_WATCHDOG_NOWAYOUT is not set
+
+#
+# Watchdog Device Drivers
+#
+# CONFIG_SOFT_WATCHDOG is not set
+CONFIG_ARM_SP805_WATCHDOG=y

Evidence

The changed XM530 defconfig alters firmware behavior by enabling the watchdog driver. PR Compliance
ID 3 requires real-camera evidence for image-changing changes, while the PR description states that
XM530/XM550 hardware was not tested and presents QEMU evidence instead.

Rule 3: Hardware evidence is present and honest
br-ext-chip-xiongmai/board/xm530/xm530.generic.config[982-990]

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 PR enables the watchdog in the XM530 image but explicitly reports that XM530/XM550 hardware was not tested, while the compliance gate requires before-and-after evidence from a real affected camera.
## Fix Focus Areas
- br-ext-chip-xiongmai/board/xm530/xm530.generic.config[982-990]
## Recommended Fix
Provide before-and-after watchdog output from a real XM530 or XM550 camera, including the affected board, device node, arming, feeding, and reset or magic-close behavior. If hardware testing is unavailable, remove or defer the unvalidated XM530/XM550 configuration change rather than claiming the QEMU result is hardware evidence.

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

---

2. XM530 cameras lose watchdog recovery 🐞 Bug ☼ Reliability

Description

Removing insmod xm_wdt.ko takes away /dev/wdt, which the currently packaged majestic opens,
while the new SP805 driver exposes /dev/watchdog and remains idle until opened. On XM530/XM550
images built before the planned majestic follow-up, majestic cannot arm the replacement, and
sysupgrade sees no owner and therefore skips its flash-phase keeper.

Code

general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[75]

-	insmod xm_wdt.ko
+	# The watchdog is the kernel's sp805_wdt (/dev/watchdog), not xm_wdt.ko: see
+	# OpenIPC/firmware#2611.

Evidence

The PR states that current majestic opens /dev/wdt and its /dev/watchdog change is a follow-up.
The XM530 image selects majestic and the XM530 driver package, while the changed script no longer
loads the vendor watchdog. Sysupgrade starts its keeper only when its scan finds an existing
/dev/watchdog owner, so the newly present but unopened node does not activate that protection.

br-ext-chip-xiongmai/configs/xm530_lite_defconfig[59-66]
general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[72-78]
br-ext-chip-xiongmai/board/xm530/xm530.generic.config[982-990]
general/overlay/usr/sbin/sysupgrade[1732-1742]
general/overlay/usr/sbin/sysupgrade[1895-1901]
general/overlay/usr/sbin/sysupgrade[3160-3168]

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 XM530/XM550 image removes the watchdog device used by its packaged majestic before majestic can open the replacement. This leaves the new watchdog idle and prevents sysupgrade from starting its keeper.
## Fix Focus Areas
- general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[72-78]
- br-ext-chip-xiongmai/board/xm530/xm530.generic.config[982-990]
## Recommended Fix
Coordinate the image change with a majestic release that opens and feeds `/dev/watchdog` on XM, and verify the selected XM530/XM550 images include that release before removing `xm_wdt.ko`.

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

---

Tip of the day

💡 Did you know, you can open the rule or relationship behind a finding in one click

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗