[U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

[U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

[Matthew L. Creech]

On Sat, Dec 3, 2011 at 11:31 PM,  <shuo.liu@freescale.com> wrote:
> From: Liu Shuo <shuo.liu@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.

(Starting a new thread so I don't hijack your patch)


Hi Scott / Liu,

We're using the MPC8313 and booting from a 2k NAND (using a SPL
image).  Like others, we're a bit concerned about continued
availability of 2k parts.  So this change -- being able to use the FCM
with a 4k chip -- would be very useful to us.

However, so far all of the 4k chips that we've seen have a higher
error rate than our current 2k chips.  Therefore they all recommend
that something stronger than 1-bit ECC is used.  Since the FCM only
supports 1-bit ECC in hardware, it implies that we'll need to use
software BCH to utilize a 4k chip.

But this seems like it's going to pose problems when we build U-Boot:
the SPL boot code is already heavily trimmed down to make it squeeze
into the requisite 4k, so it seems unlikely that we can add software
BCH support and remain within that size limit.  Have you guys run in
to this issue, or are you booting U-Boot from another source (e.g.
NOR)?

If using the U-Boot SPL: are you using a 4k part that works with just
1-bit ECC?  (If so, which one?)  Or are you using 1-bit ECC for
U-Boot, then BCH for the remainder of flash?  (This seems dangerous
for long-term usage, if errors accumulate in the blocks containing
U-Boot)

At this point we're mainly trying to size up our long-term options, if
2k part availability becomes a problem.  Thanks!

-- 
Matthew L. Creech

[U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

[Scott Wood]

On 01/03/2012 03:48 PM, Matthew L. Creech wrote:
> On Sat, Dec 3, 2011 at 11:31 PM,  <shuo.liu@freescale.com> wrote:
>> From: Liu Shuo <shuo.liu@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.
> 
> (Starting a new thread so I don't hijack your patch)
> 
> 
> Hi Scott / Liu,
> 
> We're using the MPC8313 and booting from a 2k NAND (using a SPL
> image).  Like others, we're a bit concerned about continued
> availability of 2k parts.  So this change -- being able to use the FCM
> with a 4k chip -- would be very useful to us.
> 
> However, so far all of the 4k chips that we've seen have a higher
> error rate than our current 2k chips.  Therefore they all recommend
> that something stronger than 1-bit ECC is used.  Since the FCM only
> supports 1-bit ECC in hardware, it implies that we'll need to use
> software BCH to utilize a 4k chip.

Even on SLC chips, when using an ECC block size of 512 bytes?  Or are
you only able to find MLC?

I looked for a datasheet for a 4K NAND chip, but couldn't find one
readily available from a Google search.  Hopefully someone internally
can provide me with the one for the chip we're using.

> But this seems like it's going to pose problems when we build U-Boot:
> the SPL boot code is already heavily trimmed down to make it squeeze
> into the requisite 4k, so it seems unlikely that we can add software
> BCH support and remain within that size limit.

There's also the issue of ECC on the boot page itself -- that has to be
hardware ECC, because there's no software running yet.

> If using the U-Boot SPL: are you using a 4k part that works with just
> 1-bit ECC?  (If so, which one?)  Or are you using 1-bit ECC for
> U-Boot, then BCH for the remainder of flash?  (This seems dangerous
> for long-term usage, if errors accumulate in the blocks containing
> U-Boot)

AFAIK, we've just been using 1-bit hw ECC.  I don't know what NAND chip
was used for testing, or how much stress testing was done.

-Scott

[U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

[Matthew L. Creech]

On Tue, Jan 3, 2012 at 5:08 PM, Scott Wood <scottwood@freescale.com> wrote:
>
> Even on SLC chips, when using an ECC block size of 512 bytes?  Or are
> you only able to find MLC?
>
> I looked for a datasheet for a 4K NAND chip, but couldn't find one
> readily available from a Google search.  Hopefully someone internally
> can provide me with the one for the chip we're using.
>

Yes, this is SLC.  The Micron MT29F8G08ABABAWP is one example.  The
datasheet is here (sign-up required, unfortunately - I can send a copy
if you want):

https://www.micron.com/parts/nand-flash/mass-storage/mt29f8g08ababawp

On page 93, it says "Minimum required ECC: 4-bit ECC per 540 bytes of data".

Maybe there are some 4k parts around that don't have this limitation,
but our hardware guy informed me that all of the common (high
availability) 4k parts he saw were similar.

>
> There's also the issue of ECC on the boot page itself -- that has to be
> hardware ECC, because there's no software running yet.
>

True.  I guess for random bit-flips, maybe that's just as much a
problem as the other blocks/pages?  I know that the first block is
somewhat "special", in that it's guaranteed not to be bad for some
minimum # of P/E cycles; will ECC errors still accumulate the same as
any other block?

>
> AFAIK, we've just been using 1-bit hw ECC.  I don't know what NAND chip
> was used for testing, or how much stress testing was done.
>

OK.  Thanks for the quick reply Scott!

-- 
Matthew L. Creech

[U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

[Scott Wood]

On 01/03/2012 04:43 PM, Matthew L. Creech wrote:
> On Tue, Jan 3, 2012 at 5:08 PM, Scott Wood <scottwood@freescale.com> wrote:
>>
>> Even on SLC chips, when using an ECC block size of 512 bytes?  Or are
>> you only able to find MLC?
>>
>> I looked for a datasheet for a 4K NAND chip, but couldn't find one
>> readily available from a Google search.  Hopefully someone internally
>> can provide me with the one for the chip we're using.
>>
> 
> Yes, this is SLC.  The Micron MT29F8G08ABABAWP is one example.  The
> datasheet is here (sign-up required, unfortunately - I can send a copy
> if you want):
> 
> https://www.micron.com/parts/nand-flash/mass-storage/mt29f8g08ababawp

The sign-up terms say:

> Use License
> Permission is granted to download one (1) copy of the materials on Micron's websites for personal, non-commercial transitory viewing only. This is the grant of a limited and non-exclusive license, not a transfer of title, and under this license you may not:
> 
> (a) modify or further copy the materials;
> (b) use the materials for any commercial purpose, or for any public display (commercial or noncommercial);
> (c) attempt to decompile or reverse engineer any software contained on Micron's websites;
> (d) remove any copyright or other proprietary notices on the materials;
> (e) transfer the materials to another person or "mirror" or "frame" the materials on any other website or server. 

It could be argued that my "purpose" is commercial, since I'm trying to
gain information to help support NAND controller hardware that my
employer sells (even though it's to Micron's benefit to maximize the
number of systems their NAND chips can interoperate with...).

Of course, that logic also applies to anyone using the information to
build a product for sale, that includes a Micron chip -- which seems to
be exactly who they'd be wanting to access these documents -- so it's
probably not what they meant (unless they give customers access via some
other terms).  It's not obvious what they *do* mean, though.

> On page 93, it says "Minimum required ECC: 4-bit ECC per 540 bytes of data".

OK.  Is booting from a source other than NAND (at least enough to fit
software BCH support) an option?

> Maybe there are some 4k parts around that don't have this limitation,
> but our hardware guy informed me that all of the common (high
> availability) 4k parts he saw were similar.

I found this after some more searching, but I've no idea if it (or
related chips) are highly available:

http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NANDFlash/SLC_LargeBlock/8Gbit/K9F8G08U0M/ds_k9f8g08x0m_rev10.pdf

>> There's also the issue of ECC on the boot page itself -- that has to be
>> hardware ECC, because there's no software running yet.
>>
> 
> True.  I guess for random bit-flips, maybe that's just as much a
> problem as the other blocks/pages?  I know that the first block is
> somewhat "special", in that it's guaranteed not to be bad for some
> minimum # of P/E cycles; will ECC errors still accumulate the same as
> any other block?

The datasheets I checked say things like "guaranteed to be a valid block
up to 1K program/erase cycles with 1bit/512Byte ECC" (this is on a chip
that wants 1bit ECC normally) -- so it looks like it's just guaranteed
to not be an official "bad block", not guaranteed to not have any bit flips.

You could check your datasheet to see what its specific claim is.

-Scott

[U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

[Matthew L. Creech]

On Tue, Jan 3, 2012 at 6:58 PM, Scott Wood <scottwood@freescale.com> wrote:
>> On page 93, it says "Minimum required ECC: 4-bit ECC per 540 bytes of data".
>
> OK. ?Is booting from a source other than NAND (at least enough to fit
> software BCH support) an option?
>

Not easily.  We were hoping to be able to use the existing design and
just substitute a new chip, and give the manufacturer a different
firmware image.  But it's starting to look like that might be the best
long-term option.  Booting directly from NAND has been more trouble
than it's worth in general, so we were already leaning toward having
our next design boot from a small NOR or EEPROM instead.

I'll also have our hardware guy take another look for 4k parts that
don't require >1-bit ECC (and thanks for the link).

Thanks Scott

-- 
Matthew L. Creech