• State Resolved
  • Locked Locked
  • Replies 64 replies
  • Subscribers 103 subscribers
  • Views 1839 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM6412: LPDDR4 test failed with SR2.0 devices

Koichiro Tashiro
Mastermind 22350 points
Part Number: AM6412
Other Parts Discussed in Thread: SYSCONFIG

Hi,

My customer reported LPDDR4 access failure with SR2.0 silicon.
They used SR1.0 silicon before and there were no failure with SR1.0.
The customer used sysconfig sysconfig v0.08.08.
Memory test was done with;
https://linux.die.net/man/8/memtester
and below command.
root@am64xx-evm:~# ./memtester 256M 5
 
Q1) Are there any LPDDR4 configuration changes are required between SR1.0 and SR2.0?
If so, which configuration?

Q2) They tried to update sysconfig v0.09.08 and 1333 configuration are passed.
But 1600 configuration still failed on SR2.0.
Below excel file shows how to configure sysconfig for 1600.
Could you check it and let me know if anything is wrong?
LPDDR4 configuration.xlsx
FYI, for 1333 configuration, only "FSP2 Frequency (MHz)" is changed to "666.7".

Q3) In sysconfig v0.08.08, selected Device name was "AM64x_beta".
Now it is "AM64x" in v0.09.08. Are there any changes done between these versions?

