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: Strange Boot ROM behaviour

Part Number: DM385

Hi!

We have two generations of board with DM385 cpu. The boards are pretty the same in the terms of cpu/power/memory schematics.

We observing strange boot behaviour on new boards(it works ok on old boards).

During board bringup we are trying to boot from SD card. 

U-Boot(SPL) starting ang hangs. First we thought this is due to wrong clock settings. But after we'd enabled debug printouts in SPL we see that SPL can't read u-boot image from SD card because of internal error.

Further investingating showed that when FAT device is registered in spl_register_fat_device variable fat_registered contains thrash value.

This variable is defined as:

static int fat_registered;


It is static and should be set to zero during load process.

When we take exactly that binary and run it on old board everything going fine and fat_registered variable contains zero as expected.

We found that on our new board we have cpu with part number: DM385AAARD21F and on our old boards DM385AAAR11.

Boot ROM of both boards are the same(same version and same content).

This looks very strange. This is SPL, running in L1, no DDR in use...

Can somebody help with this? 

  • Hi Dmitry,

    From what I understand you are using the same MLO/SPL source code and image for old board and new board. And both boards (old and new) are with the same silicon revision 1.1, thus have the same ROM code. Thus it seems to me that you have a HW malfunction of your new board. Please also check if below pointers will be in help:

    Errata - Advisory 1.1.88—Control Module, Pin Configuration (PINCNTLx) : ROM Modifies Bit 19
    TRM - section 4.7.4 MMC/SD card

    processors.wiki.ti.com/.../Debug_Tips_for_DM81xx_Boot_Fail
    processors.wiki.ti.com/.../AM335x_board_bringup_tips

    Regards,
    Pavel
  • Hi, Pavel.

    Thanks for the answer.

    We have launched several new boards and all of them behaves the same way. So it is not malfunction of one exact board.

    About errata:

    This strange behaviour is on new boards but not on old boards. Is it possible that Silicon Anomaly appears on new Processors and absent on old Processors, and all of these processors has the same revision?

    About debug tips:

    Boot ROM generally boots, boot media is found, code loaded, but load process going strange, perhaps. So debug tips not really applicable.

    Moreover,

    after some modification of SPL I can load and run u-boot.img. From that stage I can flash nand and try to boot from nand.

    I can say that nand SPL works wrong too. It boots and can load u-boot if compiled with debug printouts. Without debug printouts it doesn't want to load u-boot and hangs. So it is not only with SD booting - SPL boots strange by Boot ROM.

    Ok, when I successfully run u-boot, then flashed kernel and filesystem/ After that board works stable. It doesn't look like board has hardware problems.

    So the problem is only in the SPL load phase.

    Any ideas?

  • Dmitry Bodnya1 said:
    Ok, when I successfully run u-boot, then flashed kernel and filesystem/ After that board works stable. It doesn't look like board has hardware problems.

    For any detailed software support, bug fixes, or enhancements to TI software, please contact the partners recommended below.

    Regards,
    Pavel

  • I don't ask for software support.

    It seems that it is some hw problem seen during boot. Maybe something wrong with chip part..

    What can I see with emulator?

    How boot process happened, how variable initialized?
  • "This strange behaviour is on new boards but not on old boards. Is it possible that Silicon Anomaly appears on new Processors and absent on old Processors, and all of these processors has the same revision?"

    No, I do not think so.

    "What can I see with emulator?"

    You can verify that ROM Code works fine. Check trace vectors or switch to UART boot and check for CCC stream on the console. If ROM Code runs fine, the the problem is HW malfunction of SD/NAND interfaces or SW malfunction of the SPL code.

    "How boot process happened, how variable initialized?"

    The ROM Code boot is documented in TRM. The SPL boot you might get info in below files:

    www.ti.com/.../sprui83.pdf

    processors.wiki.ti.com/.../IPNC_RDK_DM38x_,_DM8127

    processors.wiki.ti.com/.../TI81XX_PSP_UBOOT_User_Guide

    processors.wiki.ti.com/.../Understanding_u-boot-min_startup_for_DM814x

    Regards,
    Pavel
  • Yes, I read how boot rom works, but for some practical example - some static variable that must be set to zero, how it is loaded?
    This 0 comes from SPL? I mean some part of code, that contains 0 is loaded from boot media to memory region, or there are some instructions to init memory region to 0 in SPL code?

    I understand that it is mostly compiler question, but maybe you can clarify this.