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.

DM385: Unable to boot from nand with u-boot.min.nand

Part Number: DM385

Hi Everyone,

I'm trying to get my custom DM385 board booting from nand. The nand we are using is MT29F2G08ABAGAH4-IT:G.

Currently, I can successfully boot the system two ways:

1. Boot from SD card, which loads the first and second stage uboot from the card, but loads the kernel and rootfs from the nand.

2. Load u-boot.min.nand using XMODEM upon power on (When I receive the CCCCC... prompt over serial). Once loaded, u-boot.min will run, loading u-boot from nand and then into the kernel.

I've tried programming the u-boot.min.nand file from the second stage u-boot with the following commands:

mmc rescan 0;fatload mmc 0 0x81000000 u-boot.min.nand; nand erase 0x0 0x20000;nand write.i 0x81000000 0x0 0x20000

 

I've also tried setting the nandecc to HW_ECC_BCH8 before programming the u-boot.min.nand with the following commands:

 

nandecc hw 2

mmc rescan 0;fatload mmc 0 0x81000000 u-boot.min.nand; nand erase 0x0 0x20000;nand write.i 0x81000000 0x0 0x20000

 

This also does not seem to work. Whenever I reboot the system, I just receive the CCCC prompt.

 

Any idea on what I need to do to get this working?

 

Thanks

 

mt

