• State Resolved
  • Locked Locked
  • Replies 27 replies
  • Subscribers 98 subscribers
  • Views 7405 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Micron NAND OOB doesn't match Micron's data sheets

Bill Goetz
Expert 1160 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

When writing data to a Micron NAND (specifically the MT29F4G08ABADAWP - which is a 4 Gigabit 8 bit interface) we're seeing the following OOB:

 

We now have over several thousand units in the field and am starting to see NAND issues.  The issue is that after a power cycle, they are getting “Bad CRC: Kernel Image not found”.  When U-Boot reads in the Linux partition, the CRC calculation fails and so the unit doesn’t come up.  When we get this error, we read the OMAP NAND Flash Status Register in EMIFA module NAND Flash Status Register (NANDFSR) we consistently see 0x30103 and 0x30303.  Both are bad, consistently 4+ errors, most of the time not correctable.

 

We do have a work-around, dual kernel images, however, we need to get to the bottom of WHY this is happening.

 

We’ve looked in it and think the problem is with the ECC calculations in U-Boot NAND driver.  Looking at the Micron device MT29F4G08ABADAWP  (8 bit wide 4 Gigabit flash) the ECC byte location didn’t seem to be written correctly.  They didn’t match with Micron’s spec with the device.

 

The change we made in the code to “fix” this (e.g. make the data match the data sheet) are:

 

./drivers/mtd/nand/davinci_nand.c:

 

static struct nand_ecclayout nand_davinci_4bit_layout_oobfirst = {

#if defined(CONFIG_SYS_NAND_PAGE_2K)

        .eccbytes = 32,

        .eccpos = {

                8,  9,  10, 11, 12, 13, 14, 15,

                24, 25, 26, 27, 28, 29, 30, 31,

                40, 41, 42, 43, 44, 45, 46, 47,

                56, 57, 58, 59, 60, 61, 62, 63,

                },

