DRA829V: DDR initialization sequence

Why do you need to re-write the DDR initialization sequence?

We need to re-write everything in terms of code.
If you ask about sequence itself (functional), we need to be able to explain each statement, its purpose and reason. And if some piece of code is not traceable to TRM or any other document, how can we explain it?

Dmitry Tuykov said:

We need to re-write everything in terms of code.

Why do you need to re-write the code? In other words, what functionality is missing and/or why does the current code not work in your system?

Regards,
Kevin 

Hi Kevin,

the problem is that the existing functionality is hardly traceable to any TI documentation, therefore I'm asking to explain some aspects (my initial message) and also ask if there are plans to give more information in the TRM or in a separate application notes. In other words we have a piece of code which is supposed to configure DDR, but we cannot explain how it is done and we cannot check and guarantee that there is no error/bug.

Also we simply cannot use the existing code cause we are working on DO-178 application and, I suppose, the existing code was not created acc. to DO-178 and there is no necessary life cycle data (plans, requirements, design, tests etc.).

All in all I'm still looking forward for a help with the initial questions.

Best regards,
Dmitry

Dmitry,

Is your requirement that you need comments included in source to trace each line of code to a document, or do you actually need to make changes impacting the compiled binary? What about all register settings of the DRA829 device (both modified by software and registers left un-touched)?

Is it a fair assumption that likely all TI delivered drivers for DRA829 are non-compliant to DO-178, or is this unique to DDR? If all drivers are non-compliant, how is this being handled for other interfaces?

In general, it is not recommended nor supported to customize the DDR driver. Register settings (including the parameter DDRSS_PLL_FHS_CNT) should come from the DDR register configuration tool (https://www.ti.com/lit/pdf/spracu8 ), which allows some customization to account for DDR memory device differences (example: different density, width, etc.) or optimizing IO settings for a particular PCB design.

At this time, there are no plans to update the DDR controller section of the TRM to elaborate on the details you are requesting.

Regards,
Kevin

Hi Kevin,

Kevin S said:

Is your requirement that you need comments included in source to trace each line of code to a document, or do you actually need to make changes impacting the compiled binary? What about all register settings of the DRA829 device (both modified by software and registers left un-touched)?

We do not need to comment each line of code. Ideally we need to write our own drivers based on TI's documentation (e.g. TRM, application notes, etc.) and our needs only. But let's be realistic, TRMs are not always precise enough and we can use TI's code as a supplement to understand functionality better. But with DDR the situation is worse than usual, TRM is almost empty as well as existing code does not bring more understanding of the made settings and the used sequences.

Regarding the other peripherals the story is the same. If a peripheral/module is used we need to configure it correctly and we should know what we are doing, we cannot rely on any existing and not certified code. So yep, we are checking everything and yes with J7 it is not so trivial as with simple TI MCUs.

Kevin S said:

Is it a fair assumption that likely all TI delivered drivers for DRA829 are non-compliant to DO-178, or is this unique to DDR? If all drivers are non-compliant, how is this being handled for other interfaces?

We are already creating our drivers for everything what is used, ideally based on the TI documentation. If there is a lack of info, we are coming here :)

Kevin S said:

