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

[Simona Toaca]

Hi Marek,

On Tue, Mar 17, 2026 at 06:10:47PM +0100, Marek Vasut wrote:
> 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.
> 
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.

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.

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

To not spam you with replies, I want to thank you here for your review on
all the patches. I will fix the issues in the next version.

Best regards,
Simona