On 1/3/22 8:27 AM, Angus Ainslie wrote:
Hi Sean,
On 2021-12-30 08:21, Sean Anderson wrote:
On 12/29/21 8:35 AM, Angus Ainslie wrote:
Hi Sean,
On 2021-12-28 08:59, Sean Anderson wrote:
Hi Angus,
NXP's mfgtool queies the mmc blocksize and splits a sparse image into blocksize size pieces for the upload.
It's still not clear to me why this is necessary. fastboot (for example) transfers in blocks of max-download-size. Using the actual block size seems like it would result in unnecessary overhead.
The version of uuu that we are using requires the block-size for the sparse upload
https://source.puri.sm/Librem5/mfgtools/-/blob/pureos/amber/libuuu/fastboot....
It looks like the upstream version will default to 4096 if the block-size is not provided
https://github.com/NXPmicro/mfgtools/blob/5397913ad97db422c1d70f314dedff4cb7...
Instead of making assumptions about the block size wouldn't it be better to provide one if requested ?
The block size is for the sparse image. This determines the granularity of the sections of the image. For example, if the block size is 1K, then all sizes will be multiples of 1K. So if you have a block with 1 byte of data and 1023 bytes of 0 then the whole block will be transferred instead of being replaced with a fill block.
Thanks for the explanation on how it works.
However, the sparse file block size size completely orthogonal to the block size of the device being written to. The only thing it affects is the efficiency of the sparse image. For example, I generate my sparse files with a block size of 1M, because it is a nice convenient number.
Ok so the way the NXP's uuu uses the blocksize is not correct. However the tool is already out there in the wild.
Can we add the block-size response to support that tool or will it be required that uuu needs to be upgraded to work with mainline u-boot ?
IMO this should be fixed in uuu. And as I understand it, this is only an issue when you transfer a raw image with uuu. Perhaps you can generate a fastboot sparse image (with img2simg) and transfer that instead.
--Sean