• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 4494 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

can not boot our AM5728 based custom board from NAND

krinali shah
Expert 1290 points
Other Parts Discussed in Thread: AM5728

Hi All,


we have interfaced 8-bit NAND (part no- MT29F2G08ABAEAWP:E TR) with our AM5728 based board.
We are able to read/write to NAND (when booted from sd boot), but as soon as we try to boot the board from NAND it fails.
Board gets hang as soon as it boots from NAND.
We have taken the reference of NAND configurations from AM335x evm file, and made settings accordingly for our board.

/* NAND: device related configs */
#define CONFIG_NAND_OMAP_GPMC
#ifndef CONFIG_SYS_NAND_BASE
#define CONFIG_SYS_NAND_BASE            0x8000000
#endif
#define CONFIG_SYS_MAX_NAND_DEVICE      1
#define CONFIG_CMD_NAND

#define CONFIG_SYS_NAND_PAGE_SIZE       2048
#define CONFIG_SYS_NAND_OOBSIZE         64
#define CONFIG_SYS_NAND_BLOCK_SIZE      (128*1024)
#define CONFIG_SYS_NAND_PAGE_COUNT      (CONFIG_SYS_NAND_BLOCK_SIZE / \
                                         CONFIG_SYS_NAND_PAGE_SIZE)
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
/* NAND: driver related configs */
#define CONFIG_NAND_OMAP_GPMC
#define CONFIG_NAND_OMAP_GPMC_PREFETCH
#define CONFIG_NAND_OMAP_ELM
#define CONFIG_SYS_NAND_ONFI_DETECTION
#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW
#define CONFIG_SYS_NAND_BAD_BLOCK_POS   NAND_LARGE_BADBLOCK_POS
#define CONFIG_SYS_NAND_ECCPOS          { 2, 3, 4, 5, 6, 7, 8, 9, \
                                         10, 11, 12, 13, 14, 15, 16, 17, \
                                         18, 19, 20, 21, 22, 23, 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, }
#define CONFIG_SYS_NAND_ECCSIZE         512
#define CONFIG_SYS_NAND_ECCBYTES        14
#define MTDIDS_DEFAULT                  "nand0=nand.0"
#define MTDPARTS_DEFAULT                "mtdparts=nand.0:" \
                                        "128k(NAND.SPL)," \
                                        "128k(NAND.SPL.backup1)," \
                                        "128k(NAND.SPL.backup2)," \
                                        "128k(NAND.SPL.backup3)," \
                                        "256k(NAND.u-boot-spl-os)," \
                                        "1m(NAND.u-boot)," \
                                        "128k(NAND.u-boot-env)," \
                                        "128k(NAND.u-boot-env.backup1)," \
                                        "8m(NAND.kernel)," \
                                        "-(NAND.file-system)"

#define CONFIG_SYS_NAND_U_BOOT_OFFS     0x000C0000
/* NAND: SPL related configs */
#ifdef CONFIG_SPL_NAND_SUPPORT
#define CONFIG_SPL_NAND_AM33XX_BCH
#endif
#define NANDARGS \
        "mtdids=" MTDIDS_DEFAULT "\0" \
        "mtdparts=" MTDPARTS_DEFAULT "\0" \
        "nandargs=setenv bootargs console=${console} " \
                "${optargs} " \
                "root=${nandroot} " \
                "rootfstype=${nandrootfstype}\0" \
        "nandroot=ubi0:rootfs rw ubi.mtd=NAND.file-system,2048\0" \
        "nandrootfstype=ubifs rootwait=1\0" \
        "nandboot=echo Booting from nand ...; " \
                "run nandargs; " \
                "nand read ${fdtaddr} NAND.u-boot-spl-os; " \
                "nand read ${loadaddr} NAND.kernel; " \
                "bootz ${loadaddr} - ${fdtaddr}\0"
#define NANDBOOT                        "run nandboot; "


we have also added gpmc_init function from our board.c file,

int board_init(void)
{
        gpmc_init();

}

After this addition we are compiling the source code and flash spl/u-boot-spl.bin and u-boot.bin files to NAND using below files,

mw.b 0x81000000 0xFF 0x20000
tftp 0x81000000 G3Z_AM57xx/u-boot-spl.bin
nand erase 0x0 0x20000
nand write.i 0x81000000 0x0 0x20000

mw.b 0x81000000 0xFF 0x100000
tftp 0x81000000 G3Z_AM57xx/u-boot.img
nand erase 0x0C0000 0x100000
nand write.i 0x81000000 0x000C0000 0x100000

Do we need to flash any other files or this two are the correct one?

Please suggest us some solution/ debug approach on this one.


