Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST
On Mon, Aug 10, 2009 at 01:27:56PM -0400, s-paulraj@dal.design.ti.com wrote:
/**
- nand_read_page_hwecc_oob_first - [REPLACABLE] hw ecc, read oob first
- @mtd: mtd info structure
- @chip: nand chip info structure
- @buf: buffer to store read data
- Hardware ECC for large page chips, require OOB to be read first.
That statement may be true on some controllers, but not all.
- For this ECC mode, the write_page method is re-used from ECC_HW.
- These methods read/write ECC from the OOB area, unlike the
- ECC_HW_SYNDROME support with multiple ECC steps, follows the
- "infix ECC" scheme and reads/writes ECC from the data area, by
- overwriting the NAND manufacturer bad block markings.
- */
+static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf, int page)
+{
- int i, eccsize = chip->ecc.size;
- int eccbytes = chip->ecc.bytes;
- int eccsteps = chip->ecc.steps;
- uint8_t *p = buf;
- uint8_t *ecc_code = chip->buffers->ecccode;
- uint32_t *eccpos = chip->ecc.layout->eccpos;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
- /* Read the OOB area first */
- chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
Note that a READ0 command will have already been issued at this point.
I guess it looks to the NAND chip as a zero-byte read, but still things are getting quite ugly. The "generic" interface is one big layering violation that assumes a certain type of very simple controller, and we're accumulating hacks to deal with less straightforward controllers. :-(
-Scott
-----Original Message----- From: Scott Wood [mailto:scottwood@freescale.com] Sent: Tuesday, August 11, 2009 6:35 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.de; Narnakaje, Snehaprabha Subject: Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST
On Mon, Aug 10, 2009 at 01:27:56PM -0400, s-paulraj@dal.design.ti.com wrote:
/**
- nand_read_page_hwecc_oob_first - [REPLACABLE] hw ecc, read oob first
- @mtd: mtd info structure
- @chip: nand chip info structure
- @buf: buffer to store read data
- Hardware ECC for large page chips, require OOB to be read first.
That statement may be true on some controllers, but not all.
[Sandeep] Yes, this is true for TI DaVinci controllers
- For this ECC mode, the write_page method is re-used from ECC_HW.
- These methods read/write ECC from the OOB area, unlike the
- ECC_HW_SYNDROME support with multiple ECC steps, follows the
- "infix ECC" scheme and reads/writes ECC from the data area, by
- overwriting the NAND manufacturer bad block markings.
- */
+static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf, int page)
+{
- int i, eccsize = chip->ecc.size;
- int eccbytes = chip->ecc.bytes;
- int eccsteps = chip->ecc.steps;
- uint8_t *p = buf;
- uint8_t *ecc_code = chip->buffers->ecccode;
- uint32_t *eccpos = chip->ecc.layout->eccpos;
- uint8_t *ecc_calc = chip->buffers->ecccalc;
- /* Read the OOB area first */
- chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
Note that a READ0 command will have already been issued at this point.
I guess it looks to the NAND chip as a zero-byte read, but still things are getting quite ugly. The "generic" interface is one big layering violation that assumes a certain type of very simple controller, and we're accumulating hacks to deal with less straightforward controllers. :-(
[Sandeep] I agree.At the beginning of the year we had a way to do it with the existing modes. WE had are own read and write funtions in the Davinci NAND driver to achieve what were are doing in this patch. But the solution was not accepted by the MTD community. I have given the link for the original kernel patches. This current solution had the blessings of Thomas Gleixner and David Brownell.
-Scott
Paulraj, Sandeep wrote:
[Sandeep] I agree.At the beginning of the year we had a way to do it with the existing modes. WE had are own read and write funtions in the Davinci NAND driver to achieve what were are doing in this patch. But the solution was not accepted by the MTD community. I have given the link for the original kernel patches. This current solution had the blessings of Thomas Gleixner and David Brownell.
OK. We'll do the same for now, then, but at some point (the ever-elusive "when I get time") I'd like to try to straighten out the interface, and shrink the footprint.
-Scott
participants (2)
-
Paulraj, Sandeep -
Scott Wood