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.

Booting OMAP3530 from 8-bit NAND

Other Parts Discussed in Thread: OMAP3530

I am trying to get a new board to boot from 8-bit nand.  I can boot the board via jtag by loading x-loader.  X-loader then finds u-boot in flash and boots fine.  The board is very similar to the OMAP3 EVM with the exception that the nand is different.  It is an 8-bit part.  The id is listed as supported in the TRM.  I have used a JTAG  debugger to step through the low-level booting and I see it read the ID and compare it to several entries in a list and eventually find the part.  I trap on accesses to the NAND data port and see it reads the first 16 32-bit words out of the nand.  It then goes on and trys the next NAND page which has nothing in it.

Any ideas why it would no be happy with the data it finds in the first page?  Here is the data, (this same image works on the evm) as displayed by nand dump in u-boot.

 38 4e 00 00 00 08 20 40  12 00 00 ea 14 f0 9f e5
 10 f0 9f e5 0c f0 9f e5  08 f0 9f e5 04 f0 9f e5
 00 f0 9f e5 04 f0 1f e5  60 09 20 40 78 56 34 12
 78 56 34 12 78 56 34 12  78 56 34 12 78 56 34 12

I used nandecc hw to write the x-loader image to nand so I know it is not an ecc problem.  Also it cannot be an ecc problem because it never reads a full 512 bytes.

I also tried adding a config section to the front using a different signing program that I found here

http://nishanthmenon.blogspot.com/2009/05/configuration-header-no-more-x-loader.html

and it does the same thing (reads 16 4byte words then gives up).

