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.

AM62L: Unable to boot the device using SD card

Part Number: AM62L
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

I am unable to boot the device, AM62L using SD card. I am getting the log uptil the PHY training completed, but only numbers  and CCCC are coming after that.

  • Will you upload the full boot log as attachment?
    Best,
    -Hong

  • NOTICE:  bl1_plat_arch_setup arch setup 
    NOTICE:  Booting Trusted Firmware
    NOTICE:  BL1: v2.12.0(debug):11.00.15-1-g2523204b0-dirty
    NOTICE:  BL1: Built : 10:50:54, Oct 13 2025
    INFO:    BL1: RAM 0x7080b000 - 0x7080f000
    INFO:    BL1: cortex_a53: CPU workaround for erratum 855873 was applied
    INFO:    BL1: cortex_a53: CPU workaround for erratum 1530924 was applied
    INFO:    lpddr4_init <-- 
    INFO:    lpddr4 dtb: ctl-data ptr=0x7080718c, pi-data=0x70807834, phy-data=0x70807da4
    NOTICE:  BL1: dram_class: 11
    INFO:    memory node =0x28 
    INFO:    lpddr4: probe done 
    INFO:    lpddr4/ddr4: init done 
    INFO:    start-status: offset =0x0 
    INFO:    start-status reg: before =0x10460b00 
    INFO:    Doing normal DDR initINFO:    lpddr4: Start DDR controller 
    INFO:    k3_lpddr4_freq_update DDR Freq change complete 
    INFO:    lpddr4: start completed successfully status=0x0
    INFO:    start-status reg: after =0x10460b01 
    INFO:    LPDDR4 start completed !! 
    NOTICE:  lpddr4: post start - PI training status=0x27c0a000 
    INFO:    lpddr4: post start - CTL Interrupt status=0x4 
    NOTICE:  bl1_platform_setup DDR init done
    NOTICE:  k3_bl1_handoff ENTERING WFI - end of bl1


    This is the log I am getting while booting with USB and some garbage values come up if I boot with sd card

  • NOTICE:  BL1: v2.12.0(debug):11.00.15-1-g2523204b0-dirty
    NOTICE:  BL1: Built : 10:50:54, Oct 13 2025
    INFO:    BL1: RAM 0x7080b000 - 0x7080f000
    INFO:    BL1: cortex_a53: CPU workaround for erratum 855873 was applied
    INFO:    BL1: cortex_a53: CPU workaround for erratum 1530924 was applied
    INFO:    lpddr4_init <-- 
    INFO:    lpddr4 dtb: ctl-data ptr=0x7080718c, pi-data=0x70807834, phy-data=0x70807da4
    NOTICE:  BL1: dram_class: 11
    INFO:    memory node =0x28 
    INFO:    lpddr4: probe done 
    INFO:    lpddr4/ddr4: init done 
    INFO:    start-status: offset =0x0 
    INFO:    start-status reg: before =0x10460b00 
    INFO:    Doing normal DDR initINFO:    lpddr4: Start DDR controller 
    INFO:    k3_lpddr4_freq_update DDR Freq change complete 
    INFO:    lpddr4: start completed successfully status=0x0
    INFO:    start-status reg: after =0x10460b01 
    INFO:    LPDDR4 start completed !! 
    NOTICE:  lpddr4: post start - PI training status=0x27c0a000 
    INFO:    lpddr4: post start - CTL Interrupt status=0x4 
    NOTICE:  bl1_platform_setup DDR init done
    NOTICE:  k3_bl1_handoff ENTERING WFI - end of bl1
    02000000011a0000616d36326c0000000000000048534653000001000000010002a6000000000000ad0bc40b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ad0bc40b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000045818321883fc1e46a7aa92789c0bb27043b4a16dc68fa2b88f7fdc4bd5503adCCCCCCCCCCCCCCCCCCCCC



    This is what I am getting when booting with sd card. Is the LPDDR4 looking for some file ?

  • The both logs shows BL1(tiboot3.bin) boots, but bootibg stops afterwards...
    1/. Is test on TI EVM or customer board?
    2/. which Linux SDK was used for testing?
    Best,
    -Hong

  • 1. This is on custom board.
    2. TI SDK 11.00.15

  • 1. I am able to boot up on EVM but not on the custom board. 
    2. Ubuntu 22

  • 1/. what're main HW difference between the customer board vs the TI EVM?
    2/. Is DDR on the customer board different comparing to the one on the TI EVM?
    Best,
    -Hong

  • 1. It is similar to the TI EVM, same PMIC, same ram, similar peripherals. 
    2. it is the same LPDDR4 as the TI EVM. The only difference is some but swapping within the 8-bit lanes. We have used the configuration tool to compensate for these changes. 

    Is there a way to get more feedback about what is failing in the DDR training?  Are there other tools to interface with the DDR?  I saw some timing analysis tools but it for the AM62L, yet. 

    thanks

  • Let me loop in my colleague to follow-up lpddr4 configuration questions.
    Best,
    -Hong

  • Hi Nathan, to get more info from the DDR please add the patch found here: 

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1358039/faq-board-bring-up-tips-for-sitara-devices-am64x-am243x-am62x-am62l-am62ax-am62d-q1-am62px#:~:text=Getting%20DDR%20register%20dump%20after%20initialization

    and post the reg dump here.  This will help determine if the DDR init and training is completing successfully.

    Regards,

    James

  • Hi,

    We tried doing this, but didn't get any result.

    NOTICE:  bl1_plat_arch_setup arch setup 
    NOTICE:  Booting Trusted Firmware
    NOTICE:  BL1: v2.12.0(debug):11.00.15-30-gc2ce2c1da-dirty
    NOTICE:  BL1: Built : 07:23:27, Oct 21 2025
    NOTICE:  lpddr4: post start - PI training status=0x27c0a000 
    NOTICE:  bl1_platform_setup DDR init done
    NOTICE:  k3_bl1_handoff ENTERING WFI - end of bl1

     

     This is the output log.

  • dfu-util 0.9

     

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2016 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

     

    Found DFU: [0451:6165] ver=0200, devnum=46, cfg=1, intf=0, path="1-2", alt=1, name="SocId", serial="01.00.00.00"
    Found DFU: [0451:6165] ver=0200, devnum=46, cfg=1, intf=0, path="1-2", alt=0, name="bootloader", serial="01.00.00.00"
    Found DFU: [0bda:5800] ver=0001, devnum=4, cfg=1, intf=0, path="3-4", alt=0, name="Camera DFU Device", serial="200901010001"
    ++ sudo dfu-util -R -a bootloader -D tiboot3.bin
    dfu-util 0.9

     

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2016 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

     

    dfu-util: Invalid DFU suffix signature
    dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
    Opening DFU capable USB device...
    ID 0451:6165
    Run-time device DFU version 0110
    Claiming USB DFU Interface...
    Setting Alternate Setting #0 ...
    Determining device status: state = dfuIDLE, status = 0
    dfuIDLE, continuing
    DFU mode device DFU version 0110
    Device returned transfer size 512
    Copying data from PC to DFU device
    Download  [=========================] 100%       225967 bytes
    Download done.
    state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
    state(2) = dfuIDLE, status(0) = No error condition is present
    Done!
    dfu-util: can't detach
    Resetting USB to switch back to runtime mode
    ++ sleep 5
    ++ sudo dfu-util -l
    dfu-util 0.9

     

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2016 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

     

    Found DFU: [0451:6165] ver=0200, devnum=48, cfg=1, intf=0, path="1-2", alt=1, name="SocId", serial="01.00.00.00"
    Found DFU: [0451:6165] ver=0200, devnum=48, cfg=1, intf=0, path="1-2", alt=0, name="bootloader", serial="01.00.00.00"
    Found DFU: [0bda:5800] ver=0001, devnum=4, cfg=1, intf=0, path="3-4", alt=0, name="Camera DFU Device", serial="200901010001"
    ++ sudo dfu-util -R -a bootloader -D tispl.bin
    dfu-util 0.9

     

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2016 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

     

    dfu-util: Invalid DFU suffix signature
    dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
    Opening DFU capable USB device...
    ID 0451:6165
    Run-time device DFU version 0110
    Claiming USB DFU Interface...
    Setting Alternate Setting #0 ...
    Determining device status: state = dfuIDLE, status = 0
    dfuIDLE, continuing
    DFU mode device DFU version 0110
    Device returned transfer size 512
    Copying data from PC to DFU device
    Download  [=========================] 100%      1472848 bytes
    Download done.
    state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
    state(2) = dfuIDLE, status(0) = No error condition is present
    Done!
    dfu-util: can't detach
    Resetting USB to switch back to runtime mode
    ++ sleep 5
    ++ sudo dfu-util -R -a u-boot.img -D u-boot.img
    dfu-util 0.9

     

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2016 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

     

    dfu-util: Invalid DFU suffix signature
    dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
    dfu-util: No DFU capable USB device available
    ++ sleep 5

  • Hi, JJD, 

     Thanks for your response. We were able to modify and apply the patch successfully. But the problem is it output is always getting stuck at  NOTICE:  k3_bl1_handoff ENTERING WFI - end of bl1
    It is not loading the tispl.bin file. We have attached logs of our boot and programming steps for your reference. We are able to program tiboot3.bin and tispl.bin but tispl is not booting and due to which we are not able to get any DDR logs. 

  • That's strange, it should output the regdump immediately after DDR init in tiboot3.bin, it shouldn't need to get to tispl.bin.

    In the link i sent, there is a section called "Adding statements to uboot".  Can you ensure the #define DEBUG statement is in the appropriate place?

    BTW, i don't see anything attached to the last post

    Regards,

    James

  • Hi JJD, 

     You can see the logs attached by Megha for your reference. We dont see any logs beyond that. Attached a screenshot for your reference.

    Sharing the git commit of patch for your reference: https://github.com/Narashiman/ti-u-boot/commit/b062312e5592064ae89765e04b45c9722f4e0b9d

  • I think the issue is similar to  RE: AM62L-PROCESSOR-SDK: tispl.bin doesn't work on the custom board.
    Attached our config as zip for your reference.Trial_1.zip

  • James

    I am also working on this with Narashiman and Megha.  I am adding a log with a register dump; we were able to get that output.

      DDR_register_dump.log

  • Hi Nathan, 

    sorry, i was reminded by our software team that the structure of the AM62L bootloader is different than previous devices, so the patch needed to be applied differently.

    At any rate, it looks like you got it working.  From the regdump, i can see that VREFca training is not completing correctly.  Can you provide the DDR datasheet and and part number you are using.  Also would like to see the schematic portion of the DDR interface, both the AM62L side and the memory side.

    Regards,

    James

  • Hi James

    We are using the same Micron part used on the development kit, we believe, MT53E1G16D1ZW-046 WT:C.  Please find attached the schematics from our design. I believe it is the same as the development kit, except we swapped the data bits within the byte lanes for easier routing.  We have used the SysConfig tool to change the .dtsi file to match our design.

    Pages from AM62L_300825_1342.pdf

  • Hi James,

    We have been able to bootup the device, there was some issue with the dtsi file that we were able to figure out.
    Thanks for the support!

    Regards,
    Megha 

  • In case someone else runs into the issue, the problem we had was with the bit swapping within byte lanes in the SysConfig tool; we missed that the left column is Processor DQ labels and the right column is Memory DQ labels; that made the ordering wrong in the original dtsi file we tried, it was backwards.

  • Hi Nathan, thanks for the explanation.  I will close this issue.

    Regards,

    James