That is fair, although it does seem like overkill to me to use an R4 as dumb ap, I am sure someone will...
I will do that in 3 devices, so thanks for mentioning!
There is no way to use WED on the R4 in combination with MT7915/MT7916 (as those will be the other 2 of my dump aps)?
Bpi r4 without wifi 7 module don't have sense.
As far as I know WED on MT7988 is only usable with MT7995 and MT7996 WiFi NICs. For older MT791x NICs you will easily be able to reach full speed also without WED.
2 Likes
I think we should pick up/backport this patch:
https://lore.kernel.org/linux-pm/20240728192659.58115-1-qyousef@layalina.io/
It's already queued up for Linux 6.12.
The patch will enable 'schedutil' governor responds faster to workloads on 'high-performance' systems such as BPI-R4.
I also think it is worth testing on all devices released in the last 10 years, and should get applied the patch.
2 Likes
I need an 5V power supply (VBUS +5V, GND). The USB-Port is unfortunately already populated, are there onboard-pins that I could utilize for that porpuse?
Look at the XH-4Pin connector on the bpi wiki image of the board population. It has 5 and 12 volt out. I think it’s the cable used for floppy drive power
Thanks, but I only found the schematics (and there I am a little bit lost). The wiki doesn't descripe the pinouts of the XH-4PIN connector.
Look for the Molex to SATA power adapter. It's like Molex, but smaller.
Actually, it's on the sinovoip wiki https://docs.banana-pi.org/en/BPI-R4/GettingStarted_BPI-R4 Red wire's 5V rail; yellow wire is 12V rail.
1 Like
If you have a display monitor with USB-C port (support charging simulaneously), can you perform a quick test, and see if your BPI-R4 powered through USB-C will enter reboot loops?
Eventually the reboots will settle down itself, and BPI-R4 happily runs stable for eons.
If you like more background, you can read this thread. To save time, simply focus on the post on 6 August or starting from there.
At this moment in time, my quest of the root cause is purely for SCIENCE.
You mean the BPI-R4 USB-C port has DP/ALT that will cause multiple reboot before it becomes stable? I just plugged my monitor USB-C (with PD) to it, I haven't connected any UART (just lazy) but from the LED flashing it doesn't look like there were multiple reboots (or it reboots very quickly?)
1 Like
The test requirements for reproducing the reboot loop are:
- a display monitor with USB-C port (the kind that accepts video input as well as charging a laptop computer at the same time)
- BPI-R4
- USB-C to USB-C cable (charging-only cable or fully-functional seems making no difference)
Plug the USB-C cable into the monitor's USB-C port. Plug the other side into BPI-R4.
Then BPI-R4 will reboot many times until settling down. Once settled down, BPI-R4 will run stably forever.
On my side the reboot loop is consistently reproducible with the 90W USB-C PD power supply inside my monitor. I cannot reproduce the issue with a stand-alone USB-C charger.
The reboot could happen from 10+ seconds or 2 mins into startup.
When the GREEN led is flashing, it means it's starting up.
When the GREEN led is steady on, it finishes startup. Ready for login.
My daily working monitor at home is a USB-C one (yeah so single cable to my Chromebook for video+charging), I do have another portable monitor with USB-C PD passthrough, and also how about USB-C hub with PD passthrough?? Did you try any?
That means I have to leave it there and wait long enough to see if it reboots?
This is the scenario I tested on my side. And I see the issue of reboot loop.
Not covered in my tests. So would be interesting to see what would happen.
I usually SSH into BPI-R4. When it disconnects, I know BPI-R4 reboots. Reboot usually happens within 2mins.
@daniel
flow control autoneg will default to on after the update to netifd a few days back.
i have included the following in rc.local and it is correctly set at boot up.
ethtool -A eth1 autoneg off rx on tx on
kern.info kernel: [ 12.201303] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 10Gbps/Full - flow control rx/tx
But after the system is boot up. any restart of network service (like change of settings) flow control autoneg will be set back to on. and that disables flow control.
"ethtool -A autoneg off" at the command line will not disable autoneg, Only way that autoneg can be set to off is via rc.local at boot up.
the above issue happened after the below commit on openwrt maintree.
The above commit makes sure flow control settings are handled by netifd even for SFP devices. You should not use rc.local for this.
You may instead add a device section to /etc/config/network:
config device
option name 'eth1'
option rxpause '1'
option txpause '1'
Using the rxpause or txpause option disables flow control autonegotiation, while the pause or asympause control the advertised flow control support.
4 Likes
just removed the entries in rc.local and edited network config. And it is working as expected.
thank you.
Anyone using this as ftth router with sfp module like this specs I currently have in my dkt ftth gateway:
FTTH 2 fiber SC/PC, SC/APC, TX: 1310 nm / RX 1550 nm
I have this module from my old router, would it work?
XGSF-BL3512-20D-E
Edit: yes I can confirm it works.
[ 8.662493] sfp sfp1: module OEM SFP-BX-U31-E rev 1.0 sn EXGU31L491 dc 121024
[ 8.671829] mtk_soc_eth 15100000.ethernet eth2: switched to inband/1000base-x link mode
This is normal wdm and i'm pretty sure that it will work.
1 Like