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.

AM4376: DDR settings in SPL

Part Number: AM4376


Hello,

My customer use AM4376 in their system and are ramping production. While ramping up production, they observed that ~10% of the boards have one of the AM4376 processors fails to boot from Ethernet. They receive the BOOTP message, but the processor SPL fails to download the image into the DDR. Their investigations led them to suspect the DDR SPL settings. THe boards all have an identical layout and use the same DDR devices. They could check through JTAG that Ethernet and the DDR work properly on systems that fail the Ethernet boot.

I am attaching in the private notes of this message the datasheet of the DDR and the customer's EMIF tool setting.

Thank you for your support.


Best regards,
François.

  • Hi all,

    Additional notes:

    Executing an application from DDR, using the debugger/GEL(IDK) runs as expected. Some findings:

    • Loading and executing SPL (bin) using debugger fails when the stack is relocated to DDR.
    • Same failure occurs when SPL is loaded thru netboot (using debugger for HW BP).


    Thanks,
    François.

  • Hi François,

    Is your customer using any software from TI, RTOS SDK, Linux SDK, etc?

    Thanks,

    Jianzhong


  • Hi jianzhongxu,

    We are using Linux SDK

    ti-processor-sdk-linux-am437x-evm-06.00.00.07
    U-Boot 2018.01-00558-g8617e02

    We have customized SPL to boot over ethernet or MMC. We did not customize DDR settings. These settings worked for a large majority of the HW, and went undetected. Recently, I have found the failure is when the stack is switched to DDR in SPL.

    This is what I have found so far:

    First scenario – altering u-boot (SPL) settings:

    I changed most DDR registers to match IDK GEL DDR config (board.c). I have executed the am43xx-ddr-analysis.dss script which led me to change/revert other registers.

    With that base set of registers, I adjusted DDR pll settings for 400MHz.
    idk_dpll_ddr = {400, 24, 1, -1, 2, -1, -1)

    All CPU's did not boot until the DDR clock was lowered (in this case 384MHz).

    Second scenario – interrupt SPL execution with debugger. HW is configured to load SPL from Ethernet:

    - Load symbols for SPL.
    - Place HW breakpoint in SPL, after sdram_config().
    - Reset board (reset button).
    - At BP run DDR config GEL script
    - Continue execution.

    This method always boots (Linux). Even on CPU’s which failed to boot in the first scenario. The GEL script sets DDR clock to 400MHz.

    I realize the GEL script performs other tasks such as leveling. Does SPL perform HW leveling in this version of u-boot?

    Next I will be looking closer at the EMIF config tool. Any help is greatly appreciated.

    Thanks,

    Peiman

  • Hi Peiman,
    My understanding is you'd ran AM437x DDR configuration tool (www.ti.com/.../sprac70)
    If yes, have you tried to populate the DDR parameters generated from the DDR configuration tool to SPL/u-boot DDR configuration?
    , i.e., $u-boot/board/ti/am43xx/board.c
    Best,
    -Hong


  • Hi Hong,

    I've attached the spreadsheet and DDR analysis using .dss script. Along with the DDR GEL file that can successfully boot all CPU's.

    With the settings below (from spreadsheet), I can get all but one CPU to boot (DDR at 400MHz). If I lower DDR PLL to 384MHz (in SPL) the problem CPU will boot a majority of the time.

    Some notes:

    - I set detail 6 on the spreadsheet, bin rating, to 800 MHz. Based on threads that I have come across. With other settings, I could not  boot any CPU.
    - I set EMIF4D_DDR_PHY_CTRL_1 to 0x00008009 (spreadsheet calculated 0x00048009). Without this change, no CPU would boot.
    - I have changed ddr.c, ext_phy_settings_hwlvl() to set the PHY registers. This was in order to change EMIF4D_EXT_PHY_CTRL_36 to 0x00000077. However I don't see this value when doing DDR analysis. Looking at ddr.c, it looks like ext_phy_settings_hwlvl() is not executed?


    I can only boot the problem CPU by user intervention, using GEL file:
    - Place HW breakpoint in SPL, in board_init_f(), after sdram_config().
    - At BP run DDR config GEL script
    - Continue execution.

    My guess is that the GEL is doing HW leveling, where SPL is not? Any thoughts are appreciated.

    Thanks,


    Peiman

    - resulting emif_regs structure, board.c


    static const struct emif_regs ddr3_idk_emif_regs_400Mhz = {
    .sdram_config = 0x61A013B0,
    .sdram_config2 = 0x00000000,
    .ref_ctrl = 0x00000C30,
    .sdram_tim1 = 0xEAAAE51E,
    .sdram_tim2 = 0x366B7FDA,
    .sdram_tim3 = 0x5F7F88BF,
    .zq_config = 0x50077D33,
    .temp_alert_config = 0x00000000,
    .emif_ddr_phy_ctlr_1 = 0x00008009,
    .emif_ddr_ext_phy_ctrl_1 = 0x00040100,
    .emif_ddr_ext_phy_ctrl_2 = 0x00000000,
    .emif_ddr_ext_phy_ctrl_3 = 0x00000000,
    .emif_ddr_ext_phy_ctrl_4 = 0x00000000,
    .emif_ddr_ext_phy_ctrl_5 = 0x00000000,
    .emif_rd_wr_lvl_rmp_win = 0x00000000,
    .emif_rd_wr_lvl_rmp_ctl = 0x80000000,
    .emif_rd_wr_lvl_ctl = 0x00000000,
    /////////////////////////////////////////////////
    .read_idle_ctrl = 0x00050000,
    .emif_rd_wr_exec_thresh = 0x00000405,
    .emif_prio_class_serv_map = 0x00000000,
    .emif_connect_id_serv_1_map = 0x00000000,
    .emif_connect_id_serv_2_map = 0x00000000,
    .emif_cos_config = 0x00ffffff
    };

    - DDR PLL values, board.c


    static const struct dpll_params idk_dpll_ddr = {
    400, 24, 1, -1, 2, -1, -1
    };

    DDR_settings_in_SPL.zip

  • Hi Peiman, start with ensuring that the EMIF tool configuration is correct in SPL:

    -change all SPL settings to the ones suggested by the EMIF tool (ensure PHY_CTRL_1 = 0x48009, and check EXT_PHY_CTRL_1, that did not look correct in the dss script you sent.  For now, don't worry about changing PHY_CTRL_36)

    -build code and run your test

    -After test fails, run .dss scripts and dump registers 0x4c000000-0x4c00031C

    Also, double check the frequency of OSC0 is 25MHz

    REgards,

    James