This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM437X: AM437x ROM code ECC scheme

Part Number: PROCESSOR-SDK-AM437X


Hello,

I have this NAND mounted on my am437x device.

[ 1.484067] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xaa
[ 1.490792] nand: Toshiba NAND 256MiB 1,8V 8-bit
[ 1.495851] nand: 256MiB, SLC, page size: 2048, OOB size: 128
[ 1.502107] using OMAP_ECC_BCH16_CODE_HW ECC scheme

Reading in detail the TRM,  it seems that it is supported by the ROM code ( it is listed in the "Supported NAND Devices" Table) and since OOB = 128, BCH16 should be selected by ROM code.

However, it seems ROM code doesn't detect it properly.

Going in deep into the TRM, if the NAND device is not ONFI compliant (our case), then the standard Read ID (command 90h / address 00h) is sent. If the Device ID (2nd byte of the ID byte stream) is recognized as a

supported device, then the device parameters are extracted from an internal ROM Code table. 

When the parameters are retrieved from the ROM table: page size and block size are updated based on
4th byte of NAND ID data.

TC58NYG1S3HBAI4 is the NAND mounted and here Read ID:

1st: 0x98

2st: 0xAA

3rd: 0x90

4th: 0x15

5th: 0x76

How the spare area size is determined in this case?
As per this patch in u-boot http://lists.infradead.org/pipermail/linux-mtd/2013-June/047338.html , we need to rely on the 5th and 6th byte of NAND ID in order to compute spare area size.

I am reporting here for below convenience.

Toshiba NAND datasheets have not been very forthcoming on OOB size
information; they do not provide any bitfields in the ID string for
spare area. In their 24nm technology flash, however, Toshiba migrated
their NAND to have 32 bytes spare per 512 bytes of page area (up from
the traditional 16 bytes), as they now require 8-bit ECC or higher.

I have discussed this issue directly with Toshiba representatives, and
they acknowledge this problem. They recommend detecting these flash
based on their technology node as follows:

  For 24nm Toshiba SLC raw NAND (not BENAND -- Built-in Ecc NAND), there
  are 32 bytes of spare area for every 512 bytes of in-band data area.

We can implement this rule with the following snippet of a device ID
decode table, which applies to all their 43nm, 32nm, and 24nm SLC NAND
(this table is not fully in the NAND datasheets, but it was provided
directly by Toshiba representatives):

  - ID byte 5, bit[7]:
          1    -> BENAND
          0    -> raw SLC

  - ID byte 6, bits[2:0]:
          100b -> 43nm
          101b -> 32nm
          110b -> 24nm
          111b -> Reserved

I'm also working with Toshiba on including this bitfield description for
their 5th and 6th ID bytes in their public data sheets.

I will provide the 8-byte ID strings from the two 24nm Toshiba samples I
have; their first 6 bytes match the documentation I received from
Toshiba:

  24nm SLC 1Gbit TC58NVG0S3HTA00
  0x98 0xf1 0x80 0x15 0x72 0x16 0x08 0x00

  24nm SLC 2Gbit TC58NVG1S3HTA00
  0x98 0xda 0x90 0x15 0x76 0x16 0x08 0x00

I have also tested for regressions with:

  43nm SLC 4Gbit TC58NVG2S3ETA00
  0x98 0xdc 0x90 0x15 0x76 0x14 0x03 0x10

  32nm SLC 8Gbit TC58NVG3SOFA00
  0x98 0xd3 0x90 0x26 0x76 0x15 0x02 0x08

Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 drivers/mtd/nand/nand_base.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1cbacff..3e56995 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3079,6 +3079,22 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip,
 		extid >>= 2;
 		/* Get buswidth information */
 		*busw = (extid & 0x01) ? NAND_BUSWIDTH_16 : 0;
+
+		/*
+		 * Toshiba 24nm raw SLC (i.e., not BENAND) have 32B OOB per
+		 * 512B page. For Toshiba SLC, we decode the 5th/6th byte as
+		 * follows:
+		 * - ID byte 6, bits[2:0]: 100b -> 43nm, 101b -> 32nm,
+		 *                         110b -> 24nm
+		 * - ID byte 5, bit[7]:    1 -> BENAND, 0 -> raw SLC
+		 */
+		if (id_len >= 6 && id_data[0] == NAND_MFR_TOSHIBA &&
+				!(chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
+				(id_data[5] & 0x7) == 0x6 /* 24nm */ &&
+				!(id_data[4] & 0x80) /* !BENAND */) {
+			mtd->oobsize = 32 * mtd->writesize >> 9;
+		}
+
 	}
 }

My question here:

Is am437x ROM code doing the same ? Or wrong OOB size (and ECC scheme) will be selected?

  • Update: flashing the NAND applying BCH8, it works.

    This means that ROM code doesn't detect oobsize = 128 but 64 and it applies BCH8 as ecc scheme.

    Can you confirm?

    BR

    Claudio

  • Hello Claudio,

    Are you using Linux or RTOS on AM437x?

    Regards,

    Nick

  • Hi Nick, linux

    Claudio

  • Hello Claudio, 

    The default ECC correction applied is BCH 8 bits per sector using the GPMC and ELM hardware. For device ID codes D3h, C3h, D5h, C5h, D7h, C7h, DEh, CEh when manufacturer code (first ID byte) is

    98h the Cell type information is checked in the 4th byte of ID data. If it is equal to 10b then the ECC correction applied is BCH 16 bits per sector. 

    So BCH 8 is selected for NAND booting by rom code for the NAND device with Manufacturer ID: 0x98, Device ID: 0xaa.

    This is consistent with your test run on NAND device booting.

    Another way to check if BCH8 or BCH16 being used for rom code NAND booting is to check trace vector recorded by rom code.

    Please refer to the Table 5.65 of AM437x TRM  

    Best,

    -Hong

  • Thanks Hong.

    That is the case only if NAND is not ONFI compliant, correct?

    I mean, if it is ONFI compliant, ECC scheme BCH16 is selected by ROM code if oob size read is 128 for example.

    Just to know if I am safe just choosing one NAND that is ONFI compliant.

    Thanks,

    Claudio