the omap4 ROM code seems can't boot x-loader when nand flash mode

Hi Achun,

The SYSBOOT sequence 0b011001 gives the boot order of USB(1), UART, MMC1, and NAND.  Since NAND is last, please ensure that you don't have a MMC1 device connected with a valid bootloader.  Also, wait a few seconds for the boot in the case that you have the USB or UART connected, as the ROM code will try those first.

Is your NAND hardware setup to follow the specifications listed in the OMAP4 TRM, section 27.4.7.4?

Is your OMAP4 device GP or HS?  I believe the x-loader filename should be "MLO" not "x-load.bin.ift", but I will try to confirm that.

Regards,
Gina 

Actually, for MMC boot, the filename is MLO, and for NAND boot, the filename is X-LOADER.

Regards,
Gina 

hi,Gina,

thank you for your reply,I'am sure that is not connected MMC1 device before boot NAND,if I use SD card,read u-boot,kernel from nand can boot successfully.I thank write x-load.bin.ift or MLO to nand is no difference,their data is the same as,so?

I use signGP tool(source in x-loader scripts/signGP.c) sign x-load.bin than generate x-load.bin.ift,the x-load.bin.ift file more than x-load.bin 520 bytes,four bytes x-load.bin size,four bytes SRAM address and 512 bytes header data,I'am not sure the header config have no effect, and in x-loader cpu/omap4/start.S,there is some assembly code,I'am not sure relate to this too.How to determine the ROM code invoked the x-loader?

My OMAP4 device is GP,where setup the NAND hardware you mentioned '..setup to follow the specifications listed in the OMAP4 TRM, section 27.4.7.4'?

BR,

Achun

Achun,

I am discussing with our experts.  Could you please provide us with some more information about the NAND part that you are using, namely:

- part number

- vendor

- datasheet (if available publicly)

- whether it is ONFI compliant?

- 2KB or 4KB page size?

This information affects the formatting of the NAND required to comprehend ECC for the boot.

Regards,
Gina 

hi,Gina,

Thank you for your reply.the info:

-part number:MT29F8G08ABBCA

- vendor:micron

is ONFI compliant.

4KB page size.

download the attachment,contain the MT29F8G08ABBCA datasheet and x-loader data.

hi,Gina,

u-boot I use HWECC mode,I use the u-boot-2012.07 source,boot from SD card,in u-boot,my write data step is:

-mmc init

-fatload mmc 0:1 80000000 x-load.bin.ift

-nand unlock

-nand erase 0 80000

-nand write 80000000 0 80000

than remove the SD card and reboot.

BR,

Achun

Achun,

We are looking into this.  Can you please point me to the specific u-boot source code that you are using?  Is it from review.omapzoom.org?

Thanks,
Gina 

hi,Gina

I use u-boot is not in omapzoom,is  ftp://ftp.denx.de/pub/u-boot/u-boot-2012.07.tar.bz2,I added the nand support,I can send the sour code to your email.thanks.

BR,

Achun

Achun,

Could you please attach to this thread the code for the NAND support that you added so that we can review?

Thanks,
Gina 

hi,Gina,

I uploaded my patch,my board use 4k page,8 bits and total 8G,I don't know how to modify related config,such as the nand.ecc.bytes = ? nand.ecc.size = ? nand_ecclayout = ? eccsize1,eccsize0,ecc_code calculate etc,can you give me some advice?Thanks.

BR,

Achun

5483.mem-common-patch.patch.txt

0763.cpu.patch.txt

4278.nand_base.patch.txt

0513.omap4_panda.patch.txt

0310.nand.patch.txt

3225.omap_gpmc.patch.txt

hi,Gina

There is 4 bits,8 bits and 16 bits correct,I do not know my nand device must use the 16 bits error correct(set GPMC_ECC_CONFIG_ECCTOPSECTOR).

the follow is my dupm oob data:

OOB:
        ff 8b 02 19 8a e3 cb f8
        a5 fa 72 e9 c7 62 01 9f
        ef 03 2c 90 2c 75 0d c9
        f9 a5 7e 5a 57 52 03 82
        59 48 fd 6f 56 dd 24 a5
        41 fb d7 d1 f5 d1 d5 47
        73 d6 9d 03 a0 59 3a fa
        81 ee 82 13 11 88 81 0f
        75 4a a3 2f 17 e6 23 1f
        4b 3f 53 46 48 d0 3b 9f
        b5 d8 67 fa 84 cb 33 dd
        29 0a 26 9d 72 ab 7d 30
        0e 52 23 39 55 fd 60 09
        59 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00

