@bialy39 Why don’t you want to use the compiled image?
1 Like
@Tohin Thanks. This image is working fine.
Can you tell me what tools i can use to resize root partition?
It’s possible to write image to EMMC?
It is a HUGE change - you’re changing the main C library used for the image. I hadn’t tested if this works at all and upstream (i.e. original OpenWRT) also does not provide glibc-base builds by default. Expect all kinds of problems. It might work, it might not - be prepared to dig a lot resolving various problems.
Well… with the attitude like this your best bet would be to use ubuntu-based or armbian-based image for this board and free yourself from all the complation-related hassle - after all building software is not a thing expected to be done by a generic standard person out there :-).
If you would change your mind and would like to check what’s going on and what’s the problem is and want people on this forum to be able to help you - please provide more details.
Important are:
- Output of
git branchcommand when executed at the same dir you executemakeat. - Full build log output. To gather it execute build like this:
make clean && make V=s | tee build.log; bzip2 build.log. Attach resulting build.log.bz2 file here. - Contents of your
.config. Again, create an archive with it like this:cat .config | bzip2 -9 - > .config.bz2and attach.config.bz2here.
Also of a great help would be to provide us with the exact details of the things you did to clone repo and prepare it for the build. Devil usually is in details, you know.
In general you cat put the image to the SD card and then use any partition manager tool you like to do the task. gparted is a best choice under linux, google for “Partition Master” or “Partition Manager” or “Partition Wizard” to find suitable utility for Windows.
There’s a catch though that makes gparted the best for this task: windows-based tools in general don’t know how to handle ext4 partitions. Then, when resizing be sure not to move first partition, you may break bootloader-related magic otherwise. It is OK to resize first partition and it is OK to resize/move other partitions or to add additional partitions. Beware squashfs-based images - they can’t be resized easily.
Fortunately images are being generated. I really can’t figure out what I missed before.
I’m on Arch Linux so I used gparted for resize rootfs partition and this also works fine.
Additionally I founded way to make this system starting from EMMC.
Solution brings me this post: Which preloader image to use?
You, @LeXa2, pointed me which preloader I must use and @frank-w pointed where I must flash.
I partitioned emmcblk0 for boot and rootfs partition, copied content and flash preloader to mmcblk0boot0. Now I can start system from EMMC. Looks like uEnv.txt is not needed because bootargs are hardcoded in preloader. I tried, just-for-fun, to boot Arch Linux ARM from /dev/sda1 (SSD) but bootargs in uEnv.txt have no effect, it’s always booting from mmcblk0 or mmcblk1.
Anyway thak you guys @LeXa2 @frank-w for help.
Now I have what I wanted.
Regards.
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 ?