Thanks and regards,
Koichiro Tashiro

  • 0
    TI__Guru* 80020 points

    Koichiro, can they send a log of the memtester errors?  

    I don't believe there are any differences between SR1.0 and SR2.0 with respect to DDR that would require a different configuration.  Is this error occurring across multiple boards?  

    I don't readily see any issues in the configuration.  Can you send the DDR datasheet (or part number)?

    -Can you send the .syscfg file from the latest sysconfig, and the final output file they are using?  Can they also send the .syscfg from the v8.08 of the tool (if they have it) and the output that worked on SR1.0?

    -Can they connect JTAG and perform a regdump using AM62A_DDRSS_CTL_PI_PHY_RegDump()  GEL script?

    Q3) there are several changes between the 2 syscfg version which are outlined in the README file in the tool.  But the 9.08 version has all of the latest optimization, so this should work on their SR2.0 silicon.

    Also, double check with the customer that they followed the DDR layout guidelines here:  https://www.ti.com/lit/pdf/spracu1

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    Thanks for your quick reply.

    JJD said:
    I don't readily see any issues in the configuration.

    So there is no other change required between SR1.0 and SR2.0, correct?

    JJD said:
    -Can you send the .syscfg file from the latest sysconfig, and the final output file they are using?  Can they also send the .syscfg from the v8.08 of the tool (if they have it) and the output that worked on SR1.0?

    Please find below .syscfg files. (.syscfg is changed to .txt)

    v0.09.08_1600MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    /**
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --device "AM64x" --package "ALV" --part "Default" --product "Processor_DDR_Config@0.09.08"
    * @versions {"tool":"1.16.1+2960"}
    */
    /**
    * Import the modules used in this configuration.
    */
    const DDRSS = scripting.addModule("/DDRSS");
    /**
    * Write custom configuration values to the imported modules.
    */
    DDRSS.system_cfg_dram_type = "LPDDR4";
    DDRSS.lpddr4.$name = "lpddr4_DDRSS_LPDDR40";
    DDRSS.lpddr4.system_cfg_dram_density = 8;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    v0.09.08_1333MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /**
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --device "AM64x" --package "ALV" --part "Default" --product "Processor_DDR_Config@0.09.08"
    * @versions {"tool":"1.16.1+2960"}
    */
    /**
    * Import the modules used in this configuration.
    */
    const DDRSS = scripting.addModule("/DDRSS");
    /**
    * Write custom configuration values to the imported modules.
    */
    DDRSS.system_cfg_dram_type = "LPDDR4";
    DDRSS.lpddr4.$name = "lpddr4_DDRSS_LPDDR40";
    DDRSS.lpddr4.system_cfg_dram_density = 8;
    DDRSS.lpddr4.config_fsp2_MHz = 666.7;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



    JJD said:
    -Can they connect JTAG and perform a regdump using AM62A_DDRSS_CTL_PI_PHY_RegDump()  GEL script?

    Could you send me the GEL file?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Q1, I cannot think of any changes that would be needed in the DDR configuration between SR1.0 and SR2.0

    The GELs are in the package that comes with CCS.  Look in C:\ti\<ccs version>\ccs\ccs_base\emulation\gel\AM64x

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    Here are some updates.

    JJD said:
    can they send a log of the memtester errors?  

    Here is memtester log.

    proto003boardmemtesterng.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    root@pos-periph:~# ./memtester 256M 10
    memtester version 4.3.0 (64-bit)
    Copyright (C) 2001-2012 Charles Cazabon.
    Licensed under the GNU General Public License version 2 (only).
    pagesize is 65536
    pagesizemask is 0xffffffffffff0000
    want 256MB (268435456 bytes)
    got 256MB (268435456 bytes), trying mlock ...locked.
    Loop 1/10:
    Stuck Address : ok
    Random Value : ok
    Compare XOR : ok
    Compare SUB : ok
    Compare MUL : ok
    Compare DIV : ok
    Compare OR : ok
    Compare AND : ok
    Sequential Increment: ok
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    JJD said:
    Is this error occurring across multiple boards?  

    Yes.

    JJD said:
    Also, double check with the customer that they followed the DDR layout guidelines here:

    Yes. They followed the guidelines.

    JJD said:
    -Can they connect JTAG and perform a regdump using AM62A_DDRSS_CTL_PI_PHY_RegDump()  GEL script?

    Here are logs:
    With v09.08 1333MTs

    JTAG_DDR_Dump_Lauterbach_BXproto_SR20_1333MTs_v0.09.08.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-dirty (May 10 2023 - 15:48:27 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (May 10 2023 - 15:48:27 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    SPL initial stack usage: 13424 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enfs
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enfs
    Authentication passed
    Authentication passed
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.7(release):08.04.01.005-dirty
    NOTICE: BL31: Built : 15:48:39, May 10 2023
    U-Boot SPL 2021.01-dirty (May 10 2023 - 15:48:47 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    With v08.08 1600MTs
    JTAG_DDR_Dump_Lauterbach_BXproto_SR20_1600MTs_v0.08.80.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-dirty (May 10 2023 - 15:29:31 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (May 10 2023 - 15:29:31 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    SPL initial stack usage: 13424 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enfs
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enfs
    Authentication passed
    Authentication passed
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.7(release):08.04.01.005-dirty
    NOTICE: BL31: Built : 15:29:43, May 10 2023
    U-Boot SPL 2021.01-dirty (May 10 2023 - 15:29:51 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro, it appears from the regdumps that the initialization and training is not completing, even on the working v8.08 configuration.  Is it possible for you to initialize the DDR using the GELs?  I'd like to do this to isolate the DDR initialization and eliminate any issues with the DDR driver.  Are you working with an HSFS device?

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    Is it possible for you to initialize the DDR using the GELs?

    Could you tell me exact GEL file and GEL function to initialize the DDR?

    JJD said:
    Are you working with an HSFS device?

    Yes. They are using SR2.0 samples, so they are all HS-FS devices.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Hi Koichiro, debug on an HS-FS device is a little trickier, here's what i think you can do:

    Boot up the board to the bootloader using the 1333MTs configuration.  This will hopefully unlock the JTAG can get the device into a state which can run the GELs.

    Add a target configuration for the board using AM64x_SK_EVM as the board.  This will help load the appropriate GELs for LPDDR4.

    After boot, connect to MAIN_PULSAR_0_0 and run Power Sleep Controller/Common PSC Power Controls->Power Sleep Controller/Reset by Power Domain Controls->PD_DDRSS_Reset  This will reset the DDR Subsystem and get it to a default state to be able to run the GELs.

    Then to run the DDR Init, select AM64 DDR Initialization->AM64_DDR_Initialization_ECC_Disabled.  This will run the DDR init and training.  Open up a memory window at 0x80000000 and perform some writes to see if the values stick in the window.  This is just a basic test to see if the init completed.    

    The configuration that is used will be AM64x-LP4_50_800.gel, which i think should work since the DDR device is similar to the one of the EVM.  If you want to try the config for the customer board, you can replace this file with the one that was generated from the DDR tool, and point to it by changing the GEL_LoadGel in AM64x_SK_EVM.gel

    Further question:  the log you sent only shows an error on one address.  Do all the boards show only 1 address in error?   Also, are the errors infrequent (you only show one error in 2 memtester loops)?  Is this similar to the other boards?

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    Thanks for the details. Let me check with the customer if they can follow these steps as they are using different debugger.

    Meanwhile, could you also check below register dump taken on SR1.0 boards?
    If they are OK, the issue is related to SR2.0 changes.

    With V09.08 1333MTs (SR1.0):

    JTAG_DDR_Dump_Lauterbach_BXproto_GP_AQUA_1333MTs_v0.09.08.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-dirty (May 17 2023 - 10:45:45 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (May 17 2023 - 10:45:45 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1333 MT/s
    SPL initial stack usage: 13432 bytes
    Trying to boot from MMC2
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.7(release):08.04.01.005-dirty
    NOTICE: BL31: Built : 10:45:57, May 17 2023
    U-Boot SPL 2021.01-dirty (May 17 2023 - 10:46:05 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    Trying to boot from MMC2
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    With V08.08 1600MT/s (SR1.0):
    JTAG_DDR_Dump_Lauterbach_BXproto_GP_AQUA_1600MTs_v0.80.80.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-dirty (May 18 2023 - 19:02:21 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (May 18 2023 - 19:02:21 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1600 MT/s
    SPL initial stack usage: 13432 bytes
    Trying to boot from MMC2
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.7(release):08.04.01.005-dirty
    NOTICE: BL31: Built : 19:02:33, May 18 2023
    U-Boot SPL 2021.01-dirty (May 18 2023 - 19:02:41 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    Trying to boot from MMC2
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro, the latest regdumps still show that the initialization has not completed.  

    Since we are seeing the init complete problem on all boards and silicon, another idea is to start using the GELs with the SR1.0 boards.  They should be able to connect to JTAG immediately after power up and run the GELs, which would be easier than working with the HSFS devices.  That way we can see if the initialization is completing with the GELs.  Be sure to use the regdump scripts after initializing with the GELs and post here.

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    I am discussing with customer for set-up GEL environment at customer side.

    Meanwhile, they ran GEL files on TI EVM(SR1.0) and got below result.
    JTAG_DDR_Dump_CCS_TI_Green_AM64x-EVM_Only_JTAG.txt
    The customer thinks below two registers shows DDR initialization completes. Is that correct?
    Line#1048 : MAIN_Cortex_R5_0_0: GEL Output: 0x0F308558 0x02000000  //DDRSS_CTL_342_DATA
    Line#1212 : MAIN_Cortex_R5_0_0: GEL Output: 0x0F30A14C 0x29C02001  //DDRSS_PI_83_DATA

    If above answer is "YES", these registers values are below after u-boot on TI EVM(SR1.0). This means DDR initialization is not competed even on TI EVM.
    CortexA53_0: GEL Output: 0x0F30A14C 0x29C02000  //DDRSS_PI_83_DATA
    CortexA53_0: GEL Output: 0x0F308558 0x00000000  //DDRSS_CTL_342_DATA
    Full dump is here:
    JTAG_DDR_Dump_CCS_TI_Green_AM64x-EVM.txt

    If the answer is "NO", could you tell me which registers values show the initialization complete?
    Also, could you share TI EVM(SR1.0) register dump after DDR initialization complete with SDK8.6?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro,

    Yes, bit1 in PI_83 and bit25 in CTL_342 should be set to 1 to indicate completed initialization.  Give me some time, i will double check the EVM.  I will have to try to find a SR1.0 EVM

    To confirm, the results where you show the done bits are '0', are you running SDK 8.4 on the SR1.0 EVM?  

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    To confirm, the results where you show the done bits are '0', are you running SDK 8.4 on the SR1.0 EVM?  

    The customer uses SDK8.6 on SR1.0 EVM.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro, thanks, still looking into it.

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    Any updates for EVM results on your side?
    The customer is waiting for your feedback.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Sorry for the delay.  This is still under investigation.

    James

  • 0 in reply to JJD
    TI__Guru* 80020 points

    Hi Koichiro, sorry for the delay

    It appears that the linux driver is actually clearing out some of the status bits related to the completion of the training.  So in the previous regdump that showed training wasn't completed, it was due to the driver clearing those bits.  So I don't think that is an issue anymore.

    I would like you to take regdumps again with the attached GEL file.  This has some enhancements which will help check the training results.  Please run this with:

    1. passing v8.08 configuration on SR1.0 device at 1600MTs

    2. failing v9.08 configuration on SR2.0 device at 1600MTs

    /cfs-file/__key/communityserver-discussions-components-files/791/AM64_5F00_DDRSS_5F00_RegDump.gel

    Also, i believe you have submitted the schematic to our team, and there are a few issues that need to be corrected which may be contributing to the errors.  Please follow their guidance.  

    Have simulation been performed on this board?

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    The customer board cannot use GEL file as it cannot connect XDS nor CCS. They are using different debugger.
    I will ask the customer to take regdumps associated with the GEL.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    ok thanks Koichiro.  I think there were a couple of schematic observations, including they didn't have 1% calibration resistor, and the had RC circuit on the reset signal.  Did they correct these on the board?

    REgards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    I think there were a couple of schematic observations, including they didn't have 1% calibration resistor, and the had RC circuit on the reset signal.


    I am asking HW team for the schematics feedback, but I did not get any issues around DDR, yet.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 22350 points

    Hi James,

    Now I have a customer board which can be connected CCS.
    I am trying to get RegDumps with your updated GEL file, but there are a few issues.

    1) When I tried to connect to MAIN_PULSAR_0_0 (MAIN_Cortex_R5_0_0), it failed with below error.
    "Error connecting to the target:
    (Error -1170 @ 0x0)
    Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
    (Emulation package 9.7.0.00213)"

    2) When I tried to connect CortexA53_0, below errors were generated.
    "CortexA53_0: GEL: Error while executing OnTargetConnect(): Target failed to read 0x0000000043000000
    at read_pid=*((unsigned int*) (0x43000000U+0x00000000U)) [AM64_DDRSS_Config.gel:92]
    at DDR_Init() [AM64x_SK_EVM.gel:53]
    at OnTargetConnect()"

    Do you know what was wrong?

    Could you take RegDumps on TI EVM (SR2.0) and share them?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Hi Koichiro, not sure why it won't connect to R5.  I am able to connect to R5 after booting all the way to the kernel

    Alternatively, i am able to connect to A53 after just booting to u-boot. 

    Try commenting out the line in yellow in AM64_DDRSS_Config.gel

    if ((Read_MMR(R5FSS_VIM_PID)) == VIM_PID_VALUE)
    {//R5
    GEL_TextOut("Running from R5\n",,,,,);
    GEL_TextOut("\n\nDDR not initialized with R5 connect.\n\nGo to menu Scripts --> AM64 DDR Initialization -> AM64_DDR_Initialization_ECC_Disabled to initialize DDR.\n\n====\n\n");
    }
    else
    {//A53
    // AM64_DDR_Initialization_ECC_Disabled();

    }
    }

    Then attempt to connect to the cores either after getting to a u-boot prompt or getting to a kernel prompt

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    Thanks. I will try that later.

    Meanwhile, the customer got RegDumps with Linux script, please check them.
    Below 6 logs were taken with failing boards with SR2.0.

    bxproto_No_058_SR2_boot_r20230215_v9.08_1600MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: BX Prototype #058 SR2.0
    u-boot: boot_r20230215_v9.08_1600MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1600 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fs
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fs
    Authentication passed
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    bxproto_No_045_SR2_boot_r20230215_v8.08_1600MTs.txt
    bxproto_No_045_SR2_boot_r20230215_v9.08_1333MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: BX Prototype #045 SR2.0
    u-boot: boot_r20230215_v9.08_1333MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1333 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from MMC2
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fa
    il on Security Enforcing(HS-SE) devices
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fa
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    bxproto_No_045_SR2_boot_r20230215_v9.08_1600MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: BX Prototype #045 SR2.0
    u-boot: boot_r20230215_v9.08_1600MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1600 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from MMC2
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fa
    il on Security Enforcing(HS-SE) devices
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fa
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    bxproto_No_058_SR2_boot_r20230215_v8.08_1600MTs.txt
    bxproto_No_058_SR2_boot_r20230215_v9.08_1333MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: BX Prototype #058 SR2.0
    u-boot: boot_r20230215_v9.08_1333MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1333 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fa
    il on Security Enforcing(HS-SE) devices
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fa
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Below 3 logs were taken on passing SR2.0 board.
    bxproto_No_96_SR2_boot_r20230215_v9.08_1333MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: BX Prototype #96 SR2.0
    u-boot: boot_r20230215_v9.08_1333MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1333 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fs
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fs
    Authentication passed
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    bxproto_No_96_SR2_boot_r20230215_v9.08_1600MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: BX Prototype #96 SR2.0
    u-boot: boot_r20230215_v9.08_1600MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1600 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fs
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fs
    Authentication passed
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    bxproto_No_96_SR2_boot_r20230215_v8.08_1600MTs.txt

    Below 3 logs were taken on SK_AM64 (SR1.0) with your GEL.
    SK_AM64_SR1_boot_r20230215_v9.08_1600MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: SK-AM64 SR1 (white)
    u-boot: boot_r20230215_v9.08_1600MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1600 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from MMC2
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This wid
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This wid
    Starting ATF on ARM64 core...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    SK_AM64_SR1_boot_r20230215_v8.08_1600MTs.txt
    SK_AM64_SR1_boot_r20230215_v9.08_1333MTs.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    ----------------------------------------------------------------------------------------------------------------------
    Board: SK-AM64 SR1 (white)
    u-boot: boot_r20230215_v9.08_1333MTs
    ----------------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1333 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from MMC2
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This wid
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This wid
    Starting ATF on ARM64 core...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    The customer wants to compare these registers with TI EVM SR2.0. Could you send me below?

    Koichiro Tashiro said:
    Could you take RegDumps on TI EVM (SR2.0) and share them?


    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro, i don't see much difference between the passing and the failing reg dumps.  

    So there are some boards installed with SR2.0 which are passing?  If this is true, there may be some differences in assembly which is contributing to the issue.    Can you provide the statistics on how many SR2.0 boards were built, and how many are passing and failing.  

    I've attached a regdump of the AM64x SK, but i don't know if it will reveal anything.  With a different layout and different memory, you are going to see a lot of differences.

    Are there any patterns to the error that are seen using memtester?  Can they provide more memtester error logs?  So far the only log they have shared is one where only one address has an error. 

    /cfs-file/__key/communityserver-discussions-components-files/791/regdump_5F00_am64xSK.txt

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    Thanks for your quick reply.

    JJD said:
    i don't see much difference between the passing and the failing reg dumps.  

    The customer wants to know which registers(and values) you checked and figured out they are ok.
    Could you tell me these points?

    JJD said:
    So there are some boards installed with SR2.0 which are passing? 

    Yes, there are some failing boards and some passing boards with SR2.0.

    JJD said:
    Can you provide the statistics on how many SR2.0 boards were built, and how many are passing and failing. 

    It is not well known the statistics. They built 60 boards total, but not all boards were tested with memtester.
    And each board shows different behavior. Some boards fails only v.08.08 1600MTs and passes v09.08, etc.

    JJD said:
    Are there any patterns to the error that are seen using memtester?  Can they provide more memtester error logs? 

    There are no similarities among failing logs. Another failing log is below.

    memtesterlog2.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    root@pos-periph:~# ./memtester 128M 10
    memtester version 4.3.0 (64-bit)
    Copyright (C) 2001-2012 Charles Cazabon.
    Licensed under the GNU General Public License version 2 (only).
    pagesize is 65536
    pagesizemask is 0xffffffffffff0000
    want 128MB (134217728 bytes)
    got 128MB (134217728 bytes), trying mlock ...locked.
    Loop 1/10:
    Stuck Address : ok
    Random Value : ok
    Compare XOR : ok
    Compare SUB : ok
    Compare MUL : ok
    Compare DIV : ok
    Compare OR : ok
    Compare AND : ok
    Sequential Increment: ok
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    And something wrong with below log you attached. it cannot be downloaded. Could you upload it again? 
    /cfs-file/__key/communityserver-discussions-components-files/791/regdump_5F00_am64xSK.txt

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro,

    there are only a handful of errors shown in the memtester log, so there is something very marginal that is failing.  Since you are seeing board to board variation, there may be assembly differences which are causing the issue, or board to board manufacturing variations.  This can be hard to track down.

    As for the schematic review, there were 2 observations that i think need to be corrected.  These should be corrected on a couple of failing boards and retested to see if there is any change in behavior

    a)  1% tolerance resistor is required on the ZQ signal (on the DRAM device)  and DDR0_CAL0 signal (on AM64x).  A lesser tolerance can cause non-optimal calibration, which could be cause the random bit flip issues you see in the memtester log

    b)  The RC circuit on the RESET signal needs to be removed.  I think this may be less of an issue, but it could cause the memory not to be reset properly at power up, which then could put certain portions of the memory in a unknown state

    I have a script that parses the registers to reveal the training results.  There are too many registers to mention here, but i'm mainly looking for the training results associated with Vref training, Write Leveling, CA training, Write DQ training and Read training.  The values i see are similar between a passing and failing regdump, which indicates the training is working properly. 

    To help debug, i think they will have to take more detailed statistics on which boards pass/fail and may have to perform ABA swap to narrow down the failure.  For each board, for example, need to document the following:

    1. Board identification

    2. AM64x revision

    3. DDR configuration version

    4. DDR frequency of operation

    5. Results of memtester (pass/fail) and associated log

    And then i would like to see a couple of failing boards modified with the 2 points above to see if that makes a difference.

    I know this is a lot of work, but with such infrequent errors with no real pattern, this will hopefully help narrow down the issue.

    Regards,

    James

    /cfs-file/__key/communityserver-discussions-components-files/791/8802.regdump_5F00_am64xSK.txt

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    Below 1% tolerance resistor was already changed. In fact it was just an error in the schematics.

    JJD said:
    a)  1% tolerance resistor is required on the ZQ signal (on the DRAM device)  and DDR0_CAL0 signal (on AM64x).  A lesser tolerance can cause non-optimal calibration, which could be cause the random bit flip issues you see in the memtester log

    The customer tried to remove the RC circuit and it shows slightly better results, but it still failed.

    JJD said:
    b)  The RC circuit on the RESET signal needs to be removed.  I think this may be less of an issue, but it could cause the memory not to be reset properly at power up, which then could put certain portions of the memory in a unknown state

    Here are summary of results taken on No_058 board.
    SysConfig v09.08 1333MTs: Pass (it was failed with RC)
    SysConfig v09.08 1600MTs: Failed
    SysConfig v08.08 1600MTs: Failed

    RegDumps are also taken.
    SysConfig v09.08 1333Mts：JTAG_DDR_Dump_boot_r20230215_v9.08_1333MTs_BXProto_No_058_newScript.txt

    JTAG_DDR_Dump_boot_r20230215_v9.08_1333MTs_BXProto_No_058_newScript.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    -----------------------------------------------------------------------------------------------------------------
    boot_r20230215_v9.08_1333MTs
    -----------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:11:18 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1333 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will
    fail on Security Enforcing(HS-SE) devices
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will
    fail on Security Enforcing(HS-SE) devices
    Authentication passed
    Authentication passed
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    SysConfig v09.08 1600Mts：JTAG_DDR_Dump_boot_r20230215_v9.08_1600MTs_BXProto_No_058_newScript.txt
    JTAG_DDR_Dump_boot_r20230215_v9.08_1600MTs_BXProto_No_058_newScript.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    -----------------------------------------------------------------------------------------------------------------
    boot_r20230215_v9.08_1600MTs
    -----------------------------------------------------------------------------------------------------------------
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    Resetting on cold boot to workaround ErrataID:i2331
    resetting ...
    U-Boot SPL 2021.01-dirty (Jun 20 2023 - 11:15:43 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    DDR: LPDDR4 1600 MT/s
    DDRSS_PI_83_DATA 0x27c0a000, DDRSS_CTL_342_DATA 0x00000000
    SPL initial stack usage: 13432 bytes
    Trying to boot from SPI
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will
    fail on Security Enforcing(HS-SE) devices
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will
    fail on Security Enforcing(HS-SE) devices
    Authentication passed
    Authentication passed
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    SysConfig v08.08 1600Mts：JTAG_DDR_Dump_boot_r20230215_v8.08_1600MTs_BXProto_No_058_newScript.txt
    JTAG_DDR_Dump_boot_r20230215_v8.08_1600MTs_BXProto_No_058_newScript.txt

     

    JJD said:

    For each board, for example, need to document the following:

    1. Board identification

    2. AM64x revision

    3. DDR configuration version

    4. DDR frequency of operation

    5. Results of memtester (pass/fail) and associated log


    The customer thought above information was already provided.
    #1 to #4 are in the name of log text file.
    ex.     bxproto_No_045_SR2_boot_r20230215_v8.08_1600MTs.txt
    And test result showed #5.
    If the information is not enough, could you tell me exactly which information is missing?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Expert 4415 points

    Greetings Koichiro,

    James is out on timebank so responses will be delayed. I spoke to him about this briefly before he left and there was something we wanted to double check, is there a different board design for SR1.0 vs SR2.0? In addition, we wanted to know what is your board failure rate (100%, 1%)?

    Sincerely,

    Lucas

  • 0 in reply to Lucas Bowe
    TI__Mastermind 22350 points

    Hi Lucas,

    Thanks for handling this issue while James is OoO.

    Lucas Bowe said:
    is there a different board design for SR1.0 vs SR2.0?

    SR1.0 board and SR2.0 board are different, but there is no significant changes around LPDDR4 or power supplies.
    And signal integrity simulation results are also the same as you can see in the e-mail thread.

    Lucas Bowe said:
    we wanted to know what is your board failure rate (100%, 1%)?

    Are you asking the failure rate on a specific failing board? If so, it depends how much memory region is tested.
    If bigger region is tested, higher failing rate.

    The customer wants to try to change LPDDR4 access timing manually.
    I think all access parameters are automatically tuned by training. And James said there is no suspicious points in register dumps.
    I wonder there are some registers which store DQS timing for READ and WRITE.
    Q1) Is it possible the user can change the training results manually?
    Q2) If so, which registers need to be modified and how?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Expert 4415 points

    Greetings Koichiro,

    We are asking how many SR2.0 boards fail, is it 10 out of 100 boards or every board?

    I was under the impression from discussion that after AB testing the SR2.0 board design is the only common factor in failing (all silicon works on SR1.0 boards but any can fail on SR2.0 boards).

    Sincerely,

    Lucas

  • 0 in reply to Lucas Bowe
    TI__Mastermind 22350 points

    Hi Lucas,

    ~7 boards in 55 boards are failing. 

    Lucas Bowe said:
    I was under the impression from discussion that after AB testing the SR2.0 board design is the only common factor in failing (all silicon works on SR1.0 boards but any can fail on SR2.0 boards).

    Yes. Your understanding is correct, but we do not know where SR2.0 board design is wrong. These two boards are almost the same.

    Could you also double check the sysconfig parameters the customer uses are no problem?
    They changed some parameters from default values based on their LPDDR4 datasheet, but they have some concerns if they missed anything.
    TI_sysconfig_settings.xlsx

    I will send you the memory datasheet and *.syscfg file and *.dtsi file offline.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 22350 points

    Hi Lucas,

    The customer found the board violates LPDDR4 initialization sequence.
    Below is the memory spec. When LPDDR4 reset is released, CKE needs to be low for tINIT2=10ns(before) and tINIT3=2msec(after).

    But on the customer’s board, CKE is toggling.

    I think CKE is driven by AM64x. 
    How this initialization sequence is managed in Linux SDK?
    They are using sysconfig settings I put in the previous post. Are there any issue here?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro, 

    the scope shot of the initialization sequence looks completely wrong.  CKE should not be toggling, and DDR_RESET should go high and be stable.  Also the CK signal is very erratic.  

    Can you provide a more detailed scope shot of the differential clock.  Ensure they have proper connection to the board.  If this isn't correct, nothing will work.  

    We might need to start looking at the layout of this design.  Can you provide a trace length report for the DDR interface signals?

    Regards,

    james

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    I will check with the customer for above points.
    BTW, you meant the initialization sequence is not configurable by software (sysconfig settings), correct?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 22350 points

    James,

    There are two more requests from customer.
    1) Could you send me the correct initialization sequence waveform?
    2) How the DDR initialization sequence is handled by the device / SDK? I guess the process is handled automatically based on sysconfig settings. Is there any documents which explain the details?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Hi Koichiro,

    the initialization sequence is as shown in the diagram you provided from the memory datasheet.  DDR initialization is handled by the DDR driver which initializes all of the Controller/PHY registers based on the sysconfig output file, and then kicks of the training sequence.  The whole training sequence is handled in hardware by the DDRSS IP.  

    A lot of the scope shot you provided doesn't look right, I'm wondering if it is a probing problem.  Can they make the same measurements on the SR1.0 board?  Or even measurements on a different SR2.0 board?  I would start with just probing the differential clock, which should be a clean periodic waveform.  Once that looks good, they can move on to monitor CKE and RESET during the initialization phase.  

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    DDR initialization is handled by the DDR driver which initializes all of the Controller/PHY registers based on the sysconfig output file, and then kicks of the training sequence.

    I understood there is little room for users to modify the DDR initialization other than sysconfig settings.
    Could you double check the customer's settings do not have wrong configurations?
    They modified only a several parameters in orange cells.
    4130.TI_sysconfig_settings.xlsx

    JJD said:
    A lot of the scope shot you provided doesn't look right, I'm wondering if it is a probing problem. 

    You are right. In fact the probe GND was not stable and this is the reason why RESET_N signal looks unstable.
    The customer is trying to get cleaner waveforms.
    But CKE signal seems toggling regardless the probing problem.
    As you can see in the schematics (already shared offline), CKE signal is directly connected between AM64x and LPDDR4.
    I wonder what causes such incorrect CKE behavior. Do you have any thought in mind?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    Can they make the same measurements on the SR1.0 board?

    Yes. And the reset behavior is the same on the SR1.0 board and SR2.0 board.
    But the memory issue is only observed on SR2.0 boards.

    Do you have DDR reset sequence waveforms measured on TI boards?
    I guess it was validated at the device ramp-up.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro, we do not have waveforms of the init sequence on TI boards.  I have taken scope shots in the past of CKE and RESET and have not seen the anomalies that your customer is seeing.  Does the clock signal look the same on the SR1.0 board?

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    we do not have waveforms of the init sequence on TI boards.  I have taken scope shots in the past of CKE and RESET and have not seen the anomalies that your customer is seeing. 

    I see. The customer will try to take waveform on TI-SK and compare with their boards.

    JJD said:
    Does the clock signal look the same on the SR1.0 board?

    Yes. But they used normal probe to monitor differential clock signal. They are trying to use differential probe.

    BTW, there was one misunderstand for below waveform.
    I thought tINIT3=2msec(min) was not met, but in fact the X scale was 5msec/Div and CKE remains Low >2ms after RESET rising edge.

    Then CKE goes to Low immediately. I think this is still unexpected behavior.
    According to memory specification, CKE remains High after RESET release.
    What causes CKE goes to Low? Does this happen with wrong sysconfig settings?
    Again, please double check customer's sysconfig settings in details.


    Beside the reset behavior, the customer still wants to know answers to below queries.
    Could you answer them as well?

    Koichiro Tashiro said:
    The customer wants to try to change LPDDR4 access timing manually.
    I think all access parameters are automatically tuned by training. And James said there is no suspicious points in register dumps.
    I wonder there are some registers which store DQS timing for READ and WRITE.
    Q1) Is it possible the user can change the training results manually?
    Q2) If so, which registers need to be modified and how?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Hi Koichiro,

    not sure what could be causing CKE to go low.  Are they able to connect via JTAG after bootup, either on a failed or passing board?  I can send you a procedure that will reset the DDR subsystem and then reinitialize it with the GEL scripts.  I think using the GEL scripts will help isolate the init sequence to see if there are any problems in the hardware.  I want to get the rest of the software out of the loop to help isolate the debug

    As for the other questions, the timing is set in the configuration file.  Can you send the latest configuration file from the sysconfig tool they are using?  I want to avoid manually setting any timings, or manually changing any training results.  This would not be efficient debug and will take a lot of time (and we don't support manual changes anyway).  The sysconfig tool output has been proven to work across many customer boards and is intended to abstract the user from all the programming details of the DDR controller/PHY.

    Regards,

    James

  • 0 in reply to JJD
    TI__Guru* 80020 points

    Koichiro,

    I forgot to mention, can they also change the following in the sysconfig reg output:

    #define DDRSS_PHY_1399_DATA 0x000C3F91

    This will help clean up the RESET signal and keep it stable throughout the initialization sequence.  This optimization was recently found and i need to incorporatedit into a future version of the sysconfig tool.  Make sure they have also removed all of the RC filters on the RESET signal.  From the last scope shot you send, it still appears that these components are still installed.

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    Can you send the latest configuration file from the sysconfig tool they are using?

    I will send you the sysconfig files offline.

    JJD said:
    #define DDRSS_PHY_1399_DATA 0x000C3F91

    I will ask the customer to try this change.

    JJD said:
    Make sure they have also removed all of the RC filters on the RESET signal.  From the last scope shot you send, it still appears that these components are still installed.

    These RC filters are removed.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Thanks, i don't see anything wrong with the files you sent.  Are they able to connect via JTAG on a failing or passing board after bootup?  This may help us isolate the issue as we can try to use the GEL scripts to initialize DDR

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    Are they able to connect via JTAG on a failing or passing board after bootup? 

    Yes. These board can be connect via JTAG. But I have some trouble to connect R5 and run GEL script as I mentioned before in this E2E thread.

    JJD said:
    I can send you a procedure that will reset the DDR subsystem and then reinitialize it with the GEL scripts.

    Please let me know the procedure in details and send me GELs. I will try them again.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 22350 points

    Hi James,

    There are a few updates.
    Please see attached ppt.
    1856.reset.pptx

    JJD said:
    Koichiro, we do not have waveforms of the init sequence on TI boards.  I have taken scope shots in the past of CKE and RESET and have not seen the anomalies that your customer is seeing.

    The customer measured exactly the same reset behavior on TI board (SK-AM64). Please see slide#3.
    I wonder it is not the issue only on the customer boards.
    Could you check why CKE toggles like this?

    JJD said:

    I forgot to mention, can they also change the following in the sysconfig reg output:

    #define DDRSS_PHY_1399_DATA 0x000C3F91

    The customer tested it on their board. Please see slide#4.
    Reset signal gets stable. Is this what you expected with above change?
    And number of CKE falling edge is reduced from 2 to 1, but CKE is still toggling.
    I am afraid this is still not the proper LPDDR4 reset sequence. CKE should be kept high.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 22350 points

    Hi James,

    Do you have any feedback on this?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro, signals look good now.  I think the small pulse on CKE may be expected, i will have to ask the IP vendor.  

    So for now, i think the initialization is good.  Do they still see DDR failures?  

    Also, do you still have trouble connecting to R5 on the HSFS device?  I'm expecting to be able to connect to R5 or A53 after the board attempts to boot up.  I believe the initial SPL on HSFS device should open up the firewalls to allow JTAG access.  Are you able to get this working?  Will try to work on a procedure on my side.

    Regards,

    James

      

  • 0 in reply to JJD
    TI__Mastermind 22350 points

    Hi James,

    JJD said:
    I think the small pulse on CKE may be expected, i will have to ask the IP vendor. 

    Please double check it with the IP vender. The customer claims the CKE behavior does not match LPDDR4 specification which keeps the CKE high.

    JJD said:
    So for now, i think the initialization is good.  Do they still see DDR failures?  

    Yes. They still see DDR failures.

    JJD said:
    Are you able to get this working?  Will try to work on a procedure on my side.

    Not yet. Please give detailed procedure working at your side step by step.

    JJD said:
    I want to avoid manually setting any timings, or manually changing any training results.  This would not be efficient debug and will take a lot of time (and we don't support manual changes anyway).  The sysconfig tool output has been proven to work across many customer boards and is intended to abstract the user from all the programming details of the DDR controller/PHY.

    Regarding above point, the customer does not intended to use manually changed timings (and/or training results) in their final product.
    They wonder the issue may be related to very marginal timing mismatch on their boards.
    In this case, are there any parameters in sysconfig or *.dtsi file which can be modified to add read or write margin?
    (ex. slightly add or reduce DQS falling/rising timing vs DQ )
    They would like to see if changing such parameters impacts to the DDR failure. It may help us to narrow down the root cause. 

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 22350 points

    Hi James,

    The customer tried some modification in sysconfig parameters and found two working configuration with 1066MTs.
    Please find below excel sheet.
    "sysconfig settings_Failing" is the configuration they used for 1600MTs. And parameters changed from TI default values are filled with orange.
    "sysconfig settings_Passing(1)" is the working parameters with 1066MTs. As you can see, they changed FPS2 Frequency to 533MHz and tINIT3 to 2,000,100. Then the issue is gone.
    "sysconfig settings Passing(2)" is another working parameters with 1066MTs. In this settings, only FPS2 and DDR Density is changed from the default values. And it also working.

    TI_sysconfig_settings_Jul25.xlsx

    Based on above, could you tell me are there any parameters the customer can modify to narrow down the root cause?
    And again, could you double check if there is any suspicious parameter in "sysconfig settings_Failing" sheet?

    Thanks and regards,
    Koichiro Tashiro


  • 0 in reply to Koichiro Tashiro
    TI__Guru* 80020 points

    Koichiro,

    comments on the spreadsheet:

    tMRRI: the value chosen in the sysconfig tool does not need to contain the tRCD component of tMRRI (defined as tRCD + 3nCK in the datasheet), the tool will automatically add this in .  This is identified in the tool if you hover over the tMRRI(tck) heading.  This is a little subtle but ultimately the value of 3 is correct in the tool

    tRPpb(tCK) and tRPab(tCK): yes this does need to change to 4tCK based on the Nanya spec.  I think the Micron datasheet for our EVM has this optimized to 3tCK, that is why there is a difference

    tWR(tCK): yes, this needs to change to 6tCK.  The Micron datasheet for the EVM has this optimized to 4tCK

    tFAW(tCK): this can stay at 0.  There is no tFAW definition in clock cycles, so the tool only uses the ns definition

    tFAW(ns):  yes, this needs to change to 40ns

    tRFCab(ns): yes, this should change to 280ns due to the different density from what the EVM uses

    tRFCpb(ns): yes, this should change to 140ns due to the different density from what the EVM uses

    tDQSCKmax(ns): yes, this should change to 3.6ns based on Nanya datasheet

    tRASmin(ns): derating will automatically be added if the temp setting is above 85C.  So this setting should remain at 42ns

    tRAMmax(ns): this should be set to 9*tREFI=35100 if operating below 85C

    tRRD(ns):  depending on which speed grade device they are using, this value should be set to 7.5ns (for speed grade 4267) or 10ns (for all other speed grades).  Setting it to 4 is incorrect

    I have attached the sysconfig files based on the changes above.  Can they try the tests with this configuration.

    /cfs-file/__key/communityserver-discussions-components-files/791/untitled-_2800_5_2900_.syscfg

    /cfs-file/__key/communityserver-discussions-components-files/791/AM64x_2D00_DDRConfig-_2800_13_2900_.gel

    /cfs-file/__key/communityserver-discussions-components-files/791/k3_2D00_am64_2D00_ddr_2D00_config-_2800_21_2900_.dtsi

    Regards,

    James

1 2