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

[Francesco Dolcini]

On Wed, May 27, 2026 at 05:33:36PM +0300, Simona Toaca wrote:
> 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.

The reality is that we are forking your OEI (AFAIK you do not take
patches) to support our boards and our use case. So we (Toradex) have it
already, and it is working 100% fine.

What is tricky here is that this structure is an ABI / contract between
the OEI firmware and U-Boot.

Just to anticipate your potential answer, our boards just work with
mainline U-Boot, so asking us to have a patch and fork U-Boot is not an
option.

Francesco