[U-Boot] Status of fsl_elbc_nand driver and 4k page NAND / 4bit ECC
Scott Wood
scottwood at freescale.com
Mon Apr 16 23:10:13 CEST 2012
On 04/13/2012 05:15 PM, Rafael Beims wrote:
> On Wed, Apr 11, 2012 at 9:22 PM, Scott Wood <scottwood at freescale.com
> <mailto:scottwood at 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 at freescale.com>
> <mailto:scottwood at freescale.__com
> <mailto:scottwood at 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
More information about the U-Boot
mailing list