armbian-install: add "spi" mode for self-contained boot on NVMe/SATA/USB

[igorpecovnik]

On boards that keep u-boot in on-board SPI/NOR flash but cannot flash it from the OS (e.g. SpacemiT K3 / k3picoitx, where u-boot is written once via fastboot/DFU), an NVMe/SATA/USB install target had no good option. The only mode offered was sd, which leaves /boot on the removable install media and binds it into the target — so the freshly installed NVMe was not bootable on its own and needed a manual /boot copy + fstab fix.

New spi mode

Offered first for nvme/sata/usb when SPI/MTD flash is present (partitioner_mtd_list non-empty) but the board has no write_uboot_platform_mtd hook. It installs a fully self-contained target:

• layout identical to emmc (local /boot the board’s u-boot reads), but with the ordinary 1MiB start offset — u-boot lives in SPI, not on this disk, so no 16MiB raw-sector reserve;
• /boot populated on the target and its boot env pointed at the target’s own new root (like emmc/mtd/ufs);
• no bootloader write — u-boot is already in SPI and its boot script scans the disk for /boot/boot.scr, so install_write_bootloader is skipped and install_bootloader_available returns 0 unconditionally (like sd);
• source partition-table type inherited, same as emmc/sd/mtd.

Wired through the TUI (dedicated warning), the CLI (--boot spi, routed to install_run_scenario) and the mode descriptions. Boards that do have write_uboot_platform_mtd still get mtd; boards with no SPI still get sd only. Offer-only — a false positive just adds an unpicked menu entry.

Tests

New unit tests for the spi layout (ext4 boot-flagged root, btrfs dedicated boot, 1MiB start, source-table inheritance) and spi bootloader-availability (no capability required). Full bats suite 97/97.

Hardware validation (k3picoitx, RISC-V)

Ran the installer standalone from a USB-booted system:

• menu offered [spi sd] for the NVMe (spi first);
• install completed 100%, exit 0;
• NVMe fstab = UUID=… / only — no /media/boot-media bind, zero dependency on the USB;
• armbianEnv.txt rootdev points at the NVMe’s own root;
• pulled the USB, rebooted → board boots straight from /dev/nvme0n1p1 via the SPI u-boot.

Related

Companion to the SpacemiT K3 u-boot / NVMe enablement in the build framework: armbian/build#10506 (u-boot k3-br-v1.0.7 bump + pci enum before nvme scan in the autoboot env, which makes NVMe boot possible in the first place). That PR makes the board able to boot from NVMe; this one makes the installer produce a bootable NVMe automatically.

Signed-off-by: Igor Pecovnik igor@armbian.com