Question on I.MX8M Mini write/read DQ delay registers

[dsmith]

In one of our design we are making small adjustments to the DDR data lines and are trying to determine if our software also needs to be updated to account for these changes. In combing through the reference manual I found several registers referring to the read/write delay of the DQ lines. However these registers have an offset formula that goes with them that I don't fully understand.

What do X and N refer too? I first thought that N was referring to the eight data lines this register seems to control, but the fields section list a different offset for the data lines. 

Also what are the timing groups 0 through 3? The reference manual doesn't seem to define what these are.

[pengyong_zhang]

HI @dsmith 

The document is " DesignWare Cores DDRn PHY Training Firmware Application Note". You can contact Synopsys and get this document.

B.R

[dsmith]

@pengyong_zhang What exactly is the Synopsys document? Do you mean the processor reference manual and if so where in the reference manual is this discussed? I found a few notes in chapter 9 in sections 9.3.2.3.3 and 9.3.2.4.2 that vaguely reference some kind of calibration being done, but nothing at the level of detail we discussed here. If you are not referring to the reference manual can you link me to the Synopsys document?

[pengyong_zhang]

HI @dsmith 

However, this didn't seem to do anything. Should it have?

>>>It should not be modified by yourself

Is this correct and if it is where can I find relevant documentation discussing this?

>>>Yes, you are right! and you can find it on Synopsys document.

B.R

[dsmith]

@pengyong_zhang 

To answer your question about the DDRC register in case 2, I added a line to try and change one of the write delay dq registers ({0x3c010180, 0x18},). However, this didn't seem to do anything. Should it have?

About case 1, your statement seems to imply (to me at least) that the write DQ delay timings are automatically calibrated and set to the appropriate value during boot. Is this correct and if it is where can I find relevant documentation discussing this? To come back to the big picture, we have a working design with working software, but due to manufacturing issues need to swap to a new DDR that will cause some of the DQ data lines to change in length. We also don't want to change our software as we don't want to have two different hardware configurations that need two different software's. So we were trying to manual adjust the DDR timings to see if this change in length will affect our software. However, if my assumption based on what you said is true (that the software automatically handles the timings during boot), then this would be a non-issue.

[pengyong_zhang]

HI @dsmith 

For your case1 :Yes, you are right. The DDT PHY  timing parameters will be calibrated when at each time board boot, And it will apply the calibration value. you can not modify it by yourself.

Your case 2 : About the DDRC register, Which register did you change? I think if you change the DDRC register, it should be applied. However, we strongly recommend not modifying registers related to time parameters, It may be defined by more than just this one register and may have unpredictable consequences.

B.R

[dsmith]

@pengyong_zhang Another question I have is how do I change these registers? We are trying to adjust these registers as in our design we are making small adjustments to the DDR data lines and are trying to determine if our software also needs to be updated to account for these changes. However, nothing I have tried seems to work. I have tried writing a new value to register 0x3c010180 to increase the delay to something that should break the system in both Linux and uboot with devmem2 and mw respectively, but when I then read the value back, it is unchanged.

u-boot=> mw 0x3C010180 0x00000040
u-boot=>
u-boot=> md 0x3C010180
3c010180: 00000000 00000000 00000000 00000000    ................
3c010190: 00000000 00000000 00000000 00000000    ................
3c0101a0: 00000000 00000000 00000000 00000000    ................
3c0101b0: 00000000 00000000 00000000 00000000    ................
3c0101c0: 00000000 00000000 00000000 00000000    ................
3c0101d0: 00000000 00000000 00000000 00000000    ................
3c0101e0: 00000000 00000000 00000000 00000000    ................
3c0101f0: 00000000 00000000 00000000 00000000    ................
3c010200: 00000000 00000000 00000000 00000000    ................
3c010210: 00000000 00000000 00000000 00000000    ................
3c010220: 00000000 00000000 00000000 00000000    ................
3c010230: 00000000 00000000 00000000 00000000    ................
3c010240: 00000000 00000000 00000000 00000000    ................
3c010250: 00000000 00000000 00000000 00000000    ................
3c010260: 00000000 00000000 00000000 00000000    ................
3c010270: 00000000 00000000 00000000 00000000    ................
u-boot=>

I have also tried adding in the changed register value into lpddr4_timing.c and recompiling my image in case the register is a protected value, but the image still boots and the register appears unchanged when I read it.

