[U-Boot] Status of fsl_elbc_nand driver and 4k page NAND / 4bit ECC
Rafael Beims
rafael.beims at gmail.com
Tue May 8 22:07:00 CEST 2012
On Mon, Apr 16, 2012 at 6:10 PM, Scott Wood <scottwood at freescale.com> wrote:
>
> 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
>
Hello Scott,
After some time browsing through the code I would like to start
implementing the migration of the bad block migration.
I just want to make sure I understand the issue enough so that I don't
do anything horribly wrong and have to start it all over again.
I just saw a post from you in the linuxppc-dev mailing list on the
same issue, and I quote:
>Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
>Scott Wood
>Wed, 14 Dec 2011 12:53:40 -0800
>On 12/13/2011 09:41 PM, LiuShuo wrote:
>> 于 2011年12月13日 05:09, Artem Bityutskiy 写道:
>>> On Tue, 2011-12-06 at 18:09 -0600, Scott Wood wrote:
>>>> On 12/03/2011 10:31 PM, shuo.... at freescale.com wrote:
>>>>> From: Liu Shuo<shuo.... at freescale.com>
>>>>>
>>>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In
>>>>> order
>>>>> to support the Nand flash chip whose page size is larger than 2K bytes,
>>>>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and
>>>>> save
>>>>> them to a large buffer.
>>>>>
>>>>> Signed-off-by: Liu Shuo<shuo.... at freescale.com>
>>>>> ---
>>>>> v3:
>>>>> -remove page_size of struct fsl_elbc_mtd.
>>>>> -do a oob write by NAND_CMD_RNDIN.
>>>>>
>>>>> drivers/mtd/nand/fsl_elbc_nand.c | 243
>>>>> ++++++++++++++++++++++++++++++++++----
>>>>> 1 files changed, 218 insertions(+), 25 deletions(-)
>>>> What is the plan for bad block marker migration.
>> I think we can use a special bbt pattern to indicate whether migration
>> has been done.
>> (we needn't to define another marker)
>>
>> Do the migration our chip->scan_bbt as follow :
>>
>> /*
>> * this pattern indicate that the bad block information has been migrated,
>> * if this isn't found, we do the migration.
>> */
>> static u8 migrated_bbt_pattern[] = {'M', 'b', 'b', 't', '0' };
>>
>> static int fsl_elbc_bbt(struct mtd_info *mtd)
>> {
>> if (!check_migrated_bbt_pattern())
>> bad_block_info_migtrate();
>>
>> nand_default_bbt(mtd); /* default function in nand_bbt.c */
>> }
>Hmm. This is OK as long as the bad block table never gets erased (which
>could happen if a user wants it reconstructed, such as if buggy software
>makes a mess of it on a developer's board). If it gets erased, we'll
>end up migrating again -- and the place that factory bad block markers
>would have been in is now data, so all blocks that have been written to
>will show up as bad unless they happen to have 0xff at the right place.
>How about a marker that is compatible with the bbt, so the same block
>can be used in production (where scrubbing the bbt should never happen),
>but that does not have to imply that the block is a bbt (so a developer
>that might want to erase the bbt can set the mark elsewhere, preferably
>just before the bbt)?
>Or have two versions of the marker, one that is also a bbt marker and
>one that is not.
>When scanning the bbt, the driver would look for one of these markers
>from the end of the chip backward. If not found, it concludes the chip
>is unmigrated. In U-Boot, this would trigger a migration (or a message
>to run a migration command). In Linux (and U-Boot if migration is a
>separate command that has not been run) an unmigrated flash could be
>read-only, with the possible exception of raw accesses if needed to
>support an external migration tool.
>-Scott
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev at lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
Based on your response, would it be OK to implement the marker in the
bbt as something like Liu Shuo suggested ('M', 'B', 'b', 't', 0) and
then do the scanning as follows:
Scan the bbt checking for the migrated flag as described. If we just
find the default bbt marker, continue searching in the next block
downwards to verify if we can find another marker indicating the
migration (and completely independent of the bbt in this case).
This second marker in this case would have to be written in a new
block, or would it be OK to write it in a new page?
It seems to me that a new block would be more appropriate, because you
mentioned that a developer would like to erase the bbt sometimes, and
that would imply the erasure of the entire block.
What are your thought's about this suggestion?
What would be an appropriate marker for the second block? It seems
that the usual (at least for the bbt) is a marker with a character
sequence. Should I just create a different character sequence and
write it in the oob of the first page of the next block to indicate
"developer" migration?
Thanks in advance for the help,
Rafael
More information about the U-Boot
mailing list