UBI: ignore/overwrite old data/PEBs after flashing

UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

Hi,

I need some help with flashing UBI images.

I work with Broadcom ARM SoCs that use a CFE bootloader. In most cases
it doesn't provide a way to clear flash content before flashing the
firmware. It means that if I have 120 MiB of space for the firmware
and I flash 20 MiB firmware, the rest of flash (100 MiB) won't be
cleared. My partitioner driver will create 2 MiB partition for kernel
and 118 MiB partition for UBI.

So the result is that UBI partition contains 18 MiB of prebuilt
(ubinize-d) image and 100 MiB of rubbish. This will lead to problems
like:
UBI warning: scan_peb: valid VID header but corrupted EC header at PEB 17

UBI will find some old PEBs, try to use them, this may even lead to
situation where the data from previous install will be still
available!


Of course, I'm aware I should not upgrade my images this way all the
time. Normally I would simply use
$ ubiformat /dev/mtd0 -f ubi.img
, but I'm trying to handle some corner cases. Sometimes the firmware
may be broken and user may not be able to boot. In such case I need to
be able to re-flash the firmware using bootloader (and sacrifice the
wearing info).


Is there some way to tell UBI to ignore & overwrite all flash data
(including PEBs) that are placed after the flashed (ubinize-d) image?
Could we add some magic PEB that will tell UBI that all the flash
content after that single PEB is rubbish?

-- 
Rafał

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Richard Weinberger]

On Thu, Oct 16, 2014 at 7:34 AM, Rafał Miłecki <zajec5@gmail.com> wrote:
> Hi,
>
> I need some help with flashing UBI images.
>
> I work with Broadcom ARM SoCs that use a CFE bootloader. In most cases
> it doesn't provide a way to clear flash content before flashing the
> firmware. It means that if I have 120 MiB of space for the firmware
> and I flash 20 MiB firmware, the rest of flash (100 MiB) won't be
> cleared. My partitioner driver will create 2 MiB partition for kernel
> and 118 MiB partition for UBI.
>
> So the result is that UBI partition contains 18 MiB of prebuilt
> (ubinize-d) image and 100 MiB of rubbish. This will lead to problems
> like:
> UBI warning: scan_peb: valid VID header but corrupted EC header at PEB 17
>
> UBI will find some old PEBs, try to use them, this may even lead to
> situation where the data from previous install will be still
> available!
>
>
> Of course, I'm aware I should not upgrade my images this way all the
> time. Normally I would simply use
> $ ubiformat /dev/mtd0 -f ubi.img
> , but I'm trying to handle some corner cases. Sometimes the firmware
> may be broken and user may not be able to boot. In such case I need to
> be able to re-flash the firmware using bootloader (and sacrifice the
> wearing info).
>
>
> Is there some way to tell UBI to ignore & overwrite all flash data
> (including PEBs) that are placed after the flashed (ubinize-d) image?
> Could we add some magic PEB that will tell UBI that all the flash
> content after that single PEB is rubbish?

I'm confused. Do you always use the same UBI sequence number?
If you flash only 20MiB why do you create a much larger MTD partition?

> --
> Rafał
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



-- 
Thanks,
//richard

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

On 16 October 2014 11:10, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> On Thu, Oct 16, 2014 at 7:34 AM, Rafał Miłecki <zajec5@gmail.com> wrote:
>> Hi,
>>
>> I need some help with flashing UBI images.
>>
>> I work with Broadcom ARM SoCs that use a CFE bootloader. In most cases
>> it doesn't provide a way to clear flash content before flashing the
>> firmware. It means that if I have 120 MiB of space for the firmware
>> and I flash 20 MiB firmware, the rest of flash (100 MiB) won't be
>> cleared. My partitioner driver will create 2 MiB partition for kernel
>> and 118 MiB partition for UBI.
>>
>> So the result is that UBI partition contains 18 MiB of prebuilt
>> (ubinize-d) image and 100 MiB of rubbish. This will lead to problems
>> like:
>> UBI warning: scan_peb: valid VID header but corrupted EC header at PEB 17
>>
>> UBI will find some old PEBs, try to use them, this may even lead to
>> situation where the data from previous install will be still
>> available!
>>
>>
>> Of course, I'm aware I should not upgrade my images this way all the
>> time. Normally I would simply use
>> $ ubiformat /dev/mtd0 -f ubi.img
>> , but I'm trying to handle some corner cases. Sometimes the firmware
>> may be broken and user may not be able to boot. In such case I need to
>> be able to re-flash the firmware using bootloader (and sacrifice the
>> wearing info).
>>
>>
>> Is there some way to tell UBI to ignore & overwrite all flash data
>> (including PEBs) that are placed after the flashed (ubinize-d) image?
>> Could we add some magic PEB that will tell UBI that all the flash
>> content after that single PEB is rubbish?
>
> I'm confused. Do you always use the same UBI sequence number?
> If you flash only 20MiB why do you create a much larger MTD partition?

