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
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.
The thing is that the rc4 is of the 21.02 branch which branched-off in February (thus the name). 21.02 is based on Linux 5.4 and does not yet come with the changes I made to modernize the mediatek target. These changes have not made it into the release and will only be available in a future release.
r17485-ae33ce2af2 seems to be rocking along smoothly. Have only been running it since this afternnoon, but so far, so good. I’m even getting full bandwidth. Don’t even need SQM, bufferbloat is low. Thanks for the help @dangowrt
Have the image now running nearly a month without any issues. Works great.
I think the lasted version is prefect for me more than the offical of BPI image that stuck old version
Hello 
How can I “increase” resize the size of the root partition ?
Regards
Hi i am booting OpenWrt from eMMC and i need fw_env.config for eMMC
Here is sd card booted one.
/dev/mmcblk1p1 0xb0000 0x10000 0x10000 1
Could you share fw_env.config for eMMC @dangowrt