does this only apply to the R4 Pro? or also to the non-pro? I have a R4 and wondering if i could simply replace the .bin
Hi oli, the r4 doesn’t have the aeonsemi 10g phy. this is r4-pro specific as the entire thread is.
1 Like
Yeah,but sdk changed to an larger driver with debug parts. So not upstreamable and i found no time yet to analyse differences in core. For upstream openwrt and mainline linux we have to first get ethmux (phy port series from maxime as base) complete.
I haven’t checked. You’ll probably be using frank-w’s kernels in that case so feel free to check the commit log for the WED patches. 
I use mine as a wired router, which is also what I recommend to others, so I simply haven’t cared enough about WED to check what patches are needed for that feature.
This looks good. Maybe I should contact BPI and ask if they can add this patch.
Hi everyone!
I don’t want to spam the PR comments on GitHub, but could you please share with the community and everyone waiting what stage this PR is currently at? Are there any specific issues or blockers you’ve run into, and is it expected that the WIP/draft label might be removed in the near future?
We really appreciate all the work you’re doing on the mainline branch and are keeping our fingers crossed
Don’t expect that to be merged and hence have mainline openwrt support earlier than June.
There are critical missing parts in the Linux kernel that will take time to be developed and than back ported. So take a seat an stick with the sinovoip or mediatek code/builds
Hello, Back again.
Just put my entire home lab through extensive testing and i’m happy to see the bpi r4 pro maxing out it’s internal inband USXGMII 10 gigabit connection without exploding.
However…
This is only through the maxlinear switch.
If i connect my PC to the 10 gigabit rj45 port then run a simple iperf3 test the bpi completely craps out and only does a few megabits/s if any
That can be “fixed” by setting scatter gather off on eth2, Then the bpi can do up to a gigabit of TX throughput and link speed RX (In my case my pc has a 5 gigabit port so 5 gigabit)
That sadly has the downside of completely nuking any high bandwidth traffic on the maxlinear switch
Any ideas?
I wanna put the blame on the fact my PC has a 5 gigabit port and the 10 gigabit port on the bpi is running at an unsupported/unadvertised speed, Could be wrong though, Lmk
It would be better creating a new topic with telling you used image (bpi,openwrt with/without sdk,…) and exact port…
There are known issues with the phy chip (rj45 port on both combo). Lan combo is behind mxl switch,wan combo directly on mtk mac.
Specific question in this general thread leading to confusion.
1 Like
a couple of comments regarding the buildimg.sh script
- wireless-regdb
points to a old repo - update to this url that has the latest regdb country settings
- /boot/uEnv.txt is created empty
one needs to add to uEnv.txt
variant=r4pro
isr4pro=1
so, uboot picks the right dts
Hi,would be better in the debian/ubuntu building page but answer directly.
Thanks i will update the link
The uenv.txt is prepared with all possible variant and choosing active one by sourcefiles_bpi-r4.conf
sorry wasn’t aware there is a build page for ubuntu would you mind to share … i only see the boards in categories
only the variant section in readme, i added recently
variant in build-config changes uEnv.txt for uboot in image to choose the right base-dts
btw. changed the regdb url too
1 Like
Why 2 versions of R4 Pro?
About mainline dts:
Will there be 2 different .dts, one for 4e and one for 8x?
Or 1 base .dts for R4 Pro, with applying .dtso for any variation on the board? (Maybe they even make more variants?)
Anyway, who will buy the 4e, when there is the 8x?
ask sinovoip 
…4e uses internal 2.5g phy instead of aeonsemi phys and only 1 sfp…it is not only ram as difference
there is a bpi-r4pro.dtsi with common-parts which is included in the 8x and 4e dts for the boards…so result is a dtb for 8x and one for 4e…overlayys for sdmmc/emmc/pcie/… are additional
so we have no redundant code for same baseboard, only adding differences in the board-dts
Good News: openwrt support goes forward. I have got the SFP slot working without mux (hardcoded channelselect in dts because phy does not work with mainline driver). So the SFP slots can be now used in my code. I hope andrew picks up my changes in his PR.
5 Likes
Is the lan sfp working too?
In that case we have a good starting point.
If your mxl switch pull request is approved we have good support and the only thing missing is muxing between phy and sfp
Both sfp were working in my short test (as you can see in the comment i’ve linked). As i said not only muxing is missing…also driver for aeonsemi phy needs change to work with r4pro.
But yes, we have now a usable base where only the 2 phy-ports not yet usable.
But i have no response yet from dev who is my contact for the aeonsemi phy 
and i’m stuck there after some debugging.
edit: made a rebase to have less commits
2 Likes
It looks like he doesn’t have enough time — he hasn’t made any changes for quite a while. I really hope he grants access to this PR or merges your changes so we can finally have a usable snapshot 
I do not want to hijack his PR,just help to move forward. He added mxl dt node patch in last week,maybe he had not much time last days. Keep calm the mxl driver is also not yet merged which is currently a requirement for r4pro PR.