Thanks,
Krinali Shah

  • 0 in reply to Biser Gatchev-XID
    TI__Guru*** 125430 points
    Have you connected with JTAG? Where is the PC? Have you checked the tracing vectors from the ROM code to see what has happened? Is it ever making it to u-boot-spl or does the ROM not even succeed in loading u-boot-spl?
  • 0 in reply to Brad Griffis
    Expert 1290 points

    Hi Biser, Brad,

    Thanks for the reply.

    As per Biser's provided guidelines we flashed MLO and u-boot.img using nand write only.

    But there is no response after that also. One thing we could notice here is, MLO image does not have valid GP header. Going through section "33.3.8 Image Format"  from AM572x's TRM, we observed that it is a mandatory header for non-XIP booting devices. Unless ROM code will not get valid image header, it will not execute the rest of the code properly.

    I believe there should be some different compilation steps to generate NAND-spl images, which contain GP headers on compilation itself.

    Please provide some guidelines on this.

    Thanks,

    Krinali Shah

  • 0 in reply to krinali shah
    Expert 1290 points

    Hi Brad,

    We have traced vector of ROM code, as you have suggested and below is the output of our register dump.

    The value of Tracing vector-1 register in NAND boot mode is as below,

    1000000001111111

    Bit               value                                        Description

    0                     1                                                             Passed the public reset vector

    1                     1                                                             Entered main function

    2                     1                                                             Running after the cold reset

    3                     1                                                             Main booting routine entered

    4                     1                                                             Memory booting started

    5                     1                                                             Peripheral booting started

    6                     1                                                             Booting loop reached last device

    7                     0                                                             GP header found (ideally this bit should be 1)

    15                   1                                                             Peripheral booting failed

    From the dump we could see that GP Header found bit is 0, which means GP header is not found.

    When we flash this same MLO file, in SD card, our board boots successfully from SD.

    It seems that there is some issue in data writing to NAND.

    Can some one guide us further on this?

    Thanks,

    Krinali Shah

  • 0 in reply to krinali shah
    TI__Expert 3480 points

    So, what is the size of the actual image when you did the nand write?

    I'm a little bothered by the fact that when you did this; you said :

    "We have taken the reference of NAND configurations from AM335x evm file, and made settings accordingly for our board."

    So... why didn't you start with the AM572x EVM NAND config file?  I'm not sure this is really at issue yet; however, in the past when issues like this have happened it's been because the size was wrong, as per this.

    e2e.ti.com/.../289070

    So can you tell me what size image you were copying that now has the wrong header?  And I might suggest a diff between the AM572x NAND config and the AM335x one, because that does seem a tad suspect.

  • 0 in reply to radar
    Expert 1290 points
    Hi radar,

    thanks for your response.
    We took reference of NAND configurations like ECC, page size etc. from AM335x's evm. Because we use the NAND part with similar configurations like page size, oob size, etc.
    In AM572x-evm, they do not have support for NAND flash, so we can not use that one.

    Thanks,
    Krinali Shah
  • 0
    TI__Guru*** 125430 points

    krinali shah said:
    mw.b 0x81000000 0xFF 0x20000
    tftp 0x81000000 G3Z_AM57xx/u-boot-spl.bin
    nand erase 0x0 0x20000
    nand write.i 0x81000000 0x0 0x20000

    Why are you using u-boot-spl.bin instead of MLO?  The only difference between the two is that MLO contains the GP header, which is the error you're seeing.

  • 0 in reply to Brad Griffis
    Expert 1290 points
    Hi Brad,

    That we were using previously.
    But after Biser's suggestion we flash MLO to NAND flash only.
    Still we get same error.
    The same MLO image works with sd card, but when we write that image to NAND flash, it can not find gp header and board gets hanged.

    Thanks,
    Krinali Shah
  • 0 in reply to krinali shah
    TI__Guru*** 125430 points

    krinali shah said:
    That we were using previously.
    But after Biser's suggestion we flash MLO to NAND flash only.
    Still we get same error.
    The same MLO image works with sd card, but when we write that image to NAND flash, it can not find gp header and board gets hanged.

    Are you sure that the ROM was not finding the GP header even in the case where you were flashing MLO?  Did you look at the tracing vectors in that scenario too?  The first step will simply be getting an image that is formatted appropriately such that the ROM will actually copy it to internal memory.  Once that part is working we can start looking at the actual code.

  • 0 in reply to Brad Griffis
    Expert 1290 points
    Yes Brad.
    I am sure that even after writing MLO image to NAND flash, ROM vector stops at GP header not found.
    The register dump stated above is of MLO flashing only.

    We also tried to flash the NAND from file system, instead of flashing it from u-boot. Still we are facing same error.

    Thanks,
    Krinali Shah
  • 0 in reply to krinali shah
    TI__Expert 3480 points

    Okay; so we would seem to me we are at one of two things- either MLO is formatted wrong or the NAND is completely misconfigured and thus not written correctly. To at least eliminate one of those; are you able to open the MLO file in a hex editor and verify the header is indeed there?  I can't imagine it wouldn't be; but let's make sure.

  • 0 in reply to krinali shah
    TI__Expert 3480 points
    Can you also post the part number for the NAND you are using?
  • 0 in reply to radar
    TI__Mastermind 26025 points

    Got more details from "radar"

    So the latest I have on this that I see the command getting strobed to the NAND on boot; but no read; as per the attached.  This is all executing from boot ROM… so if the boot ROM doesn’t try to read the NAND….not so clear to me it can make the assessment that the MLO header is wrong.   Doesn’t it HAVE to try to do a read?  All I see is a command…

  • 0 in reply to Rogerio Almeida
    TI__Mastermind 26025 points
    One more...

    Checking the Linux core U-boot user’s guide, located here:

    processors.wiki.ti.com/.../Linux_Core_U-Boot_User's_Guide

    It references a dra7xx_evm_nandboot_config, which DOES NOT EXIST in the SDK. Now maybe it shouldn’t; because the EVM doesn’t have a parallel NAND...has it been tested?

    I don’t know how to make it not do the read. I’ve asked them to validate the RDY/B* (GPMC WAIT to you) is high once again, but I’m sure it is… without that being low, how do you make the AM572x not at least try the read?
  • 0 in reply to Rogerio Almeida
    TI__Expert 3480 points

    All, so verified in the above plot; RDY/B# (GPMC_WAIT) is high throughout; so the EMIF is not being held off from attempting the read.  That said, I'm out of ideas save attaching JTAG and tryignto setp through the ROM code; but in order to do that I'd need some support from the ROM code experts (like a symbol table/.out file).  

    But bottom line- using NAND boot, what we are seeing is documented above- we see a command get strobed to the NAND but no read attempt at all.  The logger says we are at a state where no valid GP header was detected; to which I would agree- if you don't attempt the read it's not going to find it.  Send help!

  • 0 in reply to radar
    TI__Guru*** 125430 points
    So according to the TRM, the first thing the ROM does is:

    "The ROM code first performs an initial wait for device auto initialization (with a 250-ms time-out) with
    polling of the ready information."

    I assume this corresponds to sending a RESET command (0xFF) to the NAND flash. I believe the detection is based on the NAND's /BUSY signal, i.e. the ROM is expecting to see the NAND's /BUSY signal go low to indicate that a NAND device is present.

    So are we saying that the /BUSY signal never goes low? I believe we're not seeing any further reads because the ROM code thinks we don't have a NAND device on the board.
  • 0 in reply to Brad Griffis
    TI__Expert 3480 points

    And according to the NAND datasheet; the first command sent to the device should be the reset command; and if sent, indeed you are correct the R/B# should go low as per this.

    so... we only have the scope plot above; but what we've been told is that there is 'no' activity on the data lines- so that will have to be checked- when this command that we do see is sent; are the data lines all 0xFF, eg, sending a reset command?  If so and the NAND isn't responding; I'd say you're on to something; like maybe the NAND isn't powered or the /CS isn't making contact or something.  Will check with the customer; though I thought I understodd them to say teh datalines were all low, which wouldnt' be a RESET command...

  • 0 in reply to Brad Griffis
    TI__Expert 3480 points

    And according to the NAND datasheet; the first command sent to the device should be the reset command; and if sent, indeed you are correct the R/B# should go low as per this.

    so... we only have the scope plot above; but what we've been told is that there is 'no' activity on the data lines- so that will have to be checked- when this command that we do see is sent; are the data lines all 0xFF, eg, sending a reset command?  If so and the NAND isn't responding; I'd say you're on to something; like maybe the NAND isn't powered or the /CS isn't making contact or something.  Will check with the customer; though I thought I understood them to say the datalines were all low (at least 0 and 7 were), which wouldnt' be a RESET command...

  • 0 in reply to krinali shah
    TI__Expert 3480 points

    All,

    We are able to get the NAND boot to work.
    We changed "NAND_D11/BOOTMODE11" pin value to logic high level(means A/D mux mode for NAND).

    Thanks for the help!

  • 0 in reply to radar
    Expert 1290 points

    Hi All,

    We are able to get the NAND boot working.

    We have changed BOOTMODE11 pin to logic high. (A/D muxed mode for NAND).

    Thanks a lot for all your support.

    Thanks,

    Krinali Shah

  • 0 in reply to krinali shah
    TI__Mastermind 26025 points
    thanks much for the update.