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

[Tanya Brokhman <tlinder@codeaurora.org>]

On 3/18/2015 2:19 PM, Richard Weinberger wrote:
> Am 18.03.2015 um 13:12 schrieb Tanya Brokhman:
>>> We should still add a big and fat warning.
>>
>> In ubinize? yes, you're probably right. Will do. But if it's ok with you, I'll wait to get some inputs on the code before uploading another version.
>
> In ubinize. Yes, there no need to hurry. :-)
>
>>>
>>>>> 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.
>>
>> If my flasher finds bad blocks and invalidates fastmap - then the boot time will be as it was before, without this enhancement. The flashing time will be delayed by T_erase +
>> T_write_header for one PEB -> can be neglected. If We implement the whole fastmap generation in flasher then the  flashing time will increase significantly.
>
> I'm sure I miss something, how log does the fastmap creation take?
> If you update the image in memory it should be extremely fast.
> I.e. scan the NAND for bad blocks, amend the image and flash it.

(thinking out-loud, trying not to reveal our flasher details)
UBI aware flasher has to:
1. scan partition and collect ec values
2. for each PEB of the image: update the ec_header, erase PEB and flash 
the image
3. for remaining empty PEBs erase and write ec_heaser

For generating FM in flasher we need to update #2 and while flashing the 
image construct the FM data in memory. (what PEB, for what volume etc). 
this is O(1)

When we have the layout in memory we need to construct the actual FM 
data => go over all lists => O(number of dev PEBs) => probably can be 
neglected as well.

Ok, I take it back: run time wont be effected. What will be effected is 
memory consumption.

If I remember correctly, when we discussed this whole idea a while back 
you mentioned that a lot of users use their own proprietary flasher. So 
from your experience: you think users will prefer to have a libfastmap 
and not ubinize enhancement?
Maybe implementing libfastmap to be added to any flasher isn't such a 
bad idea. Then the whole "ubi awareness" can be implemented there.
I wasn't aware of the fact that ubinize is skipped. Is this common?

Thanks,
Tanya Brokhman
-- 
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project