Thats the annoying msi warning daniel wrote about.
See this on how to fix:
https://github.com/frank-w/BPI-R2-4.14/commits/5.10-pci
I have a smaller patchset (2 patches) but this make errors on other platforms. Maybe on openwrt this is not a problem if it is only applied for target mediatek (afair aarch64 is also not affected):
Patch 2+3 from here(have replaced with full patchset in other trees): https://github.com/frank-w/BPI-R2-4.14/commits/5.10-ir
Thanks I will have a look if I can use it in OpenWrt. 
Open the commit in github,add .patch to addressline,save it in the target/mediatek/patches-5.10 folder Should work if there are no conflicting patches applied first
Just compiling and then runtest again:
There is still the hdmi issue:
[ 1.452848] mediatek-dpi 14014000.dpi: Found bridge node: /hdmi@14015000
[ 1.459788] mediatek-dpi 14014000.dpi: Failed to add component: -517
Imho this is the connwctor/bridge bug that was already fixed in mainline…i wonder why you have this in 5.10. Seems openwrt have backports from 5.12
Breaking commit:
drm/mediatek: mtk_dpi: Create connector for bridges
Fix:
drm/mediatek: Don't support hdmi connector creation
Reference: BPI-R2: HDMI 4k-TV fail
Btw. Spi fix has reached stable (5.10.54).
Yep. Now also in Openwrt.
I have to send my BPI-R2 back to reichelt :’( Will need some time until I get a new one. 
Nice I will backport it and runtest again before I will wait for my new R2. 
if openwrt has recent hdmi backports you may need these 2 too:
backports from 5.13 (not yet merged to mainline): https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/
i will test the cursor plane patch next as i noticed a similar problem some time ago with a touchscreen (cursor was placed on last not current position)
In terms of HDMI OpenWrt really just uses v5.10.54 vanilla as-is. We don’t care much about video support as most people run OpenWrt on headless devices.
Forward-porting v5.10 to the level of v5.14 are 100+ patches touching drivers/soc/mediatek and drivers/gpu/drm/mediatek, so that’s not an option.
I also tried reverting a couple of top commits touching drivers/drm/mediatek and also tried disabling CMDQ. All with no success, situation unchanged. I still suspect we just miss something in DTS or a kernel config symbol which needs to be enabled…
I guessed that there is no drm/hdmi backports by default as openwrt is router os for headless use.
Mhm,5.10 should work without additional patches as dts and mt7623 related patches were merged in 5.10. Maybe any config-option is missing?
Mali is not needed for hdmi itself and needs additional mesa libs to work properly
Thanks for your work. I just cloned the actual repository, could build a new kernel, but didn´t find the needed images in the build folder. My own recipe [1] to create an usable sd-card is obsolete ATM Because I´m want to add some packages and settings to the build, the download of the finished image ist not the solution for me. How to setup the menuconfig correctly to get the full image file?
First of all this only works on the most recent OpenWrt, ie. 21.02 and 19.07 still come with the old images. If you want to build from source, pretty much like you describe:
git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
rm .config
make menuconfig
now select Mediatek ARM -> MT7623 -> BananaPi BPi-R2
If you want to preserve your existing .config, make sure you select also the bootloader and build squashfs as wll as initramfs images for the sdcard.img.gz to be created. This happens automatically if you start off an empty .config and then select the target.
If you are not modifying any source code but just want to select the packages which are installed, it’s better to use the OpenWrt ImageBuilder which can compose images from existing binaries in a much more reliable and reproducible way than building from source.
Never used the image builder so far, because I get my goal with the builded images. I will give it a try…
Update:
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
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.