On platforms that don't have a 2nd stage (in my case i.MX6 without
imx6_barebox_start_usb), it usually happens that the transfer limit for
the first (and only) upload is bigger than the actual file length.
Then the right thing to do is processing the complete image (minus its
header), but not more. This was broken by recent refactoring and fixed
for the transfer case with commit 3cf4bcd86419 ("imx-usb-loader: Don't
try to transfer more data than contained in the image").
The same bug persisted in the verification code though, breaking
imx-usb-loader -c:
verifying file...
mismatch at offset 0x000999c0. expected:
[ hexdump of last bytes of barebox binary ]
A jump to the binary will then be skipped and subsequent imx-usb-loader
invocations will have their DCD writes unanswered leading to the
dreaded:
main dcd length 328
DCD write: sub dcd length: 0x0324, flags: 0x04w3 in err=-7, last_trans=0 00 00 00 00
addr=0x021b001c, val=0x04088032 w4 in err=-7, last_trans=0 00 00 00 00
!!perform_dcd returned -7
4 in err=-7, last_trans=0 00 00 00 00
Applying the same fix as in 3cf4bcd86419 fixes this issue as well.
Fixes: 3367ebc55ebe ("scripts: imx-usb-loader: simplify code flow for file size calculations")
Cc: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
Reported-by: Roland Hieber <r.hieber@xxxxxxxxxxxxxx>
Signed-off-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
---
scripts/imx/imx-usb-loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/imx/imx-usb-loader.c b/scripts/imx/imx-usb-loader.c
index 5f9c7ff3a458..676f077c2557 100644
--- a/scripts/imx/imx-usb-loader.c
+++ b/scripts/imx/imx-usb-loader.c
@@ -1415,7 +1415,7 @@ static int do_irom_download(struct usb_work *curr, int verify)
if (verify) {
printf("verifying file...\n");
- ret = verify_memory(image, firststage_len, header_addr);
+ ret = verify_memory(image, min(fsize, firststage_len), header_addr);
if (ret < 0) {
printf("verifying failed\n");
goto cleanup;
--
2.30.2
