[PATCH v2 5/5] doc: board: nxp: Add Quickboot documentation
Simona Toaca
simona.toaca at oss.nxp.com
Fri Mar 20 16:29:44 CET 2026
Hi,
On Thu, Mar 19, 2026 at 07:02:58PM +0100, Marek Vasut wrote:
> On 3/19/26 4:17 PM, Simona Toaca wrote:
>
> Hi,
>
> > > > If one wants to store the data elsewhere, they could use
> > > > the generic fs methods to make the backup wherever they want, and re-load
> > > > it themselves to the QB_SAVED_STATE_BASE address, so that U-Boot can save
> > > > it from there.
> > >
> > > It would be good to document this mechanism, esp. how to locate the QB data
> > > in RAM and how much data have to be saved into backup storage.
> > >
> >
> > I don't recommend anyone does this sort of backup, although it is possible.
>
> I think I know of at least one such use case.
>
> > I don't see why one would do that since OEI runs training and the data can be
> > saved then. The data is board, ddr configuration and firmare specific,
> > and I wouldn't want to encourage someone to think they could save it and re-use it
> > just like that. Why not re-run OEI and save the data (by using SPL_IMX_QB, for
> > example, which does it automatically)? Or run the training multiple times and use
> > the cmdline qb command to save to all the boot devices?
>
> Consider a device that is trained in factory, at 25C. The training data are
> saved, and backed up. Then, due to some sort of training data corruption, a
> slow retraining happens in field at unknown and possibly very high or very
> low temperature, which could lead to low quality QB data. Worse, the next
> time the device starts, the conditions can be the exact opposite, very low
> or very high temperature and the DRAM may start to suffer from bitflips
> because of that. In this deployment, it is better to use the factory QB data
> from backup than to rely on the in-field training.
>
Low/High temperatures don't generate 'low quality' data, just data
more suitable for that temperature point. If there are issues with the
DRAM, one can erase the data themselves, using 'qb erase', to force a
new training. This way, the data is collected under the current operating
conditions.
If there are any PHY firmware updates, or changes in DDR configuration,
performing training again is necessary, cannot use the 'backup' data.
If the concern also includes the training time, if the data gets
corrupted, the training will happen regardless.
I am not saying it can't be done, I am just saying that for things
to work the proper way, I encourage the usage of 'qb save/erase',
as I said in my previous reply.
[ ... ]
Kind regards,
Simona
More information about the U-Boot
mailing list