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.

MLO stuck

Guru 20755 points

Hello,

We started working with custom board today, and we see that the 1st u-boot stage (minimal) which boot from SD, does not output anything. Is there a way to understand what's the problem ? (I'm not using CC or debugger).

Thanks,

Ran

  • Hi Ran,


    Its pretty hard to debug if you are not using CCS/debugger, may be try and enable your serial as soon as possible and try printing so that you can debug.

    you can follow this link to use gdb http://www.denx.de/wiki/view/DULG/DebuggingUBoot

    Or if using CCS http://processors.wiki.ti.com/index.php/U-boot_Debug_in_CCSv5

    Regards,

    --Prabhakar Lad

  • Hi Ran,

    What is your reference board and what are all the hw changes present in custom board than reference board ?

    Are you using different console serial port on custom board ?

  • Hi,

    Thanks Prabhakar , Titus

    The reference board is DM8148 EVM. The MLO runs well on it.
    The changes are only relevant to etherent (GMII), and there might be DDR configuration changes, I need to check this issue. The UART is the same. The boot is from SD.

    The strange thing is that I have MLO from other similar project, which runs well on this board, but  the source code of that project is not available !! :((

    Is the DDR configuration is conditional for first printing in the console (such as u-boot version) ? Why should it be conditional ? Isn't DDR only required for 2nd u-boot,?
    I've configured the environment from NAND instead SD (MMC), maybe it adds some problem ?


    Another question, just to be sure, when compiling 1st stage for SD it creates 2 files u-boot.bin and u-boot.min.sd. As I understand u-boot.min.sd should be renamed to MLO, is u-boot.bin should be ignored (it need to be created in 2'nd stage compilation as I understand)

    Thanks, Ran

  • Hi,

    The strange thing is that I have MLO from other similar project, which runs well on this board, but  the source code of that project is not available !! :((

    CCS could have helped here to grab register values.

    Is the DDR configuration is conditional for first printing in the console (such as u-boot version) ? Why should it be conditional ? Isn't DDR only required for 2nd u-boot,?
    I've configured the environment from NAND instead SD (MMC), maybe it adds some problem ?

    The job of the MLO is to configure the DDR timings copy the u-boot from SD/NAND to DDR and then jump to U-boot location on DDR so you need to get DDR timings right

    Another question, just to be sure, when compiling 1st stage for SD it creates 2 files u-boot.bin and u-boot.min.sd. As I understand u-boot.min.sd should be renamed to MLO, is u-boot.bin should be ignored (it need to be created in 2'nd stage compilation as I understand)

    It depends on which branch/version of code are you using the earlier version had to configs one for MLO and other for u-boot, but later there was only one config which built the both.

    Regards,

    --Prabhakar Lad

  • Hi Prabhakar,

    I see that the MLO compiled from RDK does not respond at all, but MLO compiled from ezsdk, is more responsive.
    It get stuck each time at different stages, sometimes some seconds after linux prompt is already given, and other times before that (kernel/u-boot startup).
    Another strange things is that the ALL the values (clock,pll,etc) printed in u-boot (when it is not stuck) are totally the same as those of the version which is not stuck. How can it be ?

    Is there any idea where is the problem ?

    Thanks,

    Ran

  • Hi,

    MLO compiled from ezsdk, is more responsive.
    It get stuck each time at different stages, sometimes some seconds after linux prompt is already given, and other times before that (kernel/u-boot startup).

    Good! something is coming up. by linux prompt you are able to boot the kernel ?

    Another strange things is that the ALL the values (clock,pll,etc) printed in u-boot (when it is not stuck) are totally the same as those of the version which is not stuck. How can it be ?

    Pretty hard to say unless you debug step by step :(

    Thanks,

    --Prabhakar

  • Hן Prabhakarת

    Is there a documentation of what is done in each stange (pinmux, pll ) ?  , i.e. where is pinmux donw (2nd stage) ? Is the first stage concerns only with pll and dram (which are not done in 2nd stage) ?

    Is there any configuration that is done in both stages ?
    Is it required to do changes specific in MLO, or that any configuration (including pll) can also be done later ?

    Thanks,

    Ran