tools: kwboot: Force BootROM to flush input queue after boot pattern
authorPali Rohár <pali@kernel.org>
Tue, 25 Jan 2022 17:13:08 +0000 (18:13 +0100)
committerStefan Roese <sr@denx.de>
Mon, 31 Jan 2022 09:23:38 +0000 (10:23 +0100)
Force the BootROM to flush its input queue after sending boot pattern.

This ensures that after function kwboot_bootmsg() finishes, BootROM is
able to start receiving xmodem packets without any specific delay or
setup.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
tools/kwboot.c

index c413a8b..824ae00 100644 (file)
@@ -717,6 +717,7 @@ out:
 static int
 kwboot_bootmsg(int tty, void *msg)
 {
+       struct kwboot_block block;
        int rc;
        char c;
        int count;
@@ -747,7 +748,40 @@ kwboot_bootmsg(int tty, void *msg)
 
        kwboot_printv("\n");
 
-       return rc;
+       if (rc)
+               return rc;
+
+       /*
+        * At this stage we have sent more boot message patterns and BootROM
+        * (at least on Armada XP and 385) started interpreting sent bytes as
+        * part of xmodem packets. If BootROM is expecting SOH byte as start of
+        * a xmodem packet and it receives byte 0xff, then it throws it away and
+        * sends a NAK reply to host. If BootROM does not receive any byte for
+        * 2s when expecting some continuation of the xmodem packet, it throws
+        * away the partially received xmodem data and sends NAK reply to host.
+        *
+        * Therefore for starting xmodem transfer we have two options: Either
+        * wait 2s or send 132 0xff bytes (which is the size of xmodem packet)
+        * to ensure that BootROM throws away any partially received data.
+        */
+
+       /* flush output queue with remaining boot message patterns */
+       tcflush(tty, TCOFLUSH);
+
+       /* send one xmodem packet with 0xff bytes to force BootROM to re-sync */
+       memset(&block, 0xff, sizeof(block));
+       kwboot_tty_send(tty, &block, sizeof(block), 0);
+
+       /*
+        * Sending 132 bytes via 115200B/8-N-1 takes 11.45 ms, reading 132 bytes
+        * takes 11.45 ms, so waiting for 30 ms should be enough.
+        */
+       usleep(30 * 1000);
+
+       /* flush remaining NAK replies from input queue */
+       tcflush(tty, TCIFLUSH);
+
+       return 0;
 }
 
 static int