• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 102 subscribers
  • Views 313 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.

Original question:

AM625: DDR4 slow performance of the DDR4 at address 0x880000000

AM625: DDR4 performance

Matteo Marzaro
Prodigy 10 points
Part Number: AM625
Other Parts Discussed in Thread: SK-AM62

Good Morning,

we are experiencing similar issues related to DDR4 performance at address 0x880000000.

Our design includes 2 x Micron MT40A2G8SA-062E-F memories, for a total of 4GB DDR4.


We already checked, with a memtest, that all the memory is correctly accessible from the SoC. 

However we noticed that the 2GB of memory at address 0x880000000 are considerably (more than 20 times) slower than the memory at address 0x80000000. This makes half of the memory in our design unusable.

Are there any updates regarding this issue?

Thanks

  • 0
    TI__Guru*** 148981 points

    Hi Matteo,

    Matteo Marzaro said:
    We already checked, with a memtest, that all the memory is correctly accessible from the SoC. 

    Which SDK version do you use? Did you do memtest in U-Boot or Linnux? Please provide details or logs showing the test result.

  • 0 in reply to Bin Liu
    Prodigy 10 points

    Hi Bin,

    we are currently using yocto, derived from SK-AM62 image

    As memtest we used:

    root@am62xx-evm:~# memtester 3GB 1
memtester version 4.5.1 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 3072MB (3221225472 bytes)
got  3072MB (3221225472 bytes), trying mlock ...locked.
Loop 1/1:
  Stuck Address       : setting   0
testing   0
testing  10
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

    The memtest result didn't show any error but the execution time is considerably slower by changing from 2GB to 3GB or 4GB of memory.

  • 0 in reply to Matteo Marzaro
    TI__Guru*** 148981 points

    Hi Matteo,

    What are the time numbers you measured in 2GB and 3GB?

    What is the output if you run the following command in Linux?

    # devmem2 0x0f300020 w

  • 0 in reply to Bin Liu
    Prodigy 10 points

    Hi Bin,
    I don't have the precise measured time values at the moment (if you need it I can check again in the next days but the ratio is approximately 20 times slower, as I wrote before).

    Speaking of configuration, we applied the following patch in the device-tree:

    -		/ 2G RAM /
-		reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+       / 4G RAM /
+       reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+              <0x00000008 0x80000000 0x00000000 0x80000000>;

    We also applied the following patch in the u-boot, file "drivers/ram/k3-ddrss/k3-ddrss.c":

    -	writel(0x000001EF, ddrss->ddrss_ss_cfg + DDRSS_V2A_CTL_REG);
+	writel( ((readl(0x0F300000 + 0x020) & ~0x3FF) | 0x210), 0x0F300000 + 0x020


    And, with the command you wrote, we have the following output:

    root@am62xx-evm:~# devmem2 0x0f300020 w
/dev/mem opened.
Memory mapped at address 0xffff9b1da000.
Read at address  0x0F300020 (0xffff9b1da020): 0x00000210

    Maybe there are some errors in our patch? Can you check if it is a correct value for you?

    Thanks

  • +1 in reply to Matteo Marzaro
    TI__Guru*** 148981 points

    Hi Matteo,

    Matteo Marzaro said:
    Speaking of configuration, we applied the following patch in the device-tree:

    This patch goes to the U-Boot device tree, right?

    Matteo Marzaro said:
    Can you check if it is a correct value for you?

    I need to ask our DDR expert if the value 0x210 is correct. But I was told to use 0x231.

    Can you please run the following u-boot command to set it to 0x231,

    => mw.l 0x0f300020 0x231 1

    and

    apply the following patch to kernel device tree,

    diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 3e7204440fa0..e8b04d6cf43d 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -81,6 +81,18 @@ secure_ddr: optee@9e800000 {
                        alignment = <0x1000>;
                        no-map;
                };
+
+               mid_512mb: mid_512mb@e0000000 {
+                       compatible = "shared-dma-pool";
+                       reg = <0x00000000 0xe0000000 0x00000000 0x20000000>;
+                       no-map;
+               };
+
+               upper_2gb: upper-2gb@880000000 {
+                       compatible = "shared-dma-pool";
+                       reg = <0x00000008 0x80000000 0x00000000 0x80000000>;
+                       no-map;
+               };
        };
 
        vmain_pd: regulator-0 {

    then run the following memtester commands to measure the performance between the lower 2GB and higher 2GB regions?

    # time memtester -p 0xe0000000 1M 1

    # time memtester -p 0x8e0000000 1M 1

  • 0 in reply to Bin Liu
    Prodigy 10 points

    Hi Bin,
    we applied the new register value and done some tests.
    With the commands you asked, now the result is 54.11(at 0xe0000000) vs 54.17(at 0x8e0000000).

    The performance problem seems to be solved now.


    Thank for the support

  • 0 in reply to Matteo Marzaro
    TI__Guru*** 148981 points

    Hi Matteo,

    Bin Liu said:

    # time memtester -p 0xe0000000 1M 1

    # time memtester -p 0x8e0000000 1M 1

    Can you please run the same test with the original register value 0x210 and let me know the time for each test?

  • 0 in reply to Bin Liu
    Prodigy 10 points

    Hi Bin,
    I'm sorry but I wasn't able to do the test in the past days because the hardware was not available.

    I did the thest again and the result is 54.18(at 0xe0000000) vs 54.31(at 0x8e0000000).
    At this point I think the problem wasn't there. I'm sorry but, at this point, we changed so many things that I'm not able to go back and make the problem happen again.

    Thanks for the support

  • 0 in reply to Matteo Marzaro
    TI__Guru*** 148981 points

    Hi Matteo,

    Thanks for the update.

    If the register value '0x210' doesn't cause the DDR performance issue, please set it back. The value '0x210' means for 4GB memory which is what is on your board, while '0x231' means for 8GB memory.