On Mon, Aug 10, 2009 at 01:27:56PM -0400, s-paul...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