hi,Gina

sorry,the right omap_gpmc.c patch

BR,

Achun

4251.omap_gpmc.patch.txt

hi, Gina,

In omap4460 TRM doc,there is a description:

chapter 15.4.4.13.3.2.2 Memory-Mapping of the BCH Codeword

'..For 512 bytes of data, 52 bits are required for 4-bit error correction, and 104 bits are required for 8-bit error correction and 207 bits are required for 16-bit error
correction....'

chapter 27.4.7.4.2 Read Sector Procedure

'..Page data can contain errors caused by memory alteration. The ROM code uses an ECC correction algorithm to detect and possibly correct those errors. The default ECC correction applied is BCH 8b/sector using the GPMC and ELM hardware.For device ID codes D3h, C3h, D5h, C5h, D7h, C7h, DEh, and CEh when the manufacturer code (first ID byte) is 98h, the cell type information is checked in the fourth byte of ID data. If it is equal to 10b, the ECC correction applied is BCH 16b/sector.'

According to the above, my understand is:the omap4 ROM ECC correction use the BCH 8b default,if ROM ECC correction use the BCH 16b,the manufacturer code must be 98h(TOSHIBA,such as TC58NVG3S0FTA00).is right?

in chapter 27.4.7.4.2,there are two tables,ECC Data Mapping for 2-KB Page and ECC Data Mapping for 4-KB Page,my nand device is 4-KB Page,so my choice is 'ECC Data Mapping for 4-KB Page',this required 208-bit for ecc data,so according to above ' ..207 bits are required for 16-bit error...',my software should use BCH16b correction when write data, but my nand's manufacturer code is 2C not 98h,  the omap4 default use BCH8,I don't know whether I need to replace the nand dev.

thanks,

BR,

Achun

Achun,

Sorry for the delay.  I am discussing with our experts about this.

Regards,
Gina 

Hi,

I have a similar problem

I added a piggyback with 4G-bit NAND to the pandaboard, ported the latest uboot to work with nand on panda - So via u-boot I am able to write and read this nand, and even 'saveenv' command works fine. I used the latest software BCH code - which generates 13 bytes ECC for each 512 bytes of data, and I sorted them exactly as the TI TRM said.

But the omap4 refuses to boot from it.

1. Does the omap4 HW BCH code is the same as the latest BCH u-boot's SW algorithm in generating these 13 bytes?

2. Do you have any kind of reference code (u-boot or even for the linux kernel) that utilizes this feature of the omap4 HW?

3. Do you have any kind of sample of what should be written in a NAND sector of 2048 bytes along the exact values to be stored in the 64 oob bytes?

Thanks!

Yuli, yk@magniel.com

Here is an exert of my u-boot output:

U-Boot 2012.07 (Sep 28 2012 - 02:33:53)

CPU  : OMAP4460 ES1.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xac (Micron NAND 512MiB 1,8V 8-bit)
512 MiB
MMC:   OMAP SD/MMC: 0
Scanning device for bad blocks
In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  3  0
Panda #
Panda # nand erase 0 80000


NAND erase: device 0 offset 0x0, size 0x80000

Erasing at 0x0 --  25% complete.
Erasing at 0x20000 --  50% complete.
Erasing at 0x40000 --  75% complete.
Erasing at 0x60000 -- 100% complete.
OK
Panda # mmc rescan 0

Panda # fatload mmc 0 ${loadaddr} MLO

reading MLO

26968 bytes read
Panda # nand write ${loadaddr} 0 9000


NAND write: device 0 offset 0x0, size 0x9000
 36864 bytes written: OK
Panda # nand dump.oob 0

Page 00000000 dump:
OOB:
    ff ff 27 e1 c6 1b 5f d9
    f9 b2 14 76 23 52 e2 ff
    97 34 dd a3 a8 66 22 0b
    ff f9 53 eb 81 ff fb 74
    f2 26 71 a3 4a ae a0 c1
    69 19 8e ff 88 18 54 70
    58 84 7c 65 05 8f af d2
    9a ff ff ff ff ff ff ff
