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

[Marek Vasut]

On 3/18/26 3:20 PM, Simona Toaca wrote:

>>>> Can QB data be saved to arbitrary SPI NOR ?
>>>>
>>>
>>> No, this SPI NOR refers to the SPI controller selected by
>>> the CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS options.
>>
>> Maybe the user would want to make a backup of the QB data to another SPI NOR
>> (e.g. if the device has two, which is not unheard of) ? They should not be
>> prevented from doing so.
>>
>>> The point is that the device we save the data to is also an
>>> option to boot from, otherwise the qb data is useless.
>>
>> The QB data could be stored for backup purposes, that is not useless.
>>
> There is one thing that might make this clearer, and I forgot to
> mention it explicitly:
> 
> The get_qbdata_offset method searches for a 64KB hole in the bootloader,
> so it can save the data there. OEI knows that's where the data
> should be saved. On an arbitrary non-boot device, or, on a filesystem
> partition, the hole would not exist. It is mkimage that puts that
> hole in the bootloader, and U-Boot explicitly checks for container
> header tags.

Uh, is there any danger that this might accidentally corrupt the 
surrounding bootloader ?

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

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