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

Matthew L. Creech mlcreech at gmail.com
Tue Jan 3 22:48:18 CET 2012


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

(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


More information about the U-Boot mailing list