[GIT] Pull request: u-boot-dfu (26.01.2020)

[Marek Vasut]

On 1/27/20 2:35 PM, Guillermo Rodriguez wrote:
> El lunes, 27 de enero de 2020, Marek Vasut <marex at denx.de> escribió:
> 
>> On 1/27/20 2:26 PM, Guillermo Rodriguez wrote:
>>> Hi,
>>
>> Hi,
>>
>>> El lunes, 27 de enero de 2020, Marek Vasut <marex at denx.de> escribió:
>>>
>>>> On 1/27/20 9:14 AM, Guillermo Rodriguez Garcia wrote:
>>>>> Hi Marek,
>>>>
>>>> Hi,
>>>>
>>>>> El lun., 27 ene. 2020 a las 8:52, Lukasz Majewski (<lukma at denx.de>)
>>>> escribió:
>>>>>>
>>>>>> Hi Marek,
>>>>>>
>>>>>>> On 1/26/20 9:26 PM, Lukasz Majewski wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> Guillermo Rodríguez (1):
>>>>>>>>       dfu: Add option to skip empty pages when flashing UBI images
>>>>>>>> to
>>>>>>>
>>>>>>> Can that option be enabled/disabled at runtime instead of being
>>>>>>> hardcoded?
>>>>>>
>>>>>> It has been designed in a similar way to Android's existing
>>>>>> FASTBOOT_FLASH_NAND_TRIMFFS option.
>>>>>
>>>>> Without this option, UBI images need to be built with --space-fixup
>>>>> [1] so that the kernel can "fix" the NAND on first mount.
>>>>> When this option is used, --space-fixup is no longer necessary because
>>>>> dfu knows how to correctly flash UBI images. However, UBI images built
>>>>> with --space-fixup will still work fine.
>>>>
>>>> Does NAND.TRIMFFS preserve UBI erase counters in the NAND ? I don't
>>>> think so, so I don't think "correctly flash UBI images" is the correct
>>>> formulation here.
>>>>
>>>> Yes, you are right.
>>>
>>>
>>>>> In other words, enabling this option at buildtime has no
>> countereffects.
>>>>> So there is no point in making it configurable at runtime, if support
>>>>> has been built into U-boot.
>>>>>
>>>>>  [1]: http://www.linux-mtd.infradead.org/faq/ubifs.html#
>>>> L_free_space_fixup
>>>>
>>>> So what if I want to write raw NAND image without "trimffs" on such a
>>>> system via DFU, e.g. a bootloader ? How can I do that ?
>>>>
>>>
>>> You mean on a non-ubi partition? Then you don't need to do anything
>>> special. This code is only triggered for ubi partitions.
>>
>> And what about partitions which were already built with the --space-fixup ?
>>
> 
> What do you mean with "partitions built with --space-fixup"? If you mean
> ubi *images* built with --space-fixup, these will still work fine.
> Otherwise, could you please clarify?

I'm just curious whether we're changing behavior here, which might pose
a problem. I am also not super fond of hard-coding things this way, but
maybe this is fine in this case ?