You could leave the status=disabled for the 3 pcie and drop the enable file…to make things easier.
1 Like
Indeed I could do it. But I went on this approach to not enable globally the PCIe just for the specific .dtb
if you do it for you only, why not 
currently there are only rfb and the bpi-r4…and imho all here having the r4 and no other mt7988 based board, right?
for mainlining of course the “disable first and enable in board” aproach is the way to go
1 Like
Yes, was trying to leave close to mainline and in the same time to try to touch as little as possible the original dtsi and dts file.
In this way I can apply the 2 files easier to next U-boot release and make the changes than have a full patch over the 3 main dts/dtsi files.
Only wanted to show an easier way till it is not yet supported in mainline uboot (dts changes are stopped till OF_UPSTREAM changes for which i currently upstream linux dts and we need fdtoverlay command built in uboot and merging of dtso to basedt to have the dtbs for linking into uboot).
1 Like
Thanks for the tip. In the end I was building a custom .dts for the board and I’m compiling it and used in U-boot.
Hello Gentlemen, kudos on your work so far!
I’ve been scouring the internet for anything similar, and came across this active forum post, so thought I’d throw myself out there early rather than regret it later.
I’m working on a product using a mt8395 (same as mt8195 from software perspective), for which we would like to boot into an OS on a NVMe drive. If it would take too many engineering hours, we may swap over to using a UFS drive, but the hardware engineer and I prefer NVMe. Right now I’m doing a little prototyping using the eval board, and at least confirmed the kernel level drivers work well with NVMe out-of-the-box. But, since I’m not seeing native U-boot support for NVMe (at least in MediaTek’s demo branch) I got curious about what’s already out there to address it.
Would you two (or any others) happen to have any suggestions, knowledge and/or advice? I’m a complete novice when it comes to U-boot (several coworkers historically take care of all the U-boot development, but I’ve been looking for a chance to get into it for a while), but I’m sure it’s not going to be simple. Still, I’m hoping I can port the existing upstream PCIe driver and/or your own work to the mt8195 fairly painlessly.
Are either of you aware of a better starting point and/or any major stumbling blocks I should consider before attempting to do so? Or conversely, if there is a better starting point/other project or resource out there which would be a better starting point or additional reference for my use case? Do you think it would be better to port the related files into MediaTek’s branch, or are the changes extensive enough that it would be better to just setup the eval board for upstream U-boot? I saw at least one of the Github links in this forum is dead, (perhaps because it was ported into mainline?), do you guys have all the source contained within one location? If you have any general guidance before I get too deep, please do share!
Thank you in advance and apologies if this is off topic! Good luck on your further developments!
please create an own topic as this is not related to bpi-r4, but i’m not sure anyone can help you here as mt8195 is completely different chipset where afaik bpi has no board with
hi there, just for me to be sure to understand correctly…this will allow to boot directly on the nvme like for the vanilla openwrt instead of the risky sd card?
You cannot boot directly from nvme. You can only boot from spi (nand/nor) or mmc (sd/emmc) and then in uboot continue from nvme (linux kernel,initrd,rootfs).
1 Like
Only if someone ever finished this idea. It’s just an idea now and would need someone to build the uboot image for it and the right configuration.
Then technically, yes, it would be possible to boot “straight” (boots from NAND or NOR the uboot, which then activates the nvme and chains to that) from NVME.
My uboot has most parts prepared
But for my testing i added a prompt for asking the kernel file,but this could also fixed value or something configurable with env var.
Not sure if openwrt has something similar.
if i switch to vanilla openwrt would that be possible then? i am just wondering if i go with an sd card or if i push a bit further to make it more robust with an nvme.
What is the latest State now?
I recently added nvme support for openwrt in my repo (R4+R4Pro),but not yet upstreamed as i’m unsure how to handle openwrt rootfs on nvme.
Hi Frank,
Just wanted to let you know that NVMe boot with OpenWrt rootfs is fully working on BPI-R4 - including sysupgrade from both CLI and LuCI.
The key was extending fitblk to detect NVMe via PCIe parent chain walk (pcie@11290000 phandle match). Happy to share the details or patches if it helps with upstreaming.
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.