Snagflash fastboot uboot fix bmap range reading#91
Conversation
|
|
||
| for start, end, _ in bmap._get_block_ranges(): | ||
| range_offset = bmap.block_size * start | ||
| range_offset = bmap.block_size * (end - start) |
There was a problem hiding this comment.
There is indeed an issue with this error condition, but I don't think that this analysis of the problem is correct.
When flashing bmap range (a,b), the start offset should be a blocks, and the size flashed should be at most b - a + 1 blocks. In the general case, flashing b - a + 1 blocks isn't an issue.
My suspicion is that the issue arises when the end of the file isn't aligned with a bmap block. In this situation, the last bmap range would be aligned to the next block boundary, even if the file itself didn't fully fill up the last block. So snagflash would correctly flash the end of the file, but the "truncated flash" check would fail since it would expect the full last bmap block to be flashed.
One relevant solution would be to remove the "truncated flash" check entirely. It's more bothersome than useful, since the cases where it would rightfully trigger would most often also cause other exceptions to be raised, such as a failed USB transaction.
Could you please modify this commit and commit log to remove the check instead, after verifying that it indeed solves the problem on your end?
There was a problem hiding this comment.
Indeed, removing the check works.
I suspected a more serious problem than a wrong check.
It was surprising that flash_range() reached the end of the file prematurely.
Thanks for the review.
The sys.maxint constant was removed in Python 3 [1]. Replace sys.maxint by sys.maxsize (already used in fastboot_uboot.py). [1] https://docs.python.org/3/whatsnew/3.0.html#integers Signed-off-by: Romain Naour <romain.naour@smile.fr>
As reported by bootlin#85, flashing a wic image generated by Yocto using fastboot-uboot mode trigger an error when sending the last image chunk to the target: ValueError: Truncated flash, only 82944 bytes were flashed instead of 86016 bytes The same issue is reproduced on another platform (SK-TDA4VM). [INFO] Flashing to MMC device... [DEBUG] setting MMC device to 1 [DEBUG] fastboot OKAY [DEBUG] range start 0x88100000 read size 0x2000 [DEBUG] send size 0x2000 dst offset 0x88100000 [DEBUG] fastboot DATA length: 8192 [INFO] fastboot OKAY [DEBUG] fastboot OKAY [INFO] flashed 8192/8192 bytes [INFO] Flashing sparse range 12/13 [INFO] Flashing to MMC device... [DEBUG] setting MMC device to 1 [DEBUG] fastboot OKAY [DEBUG] range start 0x936e0000 read size 0x1c000 [DEBUG] send size 0x1b800 dst offset 0x936e0000 <<< here we have "send size" < "read size" [DEBUG] fastboot DATA length: 112640 [INFO] fastboot OKAY [DEBUG] fastboot OKAY [INFO] flashed 112640/114688 bytes [DEBUG] range start 0x936fb800 read size 0x800 ValueError: Truncated flash, only 112640 bytes were flashed instead of 114688 bytes 0x936fb800 is actually the size of the wic file (2473572352). This value is verified by the ImageSize value in .bmap file. <!-- Image size in bytes: 2.3 GiB --> <ImageSize> 2473572352 </ImageSize> So it means that flash_range() reached the end of the file: blob = file.read(read_size) bytes_read = len(blob) if bytes_read == 0: break That's why "read size" != "send size" in the Snagflash debug log, file.read() returned less than requested data. Removing the bmap file allows to workaround this issue. This bug was introduced in Snagboot 2.6 when the "flashing with unspecified file sizes" feature was added. Indeed, a new "truncated flash" check was added but it expect that the image file is aligned with a bmap block. This not alway the case. Remove this "truncated flash" check since Snagflash correctly flash the end of the file. Fixes: d499ae2 ("snagflash: fb-uboot: Allow flashing with unspecified file sizes") Fixes bootlin#85 Signed-off-by: Romain Naour <romain.naour@smile.fr>
RomainNaour
force-pushed
the
snagflash-fastboot-uboot-fix-bmap-range-reading
branch
from
f806c47 to
b712670
Compare
|
Thanks a lot! |
2 participants
Hello,
I'm still experimenting Snagboot features on SK-TDA4VM board.
After successfully tested the DFU and UMS mode, the fasboot mode was more difficult.
Here is my findings.
Best regards,
Romain