Panda #

Achun,

Sorry for my delay.

First of all, the note from the TRM that you are concerned about (“The default ECC correction applied is BCH 8b/sector using the GPMC and ELM hardware. For device ID codes D3h, C3h, D5h, C5h, D7h, C7h, DEh, and CEh when the manufacturer code (first ID byte) is 98h, the cell type information is checked in the fourth byte of ID data. If it is equal to 10b, the ECC correction applied is BCH 16b/sector.”) is not applicable in this case.  This comment applies when the device is identified by the Device ID code (standard Read ID command).  This is slightly different from the ONFI case.  ECC strength is determined by the offered spare area capacity.  If there is enough room for BCH16, then the ROM code prefers this encoding; otherwise, it defaults to BCH8.  Because your NAND device is ONFI compliant, the ROM code extracts the parameters page and gets the page and spare area sizes.  Provided that the spare size is reported as 224 bytes, the ROM code assumes there is sufficient room for exercising BCH16. 

Before flashing the bootloader, it must match Figure 27-25 (“ECC Data Mapping for 4-KB Page and 16b BCH Encoding”) in the OMAP4 TRM – left column for x8.  You have to use BCH16 for this specific device, and it requires 208 bits (26 bytes) / sector, as shown in this figure. 

Regards,
Gina

Yuli,

For the NAND device that you are using, can you please clarify whether it is ONFI compliant and whether it is a 2KB or 4KB page size?

We don't have any official reference code available; however, for your question:

1. Does the omap4 HW BCH code is the same as the latest BCH u-boot's SW algorithm in generating these 13 bytes?

Can you please point me to which u-boot software BCH algorithm you are using, so that we can compare?

Thank you,
Gina 

Thanks for the reply.

I placed a copy of complete source code tar of my modified u-boot (about 12 MBtyes) here:

www.magniel.com/yuli/u-boot-2012.07-yuli_121005.tar.gz

The NAND I use is MT29F4G08ABBDAHC. It is ONFI 1.0 compliant, 8-bit, page size 2112 bytes (2048+64bytes)

I used the BCH code EXACTLY as it appears in the LATEST u-boot implementation, and I set it up to generate 13 bytes for every block of 512 bytes of data. I sorted the benerated BCH bytes EXACTLY as the TRM specified (see my previous posting).

The source code of the BCH algorithm appears in the file \lib\bch.c, and I activate it specifically in the file 'drivers\mtd\nand\omap_gpmc.c' with these commands:

    nand->ecc.mode = NAND_ECC_SOFT_BCH;
    nand->ecc.size = 512;
    nand->ecc.bytes = 13;
    nand->ecc.layout = &hw_nand_oob;

static __maybe_unused struct nand_ecclayout hw_nand_oob = {
    .eccbytes = 52,
    .eccpos = {
           2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,
          16,17,18,19,20,21,22,23,24,25,26,27,28,
          30,31,32,33,34,35,36,37,38,39,40,41,42,
          44,45,46,47,48,49,50,51,52,53,54,55,56},
    .oobfree = {
        {.offset = 57,
         .length = 7 } }
};

Thanks,

Yuli

Yuli,

Actually for 8b BCH, the hardware expects 14 bytes ECC for each 512-byte sector (13 bytes ECC + 1 byte padding).  See Figure 27-24 ("ECC Data Mapping for 2-KB Page and 8b BCH Encoding") in the OMAP4 TRM.  Is this accounted for in your software?

Regards,
Gina 

of course!

I'm kind of dazzled by this shallow answer, I attached in my initial request from Oct-3 the EXACT structure of the 64 byte oob which my software generated, I also attached in my previous message a link to my complete SW.

I'm repeating my request:

1. Does the omap4 HW BCH code is the same as the latest BCH u-boot's SW algorithm in generating these 13 bytes?

2. Do you have any kind of reference code (u-boot or even for the linux kernel) that utilizes this feature of the omap4 HW?

3. Do you have any kind of sample of what should be written in a NAND sector of 2048 bytes along the exact values to be stored in the 64 oob bytes?

Thanks