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)
1 Like
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…
1 Like
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:
- 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.