static struct dram_cfg_param ddr_ddrc_cfg[] = {
/** Initialize DDRC registers **/
{0x3d400304, 0x1},
{0x3d400030, 0x1},
{0x3d400000, 0xa1080021},
{0x3d400020, 0x222},
{0x3d400024, 0x3a980},
{0x3d400064, 0x2d00d2},
{0x3d4000d0, 0xc00305ba},
{0x3d4000d4, 0x940000},
{0x3d4000dc, 0xd4002d},
{0x3d4000e0, 0x310000},
{0x3d4000e8, 0x66004d},
{0x3d4000ec, 0x16004d},
{0x3d400100, 0x191e0c20},
{0x3d400104, 0x60630},
{0x3d40010c, 0xb0b000},
{0x3d400110, 0xe04080e},
{0x3d400114, 0x2040c0c},
{0x3d400118, 0x1010007},
{0x3d40011c, 0x402},
{0x3d400130, 0x20600},
{0x3d400134, 0xc100002},
{0x3d400138, 0xd8},
{0x3d400144, 0x96004b},
{0x3d400180, 0x2ee0017},
{0x3d400184, 0x2605b8e},
{0x3d400188, 0x0},
{0x3d400190, 0x497820a},
{0x3d400194, 0x80303},
{0x3d4001b4, 0x170a},
{0x3d4001a0, 0xe0400018},
{0x3d4001a4, 0xdf00e4},
{0x3d4001a8, 0x80000000},
{0x3d4001b0, 0x11},
{0x3d4001c0, 0x1},
{0x3d4001c4, 0x1},
{0x3d4000f4, 0x699},
{0x3d400108, 0x70e1617},
{0x3d400200, 0x1f},
{0x3d40020c, 0x0},
{0x3d400210, 0x1f1f},
{0x3d400204, 0x80808},
{0x3d400214, 0x7070707},
{0x3d400218, 0x7070707},
{0x3d40021c, 0xf0f},
{0x3d400250, 0x29001701},
{0x3d400254, 0x2c},
{0x3d40025c, 0x4000030},
{0x3d400264, 0x900093e7},
{0x3d40026c, 0x2005574},
{0x3d400400, 0x111},
{0x3d400408, 0x72ff},
{0x3d400494, 0x2100e07},
{0x3d400498, 0x620096},
{0x3d40049c, 0x1100e07},
{0x3d4004a0, 0xc8012c},
{0x3d402020, 0x20},
{0x3d402024, 0x7d00},
{0x3d402050, 0x20d040},
{0x3d402064, 0x6001c},
{0x3d4020dc, 0x840000},
{0x3d4020e0, 0x310000},
{0x3d4020e8, 0x66004d},
{0x3d4020ec, 0x16004d},
{0x3d402100, 0xa040105},
{0x3d402104, 0x30407},
{0x3d402108, 0x203060b},
{0x3d40210c, 0x505000},
{0x3d402110, 0x2040202},
{0x3d402114, 0x2030202},
{0x3d402118, 0x1010004},
{0x3d40211c, 0x302},
{0x3d402130, 0x20300},
{0x3d402134, 0xa100002},
{0x3d402138, 0x1d},
{0x3d402144, 0x14000a},
{0x3d402180, 0x640004},
{0x3d402190, 0x3818200},
{0x3d402194, 0x80303},
{0x3d4021b4, 0x100},
{0x3d4020f4, 0x599},
{0x3d403020, 0x20},
{0x3d403024, 0x1f40},
{0x3d403050, 0x20d040},
{0x3d403064, 0x30007},
{0x3d4030dc, 0x840000},
{0x3d4030e0, 0x310000},
{0x3d4030e8, 0x66004d},
{0x3d4030ec, 0x16004d},
{0x3d403100, 0xa010102},
{0x3d403104, 0x30404},
{0x3d403108, 0x203060b},
{0x3d40310c, 0x505000},
{0x3d403110, 0x2040202},
{0x3d403114, 0x2030202},
{0x3d403118, 0x1010004},
{0x3d40311c, 0x302},
{0x3d403130, 0x20300},
{0x3d403134, 0xa100002},
{0x3d403138, 0x8},
{0x3d403144, 0x50003},
{0x3d403180, 0x190004},
{0x3d403190, 0x3818200},
{0x3d403194, 0x80303},
{0x3d4031b4, 0x100},
{0x3d4030f4, 0x599},
{0x3d400028, 0x0},
{0x3c010180, 0x18},
};

[pengyong_zhang]

hi @dsmith 

 X = 0 to 3, means 1Byte to 4Byte. n = 0 to 8 means 8 DQ lines of one Byte.

And i think timing groups have same explain with X.

B.R