AM625: DDR4 Dual die support

Jhon,

i think you want to set:

Data Bus Width (per device) = 8 (8 bits per die)

Density per device (Gb) = 16 (each die is 16Gb or 2GB)

Chip Selects / Ranks = 1 (i believe the device is a single rank device, ie a single chip select is routed to 2 dies)

Regards,

James

Hi,

Thank you for your reply.

How should the device tree be modified in this node in order to support the above 4GB memory:

https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/dts/k3-am62x-sk-common.dtsi?h=ti-u-boot-2021.01#n31

Jhon

Jhon, here are the changes you would make in the device tree for the 4GB memory

 	memory@80000000 {
 		device_type = "memory";
-		/* 2G RAM */
-		reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+		/* 4G RAM */
+		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+		      <0x00000008 0x80000000 0x00000000 0x80000000>;

Regards,
James

Thanks James, I'll try it.

By the way, can you please explain the meaning of each of these values?

Each entry is 64bits each for address and length

Regards,

james

Hi James,
With the above DDR configuration (Data Bus Width = 8, Density = 16, Chip Selects / Ranks = 1 )
and .dts modification U-boot now starts with Uboot detecting a 4GB device ("DRAM:  4 GiB").
However, boot hangs at the point when trying to load filesystem from mmc1 (SD card). 
We have tested using the same SD card with same DDR configuration and just replacing in .dts the size to 2GB. In that case, boot completes without issue.
Can you suggest what might be the problem? is there any additional modifications we should make?
Has TI attempted to use a 4GB Dual-Die device with similar configuration?

Thank you for your assistance
Jhon

Jhon, there might be one other thing to check.  I'm not sure what SDK version you started with, but there is a line in k3-ddrss.c in uboot like this:

#ifdef CONFIG_K3_AM64_DDRSS
	/* AM64x supports only up to 2 GB SDRAM */
	writel(0x000001EF, ddrss->ddrss_ss_cfg + DDRSS_V2A_CTL_REG);
	writel(0x0, ddrss->ddrss_ss_cfg + DDRSS_ECC_CTRL_REG);
#endif

For AM62A to support 4GB, you need to change this line as shown:

writel(0x00000210, ddrss->ddrss_ss_cfg + DDRSS_V2A_CTL_REG);

This sets the proper address reach to 4GB in the DDRSS wrapper.

Regards,
James

Sorry, i realized there is more wrong with the original line.  Here is the updated line for AM62A 4GB support:

writel( ((readl(AM64_DDRSS_SS_BASE + 0x020) & ~0x3FF) | 0x210), AM64_DDRSS_SS_BASE + 0x020);

Ultimately, address 0x0F300020 should have 0x210 in the lower 10 bits of the register.  You should be able to double check this after DDR is initialized.

Regards,
James

Hi James:

May you help to clarify which API function should merge the patch you address as the above?

Thanks.

BR 

Rio, you should find it in k3-ddrss.c in u-boot

Regards,

James

Hi James:

Yes, I can find the file for sure, but, which Line in that file (IE: which function I need to put the patch?)

Please guide me.

Thanks.

BR Rio

Rio, should be like this:

diff --git a/drivers/ram/k3-ddrss/k3-ddrss.c b/drivers/ram/k3-ddrss/k3-ddrss.c
index e8b7aec9e0..3246c7622f 100644
--- a/drivers/ram/k3-ddrss/k3-ddrss.c
+++ b/drivers/ram/k3-ddrss/k3-ddrss.c
@@ -626,7 +626,7 @@ static int k3_ddrss_probe(struct udevice *dev)

#ifdef CONFIG_K3_AM64_DDRSS
/* AM64x supports only up to 2 GB SDRAM */
- writel(0x000001EF, ddrss->ddrss_ss_cfg + DDRSS_V2A_CTL_REG);
+ writel( ((readl(AM64_DDRSS_SS_BASE + 0x020) & ~0x3FF) | 0x210), AM64_DDRSS_SS_BASE + 0x020);
writel(0x0, ddrss->ddrss_ss_cfg + DDRSS_ECC_CTRL_REG);
#endif

Please verify the patch worked by verifying address 0x0F300020 has 0x210 in the lower 10 bits of the register.

Regards,

James

Hi,

We managed to boot the 4GB and tested its memory overnight successfully, Thank you!

Can the above change be added also for all DDR sizes or should be added just for 4GB?

Jhon

Great, thank you for the feedback.  That change is specific for 4GB.  Here are some other values for other sizes.  

0x1AF for 512MB DDR
0x1EF for 2GB DDR
0x210 for 4GB DDR
0x231 for 8GB DDR

You can check the register V2A_CTL_REG in the TRM for a description of this register, which controls the number of address bits that are used for the memory addressing.  The intention of this register is to provide some protection to prevent aliasing and coherency issues (for example, if you access an address outside of the address reach of the memory)

If you don't care about this, you could just set it to the max of 8GB and be able to access anything 8GB or less, you just wouldn't get the benefits of this feature.

Regards,

James

Hi James:

Here is my email: rc@ti.com

May you help to share your k3-ddrss.c with the merged patch?

Because we are still staying in the SDK8.5.

BR Rio

sent