public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Status of fsl_elbc_nand driver and 4k page NAND / 4bit ECC
Date: Wed, 11 Apr 2012 16:54:57 -0500	[thread overview]
Message-ID: <4F85FDB1.1040900@freescale.com> (raw)
In-Reply-To: <CABXAApE3+X03NHvjavMzSKWpuWR5VBeAKJb+tWzmCCdJt42oiw@mail.gmail.com>

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.

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

  reply	other threads:[~2012-04-11 21:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABXAApH0ffGMbC1DKPm3GGZyNO=cfzAOWmfN3VtWuUPXGwRY+Q@mail.gmail.com>
2012-04-11 21:28 ` [U-Boot] Status of fsl_elbc_nand driver and 4k page NAND / 4bit ECC Rafael Beims
2012-04-11 21:54   ` Scott Wood [this message]
     [not found]     ` <CABXAApFcrOhw0pF-w3enVqu8vY9xsEaViUpP1YujCDQeRcMRbQ@mail.gmail.com>
     [not found]       ` <4F862049.3040509@freescale.com>
2012-04-13 22:15         ` Rafael Beims
2012-04-16 21:10           ` Scott Wood
2012-05-08 20:07             ` Rafael Beims
2012-05-15 22:47               ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F85FDB1.1040900@freescale.com \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox