OpenWrt - Boot from EMMC or NFS

Hi guys,

I am quite new to OpenWRT but have successfully installed version 18.06.2 on my Banana PI R2. Also the configuration was flawless and the majority of my use cases are working fine, some details need to be taken care of, but no blockers as of now.

One topic I have to deal with is to move my working installation from my SD card to EMMC or NFS (preferred is NFS boot here). I have found a lot of pages describing how to achieve NFS root in general but nothing specific to OpenWRT. So I am reaching out to you for some help... My current setup does NOT include a serial connector so if possible I would like to handle this without it. I have read about the mmc-utils which allow to "configure" the EMMC, but I am confused about how this all works with uboot, a system I have not worked with before.

A little background: I am using Raspberry PIs for the majority of network tasks at home (vpngateway, dns server with pi-hole + unbound, vpnserver with openvpn, timeserver with DCF antenna, home automation server...) so I am not completely new to this kind of boards. All my pis are booting from a NFS share, which is very convenient when it comes to backups/restores and even updates. That is why my preferred way would be to also boot my BPI R2 from the same share.

Thanks in advance to everyone trying to help!


serial is a must.... spend some time getting used to basic serial access and simple uboot commands...

from there you can step onto the other tasks with confidence.

Ok, fair enough, can you recommend a good serial connector to use with BPI?


I will leave that to someone who has first hand experience with the Pi/BPi... i've never had the pleasure...

In general, the USB->UART boards with 5v<->3.3v jumpers or switches are handy... I've had to modify most of my UART boards to toggle TTL to 3.3v ( LM1117-3.3v>reference pin ), alot of boards don't do it well...

While frowned upon, FT232RL's ( clones ) are hard to fry... but a pain on windows...

Hi guys,

I have ordered this one now:

Do you think it will work fine with BPI?


Should be fine.

While you wait... you can play around with the buildroot and "get to know" what is required to compile a kernel with nfs boot support. ( there are some docs about this subject on its own )...

Then, there is the NFS server side... which you have some experience with and is fairly generic.... ( os independant )

Then there is just the actual "boot line" or specific uboot parameters..... I think the pi boards support "bootcmd.txt" and or "boot.scr" so this is handy for conditional/test changes.... so while you wait you could also check that out.... ( this: boot.scr-example has an example nonnfs-boot.scr creation ) you should be able to feed these to the pi from tftp... but they do kinda need to be tested by hand first... hence the need for serial...

I have tried few times to compile OpenWRT but somehow I failed... Even if the Build process was successful the img-files were missing or the BPI was not booting. I have to lern a lot in that area as I have not dealt with that process before.

I am assuming that building OpenWRT via code provided in git should be possible also for BPI R2? Do I need to rebuild the kernel separately for getting NFS support?

Talking like that, maybe a "simple" question: how to copy my current rootfs to EMMC? Is there a "simple" way?


You have a BPi R2 working?
I could not get it working. I fixed a bug with the watchdog timer in u-boot but there's more to fix.
You have to make a change to the .dtb file to fix a misconfiguration of the switch (maybe that fix got merged in.)
When it starts-up it starts with the switch in bridged mode. Tailoring of u-boot is required to fix this.
I gave up and moved on to other hardware.

I have used an already build image, was not able to compile one by myself. The image was also starting with all interfaces bridget, but after setting my own configuration it works fine. I do not know yet what is the "secret" behind compiling a working image for BPI-R2 :slight_smile:

Hi all,

I have now received the serial connector and will test it on the weekend. At the moment I am trying to compile OpenWRT 18.06.4 with the "nfs root" kernel support, but I am not able to get an SD card image. The only files that get created are the "bin" ones (kernel, sysupgrade). Can anybody tell me what I have to configure in menuconfig to also get the "img"-files for SD and EMMC?



take a look in;

make menuconfig > target images

enable tar.gz ( seems only 3rd party repos make IMG / SDIMG where did you get yours from ? )

Then you probably want;

global build settings > kernel build options > Compile the kernel with rootfs on NFS

mark things with [*] ( space bar twice usually )

then you have all you need to start testing here;

build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/Image > /mnt/sdcard/boot/kerneltest1
build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/zImage > /mnt/sdcard/boot/kerneltest2
build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/7623n-bananapi-bpi-r2-kernel.bin > /mnt/sdcard/boot/kerneltest3

bin/targets/mediatek/mt7623/openwrt-mediatek-mt7623-7623n-bananapi-bpi-r2-rootfs.tar.gz > nfsserver&untar

Hi wulfy,

can you explain me the difference between the first 3 files?

I have used a lot of third party repos but now went back to the original openwrt github repo. I guess that is the reason why SD card image is not created. Thanks for that info!

I already set the kernel option for nfs root but was not aware that only selection of image type "tar.gz" gives you the rootfs as single file, another info that is very useful :slight_smile:

Will play around and answer in case I am facing any issues or have questions (which will surely be that case).

Thanks a lot so far!


the difference is certain uboot versions like the kernel packaged in XYZ format... because I don't know your device... I gave several that you can try...

my device likes uImage ( kernel + dtb + uboot header non-compressed )... you can websearch about the names for more info....

o'... you might want this too if it's not attached to your kernel...

build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/image-mt7623n-bananapi-bpi-r2.dtb > /mnt/sdcard/boot/bpi.dtb

Hi wulfy,

current status:

  • received serial connector
  • able to connect to bpi via putty
  • currently I am having the issue that compiling openwrt does not create kernel images
  • changing uDev.txt to boot from nfs shows "
VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:

I guess this is because kernel does not have nfs support, do you agree?

uDev configuration:

roottmpl=/dev/nfs rootfstype=nfs nfsroot=,tcp,vers=3 ip=192.168.XX.XX:192.168.XX.X:192.168.XX.X: rw rootwait



dmesg | grep 'Kernel command'

( or just find that line in early boot from your serial session )

and see last post here: Banana Pi R2: Boot partiton, uboot


cp $zimageorg zimagenew
cat $dtborg >> zimagenew
staging_dir/host/bin/mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 'MIPS OpenWrt Linux-$(LINUX_VERSION)'  -d zimagenew uImage
Kernel command line: earlyprintk console=ttyS0,115200 rootfstype=squashfs,jffs2

But how does that work then when booting from SD card with ext4 file system...? Ok, but that means that I have to change the command line in the kernel_menuconfig settings because the one in uEnv.txt is obviously not configured. Will try that, thanks!


Yes... for safety... most openwrt builds hardcode the cmdline into the kernel...

For your device based on what the dude said in the post above... enabling "ATAG cmdline bootloader parameter passing" is done via


search for it in kernel_menuconfig with "/" then type "cmdline" or "atag" or "CMDLINE"

on my device it different....


( these are adjusted in your target subdir under config-KVERSION )

cat target/linux/mediatek/mt7623/config-4.14

Getting close now :wink:

I have only found this option and setting it to "y" now. This means that the configuration from uEnv.txt will be considered now?