Welcome. Glad that it had worked for you after all. Ping back here if any new troubles, chances are we might be able to help.
Upd. Out of curiosity, so am I correct that your image is built with glibc instead of musl? If that’s the case it is nice to know that it works too - you’re the first person to test it then.
1 Like
Yes, I built it with glibc.
I need glibc to run Lokinet router (https://github.com/loki-project/loki-network) but unfortunately it needs glibc 2.29 so i’m not able to start it yet. I tried to compile with external toolchain (crosstool-ng, glibc 2.29) but with no success.
For OpenWRT better luck might be to try patching/porting 2.29 to it. Take a look at toolchain/glibc folder and files underneath. Who knows, it might be porting would be as easy as changing PKG_VERSION to 2.29 and fixing resp checksums and commit ids.
I already tried this but unfortunately there was always some errors then build kernel 
I tried it in Arch Linux gcc 9 and Ubuntu Xenial gcc 5.
You may try it other way around then: build image with stock openwrt glibc first but also select in menuconfig an option to create a toolchain tarball. Then use this toolchain to self-build glibc 2.29 and then overwrite existing glibc-related files with what you had built directly in the image on the SD card. Or you may want to try building glibc 2.29 with a separate prefix, like, /opt/glibc2.29/, and then use this prefix and LD_LIBRARY_PATH/RUNPATH to build/link/run Lokinet with. This way you’d be having your desired 2.29 glibc existing alongside original image glibc.
Upd. Ah, and are you sure Lokinet has a hard dependency on glibc 2.29+? I don’t see this req stated on its github page.
I cross-compiled it on Arch Linux with glibc 2.29 (https://aur.archlinux.org/packages/arm-linux-gnueabihf-glibc/)
It’s possible that because of this is demanding glibc 2.29 on Openwrt?
Ah, that’s why you’ve got this req on 2.29 
, I see. I’d suggest to recompile it yet again on the board itself or - if you want to use openwrt as a target - enable creation of cross-toolchain tarball in openwrt’s make menuconfig and use this cross-toolchain to recompile Lokinet. My experience tells that it is generally a good idea to use the same toolchain that was used to build OS for building userland software - this way chances are minimal to hit some obscure incompatibilities.
P.S. Or you may try to use Arch Linux armhf image as your OS. Download any recent Debian image for BPi-R2, preserve anything under /lib/modules/ but replace all other contents of rootfs with Arch Linux rootfs contents.
Hi LeXa2,
after a long search I found your manual and image for the bpi-r2. I build one on my own and it’s working - as I see it - very good. One thing is left: How can get the Wifi working? I found lots of manuals for Debian/Ubuntu but none for OpenWrt, maybe you or frank-w do have an answer or hint?
Thanks in advance!
Basicly it’s same as in debian
At least you need wifi-driver in your kernel. Look in my kernelrepo for your kernel-version and apply commits with [wifi] to your kernel-source. Add options to your config (see my defconfig) and build kernel. You need same wmt-tools/config as on debian and you can also use my wifi.sh
After doing some speed tests using this fork of OpenWRT I observed the bridge interface crashes and the ports have some timeouts. Below in the trace I saw in the serial console. I was forced so reboot in order to make the system work again.
[ 435.037261] ------------[ cut here ]------------
[ 435.041881] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x158/0x224
[ 435.050086] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[ 435.056994] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUE
RADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf
_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conn
track iptable_mangle iptable_filter ip_tables crc_ccitt compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables leds_gp
io ohci_platform ohci_hcd ehci_platform ehci_hcd gpio_button_hotplug
[ 435.123492] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.95 #0
[ 435.129445] Hardware name: Mediatek Cortex-A7 (Device Tree)
[ 435.134986] [<c010ee7c>] (unwind_backtrace) from [<c010af84>] (show_stack+0x10/0x14)
[ 435.142672] [<c010af84>] (show_stack) from [<c05c467c>] (dump_stack+0x78/0x8c)
[ 435.149841] [<c05c467c>] (dump_stack) from [<c0117414>] (__warn+0xe4/0x100)
[ 435.156748] [<c0117414>] (__warn) from [<c0117468>] (warn_slowpath_fmt+0x38/0x48)
[ 435.164173] [<c0117468>] (warn_slowpath_fmt) from [<c0500fd0>] (dev_watchdog+0x158/0x224)
[ 435.172290] [<c0500fd0>] (dev_watchdog) from [<c0168980>] (call_timer_fn.constprop.3+0x28/0x94)
[ 435.180919] [<c0168980>] (call_timer_fn.constprop.3) from [<c0168a68>] (expire_timers+0x7c/0x98)
[ 435.189635] [<c0168a68>] (expire_timers) from [<c0168b00>] (run_timer_softirq+0x7c/0x160)
[ 435.197746] [<c0168b00>] (run_timer_softirq) from [<c010155c>] (__do_softirq+0xe4/0x250)
[ 435.205773] [<c010155c>] (__do_softirq) from [<c011bf44>] (irq_exit+0xac/0xf4)
[ 435.212939] [<c011bf44>] (irq_exit) from [<c0155b7c>] (__handle_domain_irq+0xbc/0xe4)
[ 435.220706] [<c0155b7c>] (__handle_domain_irq) from [<c0101440>] (gic_handle_irq+0x5c/0x90)
[ 435.228989] [<c0101440>] (gic_handle_irq) from [<c010bb4c>] (__irq_svc+0x6c/0xa8)
[ 435.236409] Exception stack(0xdf06ff88 to 0xdf06ffd0)
[ 435.241418] ff80: 00000002 c06d1a58 1ef93000 c01140c0 ffffe000 c0903c74
[ 435.249529] ffa0: c0903c28 c092ded0 8000406a 410fc073 00000000 00000000 00000002 df06ffd8
[ 435.257638] ffc0: c010842c c0108430 60000013 ffffffff
[ 435.262650] [<c010bb4c>] (__irq_svc) from [<c0108430>] (arch_cpu_idle+0x34/0x38)
[ 435.269989] [<c0108430>] (arch_cpu_idle) from [<c014af78>] (do_idle+0xa8/0x11c)
[ 435.277240] [<c014af78>] (do_idle) from [<c014b270>] (cpu_startup_entry+0x18/0x1c)
[ 435.284749] [<c014b270>] (cpu_startup_entry) from [<8010176c>] (0x8010176c)
[ 435.291667] ---[ end trace 8f73a5d7abbb2d2e ]---
[ 435.296256] mtk_soc_eth 1b100000.ethernet eth0: transmit timed out
[ 435.302402] mtk_soc_eth 1b100000.ethernet eth1: transmit timed outthis is the transmit-timeout-issue from mtk-driver where i do not know how to reproduce and there is no fix till now…have written to some developers facing this issue and there are only workarounds like checking for the issue and restarting network. maybe some interrupts conflicting…
i hope this will be also fixed by phylink-changes because i expect that the problem is in wrong setup of mt7530-switch
I’ve seen this trace before. For me it was caused by 0027-net-next-mediatek-fix-DQL-support.patch, it is the same as you see here:
With this patch applied I got traces and port crashes like in your message seconds after starting up iperf or iperf3 tests. Reverted this patch and was able to stress-test with iperf for several days in a row. Thus this patch was removed from the tree. This leads us to a question: what were the exact steps you took to compile the image? Most importantly what was the commit sha you used as a base for compiling your image. This is important as I’ve got two R2 board on hands right now running OpenWRT image built from this fork codebase and there was no stability problems with them since the beginning of the June 2019.
TL/DR version is: you don’t. Use external AP with vendor-provided firmware to get stable and performant WiFi.
Long version: In general decoupling things like central network mini-servers/routers and disposable infrastructure elements like WiFi APs is a good idea. WiFi protocols get updated and WiFi security gets patched at a way faster pace compared to the speed upgrades we get at wired networking space. R2 is performant enough to be able to satisfy my routing and home server needs for approx 5-6 next years. On the other hand I had updated my 802.11n AP to 802.11ac AP in the end of last year and it is already sort-of obsolete as WiFi 6 (802.11ax) is on its way to public.
But even leaving this aside the built-in WiFi chip in R2 is known to be “brittle/tricky”: there are no upstream linux drivers for it, vendor-shipped drivers are buggy, AP setup process is non-standard, e.t.c. So better bet would be to get a mini-PCIEx WiFi module with a WiFI chipset that is known to be well-supported under linux and try your luck with it. I’ve seen reports on other forums of people having good results with external WiFi mini-PCIEx modules under Armbian. Try checking Armbian download/FAQ page for BPi R2 for more info.
Hi for compiling I was using the steps highlighted in the first post of this thread.
That trace appeared after I was doing some online speed tests (not iperf3) from a PC connected behind the BPI-R2 box.
What are the exact steps to check the commit sha ?
Thanks @LeXa2 and @frank-w for your feedback.
So for the beginning I try to get the wired part working.
First of all thanks @LeXa2 for forking this!
I have been trying myself to no avail. Can you please share the exact steps you did? I am not sure what do with what image and using dd to write the images to mmcblk1 is not working (I am on the R2 running ubuntu right now typing this).
Thanks in advance!
Ubuntu/debian images have swapped mmc (kernel) due to compatibilty with official kernel.
Here sd-card is mmcblk0 and emmc is mmcblk1
Openwrt uses vanilla-kernel without mmc-swap
Best option should be looking for mmcblkXboot0 to determine X
cat /proc/partitions
Don’t forget flashing preloader to boot0
Btw. @bialy39 bootargs are included in uboot (not preloader) also kernelname to load.
If you do not need to change it you don’t need a uenv.txt
Thanks frank, I actually already noticed this, I tried to flash on mmcblk1 as I noticed this was the only empty one, so this had to be the EMMC.
This is where I got a problem… I found in this link below the images, so I tried mtk-bpi-r2-preloader-emmc.bin
I also tried to dd this image:
I created a fat16 partition of 256 MB to flash the preloader (mmcblk1p1) Then an ext4 partition of the rest of the storage to flash the image (mmcblk1p2)
Here are the commands I tried:
echo 0 > /sys/block/mmcblk1boot0/force_ro
dd if=mtk-bpi-r2-EMMC.img of=/dev/mmcblk1boot0 bs=1M count=1
It didn’t seem to do anything and I guess there was a problem with the partitioning So I made my own partitions and tried this:
dd if=mtk-bpi-r2-preloader-emmc.bin of=/dev/mmcblk1
dd if=mtk-bpi-r2-EMMC.img of=/dev/mmcblk1p2
But I guess I am still doing something wrong…
Hence my question on the exact images I need to use, and the exact commands I need to try
Thanks!
Drop count in your dd-command and do not write to partition (p2)…only mmcblkXboot0 (preloader) and mmcblkX (os-image)
echo 0 > /sys/block/mmcblk1boot0/force_ro
dd if=mtk-bpi-r2-preloader-emmc.bin of=/dev/mmcblk1boot0
dd if=mtk-bpi-r2-EMMC.img of=/dev/mmcblk1
Have you partitioning the emmc? Maybe it’s the PARTITIONCONFIG=0 problem…
Try to write partitionconfig like it’s written in my wiki. Also you may need to change ubootconfig
You have debug-uart working? Just to see if uboot comes up without sdcard and hang anywhere else
Like this:
# git describe
reboot-10722-gd8c62c40
# git rev-parse HEAD
d8c62c40297feabb6bfd2c091588070a2e3fc11c
To reiterate, am I correct that your traffic flow was like below at the moment of network stall?
[Client PC] <-> [R2 lanX port](NAT egres)[R2 wan port] <-> {Internet} <-> [Remote Host]