OpenWrt - Boot from EMMC or NFS

Hi guys,

I have ordered this one now:

Do you think it will work fine with BPI?

Thanks!

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?

Thanks!

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?

Thanks!

Bye

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!

Bye

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=192.168.20.5:/volume1/XXX/XXX,tcp,vers=3 ip=192.168.XX.XX:192.168.XX.X:192.168.XX.X:255.255.255.0:router:lan0 rw rootwait

Thanks!

Bye

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

zimageorg="build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/zImage"
dtborg="build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-mediatek_mt7623/image-mt7623n-bananapi-bpi-r2.dtb"

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!

Bye

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

CONFIG_CMDLINE_EXTEND

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

on my device it different....

-# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
-CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y
+# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE is not set

( 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?

Bye

None of the kernel options seems to make the uEnv.txt work. I have now set the cmdline in kernel menuconfig and will try if this works.

Then something like this;

ipaddr=192.168.20.110
netmask=255.255.255.0
serverip=192.168.20.5
bootfile=uImage1
nfsip=192.168.0.10
nfsdir=/srv/nfs/bpirootfs

set_nfsargs=setenv nfsargs "console=ttyS0,115200 ip=${ipaddr}:${serverip}:${serverip}:${netmask}::wan::${serverip}:192.168.20.5 root=/dev/nfs rw nfsroot=${nfsip}:${nfsdir},nfsvers=3,tcp nfsrootdebug"
bootnfs=run set_nfsargs; setenv bootargs "${nfsargs}"; tftp 0x80200000 ${bootfile};bootm

#run bootnfs

NOTE: On my board I maybe run something before "run bootnfs" that initialises network....easy to test that on your board just manually booting something from tftp...

I can confirm now that I have a bootable Banana PI via NFS with OpenWRT 18.06.4! Thanks a lot @anon50098793, you helped me a lot!

At the moment I achieved that by "hardcoding" the boot cmd line in the kernel settings and compiling that way. This is, obviously, not the cleanest way of doing it, but I will stick with this for now.

I am still not very clear about the usage of uEnv.txt, as it seems to only have a small effect on how the BPI is booting up.

Still a lot to learn but I am happy that my router now boots over network and not from the SD card, which is prone to damages... Next thing to do is to create a backup script to make sure, system is backed up like all my other PIs :slight_smile: Any suggestions on how to backup complete system? On my raspberries I have a nice script called "raspiBackup" which creates an image of the root partition and additionally rsyncs the complete file system keeping a defined number of versions.

Thanks!

Bye

One question: what is the best way to update the system?

with opkg I can update particular packages, which works fine. But "base-files" cannot be updated that way. On the OpenWRT site there are "sysupgrade" images avilable, but those are claiming to be for "squashfs", which might not match my configuration. The other way would be to compile from source again, which is a lot of work... Is there any other way?

Thanks!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.