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 <[email protected]> > > > > +/** > > + * 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
