UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

On 16 October 2014 13:54, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> On Thu, 2014-10-16 at 13:38 +0200, Rafał Miłecki wrote:
>> On 16 October 2014 13:27, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
>> > On Thu, 2014-10-16 at 13:17 +0200, Rafał Miłecki wrote:
>> >> On 16 October 2014 12:40, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
>> >> > On Thu, 2014-10-16 at 12:29 +0200, Rafał Miłecki wrote:
>> >> >> On 16 October 2014 12:09, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
>> >> >> > Then the solution would be to pad your image with 0xFFs and write it.
>> >> >> > UBI will notice PEBs which do not contain UBI headers and will erase
>> >> >> > them in background.
>> >> >>
>> >> >> That would be trivial trick to implement, however it's far from being
>> >> >> user friendly. Most devices have 128 MiB flash and our firmware
>> >> >> (OpenWrt) is only ~4 MiB big. It would be a waste of
>> >> >> space/bandwidth/time to provide firmware images padded with over 120
>> >> >> MiB of 0xFF.
>> >> >
>> >> > Right, this is a work-around, and it is OK for a work-around to be
>> >> > suboptimal, generally speaking.
>> >> >
>> >> > If you want a more optimal work-around, it will be more intrusive. One
>> >> > idea would be to can create a small specialized kernel driver which will
>> >> > start before UBI and clean-up your flash: erase PEBs you specify it.
>> >> > Something like 'mtd/flashcleaner.ko'.
>> >>
>> >> I'm not sure if something like this is possible. My driver would need
>> >> to have a very good understanding of UBI to know which PEBs to leave
>> >> and which to clean. I would need to find out which PEBs were recently
>> >> flashed (are part of the just-installed firmware) and which are left
>> >> from the previous installation.
>> >
>> > Why? All you need is to erase all PEBs which contain those "100MiB of
>> > rubbish". They will be sequential.
>>
>> The problem is all my 118 MiB UBI partition consist of PEBs with UBI
>> headers. This is because I was using firmware with UBI partition
>> before flashing the new firmware.
>
> Hmm, normally different images have different sequence numbers, because
> ubnize picks a random 64-bit number. And UBI will refuse attaching the
> flash if it finds out that there is more than one sequence number used.

I didn't know about that sequence number. Just tried it and it seems
to work indeed. I flashed firmware A on clean flash, then firmware B
and the firmware B complained:
[    1.314877] Reading 00680000 magic:55424923 version:1 image_seq: 3A7605BE
[    1.323836] Reading 006A0000 magic:55424923 version:1 image_seq: 3A7605BE
[    1.332787] Reading 006C0000 magic:55424923 version:1 image_seq: 3A7605BE
[    1.341739] Reading 006E0000 magic:FFFFFDFF version:FF image_seq: FFFFFFFF
[    1.350776] Reading 00700000 magic:55424923 version:1 image_seq: 749C5468
[    1.359720] Reading 00720000 magic:55424923 version:1 image_seq: 749C5468
[    1.368678] Reading 00740000 magic:55424923 version:1 image_seq: 749C5468

Unfortunately this won't work if we flash the same firmware twice (it
will contain the same sequence). Imagine someone flashing a stable
OpenWrt release, then breaking something and flashing the same image
again. It'll contain the same sequence number and my magic driver
won't clean the old data :(