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.

boot wince 7 from nandflash problem in AM3352, urgently, thanks

Other Parts Discussed in Thread: AM3352

 

I am confused by a problem(our CPU board is based on beaglebone and add a nandflash to it, BSP from TI and run W7EC):

1, some board (about 10units) in our products boot from Nandflash(the boot pin are configured: SYSBOOT[4:0]: 10011b ,boot order: NAND->NANDI2C->MMC0->UART0 ),the OS can not start up successfully. I can see CCCCC(it mean that it can not find SD card) in the Hypertrm.

 

2, I think may be the boot configure pin is wrong, but I check their voltage, they are right, and the board are products, they are impossible wrong because they booted from nandflash successfully some days ago.

 

3,So I insert a SD card with eboot and NK into the board. I see that:

(1)  waiting about 10seconds;

(2)  the screen display a picture from eboot in SD card, but it not load NK from SD card;

(3)  then it show a picture from eboot in NANDfalsh, and load NK from nandflash;

 

4, it means that only when I insert a SD card with eboot and NK into the board, the board can boot from nandflash successfully, or it will only show CCCCCC in Hypertrm.

 

5, So I compared the information from Hypertrm

(1)   the board which can boot from nandflash normally, the Hypertrm will show that:

Texas Instruments Windows CE EBOOT for AM33x, Built Feb 16 2013 at 14:50:51

EBOOT Version 0.0.1, BSP BSP_WINCE_ARM_A8 02.30.00.01

 

TI AM33X

 

ecc type:3

System ready!

Preparing for download...

INFO: Predownload....

Checking bootloader blocks are marked as reserved (Num = 18)

 

BOOT_CFG_SIGNATURE is different, read 0, expect 1111705159

WARN: Boot config wasn't found, using defaults

INFO: SW3 boot setting: 0x13

IsValidMBR: MBR sector = 0x480 (valid MBR)

OpenPartition: Partition Exists=0x1 for part 0x20.

8c30a0c8 fa43 -> c8 a0 30 8c 43 fa

8c30a0c8 fb43 -> c8 a0 30 8c 43 fb

OALFlashStoreOpen: 2048 blocks, 64 sectors/block

OALFlashStoreOpen: 2048 bytes/sector, 18 reserved blocks

 

Load NK image from flash memory

……

(2)  The  board which boot from nandflash with the help of eboot in SD card, the Hypertrm will show that:

TI AM33X

 

ecc type:3

System ready!

Preparing for download...

INFO: Predownload....

Checking bootloader blocks are marked as reserved (Num = 18)

 

BOOT_CFG_SIGNATURE is different, read -1, expect 1111705159

WARN: Boot config wasn't found, using defaults

INFO: SW3 boot setting: 0x13

IsValidMBR: MBR sector = 0x480 (valid MBR)

OpenPartition: Partition Exists=0x1 for part 0x20.

cb296abc 560d -> bc 6a 29 cb d 56

cb296abc 570d -> bc 6a 29 cb d 57

Hit space to enter configuration menu [40] 5...

Hit space to enter configuration menu [1040] 4...

Hit space to enter configuration menu [2040] 3...

Hit space to enter configuration menu [3040] 2...

Hit space to enter configuration menu [4040] 1...

Init HW: controller RST

SDCARD: requested speed 1000000, actual speed 1000000

SDCARD: requested speed 25000000, actual speed 19200000

OALFlashStoreOpen: 2048 blocks, 64 sectors/block

OALFlashStoreOpen: 2048 bytes/sector, 18 reserved blocks

 

Load NK image from flash memory

……

6,We can see that:

(1)  the problem board need to boot from SD then boot from Nandflash, Why?

(2)  The problem board debug information show that

BOOT_CFG_SIGNATURE is different, read -1, expect 1111705159

(3)   The normal board debug information show that:

BOOT_CFG_SIGNATURE is different, read 0, expect 1111705159

(4)What’s its mean and why?

 

  • David,

    The CCCCC output indicates that the CPU was unable to locate/load XLDR from NAND and is instead trying peripheral booting, UART0 presumably in this case.

    First off you should check that the flash contents are as expected. Use the Eboot menu option "Dump flash sector" to inspect sector 0. It should contain a header consisting of two 32-bit words, the first one specifying the length of the XLDR image and the second one the destination address. The raw XLDR image should follow immediately afterwards.

    I would guess that a BOOT_CFG_SIGNATURE of -1 means that the flash block in question might have been erased (or never been programmed).

  • Hi, 

         Thanks very much for your help.

          i have check the sector 0 by"Dump flash sector", i find the content of flash in problem board and normal board is very different, let me show you:

    1, the content of flash in normal board:

    Sector 0 (sector 0 in block 0)
    Reserved1: 00000000 OEMReserved: fc Bad: 48 Reserved2: ff00
    0000  f8 4f 01 00 00 10 2f 40 fe 03 00 ea ff ff ff ff  .O..../@........
    0010  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    0020  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    0030  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    0040  ff ff ff ff ff ff ff ff 45 43 45 43 64 8f 2f 40  ........ECECd./@
    0050  64 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00  d...............
    0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
     ................
    07d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    07e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    07f0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0000  ff ff ac 96 db 77 c8 74 b9 2a 13 ad f0 45 8c ff
    0010  00 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00
    0020  00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 00
    0030  00 00 00 00 00 00 00 00 00 ff 00 00 00 00 00 fc

    2, the content of flash in problem board:

    Sector 0 (sector 0 in block 0)
    Reserved1: 00000000 OEMReserved: fc Bad: 00 Reserved2: ff00
    0000  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    0010  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    0020  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    0030  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    …………… some 0xff in here

    07c0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    07d0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    07e0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    07f0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
    0000  ff ff 10 ae d1 f6 12 6c 65 3d 68 86 1a db 4a ff
    0010  10 ae d1 f6 12 6c 65 3d 68 86 1a db 4a ff 10 ae
    0020  d1 f6 12 6c 65 3d 68 86 1a db 4a ff 10 ae d1 f6
    0030  12 6c 65 3d 68 86 1a db 4a ff 00 00 00 00 00

    3, i find the content in every  problem is the same ,there is some 0xff in the sector0, May be you are right, it has not been program or erased.

    4,But i program it by the raw file in SD card,  the problem is the same and the content is the same.

    5,Why? and What can i do to solute this problem?

     

    Thanks very much

  • Hi David,

    The header (size and destination) is missing on the problem board, which could be the reason that the board is not starting up.

    The AM3352 checks four different locations in flash for the presence of a header, at addresses 0, 128 KB, 256 KB and 384 KB, so if there's a valid header (and XLDR image) in just one of these four locations, the board should still be able to boot up. So just to be sure you should examine the contents of the first sector in each of the other three areas as well.

    Another thing I notice is the bad block marker, which appears to be 0 for the problem board (reverse logic - 0 indicates a bad block, 0xff a good block). I would suggest looking at the first sector in a number of blocks (including XLDR and Eboot), just to see if sector 0 being bad is just a coincidence of if there's a problem somewhere causing blocks to get marked as bad by mistake.

    Why this happens? Difficult to say without more information.

    Have these boards started up successfully in the past? If not, then I'd suspect an issue with the flash programming routines (have you modified these in any way?) Do you program XLDR into all four locations searched by the CPU, or just the first one?

    If the boards did start up initially and then developed this fault, well, I would suspect the WinCE FMD / flash driver, which should be the only one writing to flash once the board is up and running. In particular you need to ensure that all flash blocks not intended to be used by the CE flash driver are marked as reserved.

    You mention that 10 units are showing this error, but what is the error rate - how many have you produced in total up to this point?