TDA4VM: SDK7.1 DDR api from baidu company

Following the above supplementary information, I tried to use the LPDDR4_GetMmrRegister interface to read the DDR manufacture ID, but found no success. In theory, this interface should support reading the DDR manufacture ID. I am not sure if I used it wrong or if there is a problem with the interface itself

Hi TI's expert：

Looking forward to your update！

Hi,

1) This portion of the driver is not tested by TI (as it is unused). However, I have been made aware by a colleague that the mode register read function has a bug.

2) Regardless of #1 above, the SDK does NOT support multiple configurations. 

Regards,
Kevin

Hi Kevin S

I don't understand your second point #2 above. Normally, it should support the ability to read the ddr manufacturer id. This is also a common application in the industry. I verified that there is a problem with the TI SDK. Can you help solve this problem?

Hi KevinS:

I don't understand your second point #2 above. Normally, it should support the ability to read the ddr manufacturer id. This is also a common application in the industry. I verified that there is a problem with the TI SDK. Can you help solve this problem?

Kevin,

I believe here the request is only to get the "ddr manufacturer id. " & not for multiple configs. Is there a way to read the DDR manufacturer ID from SBL?

- Keerthy

Hi Keerthy：

My thoughts are with you, are you also an engineer at TI? We at Baidu need your assistance to solve this problem, and it is also conducive to the expansion of the TDA4 platform

Hi Keerthy, Jianye,

jianye li1 said:

we need to read the DDR manufacturer ID in sbl, and then do the corresponding initialization for the ddr of this model

I interpreted the original request as:

Step 1) Read the LP4 mode register to get manufacturer ID

Step 2) Initialize the LP4

I assumed the purpose of Step 1 is so that the bootloader knows how to initialize the LP4 (in the case where multiple different memories are used in the same system).

If the intent of reading the mode register is just informational and is not being used to determine how registers are programmed, then reading the LP4 mode register could be supported IF the steps above are reversed. (i.e, Step 1 = Initialize the LP4;  Step 2 = Read the LP4 mode register)

Regards,
Kevin 

Hi Kevin,

Our needs are
Step 1) Read the LP4 mode register to get manufacturer ID
Step 2) According to the obtained manufacturing ID to initialize the corresponding common applications of LP4 in the industry, it is theoretically achievable, which is also the information provided by the LP4 supplier Micron

1: As you said, if the above steps are reversed, it means nothing to us. Our purpose is to first initialize the LP4 of this model according to the obtained LP4 manufacturer ID.
2: I think it is possible to read the mode register of LP4 before LP4 initialization. This is just a reading action, not config. I don't understand why it is necessary to rely on LP4 initialization to read the LP4 mode register.
Looking forward to your professional answer, thank you

Hi Jianye,

A full initialization is not required, but some initialization procedure has to occur (both within the DDRSS and of the LP4 memory) for the two ICs to be able to communicate. This means that we will need to trigger the DDRSS's hardware initialization routine (even if configured to perform the fewest / simplest steps) before being able to issue an MRR.

As previously mentioned, we do not have any support in the SDK to accomplish what you want to do. I am NOT saying that it is impossible; I am saying that it is not something we support today, and currently have no plans to support in the future. 

As additional information, I do not agree that your request is just a matter of "a reading action". As a full solution, this request requires major code changes to existing code repositories to be able to support multiple configurations (as your desire is to configure the registers depending on the LP4 manufacturer ID). Additionally, we would need to investigate best approach to support (effectively) two initializations of the LP4 memory (1 initialization in simplest form, and 1 initialization with final config). I'd would have to verify, but my recollection is that some of our training algorithms may not behave exactly the same when triggered during first hardware initialization (currently supported) compared to when initiated via software (currently not supported). This is a concern, as we have not tested / characterized the training algorithms in that manner. 

To summarize, my response is not a matter of whether it is possible or impossible. My response is to state what we currently support, and we do not support what you are requesting. 

Regards,
Kevin

Jianye,

One additional comment, if you are using similar memories (i.e, same underlying architecture in terms of data bus width, number of ranks, density), then likely a single config could be used between two different memory vendors and there would be no need to read the LP4 manufacturer ID. 

Additionally, there might be other solutions (like the use of an EEPROM) that could possibly serve as an alternative. If you have more information regarding the DDR part #'s you are looking to use in your system (that would share the same binary), as well as the driving factors on why different memories are needed, that may help us better understand the issue and potential solutions. 

For my own understanding, can you comment on the timeframe of your project that requires support for multiple DDR part #'s?

Thanks,
Kevin

Hi Kevin：

Based on the PATCH software package of Uboot provided by Scholz and Kevin, I transplanted it to SBL. After verification, I can get mMRValue, the value is 0x1C001D,and the function interface is k3_lpddr4_MRR，I do not know whether this value is correct, please help to confirm

Hi,

