[PATCH 2/2] ubi-utils: ubinize: Add fastmap suport to image creation

[Richard Weinberger]

Hi Tanya,

Am 18.03.2015 um 11:43 schrieb Tanya Brokhman:
> Hi Richard,
> 
> Sorry for this taking so long. Had some legal issues to overcome.

No problem. :-)

> On 3/18/2015 12:22 PM, Richard Weinberger wrote:
>> Hi!
>>
>> Am 18.03.2015 um 09:52 schrieb Tanya Brokhman:
>>> While generating ubi image with ubinize, all UBI data required for
>>> Fastmap is present. If we generate the Fastmap data as part of the
>>> image, the first boot after flash won't require full scan of the UBI
>>> device.
>>> In order to be able to generate the Fastmap data number of device
>>> PEBs is required. If this input parameter was not provided - Fastmap
>>> will not be generated.
>>>
>>> Note: In order for this to work properly change is required in flasher
>>> as well:
>>> If while flashing the image bad blocks were discovered, Fastmap
>>> should be invalidated in the flashed image. Fastmap superblock
>>> (if present) will be in PEB#2 in the image.
>>
>> I didn't look at the implementation in detail as I'm still recovering from a flu.
>>
>> NAND is allowed to have bad blocks, therefore a lot of freshly flashed
>> UBI images won't be able to use fastmap.
> 
> Yes, that's why I added the disclaimer that this patch can only be used if the flasher code is updated as well. This is how I did it for our products. We have a proprietary flasher.
> 
>> What also puzzles me is that it will just work with a non-fastmap aware flasher.
>> But boards with bad blocks will blow up at (much) later and Joe random user will curse UBI. :)
> 
> That is correct. Note that if we don't provide the "-c" parameter to ubinize, all works as before and fastmap data wont be generated. "-c" is not a must. So users that don't update
> their flashers (don't make them fastmap aware) will just continue generating images without -c and fastmap wont be generated. It is backward compatible. (and they will have to look
> for other reasons to curse UBI :) )

We should still add a big and fat warning.

>> Maybe it would make sense to but the whole fastmap creation logic into the flasher.
> 
> But then you will delay the flashing process and this time is valuable. We're always looking for ways to decrease flashing of the images and the first boot duration.

But if your flasher will invalidate fastmap if it faces a bad block a certain amount of board will still boot slowly. Can you deal with that?
As I said NAND is allowed to be shipped with bad blocks.

> Also, if you move this logic inside the flasher, perhaps we can skip ubinize at all since it feels like the logic will be just duplicated.

It is not uncommon to skip ubinize.

>> We could create a libfastmap (LGPLv2) such that everyone is allowed to use it in his custom
>> flasher.
> 
> Perhaps. It wont work for us though, so unfortunately I wont be able to help out with that if this is the solution you prefer.

Why would this not work for your? Don't you have the sources of your flasher?
Of course we'd have to write libfastmap in a way such that one can use it on non-Linux systems like a bootloader.

Thanks,
//richard