NAND flash on IMX53

[woutervh]

I have a custom board with an IMX53 and a 1GB nand flash (Samsung 8bit width, 2048 page and 64bit OOB)

I use the 2.6.35 kernel from the freescale bsp

Which driver do I use? I see mxc_nd2, mxc_nd, mxc_nand.

It gets detected by the kernelwith the mxc_nd2, however, no bad block table found  and many RS-ECC errors... In the bootloader (bareboxy) it works perfectly...

I find no way to fix this. Any help appreciated.

[woutervh]

Ok, I already have done some research, and now I get things running a bit.

The nand flash was in the nand_device_info.c (as K9K8G08UXM, but settings remain the same according to the datasheet).

However, I still have issues with the bad block table. But the problem is triggered by either the bootloader or the kernel.

And especialy the following thing.

Barebox starts to look for the bbt-descriptor at the end of one page (from byte 2048 on) and also writes it there when not found. However, the mxc_nd2.c driver, starts to look from byte 2098 onwards. This is triggered by the following piece:

/* keep compatible for bbt table with old soc */

    if (cpu_is_mx53()) {

	bbt_mirror_descr.offs = BAD_BLK_MARKER_OOB_OFFS + 2;
	bbt_main_descr.offs = BAD_BLK_MARKER_OOB_OFFS + 2;
	bbt_mirror_descr.veroffs = bbt_mirror_descr.offs + 4;
	bbt_main_descr.veroffs = bbt_main_descr.offs + 4;

   }

But what does this mean? If I comment this part out, the bootloader and kernel do match... So who is doing it wrong? Or why does the driver introduce an extra offset?

[weidong_sun · Accepted solution]

Hello,Wouter,

      mxc_nd2.c is the driver for NAND Flash Controller in i.mx53. Since ECC erros ocurred , we check if this nand is supported in nand device list.

      Please open "linux/driver/mtd/nand/nand_device_info.c" , and we can find many nand device are listed here, check if your nand type is listed here, if not, add it according to the same formmat,please !

      Then try to run your linux kernel .

Regards,

Weidong

[woutervh]

Hello,

As far as I can see, it's already in there.

It's a Samsung k9k8g08u0d (id 0xEC 0xD3 0x51 0x95)

But as I google it, I find some regression fixes for it for kernel 3.7 (something of id detect for samsung of 5 or 6 bytes)

Don't know quite sure what is wrong. In barebox, it works fine (my environment variables are already stored on it)

Edit: now I've put a printk in the nand_get_flash_type, and get the following result. I think the detection itself is ok. But it is not normal that it does not detect a bad block table (it is written in the bootloader: Bad block table written to 0x3ffe0000, version 0x01) and that I get that many uncorrectable rs-ecc errors. The places of bad blocks are the same as the ones detected in the bootloader though...

writesize= 2048, oobsize= 64, erasesize= 131072, buswidth= 0

NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V 8-bit)

Bad block table not found for chip 0

Bad block table not found for chip 0

Scanning device for bad blocks

Bad eraseblock 12 at 0x000000180000

UnCorrectable RS-ECC Error

Bad eraseblock 174 at 0x0000015c0000

UnCorrectable RS-ECC Error

RedBoot partition parsing not available

Registering NAND 1GiB 3,3V 8-bit as whole device

Edit2: another thing I noticed:

Id's red in bootloader:

id 0 = ec

id 1 = d3

id 2 = 51

id 3 = 95

id 4 = 58

id 5 = ec

id 6 = 6c

id 7 = dd

Id's red in kernel:

id 0 = ec

id 1 = d3

id 2 = 51

id 3 = 95

id 4 = 58

id 5 = ec

id 6 = 0a

id 7 = 0a

[mwsealey]

There is a very simple explanation for the mismatched ID between U-Boot and Linux - both drivers implement the NAND_CMD_READID by using a special NFC automatic process for the actual READ ID data latching.

If you go read the docs for the i.MX53 for the NFC_LAUNCH register, it actually states very clearly that the special READ ID cycle generation will toggle the read enable 6 times and put the data into the requested data area dictated by RBA bits in NFC_CONFIGURATION1.

Sending command, address then toggling read enable 6 times = transfer 6 bytes, and the two extra bytes on the end are actually trash data since no NFC command clears the internal RAM before it executes, it could be the result of any previous NAND read.

Essentially it is impossible to actually use the READ ID automatic process if you need more than 6 bytes from address 0. I consider this is a serious hardware bug (although, quirk might be less aggressive since it is definitely documented.. I still say that it's seriously stupid from a design level).

That essentially means ONFI NAND detection simply is impossible with the current driver, which is why the weird table of ids exists in older kernels and U-Boot - unfortunately if the device is not in the table and you don't have access to a datasheet for that NAND (assuming it's ONFI compliant), then you are pretty much out of luck for properly using the NAND properly.

If their NAND is ONFI compliant, and I am not sure it is but let us assume that it is for the sake of discussion, getting a NAND datasheet from Samsung these days is tantamount to impossible unless you are Apple or another department at Samsung, so even if you COULD detect it some other way, the honest and usual way of pulling parameter data via a standardized command basically probably doesn't work either.

I find it incredibly hard to believe nobody noticed this since 2006 (ONFI 1.0 spec release), or sat down and looked at this before (but, I guess it is easier to add a line to a table in Linux than actually autodetect the hardware on a system for a lot of people just hacking around) given that most i.MX NFC boards in U-Boot have NAND that is ONFI complaint, and all go ahead and define CONFIG_SYS_NAND_ONFI_DETECTION - it would never have worked without the ID in nand_ids.c or Freescale's nand_device_info.c if you're using BSP U-Boot.

And despite it being listed as supporting, and listing several supported devices in the reference manual, the driver in upstream Linux (and any BSP after around 11.05) does not support them.. because it cannot detect real parameter data, hardcodes some "common" (but actually just guessed) data instead, and completely lacks ECC support for several 2k page NAND and *all* 4k page NAND devices...

I'm working on a bunch of patches right now for mxc_nand (unfortunately not for mxc_nd2) in U-Boot and Linux to resolve some of these issues and would appreciate before upstreaming them some kind of testing from other people - the NFC has some odd behavior and I only have very restricted NAND devices to test with (all ONFI-compliant Micron chips, which work fine with my changes, but I need some other manufacturer data to see if it is causing NAND chips to lock or do really weird things due to sending commands and asking to latch <8 bytes of data but unavoidably generating a pagesize worth of read cycles...

I will bring this up on linux-mtd tomorrow as Fabio suggested, since I definitely need some real NAND experts to evaluate my findings and give me a hint as to whether the proposed fix is as insane as the design of the IP core it's running on :smileyhappy:

[fabio_estevam]

Wouter,

Please report this issue in the linux-mtd mailing list.

Regards,

Fabio Estevam