Thanks for working on it. Maybe you can cleanup patches a bit,have bot found the main logic.
Defaulting to nvme and breaking emmc is imho not good (from readme). Better would be leaving emmc boot and allow nvme boot via changing uboot env with fw_setenv.
Thanks for the quick response and feedback!
Regarding fw_setenv — that’s actually exactly how NVMe boot activation works in our implementation. The install-nvme.sh script calls fw_setenv nvme_boot 1 at the end, and U-Boot checks this variable on every boot: if nvme_boot exists, it boots from NVMe; if not, it falls back to NAND rescue. So the boot selection is fully environment-based, just as you suggested.
Regarding eMMC availability — this is a hardware constraint rather than a design choice. During rescue boot from SD card, mmcblk0 is occupied by the SD card itself, which makes eMMC inaccessible at that point. eMMC installation must therefore be done from NAND rescue where mmcblk0 is free. This is documented as a requirement in the README. Once NVMe is installed and the device boots from NVMe, eMMC remains physically accessible — it’s just that the typical use case doesn’t require both.
Regarding patch cleanup — happy to share the fitblk patch for review. The core logic is a parent chain walk in export_fitblk_bootdev() that matches the pcie@11290000 phandle (0x93) to set CI_METHOD=“nvme”, plus a nvme_do_upgrade() function that handles the actual sysupgrade write to NVMe partitions. If this is useful for upstreaming we can definitely clean it up. Could you clarify which patches specifically you are referring to — the fitblk/fit.sh changes for NVMe detection, or the full patchset?
Only took a quick look over the commits…there are some commits where it is not clean what is needed and what’s not.
It would be great if not overwriting nvme partition 2 without checkong if there is another os installed…in my case i have debian/ubuntu in a normal ext4 partition there. Maybe openwrt can also use a file-based rootfs?
Regarding commit cleanup — understood. The repository reflects our entire development process including successful and unsuccessful attempts, so there is definitely a lot of noise in the commit history. We will work on separating what is strictly needed for NVMe support from our build-specific changes and dead ends.
The partition 2 overwrite is a valid concern we haven’t addressed. Currently install-nvme.sh assumes a dedicated NVMe disk. Adding a check for existing partitions/filesystems before writing would be a reasonable safety measure.
Regarding file-based rootfs on NVMe — interesting idea. Do you have a preferred approach in mind? Using a file on an existing ext4 partition would make NVMe coexistence much more flexible.
EDIT: Regarding the coexistence idea - we are planning to extend the installer to create a third partition using the remaining disk space as empty ext4 for general use. This would allow storing data, Docker volumes, or anything else alongside OpenWrt.
We are curious though — how do you handle booting between OpenWrt and Debian in your setup? Dual boot with our U-Boot configuration is not straightforward and we would love to understand your approach before implementing anything on our side.