I have ported the patch to SBL.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_packages_2D00_ti_2D00_board_2D00_src_2D00_j721e_5F00_evm_2D00_board_5F00_ddr.c_2D00_Enable_2D00_L.patch

Please check at your end and share the values read. The patch is based on latest 8.2 SDK.

Best Regards,
Keerthy

Hi Keerthy:

I chose to incorporate this patch into the verification based on sdk7.2, and obtained several key data, but I am not sure if the result is ok, as shown below:

please help confirm

Can you please confirm the DDR part in use & the board that is run on?

- Keerthy

Hi,

Attaching the patch on top of 8.2 SDK U-Boot repository. The patch is tested for Samsung & Micron dynamic DDR detection and configuration.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_ram_2D00_k3_2D00_ddrss_2D00_Enable_2D00_dynamic_2D00_DDR_2D00_part_2D00_detection_2D00_confi.patch

Request Baidu to take a look at the patch & ensure that the end goals are met.
In parallel TI will develop the above approach on SBL.

Note: This is only a proof of concept patch on top of 8.2 SDK. There is scope for further optimization & currently supports 2 DDR configurations.
Either Samsung/Micron.

Best Regards,
Keerthy

Hi Keerthy:

The board I verified is the DDR board of Micron, but I don't know whether the data I read is Micron,

Hi Keerthy:

Our product is ultimately based on SBL, so I want to wait for you to implement this solution based on SBL. We Baidu will verify it finally. Finally, I have a question. Our product is based on sdk7.2. I am not sure whether there is any problem with integration

Hi,

We totally understand that the final product is using the SBL boot flow. I am working towards getting the feature on SBL. This was to just check
with Baidu on the flow correctness on the SPL side as we plan to implement the same design on SBL side as well.

- Keerthy

Hi,

Here is a patch on 8.2 RTOS SDK. That does below:

Add support to detect DDR dynamically. Instead of using one DDR config we now
have 3 configs.

1) A default config with which we bring up DDR to read MR5/6 registers.
2) Based on the read value decide on the DDR either micron or Samsung.
3) Config1 corresponds to micron & config2 corresponds to the other.

Tested only on J721e-EVM with Micron DDR.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_board_2D00_src_2D00_j721e_5F00_evm_2D00_board_5F00_ddr_2D00_Add_2D00_support_2D00_to_2D00_detect_2D00_.patch

Request you to test with other DDR part,

Best Regards,
Keerthy

Hi Keerthy:

I verified this patch and found that the mmrValue read was still 0,This patch you verify OK? Can you see if there is a problem with my environment through Remote Assistance

Hi,

Can you please share the SBL boot logs please?

Below is the logs from our testing:

Hi Keerthy：

Hi Keerthy:

Do you have any progress ？

Hi,

From our side we have been able to boot on both Samsung & micron DDR's with the 8.2 based SBL. Looking at the logs we are seeing that PLL is not locking. Can you try the images you have on 7.1 on the default micron DDR based TDA4 board? Does that work?

- Keerthy

Hi Keerthy:

I verified it based on the DDR card of micro and based on sdk7.1. From the results, it can be seen that the patch provided by you did not work. Otherwise, when will we hold a remote conference to see my environment

Hi,

Please share the patch that you ported on SDK 7.1 We can have a debug call next week once we review your changes.

- Keerthy

Hi Jianye,

Attaching the patch that is now on 7.2 PSDK_RTOS:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_Add_2D00_support_2D00_to_2D00_detect_2D00_DDR_2D00_dynamically._2D00_Instead_2D00_of_2D00_us.patch

Logs:

SBL Revision: 01.00.10.00 (Sep  2 2022 - 09:50:52)
TIFS  ver: 20.8.5--v2020.08b (Terrific Lla
Board_DDRInit: Initializing with default config...
        ddr_freq0 = 27500000
        ddr_freq1 = 533000000
        ddr_freq2 = 533000000
        ddr_fhs_cnt = 10
--->>> LPDDR4 Initialization is in progress ... <<<---
--->>> Frequency Change request handshake is completed... <<<---
        Detecting connected LP4 memory...
        Reading MR5...Rank0 MR5
        Channel A: 0xff
        Channel B: 0xff
MR5=0xff
        Memory matches config 1!
Board_DDRInit: Initializing with final config(1)...
        ddr_freq0 = 27500000
        ddr_freq1 = 1066500000
        ddr_freq2 = 1066500000
        ddr_fhs_cnt = 10
--->>> LPDDR4 Initialization is in progress ... <<<---
--->>> Frequency Change request handshake is completed... <<<---

Please try with MMC-SD boot mode and let me know if this works at your end with micron DDR.

- Keerthy

Hi Keerthy：

I replaced another micro DDR boardcard for testing. SD based on sdk7.2 starts SBL verification. The verification log is shown in the following figure

I need your remote online help, thank you

...