Re: [U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
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!
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
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!
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/1...
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
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
participants (2)
-
Matthew L. Creech -
Scott Wood