Thanks for any ideas.

 

 

 

  • It probably is an ECC issue.  There is something different in the ECC between 8-bit and 16-bit NAND.  I cannot remember if it is where it is stored or how it is calculated.  You would need to modify the hw ecc code in u-boot to support 8-bit; currently I think it only supports 16-bit.

    Steve K.

  • It only reads 64 bytes (not enough to calculate an ecc) and it never looks at the oob area so I don't believe it is an ecc issue.

  • John Rigby said:

    It only reads 64 bytes (not enough to calculate an ecc) and it never looks at the oob area so I don't believe it is an ecc issue.

    Which is this u-boot - can you point to the source? mainline u-boot should not mess around like this.. this definitely sounds like a bootloader issue -> nand dump should dump the entire first page. nand info gives anything useful?

  • You are correct, it is an internal rom loader issue.  X-loader and u-boot work fine.  I used CCS to load x-loader and u-boot then used u-boot to write x-loader and u-boot to nand.  I can now load x-loader with CCS and it finds u-boot at offset 0x80000 in nand and loads it.  The problem is getting the internal rom loader to load xloader.  The internal rom loader reads the first 16 words (64 bytes) and then gives up. This is the same exact image that works fine on an evm board with 16-bit NAND.  I verified that the values the rom loader reads from NAND are correct by trapping all NAND data reads in my jtag debugger.  It is behaving like a version of the chip with security enabled would act with an image that is not properly signed.

    I don't think it is an ecc problem because:

    I used nandecc hw in u-boot to write x-loader to nand with hw ecc.

    Only 64 bytes are read and hw ecc is over 512 bytes.

    I have monitored writes to the NAND command register and no READOOB has been issued so no attempt has been made to read the ecc in the OOB area.

    I also tried signing the image with your new program that adds configuration header stuff and the result was the same, the internal boot loader read 16 words and then gave up.

    One thing I did notice is that my x-loader is linked to 40200800 and I have seen others that are linked at 40508800.  Could that be a problem?  I know 40200800 works fine for the version of the processor that is on my evm board.

    Is it possible that I have a chip that has security enabled?  How do I determine if that is the case?  I realize that this is unlikely but I'm trying to eliminate all possibilities.

    Thansk for your help.

  • Sorry, there is a typo in the last message.  The two addresses I have seen for x-loader are 0x40200800 and 0x40208800.

  • Here is how i get x-loader flashed:

    a)in x-loader -> cat System.map |grep -w _start
    40200800 T _start
    b) i use gpsign as part of omap-uboot-utils to sign and generate an ift file.. e.g:

    x:~/Src/opensource/xloader$ cat System.map |grep -w _start|cut -d ' ' -f1 | xargs ../omap-u-boot-utils/gpsign -l
    or i could do:

    x:~/Src/opensource/xloader$  ../omap-u-boot-utils/gpsign -l 40200800 -f x-load.bin

    c) then flash the x-load.bin.ift to 0x0 using nandecc hw or nand ecc hw (based on the revision of u-boot you are using)..

    to confirm that I signed properly, i do the following:

    x:~/Src/opensource/xloader$ hexdump x-load.bin |head -20
    0000000 0012 ea00 f014 e59f f010 e59f f00c e59f
    0000010 f008 e59f f004 e59f f000 e59f f004 e51f
    0000020 0960 4020 5678 1234 5678 1234 5678 1234
    0000030 5678 1234 5678 1234 5678 1234 5678 1234
    0000040 0800 4020 0800 4020 57a0 4020 8894 4020
    0000050 0000 e10f 001f e3c0 00d3 e380 f000 e129
    0000060 0068 e24f 0004 e280 2040 e3a0 2002 e080
    0000070 1101 e3a0 3602 e3a0 1003 e081 3b3e e3a0
    0000080 1003 e081 07f8 e8b0 07f8 e8a1 0002 e150
    0000090 fffb 1aff 003a eb00 0017 eb00 00a4 e24f
    00000a0 1068 e51f 0001 e150 0007 0a00 2070 e51f
    00000b0 3070 e51f 2002 e043 2002 e080 07f8 e8b0
    00000c0 07f8 e8a1 0002 e150 fffb daff 0094 e51f
    00000d0 d080 e240 d007 e3cd 0098 e51f 1098 e51f
    00000e0 2000 e3a0 2000 e580 0001 e150 0004 e280
    00000f0 fffb 1aff f004 e51f 1ee8 4020 0000 e3a0
    0000100 0f17 ee08 0f35 ee07 c001 e3a0 0070 e160
    0000110 0f10 ee11 0a02 e3c0 0007 e3c0 0002 e380
    0000120 0b06 e380 0f10 ee01 0e13 e24f 10f4 e51f
    0000130 0001 e150 0001 03a0 0000 13a0 c00e e1a0
    x:~/Src/opensource/xloader$ hexdump x-load.bin.ift |head -20
    0000000 4fa0 0000 0800 4020 0012 ea00 f014 e59f
    0000010 f010 e59f f00c e59f f008
    e59f f004 e59f
    0000020 f000 e59f f004 e51f 0960 4020 5678 1234
    0000030 5678 1234 5678 1234 5678 1234 5678 1234
    0000040 5678 1234 5678 1234 0800 4020 0800 4020
    0000050 57a0 4020 8894 4020 0000 e10f 001f e3c0
    0000060 00d3 e380 f000 e129 0068 e24f 0004 e280
    0000070 2040 e3a0 2002 e080 1101 e3a0 3602 e3a0
    0000080 1003 e081 3b3e e3a0 1003 e081 07f8 e8b0
    0000090 07f8 e8a1 0002 e150 fffb 1aff 003a eb00
    00000a0 0017 eb00 00a4 e24f 1068 e51f 0001 e150
    00000b0 0007 0a00 2070 e51f 3070 e51f 2002 e043
    00000c0 2002 e080 07f8 e8b0 07f8 e8a1 0002 e150
    00000d0 fffb daff 0094 e51f d080 e240 d007 e3cd
    00000e0 0098 e51f 1098 e51f 2000 e3a0 2000 e580
    00000f0 0001 e150 0004 e280 fffb 1aff f004 e51f
    0000100 1ee8 4020 0000 e3a0 0f17 ee08 0f35 ee07
    0000110 c001 e3a0 0070 e160 0f10 ee11 0a02 e3c0
    0000120 0007 e3c0 0002 e380 0b06 e380 0f10 ee01
    0000130 0e13 e24f 10f4 e51f 0001 e150 0001 03a0

    see how the loadaddress and the actual binaries are organized, once i flash, i'd do a nand dump 0 and compare it with x-load.bin.ift -> esp the ecc values stored.. if they are similar, then it should boot..

     

    one more thing to confirm is my "nand no boot checklist" i had compiled sometime back here.

  • I don't believe the problem is in how I create my ift image.  It is identical to yours.  And recall I said that the same exact image works on evm with 16 bit nand.

    Here is a hexdump of my ift file:

    [jrigby@jrigby-laptop x-loader (master)]$ hexdump x-load.bin.ift | head -20
    0000000 4e38 0000 0800 4020 0012 ea00 f014 e59f
    0000010 f010 e59f f00c e59f f008
    e59f f004 e59f
    0000020 f000 e59f f004 e51f 0960 4020 5678 1234
    0000030 5678 1234 5678 1234 5678 1234 5678 1234
    0000040 5678 1234 5678 1234 0800 4020 0800 4020
    0000050 5638 4020 872c 4020 0000 e10f 001f e3c0
    0000060 00d3 e380 f000 e129 0068 e24f 0004 e280
    0000070 2040 e3a0 2002 e080 1101 e3a0 3602 e3a0
    0000080 1003 e081 3b3e e3a0 1003 e081 07f8 e8b0
    0000090 07f8 e8a1 0002 e150 fffb 1aff 003a eb00
    00000a0 0017 eb00 00a4 e24f 1068 e51f 0001 e150
    00000b0 0007 0a00 2070 e51f 3070 e51f 2002 e043

    Identical to yours.

    And here is a portion of the output of nand dump in u-boot:

    OMAP3_BADGER # nand dump 0             
    Page 00000000 dump:                    
            38 4e 00 00 00 08 20 40  12 00 00 ea 14 f0 9f e5
            10 f0 9f e5 0c f0 9f e5  08 f0
    9f e5 04 f0 9f e5
            00 f0 9f e5 04 f0 1f e5  60 09 20 40 78 56 34 12
            78 56 34 12 78 56 34 12  78 56 34 12 78 56 34 12
            78 56 34 12 78 56 34 12  00 08 20 40 00 08 20 40
            38 56 20 40 2c 87 20 40  00 00 0f e1 1f 00 c0 e3
            d3 00 80 e3 00 f0 29 e1  68 00 4f e2 04 00 80 e2
            40 20 a0 e3 02 20 80 e0  01 11 a0 e3 02 36 a0 e3
            03 10 81 e0 3e 3b a0 e3  03 10 81 e0 f8 07 b0 e8

    And here it is in memory after reading it with nand read 0x82000000 0 800

    OMAP3_BADGER # md 82000000
    82000000: 00004e38 40200800 ea000012 e59ff014    8N.... @........
    82000010: e59ff010 e59ff00c e59ff008 e59ff004    ................
    82000020: e59ff000 e51ff004 40200960 12345678    ........`. @xV4.
    82000030: 12345678 12345678 12345678 12345678    xV4.xV4.xV4.xV4.
    82000040: 12345678 12345678 40200800 40200800    xV4.xV4... @.. @

    I can't show you screen shots but I have verified in Code Composer Studio that these are the values that are read out of nand at boot time.  As I said before I trap all nand data reads with a hw watchpoint.

    On my previous question about the chip having security features enabled, I see in a control register that the platform type is 3 which the manual says is GP aka not secure.

    The only thing I can think of is that the rom boot loader expects a different format header for 8-bit nand.  Without reverse engineering the rom boot loader, I'm not sure how to determine why this image is bad.

    Thanks again for your help.

  • from http://nishanthmenon.blogspot.com/2009/02/nand-not-booting-on-new-omap3-board.html

    The following check list was compiled based on a discussion here
    a) Did you check if the device id of the device is in TRM under
    supported devices? -> ROM Code should support this device if it should ever boot..
    b) Did you read your CTRL_STATUS register and verify the SYSBOOT boot sequence in TRM -> is NAND in the sequence and nothing else preventing it from being hit?
    c) what is the status of your EMU0-1 JTAG pins are they both high or in tristate condition during OMAP boot? -> the wrong setting would prevent boot sequence from being executed
    d) is it on CS0? -> well OMAP boots out of CS0
    e) Do you have an 8 bit or a 16 bit NAND? is your config file in
    x-loader, u-boot handling this correctly? -> accessing wrong width is not very helpful.. ;)
    f) Did you sign x-loader.bin.ift with signGP.c? Try this in x-loader
    directory: grep _start System.map|cut -d' ' -f1|xargs signGP x-load.bin -> x-loader loads up at the address we tell it to, few variants of x-loaders seem to use different base addresses.. just to be sure..sign the x-loader correctly
    g) Finally did you use nandecc hw for flashing x-loader.bin.ift? - well.. that is the only ECC formatting that OMAP ROM Code understands..
    h) what is the result of nand dump 0? the OOB area? - this verifies the ECC organization
    i) you could in theory write a very small piece of assembly to shut down watchdog timer, and basically loop for ever -> flash this instead of x-loader then once the board boots up, connect with JTAG and see if your infinite loop is running in SRAM.. if so, you have your flashing correct, but mebbe x-loader is goofing up somewhere..
    -> this is just my fav way of debug..

     

    btw, 8bit NAND is what SDP3430 uses and it works pretty fine.. 3530 and 3430 share the same NAND device.

  • I have gone through this list already with nothing obviously wrong.  Thanks anyway.

  • Two more questions: What version of u-boot do you have and does it support 8-bit NAND? I think older u-boots did not support 8-bit and needed support added.  One change I remember is that there is a bit in the GPMC_ECC_CONFIG register that is either set or unset depending on 8-bit vs. 16-bit NAND.  If your u-boot is always setting 16-bit, then the ECC written would be incorrect.  I found this bit of code in board/omap3evm/nand.c

                    case NAND_ECC_WRITE   :
                            __raw_writel(0x101, GPMC_BASE + GPMC_ECC_CONTROL);
                            /* ECC col width) | ( CS )  | ECC Enable */
                            val = (dev_width << 7) | (cs << 1) | (0x1) ;
                            break;


    Steve K.

  • I don't think the issue I have right now is this but it may be if I ever get past the problem I have right now.  As I said before, I watch all accesses to the NAND data register and the internal boot code only pulls out 16 long words before failing.  You need 512 bytes to calculate an ecc.  Also a READOOB command is never issued so it has not read an ecc value to do a compare.

  • To give some description as to what is happening, please reference Section 25 of the OMAP3530 Technical Reference Manual (SPRUF98) which discusses the boot initialization procedures.

    Specifically, Section 25.4.7.4 discusses NAND booting.  I suspect the accesses you are seeing is the device identification portion of the flow chart illustrated in Figure 25-16.

  • I see the device id accesses earlier.  It reads a device id of 0xDC and manufacturer id of 0x20 which are correct.  I then seed it go into a loop comparing the 0xDC value to a list of known values.  It finds a match and goes on.

    Later it reads 16 32bit values which I have verifies are the first 16 32bit words in flash.

  • I am also facing the same problem with the same interface i.e. 8 bit NAND connected to OMAP3530 with page size 2048 bytes. The device ID is in the supported list of ROM. I am not getting it boot from NAND not even a single byte is copied from nand. I am flashing x-loader(.ift) and u-boot.bin using u-boot1.1.4 in MMC boot mode.after nand boot fails it is going to mmc boot and fetches x-loader from card and u-boot from nand.I am enabling nand ecc hw while flashing x-loader and nand ecc sw for u-boot. I dont think its an ecc issue because present code in u-boot shown below is for enabling haming ecc algo for 8 bit and calculating 3 bytes for 512 sector which is what ROM code understands.

    calculate_ecc{   reg = (unsigned long)(GPMC_BASE + GPMC_ECC1_RESULT);  
    val = __raw_readl(reg);
    *ecc_code++ = ECC_P1_128_E(val);
    *ecc_code++ = ECC_P1_128_O(val);
    *ecc_code++ = ECC_P512_2048_E(val) | ECC_P512_2048_O(val) << 4;}

    enable_hwecc{        case NAND_ECC_WRITE   :
                __raw_writel(0x101, GPMC_BASE + GPMC_ECC_CONTROL);
                /* ECC col width) | ( CS )  | ECC Enable */
                val = (dev_width << 7) | (cs << 1) | (0x1) ;
                break;}

    Is this algo is wrong or it is some other issue.

     

  • My problem truned out to be a hw issue.  The busy signal from the nand was not connected to the GPMC_WAIT0 signal on the OMAP so when the ROM code goes into a wait loop waiting for a nand complete interupt it times out and never actually reads any blocks.

    The 16 reads I observed earlier where part of an mlc block detect routine.