[PATCH RFC 2/2] ubi: add support for UBI_EC_FLAG_ERASE_FROM_HERE

[Rafał Miłecki]

On 30 December 2016 at 21:47, Richard Weinberger <richard at nod.at> wrote:
> On 30.12.2016 18:11, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal at milecki.pl>
>>
>> This flag can be used to mark block that should start erasing process
>> (including that block itself).
>> This can be useful for devices that don't support UBI natively (in a
>> bootloader or original firmware). In such cases we need to flash
>> ubinized image which is usually created with autoresize flag. In such
>> cases only few blocks of the whole ubi partition are programmed and the
>> rest of them should be formatted when attaching.
>>
>> Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
>> ---
>> Hi,
>>
>> This patch is my attempt of getting upstream solution of problem we were
>> solving locally in OpenWrt/LEDE projects.
>>
>> There are a lot of home routers with original firmware and bootloaders
>> not supporting UBI in any way. This is where we use ubinize tool to
>> prepare images with UBI. Unfortunately flashing such an image to the
>> firmware partition writes only few blocks (as many as were created by
>> ubinize). We need some way of formatting remainig blocks of the firmware
>> (ubi) partition.
>>
>> This is RFC and I'd really like to hear your comments.
>>
>> First of all using a global erase_all_next_pebs is a pretty bad idea. I
>> mean to store this information in struct ubi_attach_info but there goes
>> my question:
>> 1) Should I pass "struct ubi_attach_info" to the ubi_io_read_ec_hdr to
>>    let this function set some interfnal flah that all next blocks should
>>    be erased?
>> OR
>> 2) Should I introduce UBI_IO_ERASE (or similar) and add support for this
>>    new "error" in the scan_peb?
>>
>> Second question: I wasn't sure what's the better solution:
>> 1) Create empty block with UBI_EC_FLAG_ERASE_FROM_HERE
>> OR
>> 2) Set UBI_EC_FLAG_ERASE_BEYOND in the last block
>>
>> Third question: what impact this change can have? I'm pretty sure I'll
>> need to adjust ubiformat tool. We don't want to format ubi with writing
>> image at the same time, just to trigger erasing blocks on the next
>> attach attempt. I guess ubiformat shouldn't copy/write this flag when
>> writing an image (--flash-image=<file> option). What else should I
>> consider?
>
> As discussed on IRC, I'm not fond of this patches.

Thanks for the IRC discussion, it's sometimes hard to describe all
details of such problems. Glad you managed to get all extra needed
info from me ;)


> To summarize, your target devices have "bad" bootloaders pre-installed.
> You cannot change nor fix them. If you ask such a bootloader to flash
> the UBI image to the MTD partition it will erase and program only as
> much blocks as the image allokates and the remaining blocks on the MTD
> partition stay untouched.
> Later an ubiattach will fail since UBI wants to see either valid headers
> or all 0xff bytes but it finds old data since the bootloader did not erase
> all blocks.
> This patches implement an "EOF marker" to teach UBI about the last valid
> block and let UBI do the erase.

A very nice summary, thanks!


> Do these bootloaders really don't offer a command to erase the whole MTD
> partition? If they offer a flash command I'd expect an erase command too.

Some of them do, but that requires serial access to the device. Most
users use button-triggered tftp server/client or just minimal
bootloader web interface for flashing an image. In these cases you
don't have any control over what bootloader does.


> I recommend using an initramfs. In the initramfs you can do all the clean-up
> your bootloader misses. Using flash_erase you can do the erase yourself,
> load the ubi module, run ubiattach, mount ubifs and hand-over to the regular
> userspace.

I'll see if I can do that, thanks for this alternative solution idea.


> Brian, Boris, Artem, what do you think?
> I'd like to keep UBI free from such workarounds if it can be addressed
> in another way.

-- 
Rafał