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

[Sean Anderson]

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