Re: [PATCH 2/2] ubiformat: Leave space for fastmap anchor

[Tanya Brokhman <tlinder@codeaurora.org>]

On 10/22/2014 11:15 AM, Richard Weinberger wrote:
> Am 22.10.2014 um 09:48 schrieb Sascha Hauer:
>> The fastmap code needs a free eraseblock in the first 64 erasblocks
>> to write a fastmap anchor. Since ubiformat continuously writes the
>> image to the flash the fastmap code won't find a free block and
>> fastmap will be disabled.
>
> If UBI is unable to write a fastmap it will try again later.
> So, it will be not disabled.
>
>> With this patch ubiformat skips flashing
>> a block at the beginning thus allowing the fastmap code to write
>> an anchor.
>
> Hmm, this is a bit hacky. What prevents UBI itself from using this free PEB
> after the first attach? I.e. if a bitflip happens?
> The in kernel code has already a mechanism to move used PEBs < 64 to make space
> for the anchor.
> IMHO the only sane approach is to create a fastmap enabled image directly with ubiformat.
> While creating the initial fastmap code I had the plan to make mtd-tools fastmap aware
> but simply run out of budget and so far nobody cared enough.

I care :) Its in my TODO to update ubinize to leave space for fastmap 
anchor (and perhaps generate a fastmap data as well but this is just a 
thought).


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