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

Rafael Beims
2012-04-13T22:15:11Z

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