329f2g u-boot.min.nand

  • I forgot to mention, our boot mode is 10011, which corresponds to the following boot order:

    NAND
    NANDI2C
    MMC
    UART
  • Hi Mikael,

    Are you sure thats the nand write command, which you have pasted above ? Since you have not given the start and size in the NAND command

    It should be like
    # nand write.i 0x81000000 0x0 0x20000
  • Hi Dwarakesh,

    I think my first post cut off the full command for some reason, here's the exact command I use:

    mmc rescan 0;fatload mmc 0 0x81000000 u-boot.min.nand;

    nand erase 0x0 0x20000;nand write.i 0x81000000 0x0 0x20000

    I believe that's the same command you suggested.

  • Hi Mikael,

    Hope the pin order is taken care from pin 4 (1) pin 3 (0) pin2 (0) pin1 (1) pin0 (1). Please do make sure sysboot pins requirement for NAND is matched as per 4.7.3.5 Sysboot Pins for NAND Boot in TRM
  • Dwarakesh,

    I think you might have found the issue with section 4.7.3.5. It looks like there might be an un-populated resistor on one of the CS0MUX pins on our board. I'll have the hardware engineer validate this and will mark your answer correct if it's the issue.

    Thanks!
  • Hey Dwarakesh,

    We have made the change to the board to make sure the CS0MUX pins on the board are pulled low and have verified on the scope that they are low. Unfortunately, we still get "CCCC..." when booting the board.

    Just to verify, I re-flashed the u-boot.min.nand file. First, I just flashed it with the following command:

    mmc rescan 0;fatload mmc 0 0x81000000 u-boot.min.nand;

    nand erase 0x0 0x20000;nand write.i 0x81000000 0x0 0x20000

    After that didn't work, I tried it after enabling "nandecc hw 2" and still no luck.

    What else should we try?
  • Hi,

    Which software package are you using ? Can you try the prebuilt image ?
  • We were given the SDK by the maker of our eval board (nSketch) so I'm not sure what exact version it is. The cbb_psp version in ti_tools is cbb_psp_04_04_00_02. Is there a good place to find the version our software is based off of?

    I've tried writing the pre-built u-boot.min.nand that came with the SDK and it still did not boot. I do know that this pre-built version works on their eval board.
  • Hi Mikael,

    This looks to be the version psp_04_04_00_02. Can you make sure you are using both first stage and second stage as prebuilt. Flash from the prebuilt second stage bootloader. Hope you have made sure all other sysboot pins are as expected. Does the NAND part number vary from the eval board to the custom Board ?
  • Dwarakesh,

    Now that I think of it, I'm not sure if the pre-built images will work on this system. We had to modify the ram timings to get uboot to work on this system. The pre-built uboot won't have this modification and won't work.

    To test this out, I tried loading the pre-built u-boot.min.nand file via XMODEM. Once the image loaded, the CCC print out quit but nothing happened. When I do this with the u-boot.min.nand that I've built with the ram timings for our system, it will load correctly. This makes me think the issue is related to bootmodes or how the image gets written into the NAND.

    The hardware engineer on the project has double checked all of the btmode pins and he believes they are correct. I'll share them here, let me know if you see anything strange.

    btmode[0] = 1
    btmode[1] = 1
    btmode[2] = 0
    btmode[3] = 0
    btmode[4] = 1
    btmode[5] = 0
    btmode[6] = 0
    btmode[7] = 0
    btmode[8] = 0
    btmode[9] = 1
    btmode[10] = 0
    btmode[11] = 0
    btmode[12] = 0
    btmode[13] = 0
    btmode[14] = 0
    btmode[15] = 0

    As for the NAND part, the eval board uses more or less the same NAND as ours. Their chip is a few revisions behind ours and a different package.
    Our custom board is using: MT29F2G08ABAGAH4-IT:G
    The eval board is using: MT29F2G08ABAEAWP-IT

    One thing we did notice was that our btmode pins are setup exactly the same except for btmode[9]. Theirs is 0 and ours is 1. I know that relates to the ethernet boot and telling what kind of phy is attached, however the strange thing is, both the eval board and our board are using a RGMII phy. The phy they are using doesn't even support MII (GMII) according to the datasheet for their device (it uses RGMII).
  • Hi,

    I am not sure if it is valid, since it worked on the similar NAND chip, but from : processors.wiki.ti.com/.../TI81XX_PSP_04.04.00.02_Release_Notes , there is a known issue:

    "NAND: misalignment on format for storing ECC in OOB, between ROM code and UBoot/Kernel driver causing NAND Read issue with BCH8 ECC scheme."

    I would suggest you to take uboot from latest package like IPNC RDK and try.
  • Hey Dwarakesh,

    Could you point me to the latest IPNC RDK? I'm not sure where to download it at.

    Thanks
  • Hi,

    This is the link : www.ti.com/.../ipnc-rdk-csk

    This has latest u-boot 2016. It may be different, but try this package. For IPNC package 3.8 which has u-boot 2011(similar to your package), contact your local TI FAE. 3.8 package would be the better option.

    Thanks,
    Dwarakesh R
  • Dwarakesh,

    I have gone ahead and requested the IPNC 3.8 package from our TI contact since that should hopefully be easier to integrate into our existing code.

    You mentioned the known issue with my version of uboot:
    "NAND: misalignment on format for storing ECC in OOB, between ROM code and UBoot/Kernel driver causing NAND Read issue with BCH8 ECC scheme."

    Do you know where this issue is and where it was fixed? Is there a patch for it? From my searching of our code, it appears that the issue might be in the ti81xx_nand.c file.

    Thanks!
  • Dwarakesh,

    I might have stumbled upon something. I was searching around for other versions of ti81xx_nand.c online and stumbled upon the arago-project version. I searched the project for ecc and came up with the following change log:

    arago-project.org/.../

    Comparing some of these changes to my version of ti81xx_nand.c shows me that it looks like some of the BCH8 ecc fixes were implemented in my uboot, however were then removed from compilation with "#if 0" in the code.

    I'm going to go through and remove the #if 0 from the code so it more closely resembles the arago version and see if this gets me anywhere.

    Do you think there would be any issue of just cloning the arago version of uboot and using it?
  • Hey Pavel & Dwarakesh,

    I'm looking a little closer at the TRM's ROM Code section (Section 4) and noticed something that might be causing some issues. The NAND that was on our dev board was the MT29F2G08ABAEAWP_IT. For it, a page is 2048 bytes + 64 bytes obb. Our device is the MT29F2G08ABAGAH4-IT which a page is 2048+128.

    I noticed in the TRM section 4.7.3.1 that for NANDs it specifically calls out page sizes of 2048 + 64. I also noticed that the nandwrite program fails to write to the nand, outputting the text "Unknown flash (not normal NAND)". I searched around for this text and I believe it's coming from libmtd.a. Other references to that text like in the "update" or "filesys_update" application specifically prevent flashes with 2048 byte pages from working if they don't have a 64 byte obb.

    Could this be the reason our system is failing to boot? Does the ROM Code check to make sure it's 2048+64, or does this mean that we need to do anything different while writing the u-boot.min image?

    Thanks!

  • Hi Mikael,

    1)TRM suggests that ROM code looks for 10b in fourth byte(4K page) to use BCH16 scheme. Which could mean if it sees 01b, it could continue to use BCH8. If it has used BCH8, I think with even wrongly assumed OOB size of 64 bytes would have been enough to boot the Board from NAND.

    2)But there is also similar discussion regarding TI81xx(similar to DM38x) in e2e, where it is discussed that ROM code selects the BCH algorithm based on the spare area. If there is 128bytes spare area, it could use BCH16. In that case, it looks like there is no support in the uboot for the BCH16 yet. You can port it, but it would be an effort.

    So, there are two possibilites and I am not sure which one is the case. Pavel would be in a position to comment better. Awaiting for his inputs.
  • Hey Dwarakesh,

    1) I just checked and we don't have a 10b in the 4th byte, however our page size is 2K so I'm not sure if that changes anything.
    2) I think this is most likely what is happening. From what I can tell, the evidence points to this being the cause. I have also been reading the other posts regarding the ti81xx and the issues seen with a > 64 byte extra space in NAND seem very similar to what I'm seeing.

    Hopefully Pavel can help confirm that this is the issue.

    Thanks again!
  • Mikael,

    According to my calculation, BCH8 should be enough for 2k + 128 oob, see the below e2e thread:

    e2e.ti.com/.../1792717

    The below e2e thread discuss using 2K + 112 oob with BCH8:

    e2e.ti.com/.../231420

    Regards,
    Pavel
  • Hey Pavel,

    Correct me if I'm wrong, but according to the posts that I'll link to below, the ROM bootloader will use the largest ECC method it can. It might be that the ROM bootloader is different in the ti81xx so maybe the link doesn't apply. According to the wiki on BCH Flash OOB Layout, the calculations for my NAND are as follows:

    Page Size: 2048

    512 byte Sectors Per Page: 2048 / 512 = 4

    For BCH8, we need 14 * 4 = 56 bytes.

    For BCH16, we need 26 * 4 = 104 bytes.

    So if the ROM bootloader selects the largest ECC method it can fit, and we have a total of 128 OOB bytes, wouldn't it choose BCH16?

    I'm currently getting a JTAG installed so I can try to access the ROM bootloader status vectors. I'll report back when I get that information. 

    https://e2e.ti.com/support/arm/sitara_arm/f/791/p/382272/1346910?tisearch=e2e-sitesearch&keymatch=bch16%20rom%20code#1346910

    e2e.ti.com/.../842118

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_UBOOT_User_Guide#BCH_Flash_OOB_Layout

  • Mikael,

    Yes, TI81xx ROM code act the same, ROM will use the maximum BCH that it can fit into the spare area, see the below pointers:

    Below is some info I have during e-mail correspondence:

    Problem Statement:

    --------------------------

    Now both UBoot and Linux kernel driver has compile-time options to select various ECC-modes (ECC-SW, ECC_HAM1, ECC_BCH8), but they do not support ECC_BCH16 mode. So when customer has to use a particular mode, it re-builds the UBoot & Kernel with his choice of option.

    However, ROM code being a generic code for multiple device platforms was not designed with these user-options. ROM automatically selects the ‘highest possible’ ECC-mode based on size of OOB area (physical parameter) of the device it detects on the board.

    Thus in current case, the customer board has a device with 224bits of OOB area, therefore ROM code automatically selects ECC_MODE = ECC_BCH16. Whereas the UBoot image flashed either from UBoot or Kernel cannot be flashed in ECC_BCH16, because the code does not support ECC_BCH16 So, ROM code is unable to identify UBoot flashed images, and failing.

    Possible Solutions:

    (1)    Flash the U-Boot image to NAND using some 3rd party flashing tool which supports BCH-16 code, and which matches ROM code ECC layout. This way ROM can understand flashed U-Boot image, and post U-Boot loading customer can use his choice of ECC_mode.

    (2)    Boot U-Boot image from any other source apart from NAND, (example SPI Flash, SD card) and then further Linux images can be loaded from NAND.

     

    You can also check the latest DM38x IPNC RDK 3.9.1 u-boot code base, bch16 should be already available there. You can back port to your u-boot code base.

    Regards,
    Pavel

  • Thanks Pavel,

    We've decided to switch back to a NAND that will allow BCH8 ECC in the interest of time. I appreciate your help on this.