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

[Marek Vasut]

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.

>>>>> And the
>>>>> board will boot from the selected configs if one boots from spi.
>>>> Please see above.
>>>>
>>>>>> Looking at this, why can this QB not use the same interface to select
>>>>>> arbitrary block storage device/partition/... that e.g. FS_GENERIC does use ?
>>>>>
>>>>> There is a limited list of boot devices. By keeping things the way they are
>>>>> we limit the usage of this command to the actually useful boot devices (and
>>>>> that we also test this command on).
>>>>
>>>> I would argue that it is better to use generic code instead of hand-writing
>>>> local ad-hoc implementation which is a limited version of the same.
>>>
>>> In the above context, using filesystem methods might not
>>> be feasible.
>> Look at cmd/blk_common.c , that is not filesystem, that is generic interface
>> for block devices.
> 
> I looked through the code and it seems that the driver for the storage device
> has to call blk_create_device in order to be able to use the blk_* commands
> later. MMC indeed does that, and some other drivers. For SPI NAND I could find
> that mtd_bind is called and that calls blk_create_device. But for SPI NOR there
> is no such thing.
> 
> Is there something I missed?

All block devices can (and should) use the unified block device 
accessors, otherwise this will only add yet another ad-hoc block device 
handling. MTD devices may have to be special cased.