Hello Daniel,
On Tue, Nov 03, 2026 at 12:39:22PM +0000, Daniel Drake wrote:
> Various i.MX-based boards can be booted in a USB-serial download mode,
> where the bootrom pauses and waits for an upload from the host.
>
> The documented and expected behaviour is that a separate host computer
> then uploads a U-Boot binary which then boots into fastboot mode,
> allowing for storage devices to be flashed, usually by the 'uuu' tool.
Why is this i.MX specific? We (Toradex) have exactly the same on other
boards that does not use any NXP SoC.
>
> This is implemented inconsistently over different boards, for example
> within the i.MX9 family:
>
> - i.MX93 FRDM: fastboot mode only activates if "bootflow scan" fails to
> boot an OS from an available storage device.
> - phyCORE i.MX91/93: fastboot is prepended to the default bootcmd, and
> the board boots normally once the host ends the session.
> - Kontron OSM-S i.MX93: bootcmd is replaced with "fastboot 0" and
> bootdelay set to 0, so U-Boot stops at the prompt afterwards.
> - Variscite i.MX93 VAR-SOM, Toradex Aquila, SMARC and Verdin i.MX95:
> USB fastboot is enabled, but nothing starts it, so the normal boot
> command runs.
>
> Implement a common i.MX handler for this, offering consistent behaviour:
> on a USB boot, prepend "fastboot usb <FASTBOOT_USB_DEV>" to bootcmd from
> the last-stage init event.
>
> This handler takes effect on i.MX8, i.MX8M, i.MX8ULP and i.MX9 families
> when USB fastboot is enabled, and only when the bootcmd has not been
> customised by the user or by the board code.
How can I opt out from it?
Did you consider having a new boot command variable.
if (bootcmd_usb_recovery && booting_from_usb_recover())
env_set(bootcmd, bootcmd_usb_recovery)
The issue I see with this simple proposal is the USB instance number,
but maybe this can be solved?
Francesco