I tried to explain everything, but ofc forgot about this.

The answer is:
vol_flags=autoresize
I create much bigger MTD partition, because I want UBI to resize my
partition (to let user use whole flash space).

-- 
Rafał

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Artem Bityutskiy]

On Thu, 2014-10-16 at 12:21 +0200, Rafał Miłecki wrote:
> I tried to explain everything, but ofc forgot about this.
> 
> The answer is:
> vol_flags=autoresize
> I create much bigger MTD partition, because I want UBI to resize my
> partition (to let user use whole flash space).

Yes, that's the feature you may find convenient, but you still need to
get rid of the "rubbish". Otherwise the UBI driver won't even reach the
code where it handles the 'autoresize' flag.

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Artem Bityutskiy]

On Thu, 2014-10-16 at 07:34 +0200, Rafał Miłecki wrote:
> Hi,
> 
> I need some help with flashing UBI images.
> 
> I work with Broadcom ARM SoCs that use a CFE bootloader. In most cases
> it doesn't provide a way to clear flash content before flashing the
> firmware. It means that if I have 120 MiB of space for the firmware
> and I flash 20 MiB firmware, the rest of flash (100 MiB) won't be
> cleared. My partitioner driver will create 2 MiB partition for kernel
> and 118 MiB partition for UBI.

So what I hear is that the flasher does not provide users the "erase"
operation, but only provides users a "write" operation?

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.

And by the way, this is not related to your problem, but if you are
using a dumb flasher and you wanna use UBIFS, you may need to check the
"space fixup" stuff:

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_free_space_fixup

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

On 16 October 2014 12:09, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Thu, 2014-10-16 at 07:34 +0200, Rafał Miłecki wrote:
>> Hi,
>>
>> I need some help with flashing UBI images.
>>
>> I work with Broadcom ARM SoCs that use a CFE bootloader. In most cases
>> it doesn't provide a way to clear flash content before flashing the
>> firmware. It means that if I have 120 MiB of space for the firmware
>> and I flash 20 MiB firmware, the rest of flash (100 MiB) won't be
>> cleared. My partitioner driver will create 2 MiB partition for kernel
>> and 118 MiB partition for UBI.
>
> So what I hear is that the flasher does not provide users the "erase"
> operation, but only provides users a "write" operation?

That's right (at least for some/most of the CFE versions). Some
vendors hack CFE on their own, but the main problem still affects many
devices.


> 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.

-- 
Rafał

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Artem Bityutskiy]

On Thu, 2014-10-16 at 12:29 +0200, Rafał Miłecki wrote:
> On 16 October 2014 12:09, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > On Thu, 2014-10-16 at 07:34 +0200, Rafał Miłecki wrote:
> >> Hi,
> >>
> >> I need some help with flashing UBI images.
> >>
> >> I work with Broadcom ARM SoCs that use a CFE bootloader. In most cases
> >> it doesn't provide a way to clear flash content before flashing the
> >> firmware. It means that if I have 120 MiB of space for the firmware
> >> and I flash 20 MiB firmware, the rest of flash (100 MiB) won't be
> >> cleared. My partitioner driver will create 2 MiB partition for kernel
> >> and 118 MiB partition for UBI.
> >
> > So what I hear is that the flasher does not provide users the "erase"
> > operation, but only provides users a "write" operation?
> 
> That's right (at least for some/most of the CFE versions). Some
> vendors hack CFE on their own, but the main problem still affects many
> devices.
> 
> 
> > 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'.

May be you can invent an nice UBI feature to do this, but so far I feel
like a separate driver should be a better way to go.

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

On 16 October 2014 12:40, Artem Bityutskiy <dedekind1@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@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.


> May be you can invent an nice UBI feature to do this, but so far I feel
> like a separate driver should be a better way to go.

-- 
Rafał

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Artem Bityutskiy]

On Thu, 2014-10-16 at 13:17 +0200, Rafał Miłecki wrote:
> On 16 October 2014 12:40, Artem Bityutskiy <dedekind1@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@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.

And of course this would be a one-time driver. You'd need to run it only
on the very first boot.

