[U-Boot] Status of fsl_elbc_nand driver and 4k page NAND / 4bit ECC

[Scott Wood <scottwood@freescale.com>]

On 04/13/2012 05:15 PM, Rafael Beims wrote:
> On Wed, Apr 11, 2012 at 9:22 PM, Scott Wood <scottwood@freescale.com
> <mailto:scottwood@freescale.com>> wrote:
> 
>     On 04/11/2012 07:14 PM, Rafael Beims wrote:
> 
>         Hello Scott,
>         On Wed, Apr 11, 2012 at 6:54 PM, Scott Wood
>         <scottwood at freescale.com <mailto:scottwood@freescale.com>
>         <mailto:scottwood@freescale.__com
>         <mailto:scottwood@freescale.com>>> wrote:
> 
>            On 04/11/2012 04:28 PM, Rafael Beims wrote:
> 
>                Hello,
>                I work with several MPC83xx boards in our company, and a
>         while
>                ago we were
>                informed that the NAND chip we used was being
>         discontinued. The only
>                options for a replacement were the newer 4k page ones.
>                Specifically, we are
>                using now the Micron 29F8G08ABABA (8 gigabit).
> 
>                I was sweeping the repositories and this list's archives
>         and I'm
>                with the
>                impression that these chips are not supported yet. I saw some
>                patches sent
>                hacking the driver to allow for the use of 4k pages.
> 
>                Additionally, I'm worried about the use of the 4 bit ECC lib
>                (BCH), as it
>                seems to me that the fsl_elbc_nand driver is not prepared
>         to use
>                a software
>                ECC config. Maybe I'm wrong, but it seems that the driver
>         always
>                uses the 1
>                bit HW ECC that's present in freescale's controller.
> 
>                Because of this, I would like to ask for an overall status of
>                these things.
>                What can I expect to be working? What are the main areas
>         of concern?
>                If there is no complete implementation yet (as I saw some
>                patches being
>                rejected / not merged yet), what is currently missing?
>                What is the area where most work is needed?
> 
> 
>            The main thing that is missing from the current patches is
>         migrating
>            bad block markers on first use, and checking that this has
>         happened
>            before using the hack. See the discussion on the Linux version of
>            these patches. I was hoping to take care of this earlier this
>         year,
>            but other tasks have intruded.
> 
> 
>         Does this have to do with the fact that the oob size is
>         different in the
>         bigger page NAND's (sorry if my question seems dumb, but I'm not
>         very
>         familiar with the NAND drivers and the software use. Until now
>         the NAND
>         part was just plug and play :) )
> 
> 
>     The hack involves changing the flash layout from "4096 main 128
>     spare" to "2048 main 64 spare 2048 main 64 spare".  This means that
>     the factory bad block marker is now in an area we use for main data.
>      We need to move it to where it belongs in the new layout before
>     doing anything else with the chip.
> 
> 
>            And as you note, many 4K-page NAND chips require 4-bit ECC which
>            means the driver will need to be updated to support software ECC
>            (this should be fairly straightforward, except maybe the
>         decision of
>            when to do this).
> 
>            -Scott
> 
> 
>         I will have a look at the driver and try to do the modifications to
>         support SW ECC. As I understand the fsl_elbc_nand driver is in
>         sync with
>         the linux kernel, and in this case the patches should be
>         implemented and
>         sent to the kernel first?
> 
> 
>     Ordinarily yes, but in this case it might be better to start with
>     U-Boot.  We'll likely do the bad block migration in U-Boot, whereas
>     Linux will just check that it's been done via some sort of marker.
>      And the ECC stuff doesn't make much sense until we have the 4K
>     support (I haven't heard of a 2K chip that needs 4-bit ECC).
> 
>     -Scott
> 
> 
> OK, I will have a look at it. I was just wondering, is there a tree
> somewhere that contains the patches for the 4k hack applied?

Not that I know of.

> I saw that a version 2 of the patch was sent by Shengzhou Liu in
> December 12, 2011, but I cannot find these patches applied in the main
> git://git.denx.de/u-boot-nand-flash.git
> <http://git.denx.de/u-boot-nand-flash.git>.

No, they were rejected because the bad block problem was not dealt with
(among other things, probably).

I do not want to apply a half-measure to the tree, and have people use
it and corrupt their data.

> I think that has something to do with the fact that the patches were not
> accepted in the way that they were presented, but I would like to know
> what's the procedure to start working from there to a possible solution.

Take their patches, turn them into something acceptable, and submit.

> I even tried to apply the patches to the current tree, without success.
> I could manually apply them, but this code is not mine and if I manually
> applied it, it would appear as mine.

You just need to preserve the signed-off-by and the from line (git
tracks committer and author separately), and add your own signed-off-by
at the end (make sure you read the developer's certificate of origin
before adding your signed-off-by).

See www.denx.de/wiki/U-Boot/Patches, and Documentation/SubmittingPatches
in the Linux tree (U-Boot follows a similar process as Linux).

-Scott