[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood <scottwood@freescale.com>]

On 09/12/2011 08:02 PM, Marek Vasut wrote:
> On Tuesday, September 13, 2011 01:24:22 AM Scott Wood wrote:
>> On 09/12/2011 02:42 PM, Marek Vasut wrote:
>>> On Monday, September 12, 2011 09:36:49 PM Scott Wood wrote:
>>>> On 09/12/2011 02:28 PM, Marek Vasut wrote:
>>>>> On Monday, September 12, 2011 09:19:06 PM Scott Wood wrote:
>>>>>> What's it doing with them?  Migrating them is something that should
>>>>>> only happen on the first use, as there will later be data in the
>>>>>> factory bad block area, right?  So it shouldn't be "always". 
>>>>>> Migration should be an explicitly requested option.  Like scrub. :-)
>>>>>>
>>>>>> Where is the code that does this?  Which driver?
>>>>>
>>>>> The BCH accelerator does this.
>>>>
>>>> In hardware?  What chip is this, and where is the code that drives this
>>>> chip?
>>>
>>> I think it does something to it, yes. i.MX287, see the patchset [PATCH
>>> 00/15 V2] Support for the DENX M28 SoM, [PATCH 09/15] iMX28: Add GPMI
>>> NAND driver .
[snip]
> The problem with erase here is that the block's ECC is updated on erase.

I don't understand this -- wouldn't that stop you from being able to
later write a different ECC (when you write the actual data)?  Is the
controller snooping the command bytes you issue for erase, and then
generating a program sequence?  How would the hardware even know that
you told U-Boot to scrub?

>>> I looked at the code and the datasheet, and without getting into it too
>>> deeply, I don't see how BCH is involved in an erase operation.  What
>>> specifically are you seeing happen?
>>>
>>> The "Raw NAND Boot Mode" section (12.12 in my copy of the i.MX28 manual)
>>> says that it uses BCH for ECC -- is this not the case?  Is it some
>>> special configuration of BCH?
>>>
>>> I tried reading the "Bad Block Handling in the ROM" section and got a
>>> headache.
>> 
>> 12.12.1.8 is exactly it. See fig. 12-11.

I think we have different versions, that's "Layout of Boot Page
containing FCB" in my copy, which shows a fixed spare/data/ECC layout
that may not match what is programmed for normal BCH operations, but it
doesn't say anything about bad block markers.

The bad block marker stuff is in 12.12.1.12 (figure 12-13) in my copy.
It says:

> In order to preserve the BI (bad block information), flash updater or gang programmer
> applications need to swap Bad Block Information (BI) data to byte 0 of metadata area for
> every page before programming NAND Flash.

Before first programming the flash, you'll need to make sure that all
blocks that are marked bad in the normal way get marked bad in the new
layout, but you don't need to *swap* anything.  The block's bad, the
rest of the block doesn't matter.  But anyway...

> ROM when loading firmware, copies back
> the value at metadata[0] to BI offset in page data. The following figure shows how the
> factory bad block marker is preserved.

...this is insane.  It seems that they want you to swap this byte even
in good blocks, so that you put the byte of real data that should go
somewhere in the middle of the last 512-byte ECC chunk at offset zero in
the page.  This means that it will show up as a bad block when normal
(but new-layout-using) software looks at it, which is why you need
scrub.  Ew.

How many blocks are being loaded by this mechanism?  Just block zero
(which is normally supposed to be guaranteed good anyway...)?  Or
multiple blocks?

Any chance you could blow the NAND_MEMBLOCK_MARKER_RESERVE fuse? :-)
Otherwise, I guess you do need to scrub.  Have you complained to
Freescale sales/support?

> But we want to write a block in our own format, so we need to scrub (wipe the block 
> completely).

Erase always wipes the block completely, if it erases at all.  Scrub in
this context just means that U-Boot ignores the bad block indications
(marker or table).  Otherwise it would avoid erasing bad blocks, so that
they stay bad, and you won't have scrubbed the entire region requested.

>> I work for the PowerPC side of Freescale, in case you're wondering why
>> I'm unfamiliar with this. :-)
> 
> Interesting ... does everyone work for the PowerPC side of Freescale or is there 
> some other reason why I never met anyone working for the ARM side of Freescale ? 
> ;-)

They exist, but don't seem to engage Open Source development communities
to the same degree.

-Scott