On the other hand, may be you can add an "wipe_rubbish" kind of UBI
module parameter, which would make it to just erase any PEB containing
"rubbish", i.e., anything without an EC header. My worry is that this
could be potentially dangerous - if you have a PEB corrupted, and it
contains precious data, UBI will just destroy the precious data instead
of refusing the flash. So a feature like this would need to be used
carefully.

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

On 16 October 2014 13:27, Artem Bityutskiy <dedekind1@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@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@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.

So there is 118 MiB of space filled with UBI-header-ed PEBs, but only
first few first MiBs of PEBs are coming from the recently flashed
firmware. The rest of PEBs are old data (but they still contain UBI
headers).


> And of course this would be a one-time driver. You'd need to run it only
> on the very first boot.
>
> On the other hand, may be you can add an "wipe_rubbish" kind of UBI
> module parameter, which would make it to just erase any PEB containing
> "rubbish", i.e., anything without an EC header. My worry is that this
> could be potentially dangerous - if you have a PEB corrupted, and it
> contains precious data, UBI will just destroy the precious data instead
> of refusing the flash. So a feature like this would need to be used
> carefully.

If I could modify UBI this would be much easier. I was thinking about
appending a one special block to the ubinized image. This could be PEB
with UBI header containing some flag START_ERASING_FROM_HERE. Such a
flag could be removed after erasing rubbish to minimize the risk of
situation you described.

-- 
Rafał

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Artem Bityutskiy]

On Thu, 2014-10-16 at 13:38 +0200, Rafał Miłecki wrote:
> On 16 October 2014 13:27, Artem Bityutskiy <dedekind1@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@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@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.

Anyway, let's assume the worst case - you have all 100MiB of PEBs
contain UBI headers with the same sequence number. Now you flash your
18MiB image with the same sequence number.

UBI may actually even attach it without complaining. But it will be
completely messed up, you may find random data in your LEBs.

Very bed. Yr cannot fix this from within UBI, because for UBI all blocks
will look valid. So it will mix the new and old data in a random way. Or
it will fail if it find an inconsistency.

> So there is 118 MiB of space filled with UBI-header-ed PEBs, but only
> first few first MiBs of PEBs are coming from the recently flashed
> firmware. The rest of PEBs are old data (but they still contain UBI
> headers).

Yeah, so the point is that if you know that the last PEB of the new
image is X, you may erase all PEBs after X using the 'flashcleaner'
driver.

> If I could modify UBI this would be much easier. I was thinking about
> appending a one special block to the ubinized image. This could be PEB
> with UBI header containing some flag START_ERASING_FROM_HERE. Such a
> flag could be removed after erasing rubbish to minimize the risk of
> situation you described.

This sounds like an elegant solution.

But what if the image contains fastmap?

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

On 16 October 2014 13:54, Artem Bityutskiy <dedekind1@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@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@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@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 :(

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Artem Bityutskiy]

On Thu, 2014-10-16 at 15:51 +0200, Rafał Miłecki wrote:
> 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 :(

Yes, flashing with ubiformat would be fine, because it changes the
sequence number on-the-fly. With industial flashers, you'd need to erase
the flash.

Now you say you do not have the erase operation. You idea of a
"IMAGE_ENDS_HERE" bit seems to be nice, and you could implement it, but
you should think about the fastmap case too. Probably you need to do
nothing, because fastmap will only refer the PEBs within the image, and
the PEBs outside of the image will be scheduled for erasure. But you
should verify this.

Artem.

Re: UBI: ignore/overwrite old data/PEBs after flashing

[Rafał Miłecki]

On 20 October 2014 15:47, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Thu, 2014-10-16 at 15:51 +0200, Rafał Miłecki wrote:
>> 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 :(
>
> Yes, flashing with ubiformat would be fine, because it changes the
> sequence number on-the-fly. With industial flashers, you'd need to erase
> the flash.
>
> Now you say you do not have the erase operation. You idea of a
> "IMAGE_ENDS_HERE" bit seems to be nice, and you could implement it, but
> you should think about the fastmap case too. Probably you need to do
> nothing, because fastmap will only refer the PEBs within the image, and
> the PEBs outside of the image will be scheduled for erasure. But you
> should verify this.

So far I've implemented it for OpenWrt needs with a hacky patch you
can see there:
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=21741f060cab636c04d61ae696cd933adfea6e16
(it expects a PEB with 0xdeadc0de in place of UBI's magic).

I'll try to work on a clean solution when a find a bit of time. I
still need to learn about fastmap.

-- 
Rafał