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

[Simona Toaca]

Hi,

On Wed, Mar 18, 2026 at 09:32:33PM +0100, Marek Vasut wrote:
> 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 ?
> 

No, the space in the bootloader is exactly 64K, and memcpy uses a fixed size,
sizeof(struct ddrphy_qb_state), which is less that 64K.

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

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

My implementation is also aligned with what happens in SPL for parsing the
image containers (see arch/arm/mach-imx/image-container.c).

Regards,
Simona