[PATCH] distroboot: Fix ubifs

[Frieder Schrempf]

Am 23.06.22 um 18:09 schrieb Pali Rohár:
> On Tuesday 31 May 2022 10:32:36 Pali Rohár wrote:
>> Fix multiple issues in ubifs distroboot code:
>>
>> U-Boot supports attaching only one MTD device as UBI at the time. So
>> always call 'ubifsmount ubi0:${bootubivol}' for mounting UBI volume
>> ${bootubivol}. Usage of 'ubi${devnum}' is incorrect as 'ubi part'
>> command attach MTD device always as UBI device ubi0.
>>
>> Set distroboot ${bootfstype} variable to ubifs in ubifs_boot command.
>> Distroboot scripts require ${bootfstype} variable to be properly set and it
>> is already set for all other boot types.
>>
>> Set distroboot ${distro_bootpart} variable to ${bootubivol} value. UBI
>> device does not have partitions, but has volumes. Distroboot scripts
>> require something to be set in ${distro_bootpart} variable, so set it to
>> the UBI volume which is currently mounted by ubifs.
>>
>> Set distroboot ${devnum} variable to fixed string "ubi0". ubifs code
>> differs from the other partition code that it requires "ubi" prefix before
>> number.
>>
>> Explicitly unmount ubifs volume after loading all data from it. This allows
>> to detach UBI device from MTD device.
>>
>> Move definition of MTD device with UBI and UBI volume with ubifs filesystem
>> from global env variables ${bootubipart} and ${bootubivol} into the
>> distroboot "func" macro, defined in board include config files. UBIFS
>> distroboot macros then set ${bootubipart} and ${bootubivol} local variables
>> for compatibility with existing distroboot scripts.
>>
>> This last change allows to define more UBIFS target devices and make it
>> clear what is boot MTD/UBI device.
>>
>> All board include config files are adjusted to use this new scheme of
>> specifying boot MTD/UBI device.
>>
>> Signed-off-by: Pali Rohár <pali at kernel.org>
> 
> PING?
> 

Sorry, I currently don't have the time to properly review and/or test
this. Though, in general the changes look good and I can at least provide:

Acked-by: Frieder Schrempf <frieder.schrempf at kontron.de>

I think it would help to split this up in smaller chunks, so people can
review it more easily...