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

[Simon Glass]

Hi Simona,

On Tue, 21 Apr 2026 at 01:41, Simona Toaca <simona.toaca at oss.nxp.com> wrote:
>
> Hi,
>
> On Tue, Apr 07, 2026 at 12:13:51PM -0600, Simon Glass wrote:
> > Hi Simona,
> >
> > On Mon, 6 Apr 2026 at 02:28, Simona Toaca <simona.toaca at oss.nxp.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, Apr 05, 2026 at 05:49:56AM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Thu, 2 Apr 2026 at 03:29, Simona Toaca (OSS)
> > > > <simona.toaca at oss.nxp.com> wrote:
> > > > >
> > > > > From: Simona Toaca <simona.toaca at nxp.com>
> > > > >
> > > > > DDR training data can be saved to NVM and be available
> > > > > to OEI at boot time, which will trigger QuickBoot flow.
> > > > >
> > > > > U-Boot only checks for data integrity (CRC32), while
> > > > > OEI is in charge of authentication when it tries to
> > > > > load the data from NVM.
>
> [ ... ]
>
> > > > Note that this feature is present on x86 boards already.
> > > >
> > > > I wonder if we could make this more generic? E.g. it could be a
> > > > function of UCLASS_RAM ? I could do the x86 part to try it out if you
> > > > like.
> > > >
> > >
> > > Can you please point me to the implementation for x86? This Quickboot
> > > feature is specific to Synopsis DDR PHYs, and the location where we
> > > save this data is specific to iMX9 series (since it is needed by OEI).
> > > I need a bit more details about what you mean.
> >
> > Yes, if you look at mrccache_save() you will see how this works. It is
> > controlled by a flash layout within the SPI-flash node:
> >
> >  spi: spi {
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> >     compatible = "intel,ich9-spi";
> >     spi-flash at 0 {
> >        #address-cells = <1>;
> >        #size-cells = <1>;
> >        reg = <0>;
> >        m25p,fast-read;
> >        compatible = "winbond,w25q64dw",
> >           "jedec,spi-nor";
> >        memory-map = <0xff800000 0x00800000>;
> >        rw-mrc-cache {
> >           label = "rw-mrc-cache";
> >           reg = <0x005e0000 0x00010000>;
>
> [ ... ]
>
> Sorry for the late reply.
>
> By 'UCLASS_RAM' you mean having a SoC-specific RAM driver
> (e.g. 'imx9_dram') that implements 'get_info' and a set of
> methods for training data check/save/erase?
>
> mrccache does not have the checking/erasing option, but it
> has mrccache_reserve/mrccache_get_region public methods that
> do not have an equivalent in quickboot.
>
> In this context, it feels like the exposed methods for dealing
> with training data do not have a unified interface, so in reality
> the only common ground is the 'save' method, and that would also
> need parameters for specifying the boot device to save to (as this
> is an option in qb, but not in mrc).
>
> Also, because you mentioned the SPI flash node for specifying
> the saving location in SPI, this wouldn't work for the i.MX quickboot
> implementation. The saving location is a space in the bootloader
> that depends on the other components' sizes, so it is not a fixed addres.

Yes that's what I mean by uclass RAM. Yes, at the moment it does not
have methods for caching the parameters, but it could be added.

If you have the energy and interest to design something here, please
do. I could convert x86 over to use it.

But it's up to you.

Regards,
Simon