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

[Marek Vasut]

On 3/17/26 1:53 PM, Simona Toaca wrote:
> On Mon, Mar 16, 2026 at 01:32:48PM +0100, Marek Vasut wrote:
>> On 3/16/26 9:15 AM, Simona Toaca (OSS) wrote:
>>
>>> +After successful saving, U-Boot clears the data in volatile memory so
>>> +that qb check fails at next reboot and the NVM isn't accessed again.
>>> +
>>> +There are 2 ways to save this data (both can be enabled):
>>
>> Replace () with , .
>>
>>> +1. automatically, in SPL (by enabling CONFIG_SPL_IMX_QB)
>>> +
>>> +- this will save the data on the current boot device (e.g. SD)
>>> +- other configs specific to the boot device need to be enabled (CONFIG_SPL_MMC_WRITE for saving to eMMC/SD)
>>> +- use for: automating qb save / saving qb data if using Falcon mode (skipping U-Boot proper)
>>> +
>>> +2. using qb command in U-Boot console (by enabling CONFIG_CMD_IMX_QB)
>>> +
>>> +- supports saving on the current boot device, or on another, specified device.
>>> +- if flashing via uuu, the command can be added in an uuu script (boot device needs to be specified)
>>> +- use for: saving the qb data during flashing / controlling the NVM to save to
>>> +
>>> +::
>>> +
>>> +        # To save/erase on current boot device
>>> +        => qb save/erase
>>> +
>>> +        # To save/erase on other boot device
>>> +        => qb save/erase mmc 0 # eMMC
>>> +        => qb save/erase mmc 1 # SD
>>> +        => qb save/erase spi   # NOR SPI
>>
>> 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.

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