On 1/24/23 18:08, Koen Vandeputte wrote:
Hi,
I think our previous mails overlapped a bit as I didn't notice your
previous response :)
I'll send the data tomorrow.
I'm also wondering if adding a sleep before ubiformat in the old way
would influence/break it's behaviour?
possibly yes
Piotr,
Would you have any idea here?
Thanks again for your efforts,
Koen
if your active watchdog device is /dev/MyWatchdog, then...
just before the line:
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
-m "$mtdnum"
you could add this to try disable the watchdog:
echo -n V >/dev/MyWatchdog
or else you could tickle the watchdog while flashing like this:
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - 2>&1 | tee
/dev/MyWatchdog && ubiattach -m "$mtdnum"
BUT... this is a hack, cause shell option pipefail would be needed to
detect a failure of ubiformat then, as normally only the exit code of
the last piped process gets returned from the pipe expression.
so these are just tests, not fixes.
another dirty thing you could do is doubling the watchdog timeout period
for your platform. this at least could maybe be accepted as a stopgap
band aid in the openwrt tree. but the race condition remains, and it
will bite back sometime. a real fix for the race should be implemented.
BTW your watchdog seems to be:
https://www.kernelconfig.io/config_imx2_wdt
thanks!
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
