Hi Ahmad,

On 12/19/2024 6:27 PM, Ahmad Fatoum wrote:

Hello Peng,

On 30.09.24 08:38, Peng Fan wrote:

...

...

Subject: i.MX8/9: question about unused DDR PHY trained CSR board array Looking at the DDR setup code for i.MX8M and i.MX9 that you had contributed, I am wondering about struct dram_cfg_param::ddrphy_trained_csr and the global ddrphy_trained_csr array.

struct dram_cfg_param::ddrphy_trained_csr is presumably generated by the i.MX DDR tool and it seems populated by all the i.MX8M/9 boards in U-Boot.

This struct member is wholly unused though and instead a global ddrphy_trained_csr is used.

What I wonder about is whether it's possible for the DDR tool to generate a different ddrphy_trained_csr than the default:

1. If yes, we should drop the global ddrphy_trained_csr and actually

use the board-specific array

2. If not, we should drop the board-specific array and perhaps ask for

 the DDR tool to be changed

I initially assumed 1) and because all boards supported by barebox had a board-specific ddrphy_trained_csr that's identical to the global ddrphy_trained_csr, I dropped the unused array[1][2].

I now have the DDR settings for an i.MX9 LPDDR4 board in front of me that has different contents for struct dram_cfg_param::ddrphy_trained_csr than the default.

I will inquire how that came about, but in parallel I wanted to ask you if this is supposed to happen and to alert you to this issue.

Thanks for raising this issue. I think board specific csr should be used.

I will check with DDR TOOL owners on this.

Did you hear back in the meantime?

Thanks, Ahmad

We have discussed this internally. The DDR tool may generate different board specific csr. Currently in DDR retention, because we load csr + ddr_phy_pie, so it is safe to use this global csr.

But we agree this global csr is confused and waste some memory. It is better to switch to the board csr.

Best regards,

Ye Li

...

...

The way things are, this is either a bug or a missed space saving opportunity for U-Boot.

Thanks, Peng.

Hi Ahmad,

On 12/20/2024 2:12 PM, Ahmad Fatoum wrote:

[You don't often get email from a.fatoum@pengutronix.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hello Ye Li,

On 20.12.24 02:58, Ye Li wrote:

...

On 12/19/2024 6:27 PM, Ahmad Fatoum wrote:

...

On 30.09.24 08:38, Peng Fan wrote:

...

...

I now have the DDR settings for an i.MX9 LPDDR4 board in front of me that has different contents for struct dram_cfg_param::ddrphy_trained_csr than the default.

I will inquire how that came about, but in parallel I wanted to ask you if this is supposed to happen and to alert you to this issue.

Thanks for raising this issue. I think board specific csr should be used.

I will check with DDR TOOL owners on this.

Did you hear back in the meantime?

We have discussed this internally. The DDR tool may generate different board specific csr. Currently in DDR retention, because we load csr + ddr_phy_pie, so it is safe to use this global csr.

So ddr_phy_pie contains the firmware to the DDR PHY µC and it will train the PHY and thus will iron over any missing entries in the stored CSR? Is my understanding correct?

PIE is not used for training and does not contain firmware. It sequences PHY initialization like pll lock, power gating, etc.

Normally its configuration registers should be saved as a part of ddrphy_trained_csr list. Our DDR expert thinks the major missing in the global CSR is the PIE configuration registers.

Best regards,

Ye Li

...

But we agree this global csr is confused and waste some memory. It is better to switch to the board csr.

Thanks for the confirmation.

Cheers, Ahmad

-- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |