[U-Boot] [PATCH v2] nand: Hack to support 4k page in fsl_elbc_nand

[Scott Wood]

On 07/02/2012 04:00 PM, Rafael Beims wrote:
> On Fri, Jun 29, 2012 at 8:06 PM, Scott Wood <scottwood at freescale.com> wrote:
>> This raises the question of whether we should write the marker multiple
>> times, or otherwise deal with the possibility that the marker gets
>> bitflipped.  We don't want the migration to run again, finding bogus bad
>> block markes in what is now being used as a data area.
>>
> 
> Looking at the code again I realized that the intention was to have a
> backup, as you said. So I guess it would be good to write the marker
> more than once in other blocks for redundancy. As for the question of
> whether 2 blocks is enough, I think I don't have enough experience to
> tell that...

Regardless of how many extras we have, if we find one but not all of the
markers intact, we should repair it... which means we really need to
dedicate a block to this.

Simplest would be to write the marker in all pages of the block, if
we're consuming the entire block anyway.

Of course, to continue down the path of paranoia, what if we lose power
during said repair, after erasing but before writing a marker?  Make it
two blocks. :-(

>>>>> +             /* Allocate a temporary buffer for one eraseblock incl. oob */
>>>>> +             len = (1 << this->phys_erase_shift);
>>>>> +             len += (len >> this->page_shift) * mtd->oobsize;
>>>>> +             buf = vmalloc(len);
>>>>
>>>> This code isn't going to be shared with Linux, so just malloc().
>>>> Likewise printf(...) instead of printk(KERN_ERR ...).
>>>>
>>>> BTW, should mention at least in the changelog that this is partially
>>>> derived from code in nand_bbt.c.  Also, using this code means we need to
>>>> remove the "or later" from fsl_elbc_nand.c, because nand_bbt.c is GPL v2
>>>> only.  Wolfgang probably won't be pleased.  It might be better to just
>>>> write it from scratch -- I'm not sure how much it really helps to be
>>>> mimicking the bbt code here (without actually being able to share it),
>>>> versus straightforwardly coding this specific task.
>>>>
>>>
>>> I'm not shure I follow here. Is the use of the bbt descriptor a
>>> problem? Aside from that, the code indeed is somewhat based on the
>>> code on bbt (I used nand_bbt.c extensively for example code), but much
>>> of it is just plain running through the blocks and searching for
>>> patterns.
>>> I just want to understand what needs to be different, so I can work on it.
>>
>> The license on nand_bbt.c is GPLv2 only.  The license on fsl_elbc_nand.c
>> is GPLv2 or later.  So if we do use nand_bbt derived code, we need to
>> change the license on fsl_elbc_nand.c, or move this code into a
>> different v2-only file.  The only reason I suggested that it might be
>> better to just write new code is that the bbt code seems to be an
>> imperfect fit, and a bit more complicated than it needs to be.
>>
> 
> I tried to remove all references to the nand_bbt code in the last
> version of the patch (will follow after this). I hope that what I done
> is enough.

It needs to be not derived from the nand_bbt code if we're going to keep
v2-or-later -- not just references removed.

-Scott