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.cpp#L501
It looks like the upstream version will default to 4096 if the block-size is
not provided
https://github.com/NXPmicro/mfgtools/blob/5397913ad97db422c1d70f314dedff4cb7d976b9/libuuu/fastboot.cpp#L642
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
