12 Aug
2009
12 Aug
'09
12:34 a.m.
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