[PATCH v4 1/4] imx9: Add support for saving DDR training data to NVM

[Simona Toaca]

Hello Emanuele,

On Mon, May 25, 2026 at 10:59:00AM +0200, Emanuele Ghidoli wrote:
> 
> 
> On 4/30/26 10:33, Simona Toaca (OSS) wrote:
> > From: Simona Toaca <simona.toaca at nxp.com>
> > 
> > +/**
> > + * This structure needs to be aligned with the one in OEI.
> > + */
> > +struct ddrphy_qb_state {
> > +	u32 crc;		  /* Used for ensuring integrity in DRAM */
> > +#define MAC_LENGTH		8 /* 256 bits, 32-bit aligned */
> > +	u32 mac[MAC_LENGTH];	  /* For 95A0/1 use mac[0] to keep CRC32 value */
> > +	u8 trained_vrefca_a0;
> > +	u8 trained_vrefca_a1;
[...]

> > +	u16 acsm[DDRPHY_QB_ACSM_SIZE];
> > +	u16 pst[DDRPHY_QB_PST_SIZE];
> > +};
> 
> Hi Simona,
> 
> Would you consider reserving a small u16 board-defined field at the
> end of struct ddrphy_qb_state? Something like:
> 
> 	u16 board_ddr_config;	/* board-defined tag, opaque to U-Boot */
> 
> Use case: boards that carry multiple LPDDR configurations
> (single-/dual-rank, different sizes, ...). At QuickBoot time the
> boot code needs to know which configuration produced the persisted
> PHY training data, in order to load the matching timing table
> before DDRC init, in OEI. A 16-bit board-defined identifier is enough; the
> value is opaque to U-Boot.
>
I am taking into consideration adding such a field into qb_state
in the future, but for now we do not support a mechanism
for deciding the dram timing at runtime.

> A generic placeholder is equally fine for our purpose, so each
> board/vendor can use it as they see fit.
> 
> Cost on the persisted blob is essentially zero: mac[] (u32) forces
> 4-byte struct alignment, which already leaves 2 bytes of trailing
> padding in the current layout. Adding a u16 field there does not
> change sizeof(struct ddrphy_qb_state) nor the on-storage size.
> 
It means that U-Boot will save those 2 bytes anyway into NVM, so as long as
no other changes are made to the structure, it should be ok for your usecase.

Best regards,
Simona