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

[Rafael Beims <rafael.beims@gmail.com>]

On Wed, Apr 11, 2012 at 9:22 PM, Scott Wood <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@freescale.com
>> <mailto:scottwood at freescale.**com <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?

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.

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.
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.

Thanks for the support so far,
Rafael