based on the Wiki (https://wiki.banana-pi.org/Banana_Pi_BPI-R2_Pro) the switch-chip is a RTL8367RB-VB-CG. this have no dsa-driver. but openwrt offers a phy-driver and i have one in my old 5.4-r64 branch…
is this chip replaced after some time with another like it was done for r64?
seems like openwrt uses much smaller driver than i had used on my old r64 branch…but i guess it depends on swconfig framework
is the driver only this file (maybe some includes)?
i see no Makefile/Kconfig including it…
added both drivers to branch 5.15-r2pro of my repo…old driver is still not compilable due to api changes, openwrt-driver compiles (currently active)
regards Frank
as current dts for rk3568 EVB board does not have ethernet-node, i copied the node from rk3368 (clock constants are unknown, as they have different names like ACLK_GMAC0/PCLK_GMAC0/…) and changed compatible, as driver seems to support it
With the R2-Pro, my guesses would be that the RTL8367RB is connected via MDIO bus, and MAC-MAC RGMII fixed link to EXT1 interface of switch from GMAC of SoC.
The design part is tricky as GMAC requires RGMII reference clock of 125Mhz, else the interface can’t be brought up.
This depends on the exact switch model used on the R2-Pro.
RTL8367 has a lot of variants, the one I was working on had RTL8367RB marked on the chip, but actually was the RTL8367C or SB (idk why realtek would do that)
The OpenWrt RTL8367RB drivers wasn’t able to recognize the switch,
I copied the file rtl8367b and its depencies to my repo…so i hope RTL8367RB-VB-CG is supported by this. If this does not work i can try the driver i’ve used on bpi-r64 (but this still needs some changes to be compilable in 5.15)
i don’t know swconfig tool much (only its name) and cannot compile it outside of openwrt (tried some years ago). basicly it should have a fixed config for debian/ubuntu (wan to eth1,lanX to eth0)
IMHO bringing up the RTL8367 won’t be an issue. although, getting a fixed-link at GMAC to EXT interface of switch will require some modifications to stmmac drivers.
seems like perl called by lintian is failed due to missing procfs…
Cannot open /proc/109668/fd, falling back to generic method - No such file or directory at /usr/share/perl5/IO/Async/OS/linux.pm line 38.
so i did this:
sudo mount -o bind /proc $rootdir/proc
now the error disappear, but still no binary in deb…but i see binary in usr/src/swconfig with actual timestamp and i can call it inside the chroot, so i append it here…no need for debian-package for now
/usr/src/swconfig# ./swconfig
swconfig list
swconfig dev <dev> [port <port>|vlan <vlan>] (help|set <key> <value>|get <key>|load <config>|show)
Openwrt tries to recognize chip model by software version:
Seems it is impossible to get the chip_id,you can try add your chip_ver to the switch above
Currently i look if we can transform openwrt phy driver above into an dsa driver. One problem is to find out mdio-gpio which is needed by realtek smi driver
I hope i get sample soon to check if at least phy driver is working or to look what to modify
Thank you,can you tell me if switch will be replaced by mt753x or similar (as it was done on r64 v0.x)? I see there is no switch driver in uboot yet,so netboot will not be possible
maybe someone from bpi team can help me transforming the rtl8367 phy-driver to a dsa driver…i have stripped needed functions from the codebase (100k => 3.5k lines) to get a smaller driver. but i hang on mdio-bus needed for dsa (for accessing the phy)…don’t understand the concept behind acces from dsa core to the switch phy (imho driver should setup the switch not the dsa core, maybe some translation is required).
@wei.zuo can you tell me whats different in network compared to evb? I can boot mainline (5.16-rc4) with my dts (evb with changed iodomain and switch node added),but ethernet driver reports it cannot connect to phy
Just for info: mainline uboot (2022-01-rc) with patch for fip-creation is bootable,but cannot boot kernel. Confirmed by Peter. So i use peters uboot and boot Image+dtb with extlinux.conf (currently with his initrd and reduced quartz64 defconfig)
Our chipid 0x6367 seems to be supported.
Currently i hang on getting gmac/mdio up on soc-side (with reduced phy driver) but then we can test the dsa driver. currently it’s hard to apply it because it depends on net-next with many other patches before.
If anybody can figure out,how to define the dts (linking to mdio, interface mode) we can test it.
I have added the dsa driver in 5.16-r2pro-dsa tree,and do some tests woth old r64,but it seems that mdio is not working right…i always get 0x0 as chip id and so initialization is not done
Maybe anyone has an idea whats missing/wrong? Maybe the reset is needed,but driver does not support it yet
with a reset of switch using the gpio definition from phy-driver, i get dsa-driver running partially on my r64 v0.1…switch is initialized and dsa-ports are shown in “ip a”…after changing names the seem to be functional…but i cannot get the gmac to run (no traffic), in phy-driver it uses EXTPORT0 as gmac0 (sgmii-port in r64v0.1 i have changed to rgmii/1000Mbit/s already, dsa driver only supports only rgmii). this is mapped to internal number 16, need to look how this is used and compare to dsa driver where a dts-property “realtek,ext-int” (defined as 0-2, so i used 0) is used like it seems…but i’m unsure if i need to change “reg” too
but it seems they come not together (no traffic), rx_pkt_n is zero whereas tx_pkt_n is 51 after some pings (using “lan0” port, first lan next to wan)
@wei.zuo any idea? btw. i wonder why switch driver setup 2 gmacs but wan-port seems not going over switch (is already working in my mainline linux without working switch)
Edit: problem is portmap…as wan is directly connected i dropped portmap property in dts. Now the last port (port4,not connected) get the vlan config for “wan”…now all 4 lan-ports working with full phy driver. And after changing mdio phy-id (r64 used 29,r2pro uses 0) in my reduced driver it works too
edit 2: my reduced phy driver has now a dts property to set the phy-id, works on both devices without touching driver code. got dsa driver on r64 working by using second gmac (already rgmii), maybe first gmac/switchport does not support rgmii. wait for next version and merge this then to r2pro and test there
FYI: With some minor problems (strange ip assignment, flapping unconnected interfaces) i got the dsa driver posted to mainline working on my r2pro. It will not be merged to 5.17 but maybe 5.18.
It is a very basic driver that does not support internal switching (all traffic goes to cpu), no hw offload and rgmii only.
or are the printed values the right ones? Did not found pmu-domain in this dts
but this alone is not enough