[Firmware] Enable the watchdog kernel module on hi3516cv200/hi3518ev200 devices

[ZigFisher]

Enable the watchdog kernel module on hi3516cv200/hi3518ev200 devices

[widgetii]

Fixed in #2517, which pins openhisilicon at ecbc855 (OpenIPC/openhisilicon#235). Verified on a lab hi3518ev200 with the kernel console on UART.

The module was never the missing piece. It has been insmoded on these parts all along, and hisilicon-opensdk installs open_wdt.ko over the vendor blob as wdt.ko, so openhisilicon's build is what has been running. What was broken is the driver: hidog_release() handed the device to the driver's own kernel feeder thread the moment userspace let go. So the one event a watchdog exists for — the guarded process dying, and the kernel closing its descriptor — ended with the driver feeding the dog forever.

Here is the stock driver caught in the act. A 30 s margin was armed, the owner was killed without writing "V", and the board ran on for 106 s:

CTRL  = 0x00000003   enabled, RESEN set
LOAD  = 0x055D4A80   90,000,000 = 30 x 3MHz  <- twice the margin, a second bug
VALUE = 0x0033F866   counting down

Armed, enabled, counting — and never firing. That is why nodeamon=1 appeared to help: it removes the feeder thread entirely, so nothing is left to keep the dog quiet. You should no longer need it. It also had a cost, which is worth saying plainly: with no feeder, nothing covers the window between the module loading and majestic opening the device, so a slow boot could reset the board. The fixed driver keeps the feeder for exactly that window and stops it for good once userspace takes over.

After, on the same board:

crash and recover	18 of 18 cycles, unattended, board back in 17–28 s
bite time	30 s for a 30 s margin, on the UART clock — the stock driver gave 60
majestic soak	521 s against its 300 s margin, no spurious reboot

On the concern raised in #1803 about losing a camera to a reset loop — that was worth taking seriously, and it is the thing I spent the most hardware time on. Recovery was clean 18 times out of 18 on this board, and the SP805 turns out to be fully reset by its own bite (CTRL back to 0, LOAD back to 0xFFFFFFFF), so nothing is left armed for the bootloader to trip over. One other unit in the lab did fail to come back twice, but it also failed a plain reboot with no watchdog involved, so that is a sick board rather than a property of this change.

Two more bugs specific to this generation, found on the way:

• The magic close was inverted. hidog_write() assigned the nowayout module parameter, so writing "V" — the documented way to say "I am stopping it deliberately" — took the branch that left the dog running, and not writing it took the branch that stopped it. Worse, one "V" flipped nowayout for the rest of the boot, after which every WDIOC_SETOPTIONS was refused with -WDIOS_UNKNOWN = -(-1) = +1, a positive ioctl return that userspace reads as success. Current majestic writes "V", so a single clean S95majestic stop silently disabled that ioctl.
• hi3520dv200 had if (IS_ERR(p_dog) < 0), which is never true, so its feeder-creation failure was never detected.

What to expect when you take the next build. These cameras go from a watchdog that never fired to one that does, so a camera whose majestic wedges will now reboot where it previously sat there unguarded. That is the fix, and it is the first thing you will notice.

Scope. Measured on hi3516cv200/hi3518ev200. hi3520dv200 is build-verified and hi3516av100 syntax-checked only — same driver, same patch, but no hardware here for either. If anyone has one of those on a bench, a crash-and-recover drill on it would be welcome.

Thanks for the report, and for pinning down nodeamon=1 as the workaround — that detail is what pointed straight at the feeder thread.