i.MX ProcessorsのトピックRe: DDR_PHY programming issue on IMX8M board

DDR_PHY programming issue on IMX8M board

vyacheslavbonda — Mon, 26 Aug 2019 08:16:02 GMT

Hello!

Trying to bring up DDR controller on out own board based on IMX8M processor. Without success for now,

We are using DDR4 memory. Tried to use MSCALE_ddr_tool utility, log and DDR script is attached.

There is a problem with our board with DDR data bus connection -- DQ pins swapped. As I was able to understand from Reference manual, this may be fixed by setting appropriate values to DDR_PHY.DWC_DDRPHYA_DBYTEn.Dq[0-7]LnSel[0:3], but wasn't able to write to that registers from u-boot or from DDR script of MSCALE_DDR_tool utility. Writing from U-Boot SPL has no effect, reading back as zeroes(actually, all DDR_PHY registers reads as zeroes). It seems some basic initalization wasn't done for DDR_PHY(clocks or something like that)...

We are using uboot-imx version imx_v2017.03_4.9.88_2.0.0_ga, u-boot config imx8mq_arm2(by the way, from what board this config is and can we look at it's schematic?).

How we can set DDR_PHY.DWC_DDRPHYA_DBYTEn.Dq[0-7]LnSel[0:3] registers from U-Boot?

Additionally, I can't figure out DDR_PHY register address calculation principle. In RM we have DDR_PHY base 0x3c000000, DWC_DDRPHYA_DBYTE0 block offset 0x10000, and Dq0LnSel register offset 0x140, so address should be 0x3c010140. But in MX8M_LPDDR4_RPA_v23.xlsx file(which was used as a reference to generate "memory set" commands for DS) address specified for that register is 0x3C040280. I can understand that register offset should be multiplied by 2, because it's 16-bit word offset, but why block offset multiplied by 4?? How to determine register addresses of DDR_PHY block? For our experiments with U-Boot we used addresses from MX8M_LPDDR4_RPA_v23.xlsx.

Regards,

Vyacheslav Bondarev

Re: DDR_PHY programming issue on IMX8M board

Yuri — Wed, 28 Aug 2019 03:52:10 GMT

Hello,

For LPDDR4, there is Exceel sheet “BoardDataBusConfig” in “MX8M_LPDDR4_RPA_v23.xlsx”

to provide proper data bus mapping.

Customers can try using init code (# DDR PHY DQ lane to memory mapping ) from

the LPDDR4 RPA. Note, the initialization file is meant specifically for the DDR Stress Test

GUI tool, but not for a JTAG debugger or U-boot. So, follow instructions “MSCALE_DDR_Tool_User_Guide.pdf”

in mscale_ddr_tool_v2.10 package how to port corresponding settings to BSP after memory testing.

Have a great day,

Yuri

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

-------------------------------------------------------------------------------

Re: DDR_PHY programming issue on IMX8M board

vyacheslavbonda — Wed, 28 Aug 2019 07:10:35 GMT

Hello, Yuri! Thank you for your reply.

We tried the "BoardDataBusConfig" sheet from MX8M_LPDDR4_RPA_v23.xlsx already. IMX8M.ds file attached to my original message contains it's results("memory set 0x3c04xxxx ..." commands copied from "DDR stress test file" sheet of MX8M_LPDDR4_RPA_v23.xlsx file). I understand, that "memory set" is only for DDR Stress Test GUI tool, but it's possible take pairs of register address/value and pass it as reg32_write function arguments in u-boot, right?

I can't follow instructions in MSCALE_DDR_Tool_User_Guide.pdf because calibration on our board is not working. Log is also attached to my original message. I understand, that problem may be caused by mistakes in our board, but what means error from MSCALE_DDR_Tool "PMU: Error: Dbyte 0 couldn't find the rising edge of DQS during RxEn Training" and how to debug it?

Can I read somewhere detailed description of DDR thraining process?

What is the block of DDR_PHY with offset 0x50000, where, according to u-boot, trainig code is loaded?

Why after executing ddr4_phyinit_train_2400mts() function in u-boot DDR_PHY registers become unaccessible(always reads as 0, can't be written)?

Hope you can help me...

Regards,

Vyacheslav Bondarev

Re: DDR_PHY programming issue on IMX8M board

Yuri — Thu, 29 Aug 2019 06:05:07 GMT

Hello,

According to section 4.3 (Building u-boot image) of i.MX8/MSCALE DDR Tool User’s Guide,

Rev. V1.1.0, located in “mscale_ddr_tool_v210” package:

MX8MSCALE integrates a MCU based DDR PHY, which needs to load DDR firmware before

DDR initialization. The version of the DDR firmware used in the BSP may differ from the

version used by the MSCALE DDR Tool. The MSCALE DDR tool always uses the latest

firmware. When you use the DDR tool generated SPL codes instead of the original ones,

please make sure to replace all firmware binaries with DDR tool provided in the bin directory.

So, it is needed to build U-boot just for Your board.

Regards,

Yuri.

Re: DDR_PHY programming issue on IMX8M board

vyacheslavbonda — Thu, 29 Aug 2019 10:58:49 GMT

Hello!

Thank you for pointing out to firmware replacement necessity after code generation with MSCALE DDR Tool, it's may be important. But it's not a question for now, which version of DDR_PHY firmware to use in U-Boot, because neither is working. Code generation is not working...

In the meantime, I was performing my own investigation, what may lead to MSCALE_DDR_Tool error "PMU: Error: Dbyte 0 couldn't find the rising edge of DQS during RxEn Training". As far as I can understand, RxEn training(which also called "read preamble training"?) starts with DQS signal assertion, which also reads back into PHY and checked by the MSCALE_DDR_Tool. The response is not comply, so we get that error. Question is, why PHY can't see DQS pulse, while it's present on the line(we see it by oscilloscope)?

Regards,

Vyacheslav Bondarev

Re: DDR_PHY programming issue on IMX8M board

Yuri — Fri, 30 Aug 2019 07:46:23 GMT

Hello,

Please try to fine tune ATxImpedance / ODTImpedance / TxImpedance parameters to find a reasonable

window. Please refer to RPA tool for the details and available options of the above parameters.

Also, section 4.2 (Run DDR Calibration and generate DDR initial code) of

"MSCALE_DDR_Tool_User_Guide.pdf" may be helpful.

Regards,

Yuri.

Re: DDR_PHY programming issue on IMX8M board

vyacheslavbonda — Fri, 30 Aug 2019 11:41:12 GMT

Hello,

We tried to adjust impedance settings in RPA tool. When we set ODTImpedance to 240 Ohm, error message changed to

"PMU: Error: Dbyte 1 couldn't find the rising edge of DQS during RxEn Training". Is that means that DByte 0 DQS check completed successfully and MSCALE_DDR_Tool goes to Dbyte 1 checking, which fails? ATxImpedance and TxImpedance has no impact on this result, we tried different values.

Also, I tried changing TrainInfo parameter value to 0x05, as recommended in MSCALE_DDR_Tool_User_Guide.pdf, chapter 4.2 to get detailed debug messages, but got no additional messages.

How to determine proper value for PhyVref parameter(0x36 in RPA by default)?

Regards,

Vyacheslav Bondarev

Re: DDR_PHY programming issue on IMX8M board

Yuri — Mon, 02 Sep 2019 07:26:42 GMT

Hello,

the relation between the Vref and PhyVref value is as follows:

Vref = VDDQ*PhyVref/128

If the initial value is applied:

Vref = 1100*0x11/128 = 146.1 mV

Note that this setting affects only Vref for the reads.

Regards,

Yuri.

Re: DDR_PHY programming issue on IMX8M board

Yuri — Mon, 02 Sep 2019 08:46:31 GMT

Yes, Dbyte1 RxEn training failed. Dbyte0 passed.

~Yuri.

Re: DDR_PHY programming issue on IMX8M board

vyacheslavbonda — Mon, 02 Sep 2019 09:46:45 GMT

Hello,

Can this failure be caused by improper ODT signal connection? In our board all ODT inputs of DRAM is wired from ODT0 of CPU. Can we override this by setting DDRC_ODTMAP register?

Regards,

Vyacheslav Bondarev

Re: DDR_PHY programming issue on IMX8M board

Yuri — Tue, 03 Sep 2019 08:15:41 GMT

Hello,

i.MX8M ODT0 - for CS0; ODT1 - for CS1. I've sent You schematic example.

You can try to use DDRC_ODTMAP for testing.

Regards,

Yuri.

Re: DDR_PHY programming issue on IMX8M board

vyacheslavbonda — Wed, 04 Sep 2019 12:17:09 GMT

Hello,

We tried remap ODT signals through DDRC_ODTMAP, with no success. As I understand, ODT is suitable for terminating inactive DRAM device, which is sharing same DQ bus. But in our configuration DRAM devices does not sharing DQ bus, so ODT signal is unused. Is that correct?

Also we performed some tests to find some new solution for that problem. Last time we passed RxEn training for DByte 0, when we set ODTImpedance to 240 Ohm. This time we got same result when we just disabled address mirroring for channel 1. Yes, DByte 0 RxEn training passed, when we disabled address mirroring for DByte 1. Interesting, that in case address mirroring disabled, ODTImpedance has no more impact on result. What is it could mean?

Regards,

Vyacheslav Bondarev

Re: DDR_PHY programming issue on IMX8M board

Yuri — Tue, 10 Sep 2019 04:32:14 GMT

Hello,

It is possible to apply ODT for terminating not only inactive DRAM device, but
for active DRAM too, depending on ODT/Rank Map Register (ODTMAP) settings.
In Your case, when the second rank (CS1) is not used address mirroring
should be disabled. What do You mean "disabled address mirroring for DByte 1"?
If this is hardware approach - it is OK.

Regards,

Yuri.

Re: DDR_PHY programming issue on IMX8M board

azurind — Wed, 03 Mar 2021 15:26:47 GMT

I'm having a similar issue, what was the resolution for your board? Thank you!

Re: DDR_PHY programming issue on IMX8M board

melon87 — Thu, 04 Jan 2024 19:47:54 GMT

@azurind @vyacheslavbonda Me too - did you solve it? If so - how?

Re: DDR_PHY programming issue on IMX8M board

melon87 — Thu, 04 Jan 2024 20:00:22 GMT

@Yuri - I am having the same issue "MSCALE_DDR_Tool "PMU: Error: Dbyte 0 couldn't find the rising edge of DQS during RxEn Training".

We have used the latest tool, in admin and updated script using the spreadsheet.

I need to try to update the pin mapping as you advise - using the LP-DDR spreadsheet and also check PhyVref value is correct. Would both of these being wrong cause the above error message? If not, what else should we look at?

Thanks in advance