In general, it is not recommended nor supported to customize the DDR driver. Register settings (including the parameter DDRSS_PLL_FHS_CNT) should come from the DDR register configuration tool (https://www.ti.com/lit/pdf/spracu8 ), which allows some customization to account for DDR memory device differences (example: different density, width, etc.) or optimizing IO settings for a particular PCB design.

We do not need to modify it, we need to write our driver, which is ideally based on official documentation and highly probable will do the same as TI's driver does. But to do it, we need to know the procedure to initialize the DDR. I see that there is something in the TRM, but no complete picture, not clearly defined sequence of actions to be done.

DDR register configuration tool is not a qualified tool and therefore we cannot use it as an official source, only as an example/supplement. But the question about the registers I left outside of this thread on purpose, it is a bit complicated and we probably come to it later. Now I'm just trying to get information about the configuration sequence only, top level stuff.

Kevin S said:

At this time, there are no plans to update the DDR controller section of the TRM to elaborate on the details you are requesting.

Pity to hear it, but honestly it is a bit strange to me. The information in the TRM seems to be not completed, but there is something defined. You tell me that configuration not recommended and not supported but all 2000+ registers are part of the documentation in some form. There is some contradiction about it.

Altogether is there any chance to get some clarifications regarding the configuration sequence and answers on the questions listed in the 1st message?

Best regards,
Dmitry

Hi Dmitry,

Our DDR driver plus TRM and DDR register configuration tool (https://www.ti.com/lit/pdf/spracu8) are what we have to enable customers to bring up DDR on the custom board.

For the additional information needed in case of DO-178 certification, we will follow up and get back to you.

Regards,
Stanley

Hi Stanley,

thank you and looking forward for the information from your side.

Best regards,
Dmitry

Dmitry,

Customization is not supported. Regarding some of your questions:

#5 

Dmitry Tuykov said:

Is DDR training a part of the current initialization routine (PDK)? If yes, where can I find the corresponding code?

Yes, training should always be enabled during initialization. It is performed by hardware automatically when enabled in the registers. Software's role is to ensure that the hardware training is enabled, and to support frequency change requests during command bus training. The register configuration tool enables initialization training and does not provide an input for the customer to disable this. The trainings that are enabled are documented in the "supported features" section of the register configuration tool application note: https://www.ti.com/lit/pdf/spracu8 

#2

Dmitry Tuykov said:

LPDDR4_Start function contains settings of DDRSS_PI_5.PI_INIT_LVL_EN and DDRSS_PI_5.PI_NORMAL_LVL_SEQ to 1.
I cannot link these setting to the TRM and description of the registers is unclear to me. Could you please explain these settings.

These are both already enabled by the register configuration tool (v0.10.0), so setting them in the driver is redundant. As stated in the answer to #5, training (or "leveling") is performed by hardware; therefore, PI_INIT_LVL_EN should be enabled. PI_NORMAL_LVL_SEQ is recommended to be enabled.

#3

Dmitry Tuykov said:

Chapter 'PI Initialization' of the TRM says that PI initialization complete is indicated by 'dfi_init_complete'. But what is 'dfi_init_complete', which register is it?

'dfi_init_complete' is an internal status interface signal between the controller and PHY (the DDR PHY interface, or DFI). The DFI interface is standardized, and you can read about this signal in the DFI specification. 

#4

Dmitry Tuykov said:

Number of this iterations is determined by the define 'DDRSS_PLL_FHS_CNT'. In different PDK versions I saw different values - 5, 6 or 10. But I would like to understand what is the basis of these iterations, what I need to know to define this constant correctly.

This parameter should be set by the register configuration tool. It is dependent on the number of ranks and frequency set points enabled.

Dmitry Tuykov said:

And if we do not need to support two clocks and FSP, can we simplify initialization sequence here somehow?

No, you cannot because at the very minimal you need to change frequency 3 times during command bus training. It is required by the LPDDR4 memory to boot at a slow frequency. Please read about command bus training in your memory's datasheet and/or the LPDDR4 JEDEC standard.

#6

Dmitry Tuykov said:

For example PLL is being configured after PI, PHY and controller is triggered to be initialized, but why at this time point, why not before?

As stated in answer to #4, it is required by the LPDDR4 memory to boot at a slow frequency. This is documented in the LPDDR4 memory datasheet and/or LPDDR4 JEDEC standard. Additionally, it is required to change the clock frequency during command bus training. Therefore, the PLL gets reconfigured several times after the PI, PHY, and Controller registers are programmed and the START bits are enabled.

Hi Kevin,
Hi Stanley,

please keep the thread open for a while, I need a bit time to analyze your answer.

Regards,
Dmitry