[PATCH v2 5/5] doc: board: nxp: Add Quickboot documentation

[Marek Vasut]

On 3/20/26 4:29 PM, Simona Toaca wrote:

Hello Simona,

>> 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.

This may be something a developer may do with a singular devkit, but 
this is not something one can do on a fleet of deployed devices.

In deployment, if the device breaks and cannot automatically recover 
itself, it is broken and useless, and that makes users unhappy. If the 
device becomes unstable, e.g. because it was moved from hot environment 
to cold environment which is the normal mode of operation for some of 
the devices, then it is broken, see above.

The solution is simple -- keep factory produced training data around.

> If there are any PHY firmware updates, or changes in DDR configuration,
> performing training again is necessary, cannot use the 'backup' data.

Not all of these devices are connected to the internet, this is not 
applicable.

> If the concern also includes the training time, if the data gets
> corrupted, the training will happen regardless.

This is also not applicable.

> 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.
What I am saying is, that the user should have a way to save QB data to 
arbitrary location of their choosing. If they then decide to restore 
those QB data in OEI because the original QB data were corrupted, that 
is up to them to patch the OEI. But that option should be available to 
the users, because there is a use case for that. And there is a generic 
way to specify the target storage device, at least for block devices.

[...]