odroidm1: clear SPI u-boot env on every (re)flash (fixes NVMe boot from SPI)

[igorpecovnik]

Problem

"Boot from SPI, root on NVMe" on the Odroid M1 doesn't boot. Serial shows u-boot loads from SPI fine, then:

Loading Environment from SPIFlash... OK
Card did not respond to voltage select! : -110
## Error: "mtd_boot" not defined            (×3)
starting USB... → BOOTP/DHCP → no boot

It never scans NVMe, and reflashing a newer u-boot (2026.01 → 2026.07) changes nothing.

Root cause — stale SPI env shadows the new u-boot

write_uboot_platform_mtd writes SPL (mtd0) and u-boot (mtd2) but only erases the env partition (mtd1) if it detects petitboot:

if fw_printenv | grep -q -i petitboot; then flash_erase /dev/mtd1 0 0; fi

Any other saved env — an older Armbian u-boot, or a factory env that doesn't match the petitboot string — survives, and u-boot loads it (Loading Environment from SPIFlash... OK) in preference to its built-in default. That stale env's bootcmd runs mtd_boot (which doesn't exist in the current u-boot — grep of the whole 2026.07 tree finds nothing) and its boot_targets predates nvme. So NVMe is never scanned. Because the reflash never touches mtd1, both 2026.01 and 2026.07 fail identically.

The board's built-in BOOT_TARGETS (and the board's boot-order override) already include nvme — they're just being overridden by the saved env.

Fix

Always flash_erase /dev/mtd1 when (re)flashing u-boot to SPI, so the fresh u-boot regenerates its default env with the correct boot order. A fresh install should reset the env to match the bootloader.

Confirming on hardware (no rebuild needed)

At the M1 u-boot prompt this reproduces the fix immediately:

printenv bootcmd        # references mtd_boot
printenv boot_targets   # no nvme
env default -a ; saveenv ; reset   # → scans NVMe, boots

Scope

This is the board-hook side. The configng installer (PR #973) correctly calls write_uboot_platform_mtd; nothing to change there.

Summary by CodeRabbit

• Bug Fixes
  • Improved Odroid M1 U-Boot flashing reliability by consistently clearing the SPI environment partition after updating bootloader images.
  • Prevents stale boot configuration data from interfering with newly flashed systems.

[coderabbitai]

📝 Walkthrough

Walkthrough

The Odroid M1 U-Boot flashing configuration now always erases the SPI environment partition after writing the SPL and U-Boot images. The previous Petitboot detection and conditional erase logic was removed.

Changes

Odroid M1 U-Boot flashing

Layer / File(s)	Summary
Unconditional SPI environment cleanup config/boards/odroidm1.conf	The flashing command erases /dev/mtd1 after writing the SPI boot images. The fw_printenv and Petitboot check was removed.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested labels: Patches

Suggested reviewers: rpardini, evilolaf

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the Odroid M1 SPI environment fix and its NVMe boot purpose.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/odroidm1-clear-spi-env-on-flash

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[igorpecovnik]

Hardware-confirmed on the Odroid M1: at the u-boot prompt, env default -a; saveenv; reset (resetting the stale SPI env to the built-in default) makes u-boot scan the NVMe and boot to kernel from the NVMe root. That's exactly what this patch does automatically on flash (flash_erase /dev/mtd1), so a fresh "boot from SPI, root on NVMe" install will now come up without the manual env reset.