Never used the image builder so far, because I get my goal with the builded images. I will give it a try…
Update:
- HDMI is now fully working (was just a bunch of kernel symbols not being selected)
- no more MSI warnings when loading SATA/AHCI driver
1 Like
Very excited that OpenWrt 21.02.0-rc4 is building correctly on the site. I’ve been running snapshot builds for a long time now, getting worn out from manual updates. Download and flash, up and running in minutes.
Now working on my gnu libc build (everything I like to run on it needs gnu libc). (I have 2 bpi-r2, 1 as main and one to tinker with)
I do have one problem though, I’m still getting disappointing throughput. Service is 1Gb and I can barely get 150-200Mb down. (Even before installing and enabling SQM) Not sure what causes this. The last version that gave good throughput was frank-w’s 18.06. Trying to investigate the differences proved too challenging for me.
Does anyone A. report better performance with the buildbot provided 21.02? or B. Know off hand what patches are missing to get throughput working properly? Or C. report better performance with snapshots?
Maybe a stupid question, but does your r2 start automatically when power is connected or do you still have to push the “start” button?
You always need to push the start button unless you modify the board (solder the bridge next to the switch) BUT, sometimes, if I use the USB console (in the back) it turns itself on. (probably the 5v from the host) But I usually use the other serial which doesn’t pass power. I haven’t tried the uart pins on the gpio
1 Like
Have been running rc4 for a week now. I have a problem with lan ports randomly flapping. The r2 is my edge router, I only use one downlink to my AP/bridge. It works fine for hours/days at a time, and then this:
Sun Aug 29 12:52:50 2021 kern.info kernel: [330726.006066] mt7530 mdio-bus:00 lan1: Link is Down
Sun Aug 29 12:52:50 2021 kern.info kernel: [330726.011116] br-lan: port 2(lan1) entered disabled state
Sun Aug 29 12:52:50 2021 daemon.notice netifd: Network device 'lan1' link is down
Sun Aug 29 12:52:51 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sun Aug 29 12:52:51 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sun Aug 29 12:52:55 2021 daemon.notice netifd: Network device 'lan1' link is up
Sun Aug 29 12:52:55 2021 kern.info kernel: [330731.206212] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Sun Aug 29 12:52:55 2021 kern.info kernel: [330731.213648] br-lan: port 2(lan1) entered blocking state
Sun Aug 29 12:52:55 2021 kern.info kernel: [330731.218985] br-lan: port 2(lan1) entered forwarding state
Sun Aug 29 12:52:55 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sun Aug 29 12:52:55 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sun Aug 29 12:53:07 2021 daemon.notice netifd: Network device 'lan1' link is down
Sun Aug 29 12:53:07 2021 kern.info kernel: [330742.646065] mt7530 mdio-bus:00 lan1: Link is Down
Sun Aug 29 12:53:07 2021 kern.info kernel: [330742.650978] br-lan: port 2(lan1) entered disabled state
Sun Aug 29 12:53:08 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sun Aug 29 12:53:08 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sun Aug 29 12:53:09 2021 daemon.notice netifd: Network device 'lan1' link is up
Sun Aug 29 12:53:09 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sun Aug 29 12:53:09 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sun Aug 29 12:53:09 2021 kern.info kernel: [330744.726208] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Sun Aug 29 12:53:09 2021 kern.info kernel: [330744.733638] br-lan: port 2(lan1) entered blocking state
Sun Aug 29 12:53:09 2021 kern.info kernel: [330744.738968] br-lan: port 2(lan1) entered forwarding state
I’m not detecting a pattern to this interval. I’ve already replaced the AP/bridge, convinced it was the bridge.
It’s also a completely random chance that the interface comes back up at all. Twice, it’s gone down and refused to come back up without a restart.
It also gets worse/more frequent if I enable SQM.
Does anyone report similar?
I will find an opportunity this week to switch R2’s to see if it’s a hardware issue with this unit, but that’s a stretch.
As you said, I’m throwing a snapshot version to the sd card. but the device keeps restarting at boot. I don’t know where is the problem. Until now, only the software in the link below has worked without any problems.
But I want to use the official openwrt build.
The repository in the link you provided may work for OpenWrt 19.07 and even 21.02, but certainly needs to be updated for more recent OpenWrt.
To give current development a try please prepare the SD card like this (assuming it’s /dev/mmcblk0 on your build system):
wget https://downloads.openwrt.org/snapshots/targets/mediatek/mt7623/openwrt-mediatek-mt7623-bananapi_bpi-r2-sdcard.img.gz
gzip -cd openwrt-mediatek-mt7623-bananapi_bpi-r2-sdcard.img.gz | dd of=/dev/mmcblk0
and see if that works for you. If you encounter any problems, please report.
In the same way, I write to the sd card without any problems. I am checking with serial cable connected. the device turns on, then reboots at some point. I tried to write to emmc in row 7 during u-boot. Then I removed the sd card. still the same problem persists.
As you got the serial console connected, please log all output into a file and share that (via PM if you like). The same method has worked for me and others and without more information it is impossible to tell what’s going on in your case. I’m running OpenWrt SNAPSHOT, r17444-1c8214d6f2 on the board right now and it boots fine.
I soldered it here so that the device would turn on automatically. Could the problem be here? The software in the link I mentioned in the previous message works without any problems. https://github.com/mammo0/openwrt-bpi-r2
Yes, this seems to be the cause. If I keep the POWER button presser constantly my board also keeps rebooting.
i guess the pmic-keys are defined in uboot and driver is compiled in…
see https://github.com/frank-w/BPI-R2-4.14/issues/35
in linux we solved it by building the mtk-pmic-keys as module…but i do not see driver/dts nodes in my 2021-07-rc3
Edit: oh your reboot happens in linux too
I changed the place in the screenshot to “n” and I compiled it. Problem solved. Thank you very much to both of you. 
@dangowrt @frank-w
1 Like
Is there no way to do this without soldering? 
Thanks for your answer.
Afair passing 5v to otg port has same effect
So I switched over to my spare r2. Problem persists, though less frequent. Still random, though I suspect it happens during periods of high load.
root@Edge-IPS-02:/# logread | grep kern.info
Fri Sep 3 12:19:16 2021 kern.info kernel: [358106.583118] mt7530 mdio-bus:00 lan1: Link is Down
Fri Sep 3 12:19:16 2021 kern.info kernel: [358106.588167] br-lan: port 2(lan1) entered disabled state
Fri Sep 3 12:19:20 2021 kern.info kernel: [358110.743284] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Fri Sep 3 12:19:20 2021 kern.info kernel: [358110.750723] br-lan: port 2(lan1) entered blocking state
Fri Sep 3 12:19:20 2021 kern.info kernel: [358110.756064] br-lan: port 2(lan1) entered forwarding state
Fri Sep 3 12:19:32 2021 kern.info kernel: [358122.183410] mt7530 mdio-bus:00 lan1: Link is Down
Fri Sep 3 12:19:32 2021 kern.info kernel: [358122.188289] br-lan: port 2(lan1) entered disabled state
Fri Sep 3 12:19:35 2021 kern.info kernel: [358125.303343] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Fri Sep 3 12:19:35 2021 kern.info kernel: [358125.310776] br-lan: port 2(lan1) entered blocking state
Fri Sep 3 12:19:35 2021 kern.info kernel: [358125.316110] br-lan: port 2(lan1) entered forwarding state
Fri Sep 3 12:31:24 2021 kern.info kernel: [358834.583150] mt7530 mdio-bus:00 lan1: Link is Down
Fri Sep 3 12:31:24 2021 kern.info kernel: [358834.588131] br-lan: port 2(lan1) entered disabled state
Fri Sep 3 12:31:28 2021 kern.info kernel: [358838.743371] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Fri Sep 3 12:31:28 2021 kern.info kernel: [358838.750812] br-lan: port 2(lan1) entered blocking state
Fri Sep 3 12:31:28 2021 kern.info kernel: [358838.756148] br-lan: port 2(lan1) entered forwarding state
Fri Sep 3 12:31:40 2021 kern.info kernel: [358850.183233] mt7530 mdio-bus:00 lan1: Link is Down
Fri Sep 3 12:31:40 2021 kern.info kernel: [358850.188272] br-lan: port 2(lan1) entered disabled state
Fri Sep 3 12:31:43 2021 kern.info kernel: [358853.303391] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Fri Sep 3 12:31:43 2021 kern.info kernel: [358853.310827] br-lan: port 2(lan1) entered blocking state
Fri Sep 3 12:31:43 2021 kern.info kernel: [358853.316161] br-lan: port 2(lan1) entered forwarding state
Fri Sep 3 17:28:12 2021 kern.info kernel: [376642.500724] mt7530 mdio-bus:00 lan1: Link is Down
Fri Sep 3 17:28:12 2021 kern.info kernel: [376642.505788] br-lan: port 2(lan1) entered disabled state
Fri Sep 3 17:28:16 2021 kern.info kernel: [376646.661218] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Fri Sep 3 17:28:16 2021 kern.info kernel: [376646.668653] br-lan: port 2(lan1) entered blocking state
Fri Sep 3 17:28:16 2021 kern.info kernel: [376646.673981] br-lan: port 2(lan1) entered forwarding state
Fri Sep 3 17:28:27 2021 kern.info kernel: [376658.100714] mt7530 mdio-bus:00 lan1: Link is Down
Fri Sep 3 17:28:27 2021 kern.info kernel: [376658.105749] br-lan: port 2(lan1) entered disabled state
Fri Sep 3 17:28:31 2021 kern.info kernel: [376661.220902] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control off
Fri Sep 3 17:28:31 2021 kern.info kernel: [376661.228343] br-lan: port 2(lan1) entered blocking state
Fri Sep 3 17:28:31 2021 kern.info kernel: [376661.233680] br-lan: port 2(lan1) entered forwarding state
Can anyone suggest a test to determine if the problem is a load issue? Can someone suggest what else I can look at to determine what causes this?
Recap: 21.02.0-rc4 official image works great except lan ports flap randomly sometimes. Doesn’t happen with wan port. Suspect load issue since it happens more frequently with SQM enabled. Have already tried swapping hardware.
Did you try the updated OpenWrt image this thread is all about as well and does the issue come up with that as well?
As you are reporting the problem of loss-of-link may show under high load: are you using a strong enough power supply and/or have you tried swapping that as well?
I’m asking all this because I run current OpenWrt snapshot (updated every couple of weeks) and have high uptime on my device (now been up constantly for many days since last updated), also sometimes running with quite a bit of load, and my logs are free of these entries showing flaky link…
I’m using rc4 which is from Aug 2 (newer than the snapshot you posted in the OP) Your link points to the snapshot, which is updated every day. I will try a newer snapshot when I get an opportunity. For comparison what r version and commit are on your known-good snapshot? I’m on r16256-2d5ee43dc6
Using the power supply that came with the unit. I have 2. I’ve tried both.
I will try a new snapshot soon.