[PATCH v2 1/1] fastboot: fb_getvar: Add getvar_logical_blocksize for NXP mfgtool

[Sean Anderson]

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.

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.

--Sean