        .oobfree = {

                {.offset = 0, .length = 0, },

#if 0

        // bgg - orig

        .eccbytes = 40,

        .eccpos = {

                24, 25, 26, 27, 28,

                29, 30, 31, 32, 33, 34, 35, 36, 37, 38,

                39, 40, 41, 42, 43, 44, 45, 46, 47, 48,

                49, 50, 51, 52, 53, 54, 55, 56, 57, 58,

                59, 60, 61, 62, 63,

                },

        .oobfree = {

                {.offset = 2, .length = 22, },

#endif

        },

 

 

Using the following commands from U-Boot to write a page of data containing only the byte 0x34:

 

mw c0700000 0x34343434 512

nand erase 0 20000

nand write.e c0700000 0 800

 

 

Then examining the data using:

 

nand dump 0

 

The results are make the ECC data look like the following:

 

U-Boot > nand dump 0

bgg - made it to nand_print_info...

nand_read_page_raw_syndrome: page:0 Page 00000000 dump:

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

OOB:

        ff ff ff ff ff ff ff ff

        ad a8 f7 f5 ab c1 0e 19

        ff ff ff ff ff ff ff ff

        ad a8 f7 f5 ab c1 0e 19

        ff ff ff ff ff ff ff ff

        ad a8 f7 f5 ab c1 0e 19

        ff ff ff ff ff ff ff ff

        ad a8 f7 f5 ab c1 0e 19

U-Boot >

 

 

Performing this test WITHOUT the change yields the following OOB block:

 

U-Boot > nand dump 0

Page 00000000 dump:

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

        34 34 34 34 34 34 34 34  34 34 34 34 34 34 34 34

OOB:

        ff ff ff ff ff ff ff ff

        ff ff ff ff ff ff ff ff

        ff ff ff ff ff ff ff ff

        ad a8 f7 f5 ab c1 0e 19

        e3 de ad a8 f7 f5 ab c1

        0e 19 e3 de ad a8 f7 f5

        ab c1 0e 19 e3 de ad a8

        f7 f5 ab c1 0e 19 e3 de

U-Boot >

 

 

The question is: What is the layout of the OOB supposed to look like?

This is a critical problem, please help..!

 

Thanks,

Bill

 

  • 0
    TI__Genius 17355 points

    Bill,

    The ECC info in the OOB area of the NAND pages needs to be 40 bytes.  I'm not sure if which 40 bytes (out of the typical 64) that are used matters so much (the original layout shows just using the last 40 as one big chunk), but you definitely need 40.  The parity information for each 512 byte chunk is 80 bits, or 10 bytes, in length.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Expert 1160 points

    Hi Daniel,

    Yes, after some thought we actually had the same theory - that the OOB data can be mapped any way - when Micron NANDs write it, they just happen to be choosing a different layout than what you guys choose.  Sounds plausable.

    So the REAL problem we are having is that on a fairly decent percentage of units (~5% or more) :

     

     

    NAND read: device 0 offset 0x400000, size 0x400000

    4194304 bytes read: OK

     

    Loading from NAND 512MiB 3,3V 8-bit, offset 0x200000

       Image Name:   Linux-2.6.33-rc4

       Image Type:   ARM Linux Kernel Image (uncompressed)

       Data Size:    2011416 Bytes =  1.9 MB

       Load Address: c0008000

       Entry Point:  c0008000

    ## Booting kernel from Legacy Image at c0700000 ...

       Image Name:   Linux-2.6.33-rc4

       Image Type:   ARM Linux Kernel Image (uncompressed)

       Data Size:    2011416 Bytes =  1.9 MB

       Load Address: c0008000

       Entry Point:  c0008000

       Verifying Checksum ... Bad Data CRC

    ERROR: can't get kernel image!

     

    When we read the NAND Flash Status Register (NANDFSR), we consistently see either 0x103 or 0x303 - both very bad:

    11-8 ECC_STATE 0-Fh ECC correction state while performing 4-bit ECC Address and Error Value Calculation

    0 No errors detected

    1h Errors cannot be corrected (5 or more)

    2h Error correction complete(errors on bit 8 or 9).

    3h Error correction complete(error exists).

    4h Reserved.

    5h Calculating number of errors

    6h-7h Preparing for error search

    8h Searching for errors

    9h-Bh Reserved.

    Ch-Fh Calculating error value

     

    U-Boot > md 68000000

    68000000: 40000205 f0000000 00000620 000004e2    ...@.... .......

    68000010: 3ffffffc 3ffffffc 3ffffffc 3ffffffc    ...?...?...?...?

    68000020: 42215810 00000000 00000000 00000000    .X!B............

    68000030: 00000000 00000000 00000000 00000009    ................

    68000040: 0000000c 00000000 00000000 00000000    ................

    68000050: 00000000 00000000 00000000 00000400    ................

    68000060: 00000012 00000303 fcfcfcfc 00000000    ................

    68000070: 00000000 00000000 00000000 00000000    ................

    68000080: 00000000 00000000 00002091 00000000    ......... ......

    68000090: 00000000 00000000 00000000 00000000    ................

    680000a0: 00000000 00000000 00000000 00000000    ................

    680000b0: 00000003 00000000 00000000 0000033f    ............?...

    680000c0: 00000000 00000000 00000000 00000000    ................

    680000d0: 00000173 00000000 00000080 00000000    s...............

    680000e0: 00000000 00000000 00000000 00000000    ................

    680000f0: 00000000 00000000 00000000 00000000    ................

     

    Once this happens, the unit must be RMA'ed, which has been a huge headache for our customers.

    Please advise us on how we can fix this.

     

    Much thanks,

     Bill

     

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    I'm not an expert on the NAND driver that is in u-boot, but I'm surprised that no error is returned when the NAND read operation is performed, if the issue is in fact an ECC failure.

    I thinkI might try to debug this by adding some output in the NAND driver when one of these fatal error conditions is encountered (i.e. when the NANDFSR gets put into the bad state you indicated).  It would be useful to try and trace down whether the issue appears at the same location every time the boot fails (likely indicating a true bad block) or whether it varies.

    Also, just to cover all my bases, you are doing "nand read.e" for your boot commands?

    Regards, Daniel

     

  • 0 in reply to Daniel Allred
    Expert 1160 points

    Hey Daniel,

    What we learned today and yesterday:

     

    -   How our NAND organizes and stores data on the flash.

    -   How the OOB data is stored, and how it is written by the software driver.

    -   That the OOB data is just a block of data that is completely under software control.

    -   The 0x103 and 0x303 errors we see after completing the flashing station are a ruse – they always are occurring on the last page of the last block of both the Linux and File system partitions.  We verified this by reading in 0x3af800 bytes SUCCESSFULLY many times on multiple systems, however when reading in the very last page of the last block we ALWAYS get the 0x103 error.

    -   We also verified this by reading back Linux on two different APs.  The final page of the final block was ALWAYS DIFFERENT – basically whatever was in RAM at the time it was written.

    -   We also found that the sfh-OMAP_L138.exe file that we are using to program UBL and U-Boot are instructing the target NAND (note that this file can write to MULTIPLE NAND sizes) instructs the target NAND device to USE ITS OWN ECC calculation engine.  We verified this by observing that the OOB data EXACTLY matched Micron’s specifications.

    -   Because of this, Amitav ALWAYS got a 0x103 error once he read in U-Boot from U-boot, since U-Boot has a COMPLETELY different mapping for the OOB than Micron uses for its NAND devices.

    -   We found the difference between a good AP image and a bad one is ONE SINGLE bit that IS NOT IN THE SAME PLACE:

    -   Also the bit difference is that a bit did NOT get programmed correctly (e.g. it did not go from the default “1” to a “0”):

     

    Good APs:

    c0744670: 7a6fd622 0972bb18 77d1eeea 8ac3ed37

     

    Bad AP 1:

    c0744670: 7a6fd622 0972bb18 77d1eeea 8ac3fd37

     

     

    Good APs:

    c07787e0: f816e65d 53ab6434 305e8d95 f03758f9

     

    Bad AP 2:

    c07787e0: f81ee65d 53ab6434 305e8d95 f03758f9

     

    The apparent conclusion from this is that the ECC “correction” algorithm is NOT ABLE TO CORRECT A SINGLE BIT ERROR!!

     

    We will continue to work toward finding out WHY this is the case tomorrow.

    Daniel, isn't it the OMAP's job to fix these SINGLE bit errors??

    Thanks, Bill

     


  • 0 in reply to Bill Goetz
    Expert 1160 points

    ...or possibly there were too many errors (>4) which is what the 0x103 implies from reading the NANDFSR register.

     

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Does anyone out there have the source code for the “sfh_OMAP-L138.exe" program?

    We just want to verify that the code instructs the target device to write the OOB for each page on the NAND using the target NAND ECC internal engine.

    Thank you.


  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    You can find the source in the latest package available here.  But I can tell you that it has no concept of NAND internal ECC, and it will only use the ECC engine of the EMIF controller on the device.  I need to go back and look more closely at your previous post, but this was the thing that perplexed me - the internal ECC of the NAND should not be active and why would it only affect the last page of the last block read?

    Regards, Daniel

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill Goetz said:

    Does anyone out there have the source code for the “sfh_OMAP-L138.exe" program?

    We just want to verify that the code instructs the target device to write the OOB for each page on the NAND using the target NAND ECC internal engine.

    As a followup: The sfh program writes the ECC info in the OOB (spare bytes) region of a NAND page such that the ROM boot loader of the device can load and process it correctly.  The layout that the ROM expects can be seen in Figure 21 of the boot loader app note.  This is not exactly the same as the internal ECC format Micron documents, but it is close to it.  So I believe you are misinterpreting the data seen in the nand dumps and making an assumption that the internal ECC of the NAND is in use.  Moreover, the ECC layout is distinct from the one u-boot uses, so it should be no surprise that attempting to read the u-boot image from the NAND (which was written with a ECC layout that matches the ROM boot loader expectation) should show errors, as the NAND driver in u-boot has a different ECC layout expectation.

    The boot problems you are reporting are confined to u-boot and your investigations should focus there.  The sfh tool has nothing to do with reading or writing the Linux kernel.  If you are missing chunks of data at the end of your images, then you need to look at what tool is writing that data.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Expert 1160 points

    Hey Daniel, 

    Thanks for your information.  It's been helpful!  So, after further investigation, we found what we believe to be the true source of the problem - the ECC correction is NOT working!  It's NOT fixing a SINGLE bit error!  We finally think we have the NAND status registers figured out.  On some of the RMA'ed units we got back we ran the command:

    nand read.e 0xc0700000 0x200000 0x200000

    (we' still have a small Linux kernel, so we still only need 2MB)  Then, we do the following command to view all of the NAND controller registers:

    md 0x68000000

    U-Boot > md 68000000

    68000000: 40000205 f0000000 00000620 000004e2    ...@.... .......

    68000010: 3ffffffc 3ffffffc 3ffffffc 3ffffffc    ...?...?...?...?

    68000020: 42215810 00000000 00000000 00000000    .X!B............

    68000030: 00000000 00000000 00000000 00000009    ................

    68000040: 0000000c 00000000 00000000 00000000    ................

    68000050: 00000000 00000000 00000000 00000400    ................

    68000060: 00000012 00000303 fcfcfcfc 00000000    ................

    68000070: 00000000 00000000 00000000 00000000    ................

    68000080: 00000000 00000000 00002091 00000000    ......... ......

    68000090: 00000000 00000000 00000000 00000000    ................

    680000a0: 00000000 00000000 00000000 00000000    ................

    680000b0: 00000003 00000000 00000000 000000aa    ................

    680000c0: 00000000 00000000 00000000 00000000    ................

    680000d0: 00000025 00000000 00000008 00000000    %...............

    680000e0: 00000000 00000000 00000000 00000000    ................

    680000f0: 00000000 00000000 00000000 00000000    ................

     

    Note that in the NANDERRADD1 and NANDERRADD2 registers, there in only a SINGLE address!  So doesn't this imply that there in only a SINGLE error??  If so, WHY isn't it being corrected?  

    Please, how do we configure the ECC correction algorithm from both U-Boot AND from Linux??

    Any help would be greatly appreciated!

    Thanks,

     Bill

     

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill,

    The register dump shows zeros in the NAND4BITECC registers and also shows ECC_ERRNUM of the NANDFSR to be zero.  Based on the steps documented to use the 4-bit ECC engine of the EMIF, I pretty sure the NANDERRADDR and NANDERRVAL values are simple stale remnants from a correction that did take place sometime during the read operation that you initiated.

    You want proof that the ECC operations under u-boot are functioning correctly.  As I mentioned previously, I would consider modifying u-boot to add debug output info surrounding the ECC operations. Let it tell you when it corrects errors, how many it corrects, etc.  The way I understand the NAND drivers used in u-boot and Linux, is that they both share a lot of code.  I am also led to beleive that they do test the ECC operations, to make sure that they work.  If you wanted to test them yourself (aside from the suggestion above of printing debug output in u-boot), you would need the capability to write data pages to the NAND with purposefully introduced errors, but with the correct OOB/spare ECC data. I don't know if u-boot gives this capability with it's NAND commands, but this is an operation that I have performed outside of u-boot and I can confirm that the ECC hardware does operate exactly as specified. I won't discount the possibility of some sort of bug in the NAND driver implemented in u-boot, but so far you have not presented any evidence that supports that (in fact the register dump given indicates to me that correction of one bit error did take place).

    Regards, Daniel

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Hey Daniel,

    We fixed the problem!  Problem was in the device driver.  Please see the diffs below.  The wait loop NEVER waited!  The first value read is 0, so the loop IMMEDIATELY exits.  
    You might want to propagate these back to your code base to avoid issues like this in the future.

    BTW, any reason why the NAND controller hardware is so timing dependent???

    Thanks again for your help,
     Bill 

     

    $ diff -C 6 drivers/mtd/nand/davinci_nand.c_orig drivers/mtd/nand/davinci_nand.c

    *** drivers/mtd/nand/davinci_nand.c_orig        2011-10-03 19:05:36.057719111 -0700

    --- drivers/mtd/nand/davinci_nand.c     2011-10-07 15:46:49.511108969 -0700

    ***************

    *** 34,46 ****

       *  Overview:

       *   This is a device driver for the NAND flash device found on the

       *   DaVinci board which utilizes the Samsung k9k2g08 part.

       *

       Modifications:

       ver. 1.0: Feb 2005, Vinod/Sudhakar

    !  -

       *

       */

     

      #include <common.h>

      #include <asm/io.h>

      #include <nand.h>

    --- 34,49 ----

       *  Overview:

       *   This is a device driver for the NAND flash device found on the

       *   DaVinci board which utilizes the Samsung k9k2g08 part.

       *

       Modifications:

       ver. 1.0: Feb 2005, Vinod/Sudhakar

    !

    !  * Change Log

    !  * 10/7/2011  Altierre  Fixed do/while loop and added delan to

    !  *                            nand_davinci_4bit_correct_data

       *

       */

     

      #include <common.h>

      #include <asm/io.h>

      #include <nand.h>

    ***************

    *** 481,498 ****

             */

            i = NAND_TIMEOUT;

            do {

                    val = emif_regs->NANDFSR;

                    val &= 0xc00;

                    i--;

    !       } while ((i > 0) && val);

     

            iserror = emif_regs->NANDFSR;

            iserror &= EMIF_NANDFSR_ECC_STATE_MASK;

            iserror = iserror >> 8;

     

            /*

             * ECC_STATE_TOO_MANY_ERRS (0x1) means errors cannot be

             * corrected (five or more errors).  The number of errors

             * calculated (err_num field) differs from the number of errors

             * searched.  ECC_STATE_ERR_CORR_COMP_P (0x2) means error

             * correction complete (errors on bit 8 or 9).

    --- 484,505 ----

             */

            i = NAND_TIMEOUT;

            do {

                    val = emif_regs->NANDFSR;

                    val &= 0xc00;

                    i--;

    !       } while ((i > 0) && !val);

    !       // bgg orig } while ((i > 0) && (val > 0));

     

            iserror = emif_regs->NANDFSR;

            iserror &= EMIF_NANDFSR_ECC_STATE_MASK;

            iserror = iserror >> 8;

     

    +       // bgg - added delay, required unfortunately

    +       udelay(1000);

    +

            /*

             * ECC_STATE_TOO_MANY_ERRS (0x1) means errors cannot be

             * corrected (five or more errors).  The number of errors

             * calculated (err_num field) differs from the number of errors

             * searched.  ECC_STATE_ERR_CORR_COMP_P (0x2) means error

             * correction complete (errors on bit 8 or 9).

    $

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Daniel, 

    2 questions:

    Could you tell me if the following partitions are ECC corrected?  It looks like they're checked, however, it doesn't appear that if there ARE bit errors, they are corrected:

    partition 0: u-boot environment variables
    partition 1: UBL
    partition 2: U-Boot

    If not, could you possibly tell us how we might protect them?

    Second question, could you possibly point me to the code base to the latest code for mtd-utils/flash_unlock.c ?  In order to upgrade units in the field, we'll have to unlock the U-Boot partition then overwrite it.  For some reason, it isn't working..

    BTW, the above changes are definitely required to get the nand_davinci_4bit_correct_data() routine to correct bit errors.  I'm curious to know if anyone else has had this issue and can validate this fix.

    What's interesting to me is that this delay isn't required in the Linux ECC correction algorithm (nand_davinci_correct_4bit())  for some reason.  The algorithm is slightly different, however, no delay is used.  We also verified that bit errors do get fixed by the routine.

    Thanks,

     Bill

     

     

     

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Hi Daniel,

    First, we found answers to the above: 

    The following line in the below link confirms that 4 BIT ECC is supported in RBL.

    Unlike OMAP35x/AM35x devices, DM/OMAPL13x/C674x/AM1xxx doesn't have GPMC or ECC support in ROM bootloader firmware. These device's EMIF hardware supports detection and correction for most of the devices (the ROM bootloader uses EMIF HW to support ECC). details.

    http://processors.wiki.ti.com/index.php/Raw_NAND_ECC

    Further, we have seen in our tests that 40 spare area bytes (OOB) per page are being populated when UBL and UBOOT is written to flash.  It is the software driver that writes the 40 spare bytes in the OOB region. When driver is following the write procedure per datasheet of NAND CONTROLLER then it must be following the read procedure of datasheet.

     

    Now, we have a BIG problem we're hoping you could give us some insight into.  We noticed that you wrote the sfh_OMAP-L138.exe application.  We noticed that the ECC calculation does not match the ECC calculation used by the U-Boot or Linux NAND drivers - it must match what the RBL in the OMAP expects, correct?

    Our BIG problem is that we have several thousand Access Points in the field that need the U-Boot fix we mentioned above.  Since the OOB calculations are different, we can't write the new U-Boot.bin file through either U-Boot or Linux.  Do you have any suggestions on how we can upgrade the units in the field?

    Thanks, Bill

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill,

    There is a patch that I think addresses this issue:

    http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commitdiff;h=1075b07e2c67c1f504d9f3a6f1b9aaa8f81393b2

    This adds an extra loop to make sure the EMIF hardware enters into the correcting state before moving back into the finalized state (the added comment explains it all). I think this should be used instead of a delay loop.

    Regards, Daniel

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill Goetz said:
    Now, we have a BIG problem we're hoping you could give us some insight into.  We noticed that you wrote the sfh_OMAP-L138.exe application.  We noticed that the ECC calculation does not match the ECC calculation used by the U-Boot or Linux NAND drivers - it must match what the RBL in the OMAP expects, correct?
    Our BIG problem is that we have several thousand Access Points in the field that need the U-Boot fix we mentioned above.  Since the OOB calculations are different, we can't write the new U-Boot.bin file through either U-Boot or Linux.  Do you have any suggestions on how we can upgrade the units in the field?

    My best suggestion in these circumstances is to bypass the ECC usage in either Linux or u-boot and do raw writes to the NAND main data pages and the OOB areas. I think this is possible.  You can calculate the ECC parity info offline using the genecc program that is available as part of the boot and flash utilities package. The genecc program will generate the register values that the EMIF hardware would generate - you would have to take that data and format it as the ROM and UBL requires.

    That is my best suggestion for updating the early bootloader data.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Expert 1160 points

    Hi Daniel,

    First, thanks for the responses.  It's most appreciate.  So we actually did have that patch that you mentioned.  It just did not work at all.  Looking at the registers as well as the documentation on how the ECC correction works, we had to change that code to the following:

    The key problem in that fix is that only two of the four bits in ECC_STATE in the NANDFSR register are checked initially, so that the first loop is completely bypassed because the initial value is 0 (because the value is masked with 0xc00 not 0xf00).  Believe me, we have a dozen units ALL with a single bit error in the Linux kernel that failed to boot using that loop!  Loading the new U-Boot with the changes below, all of the APs with the bit error in the Linux partition booted right up.  BTW, you are right, the delay wasn't the way to go.  If you could, please get this into your code base!  I'd be more than happy to show you or an AE that that patch you mentioned doesn't work, but the code below does.  (We could have made the while condition more efficient, however, it's easier to understand as it is implemented below). 

    Regards, Bill

     

     

    ***************

    *** 475,494 ****

             */

            emif_regs->NANDFCR |= 1 << 13;

     

            /*

             * Wait for the corr_state field (bits 8 to 11)in the

             * NAND Flash Status register to be equal to 0x0, 0x1, 0x2, or 0x3.

             */

            i = NAND_TIMEOUT;

            do {

                    val = emif_regs->NANDFSR;

    !               val &= 0xc00;

                    i--;

    !       } while ((i > 0) && val);

     

            iserror = emif_regs->NANDFSR;

            iserror &= EMIF_NANDFSR_ECC_STATE_MASK;

            iserror = iserror >> 8;

     

            /*

             * ECC_STATE_TOO_MANY_ERRS (0x1) means errors cannot be

    --- 479,507 ----

             */

            emif_regs->NANDFCR |= 1 << 13;

     

            /*

             * Wait for the corr_state field (bits 8 to 11)in the

             * NAND Flash Status register to be equal to 0x0, 0x1, 0x2, or 0x3.

    +        *

    +        * Altierre: ECC_STATE starts out at 0 when masking out only bits 10 and 11,

    +        * so the following loop used to exit immediately which is not the correct behavior

             */

    +

            i = NAND_TIMEOUT;

            do {

                    val = emif_regs->NANDFSR;

    !               //val &= 0xc00;

    !               val &= 0xf00;

                    i--;

    !               //cpu_relax();

    !       // } while ((i > 0) && !val);

    !       } while ((i > 0) && ((val != 0x100) || (val != 0x200) || (val != 0x300)));

     

            iserror = emif_regs->NANDFSR;

            iserror &= EMIF_NANDFSR_ECC_STATE_MASK;

            iserror = iserror >> 8;

     

            /*

             * ECC_STATE_TOO_MANY_ERRS (0x1) means errors cannot be

     

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill,

    So I'm still confused about the patches you are showing. You seem to be converting a loop that checks for the state being equal to a value between 0x0 to 0x3 to one that checks that it is NOT equal to a value between 0x0 and 0x3.  The current source in the git repository looks like the following:

     /*
     487          * Wait for the corr_state field (bits 8 to 11) in the
     488          * NAND Flash Status register to be not equal to 0x0, 0x1, 0x2, or 0x3.
     489          * Otherwise ECC calculation has not even begun and the next loop might
     490          * fail because of a false positive!
     491          */
     492         i = NAND_TIMEOUT;
     493         do {
     494                 val = __raw_readl(&davinci_emif_regs->nandfsr);
     495                 val &= 0xc00;
     496                 i--;
     497         } while ((i > 0) && !val);
     498
     499         /*
     500          * Wait for the corr_state field (bits 8 to 11) in the
     501          * NAND Flash Status register to be equal to 0x0, 0x1, 0x2, or 0x3.
     502          */
     503         i = NAND_TIMEOUT;
     504         do {
     505                 val = __raw_readl(&davinci_emif_regs->nandfsr);
     506                 val &= 0xc00;
     507                 i--;
     508         } while ((i > 0) && val);
     509
     510         iserror = __raw_readl(&davinci_emif_regs->nandfsr);
     511         iserror &= EMIF_NANDFSR_ECC_STATE_MASK;
     512         iserror = iserror >> 8;

    The first loop will go until the state does not equal a value between 0x0 and 0x3 (we mask the lower two bits and wait for val to be non-zero (the !val condition), which would indicate the state has a value between 0x4 and 0xF).  So, even if the ECC state field was zero, the code should loop until the state transitions to something greater than or equal to 0x4 (which indicates the correction logic is underway).  In the second loop, the condition is changed to val (instead of !val), so that the loop should only exit when the ECC state has returned back to a value between 0x1 and 0x3 (a state of 0x0 should never happen, because we check for the "no errors" condition earlier in the code and will exit at that point).

    I would consider downloading the davinci_nand.c source from the head of the repo and diffing it with your original source and your modified source.  The source from the GIT repo with the two loops I copied above should work as I described.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Expert 1160 points

    Hey Daniel,

    Thanks again for your reply.  OK, THIS version of the routine you sent looks great (logically equivalent to ours..).  Unfortunately both of those loops were NOT there in the version of U-Boot we used originally..  We're still in the process of trying to figure out how to upgrade thousands of units in the field..  We'll keep you posted..

    Regards, Bill

     

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Hi Daniel,

    Below is the email I got requesting information as to where the git tree is for U-Boot.  The link points to a tree that does not have that fix in it (e.g. both do/while loops).  Could you kindly let us know where the correct U-Boot tree is for the OMAP L-138, with the fixed NAND driver?

    Much thanks,

     Bill

     

     

    Bill,

     

    Below from our PSP team. Let us know if this works.

     

    Thanks,

    Padmaja

     

    There is now a new U-Boot available which uses the same ECC/Bad block table positioning that is used by kernel. Can your customer update to the new release?

     

    The code is available here: http://arago-project.org/git/people/?p=sekhar/u-boot-omapl1.git

    He can use the tag: v2009.11_DAVINCIPSP_03.20.00.10

     

     

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Daniel,

    Help.....  We're trying to do something that theoretically seems doable, however, it isn't working and we can't figure out why.  In a nutshell, we are writing a new U-boot (with the NAND fix) into /dev/mtd6 from Linux using flash_eraseall /dev/mtd6; nandwrite -p /dev/mtd6 u-boot-new.bin.  Then, rebooting, stopping at U-Boot, manually loading it using 'nand read.e 0xc1180000 2400000 40000'.  Next, we do a 'go 0xc1180000' and it just doesn't start executing the code there.

    We also tried the same test writing the new U-Boot from U-Boot and the result is the same.

    In both cases, it seems to always start executing the original U-Boot, (then hangs).  Why is that???

    Our largest customer is asking us daily for status.

    Much thanks,

     Bill

     

     

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill,

    Is there anyway for you to confirm that the contents read back from the NAND with the "nand read.e" command match 100% with the what you programmed?  Instead of reading it from NAND, can you get the new u-boot binary into memory another way (serial download or TFTP) and then trying your go command?  Is the u-boot image compiled to execute from 0xc1180000?  What address is the currently executing u-boot running from?

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Expert 1160 points

    Hi Daniel,

    Unfortunately all of our installed access points are on ceilings with no serial port connection, only PoE.  Also, since each location may have a different tftp host, getting tftp to work in thousands of stores is, unfortunately, not practical.  That said, you asked "Is the u-boot image compiled to execute from 0xc1180000?  What address is the currently executing u-boot running from?"  Could you shed some light on how to specify that?  

    Also, if you don't mind, any tips on building UBL from Linux?  Looks like it currently setup to compile with Code Composer.  Any way we can compile it from Linux?  Didn't see it in the Makefile, nor does it seem to be one of the targets (confirmed that after running 'make all' there was no 'ubl_OMAPL138_NAND.bin' file in the tree).

    Much thanks, Bill

     

    #==============================================================================

    # Build everything rebuildable.

    #==============================================================================

    all: components u-boot psp_examples ceexamples audio_soc_example c6run_examples matrix dsp_benchmark gstreamer_ti

     

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Hi Daniel,

    You commented "My best suggestion in these circumstances is to bypass the ECC usage in either Linux or u-boot and do raw writes to the NAND main data pages and the OOB areas. I think this is possible".

    Is there any chance you might have a code example for this?

    Much thanks, Bill

     

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Daniel,

    We're trying to get the U-Boot 'go' command to work but aren't having much luck.  It looks like address of where it loads in DRAM is somehow part of the image (or image header).  What kind of binary image is the 'go' command expecting?  We desperately are in need of a solution.

    Thanks, Bill

     

  • 0 in reply to Bill Goetz
    Expert 1160 points

    Daniel,

    We just need to know how to change the load address for a u-boot standalone application that can be executed with the 'go' command.  Any clues?

    thanks, Bill

     

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill,

    Sorry for the neglect here.  I'm looking into this, but I definitely think this is your issue with running a new version of u-boot.  By default it is statically linked to run at 0xC1080000.  If you want to load a new one inside of u-boot and then jump into it with the go command, you will have to statically link it to run from that new load address (0xC1180000 in your case).  Unfortunately, it's not entirely clear to me how that address is determined.  It looks like this value is configured in the boards/davinci/da8xxevm/config.mk file (the TEXT_BASE variable).  I'm not sure if there might be some variables that also might need to be modified in the include/configs/da850evm.h file.

    Also, reading the u-boot docs on the go command, I'm not entirely sure if this will work, but it certainly is worth a shot.

    Regards, Daniel

  • 0 in reply to Bill Goetz
    TI__Genius 17355 points

    Bill Goetz said:

    Hi Daniel,

    You commented "My best suggestion in these circumstances is to bypass the ECC usage in either Linux or u-boot and do raw writes to the NAND main data pages and the OOB areas. I think this is possible".

    Is there any chance you might have a code example for this?

    Much thanks, Bill

     

    Bill,

    It looks like the nandwrite utility of the mtd-utils package can write OOB data.  I'll be honest that I've never tried it, but I suspect it probably works the way it is documented in the source (in the display_help function):

    http://git.infradead.org/mtd-utils.git/blob/HEAD:/nandwrite.c

    Regards, Daniel