OOB buffers with syndrome calculating controller

[Ben Leinweber]

My company is currently trying to integrate a NAND flash chip into our product, and we have acquired in NAND flash controller IP core. I am responsible for writing the driver for this IP core.

The IP core automatically calculates the ECC on write and computes the syndromes on read. I am writing to this list because I am somewhat confused by how the default syndrome read/write functions handle the error codes in the internal NAND layer OOB buffers and am looking for a little help.

The way that the IP core writes data to the flash chip is as follows:
  |-------Data Column-------/~/------Data Column------|----Spare Column-----|
  Data-0 ECC-0 Data-1 ECC-1 /~/ Data-14 ECC-14 Data-15 USR-OOB Data-15 ECC-15
   512B   16B   512B   16B       512B    16B    272B    192B    240B    16B

This is for an 8kB page with 448 bytes in the spare column.

So the final chunk of data is split into two pieces and the final ECC data physically resides at the end of the spare column. When doing a normal non-raw read/write, all of this is handled by the controller and the driver only need concern itself with the data and the user OOB data. When performing a read, the controller automatically calculates the syndrome data and provides it to the driver through some registers.

Now to my questions.

1. The nand_read_page_raw_syndrome() reads each ECC chunk and stores them first in chip->oob_poi buffer, storing the user OOB data after. nand_write_page_raw_syndrome() also assumes that the ECC data is at the front of the chip->oob_poi and user OOB data is after.

Isn't this reverse from just about all of the defined nand_ecclayout structures? Almost all of them store the ECC data at the end of the OOB so as to never risk overwriting the bad block marker. Is there a reason that the data is stored in this order? Is there actually a consumer of the ECC data outside of the Flash driver?

2. nand_page_read_syndrome() appears to assume that the controller will return the ECC bytes when reading from a page in non-raw mode. It writes these bytes to the chip->oob_poi buffer. But my controller does not return the ECC bits when reading from it. I do not have direct access to the ECC bits in non-raw mode. Again, is there a consumer of the ECC data when read that way or may I just read the user OOB into chip->oob_poi?

3. nand_read_oob_syndrome() seeks for each of the ECC chunks, and reads them in to the chip->oob_poi buffer before reading in the user OOB into the chip->oob_poi. nand_write_oob_syndrome() assumes that the ECC data is there and goes out of its way to write to write to each of the columns which contain ECC data before writing the user data in the OOB. I'm confused why it bothers writing to these locations at all. It's not writing to the normal data columns. Is there really an external entity which is providing ECC data that needs to be threaded into the flash like this?



I understand that these functions probably were not written with my controller in mind, but I'm trying to understand the logic behind them and whether or not what they are doing is actually necessary in my case.

Thanks for any help!

Ben Leinweber
Andrews Space, Inc.

PROPRIETARY INFORMATION NOTICE: Except where otherwise noted, this Electronic Mail (e-mail) is the property of Andrews Space, Inc. and is intended only for the use of the individual or entity to which it is sent. You may not possess, use, copy or disclose this document or any information in it, for any purpose without permission. Neither receipt nor possession of this document alone, from any source, constitutes such permission. Possession, use, copying or disclosure by anyone without the express written permission of Andrews Space, Inc. is not authorized and may result in criminal and/or civil liability. If you receive this message in error, please notify the sender, do not make any use of the information in it and destroy it and all copies.