No support for the BPi-R2 even in Fedora-26. I was told to look at: https://www.solid-run.com/product/clearfog-pro/ But it is pricey. On 05/10/2017 08:13 AM, Robert Moskowitz wrote: > I would be interested in getting an R2 to work with it is fully > supported with the distributed kernel. I am not into patching things. > > > On 05/10/2017 08:06 AM, mo.ucina wrote: >> Update , the RGMII patch has finally made it in , but it is in kernel >> 4.11 . What are the chances it will be backported to 4.9 ? Or is >> there a plan to uplift Centos arm kernel to 4.11 ? >> >> Regards >> >> Milorad >> >> >> On 10/05/17 21:50, mo.ucina wrote: >>> Hello Guys, >>> >>> I have been using the patches for the switch driver on kernel 4.4 >>> for a while now , and compiling them into the kernel . The sources >>> are from OpenWrt and require a userspace program to configure the >>> switch called swconfig as I mentioned below . It also needs to be >>> compiled from OpenWrt sources and patched to remove some unnecessary >>> bits that OWRT puts in . Things such as Lucy support anywho , it >>> works ok . I am using the Lamobo R1 to route so I have defined two >>> interfaces with vlans , then I use the swconfig to assign those >>> vlans to switch ports . This is done on boot (since config is lost >>> after reboot , it is not persistent ) by NetworkManager Dispatcher >>> via a script . The path for that is >>> /etc/NetworkManager/dispatcher.d/pre-up.d/ . In there the >>> configuration is is set up such as this : >>> >>> #!/bin/bash >>> >>> # VLAN config for BCM53125 >>> >>> ifconfig eth0 up >>> >>> /usr/local/bin/swconfig dev eth0 set reset >>> /usr/local/bin/swconfig dev eth0 set reset_mib 1 >>> /usr/local/bin/swconfig dev eth0 set enable_vlan 1 >>> /usr/local/bin/swconfig dev eth0 vlan 101 set ports '3 8t' >>> /usr/local/bin/swconfig dev eth0 vlan 102 set ports '4 8t' >>> /usr/local/bin/swconfig dev eth0 set apply >>> >>> >>> Since kernel 4.9 the upstream have added more generic drivers for >>> the lamobo r1 , and all of above is not necessary . The new approach >>> is not to use programs to configure the switch , but to relay on >>> generic concepts already in linux such as bridge . So to replicate >>> the above basically in the new 4.9 kernel we would do something like : >>> >>> cat /etc/NetworkManager/dispatcher.d/pre-up.d/bcm53125-config >>> >>> #!/bin/bash >>> >>> # Network and VLAN config for BCM53125 router >>> >>> /usr/sbin/ip link add br1 type bridge >>> /usr/sbin/ip link set dev br1 up >>> /usr/sbin/ip link set lan1 master br1 >>> /usr/sbin/ip link set lan2 master br1 >>> /usr/sbin/ip link set lan3 master br1 >>> /usr/sbin/ip link set lan4 master br1 >>> /usr/sbin/ip link set wan master br1 >>> /sbin/bridge vlan add vid 2 dev wan pvid untagged >>> /sbin/bridge vlan del vid 1 dev wan >>> /usr/sbin/ip link set lan1 up >>> /usr/sbin/ip link set lan2 up >>> /usr/sbin/ip link set lan3 up >>> /usr/sbin/ip link set lan4 up >>> /usr/sbin/ip link set wan up >>> >>> >>> >>> This will set up a config where in my case : >>> >>> eth0.1 vlanid 1 connects to LAN and has 192.168.1.1 address >>> eth0.2 vlanid 2 connects to WAN and has 192.168.0.10 address >>> >>> I have done some testing of the new method , however have not used >>> this in my production environment yet . The author of the switch >>> driver has recommended a patch to the dts , as we see here : >>> >>> The CPU port of the BCM53125 is configured with RGMII (no delays) but >>> this should actually be RGMII with transmit delay (rgmii-txid) because >>> STMMAC takes care of inserting the transmitter delay. This fixes >>> occasional packet loss encountered. >>> >>> Fixes: d7b9eaff5f0c ("ARM: dts: sun7i: Add BCM53125 switch nodes to >>> the lamobo-r1 board") >>> Reported-by: Hartmut Knaack<knaack.h at gmx.de> >>> Signed-off-by: Florian Fainelli<f.fainelli at gmail.com> >>> --- >>> arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts >>> b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts >>> index 72ec0d5ae052..bbf1c8cbaac6 100644 >>> --- a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts >>> +++ b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts >>> @@ -167,7 +167,7 @@ >>> reg = <8>; >>> label = "cpu"; >>> ethernet = <&gmac>; >>> - phy-mode = "rgmii"; >>> + phy-mode = "rgmii-txid"; >>> >>> However the patch has not made it yet upstream . SO I am waiting >>> until it does . >>> >>> Having said that I am not sure that I will persist with the lamobo >>> r1 going forward , and the new kernel would not make any difference >>> for me . This is because of the performance envelope of the R1 . As >>> an ASDL user the performance is very good , taking into account the >>> small power consumption and adequate throughput . However when >>> moving up to higher speeds , the R1 will not be able to manage . In >>> my testing with iperf the routing starts becoming CPU limited . And >>> it maxes out the R1 at about 370 to 400 Mbps . At first this looked >>> OK since I was planing to move over to a 100Mbps Cable plan . >>> However my testing around 100Mbps showed that R1's throughput starts >>> to decline at about 80Mbps, which gets worse as the input increases >>> . So to get 100Mbps out , you need to be feeding in about 120Mbps . >>> I guess for my usecase I just need a bit more CPU power . Is there >>> an R2 yet? >>> >>> My current plan is to go up to a board with a J1900 celeron , more >>> power consumption unfortunately , but on the plus side a 64 bit >>> intel cpu that runs stock Centos 7 . >>> >>> >>> Best Regards >>> >>> Milorad >>> >>> >>> On 25/04/17 03:39, Robert Moskowitz wrote: >>>> It looks from this that he did not get the LAN ports working, only >>>> the WAN (eth0)? >>>> >>>> I believe Fedora25 fully supports the WAN port, the LAN might be >>>> another challenge. >>>> >>>> And what of the R2 quad processor? >>>> >>>> If I had some more boards, I could test them. But I don't have >>>> ready money to buy different boards for different testing :( >>>> >>>> On 02/26/2017 02:33 AM, Karanbir Singh wrote: >>>>> On 28/02/16 05:40, mo.ucina wrote: >>>>>> Hello Guys, >>>>>> >>>>>> After a bit of fiddling around I found my missing files and >>>>>> copied them >>>>>> over to /boot . The procedure that I used is as follows (first >>>>>> install >>>>>> home-made kernel) : >>>>>> >>>>>> - yum localinstall kernel* >>>>>> >>>>>> Then /boot files: >>>>>> >>>>>> rsync -av /usr/lib/modules/4.4.2-300.LR1.el7.armv7hl/dtb/ >>>>>> /boot/dtb-4.4.2-300.LR1.el7.armv7hl >>>>>> cp /usr/lib/modules/4.4.2-300.LR1.el7.armv7hl/System.map >>>>>> /boot/System.map-4.4.2-300.LR1.el7.armv7hl >>>>>> cp /usr/lib/modules/4.4.2-300.LR1.el7.armv7hl/config >>>>>> /boot/config-4.4.2-300.LR1.el7.armv7hl >>>>>> cp /usr/lib/modules/4.4.2-300.LR1.el7.armv7hl/vmlinuz >>>>>> /boot/vmlinuz-4.4.2-300.LR1.el7.armv7hl >>>>>> dracut /boot/initramfs-4.4.2-300.LR1.el7.armv7hl.img >>>>>> 4.4.2-300.LR1.el7.armv7hl >>>>>> >>>>>> /boot dir now looks like this : >>>>>> >>>>>> root at bananapi /boot # ls -l >>>>>> total 87757 >>>>>> drwxr-xr-x. 5 root root 1024 Feb 27 09:17 >>>>>> 38f5ec9e217b471e8adee477d933f640 >>>>>> -rw-r--r--. 1 root root 171924 Nov 26 00:43 >>>>>> config-4.2.3-200.el7.armv7hl >>>>>> -rw-r--r--. 1 root root 176632 Feb 28 05:03 >>>>>> config-4.4.2-300.LR1.el7.armv7hl >>>>>> drwxr-xr-x. 2 root root 15360 Dec 3 14:37 >>>>>> dtb-4.2.3-200.el7.armv7hl >>>>>> drwxr-xr-x. 2 root root 17408 Feb 27 09:11 >>>>>> dtb-4.4.2-300.LR1.el7.armv7hl >>>>>> drwxr-xr-x. 2 root root 1024 Feb 27 10:33 extlinux >>>>>> drwxr-xr-x. 2 root root 1024 Jan 1 1970 grub >>>>>> -rw-r--r--. 1 root root 34922581 Dec 3 14:46 >>>>>> initramfs-4.2.3-200.el7.armv7hl.img >>>>>> -rw-r--r--. 1 root root 35844383 Feb 28 05:08 >>>>>> initramfs-4.4.2-300.LR1.el7.armv7hl.img >>>>>> -rw-r--r--. 1 root root 592347 Dec 3 14:37 initrd-plymouth.img >>>>>> drwxr-xr-x. 3 root root 1024 Dec 3 14:44 loader >>>>>> drwx------. 2 root root 12288 Dec 3 14:31 lost+found >>>>>> -rw-------. 1 root root 2879429 Nov 26 00:43 >>>>>> System.map-4.2.3-200.el7.armv7hl >>>>>> -rw-------. 1 root root 2945068 Feb 28 04:58 >>>>>> System.map-4.4.2-300.LR1.el7.armv7hl >>>>>> -rwxr-xr-x. 1 root root 5866104 Nov 26 00:43 >>>>>> vmlinuz-4.2.3-200.el7.armv7hl >>>>>> -rwxr-xr-x. 1 root root 6032808 Feb 28 05:04 >>>>>> vmlinuz-4.4.2-300.LR1.el7.armv7hl >>>>>> >>>>>> then modify extlinux.conf : >>>>>> >>>>>> root at bananapi /boot # cat extlinux/extlinux.conf >>>>>> #Created by RootFS Build Factory >>>>>> ui menu.c32 >>>>>> menu autoboot centos >>>>>> menu title centos Options >>>>>> #menu hidden >>>>>> timeout 60 >>>>>> totaltimeout 600 >>>>>> label centos >>>>>> kernel /vmlinuz-4.4.2-300.LR1.el7.armv7hl >>>>>> append enforcing=0 >>>>>> root=UUID=9359b607-7331-40ef-98d7-556faebff04d >>>>>> fdtdir /dtb-4.4.2-300.LR1.el7.armv7hl >>>>>> initrd /initramfs-4.4.2-300.LR1.el7.armv7hl.img >>>>>> >>>>>> then reboot: >>>>>> systemctl reboot >>>>>> >>>>>> Once rebooted the new kernel loaded : >>>>>> root at bananapi /home/user # uname -a >>>>>> Linux bananapi 4.4.2-300.LR1.el7.armv7hl #1 SMP Sat Feb 27 >>>>>> 01:39:09 UTC >>>>>> 2016 armv7l armv7l armv7l GNU/Linux >>>>>> >>>>>> And the switch driver was detected , from dmesg: >>>>>> >>>>>> [ 22.138529] b53_common: found switch: BCM53125, rev 4 >>>>>> [ 22.147309] RX IPC Checksum Offload disabled >>>>>> [ 22.154566] No MAC Management Counters available >>>>>> [ 22.207713] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready >>>>>> [ 22.553164] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready >>>>>> [ 22.632139] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready >>>>>> [ 24.143962] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - >>>>>> 1Gbps/Full - flow control off >>>>>> >>>>>> Because the eth0 was set for dhcp , it automatically came up , >>>>>> since I >>>>>> had the Ethernet cable plugged into the "WAN" port : >>>>>> >>>>>> root at bananapi /home/user # nmcli con >>>>>> NAME UUID TYPE DEVICE >>>>>> eth0 a19cdd55-f428-40cb-baf7-8c0e9221bc66 802-3-ethernet eth0 >>>>>> >>>>>> root at bananapi /home/user # ifconfig >>>>>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >>>>>> inet 192.168.1.166 netmask 255.255.255.0 broadcast >>>>>> 192.168.1.255 >>>>>> inet6 fe80::c7:6ff:fec2:f2eb prefixlen 64 scopeid >>>>>> 0x20<link> >>>>>> inet6 fdc1:4e49:af09:1:c7:6ff:fec2:f2eb prefixlen 64 >>>>>> scopeid >>>>>> 0x0<global> >>>>>> ether 02:c7:06:c2:f2:eb txqueuelen 1000 (Ethernet) >>>>>> RX packets 537 bytes 46072 (44.9 KiB) >>>>>> RX errors 0 dropped 0 overruns 0 frame 0 >>>>>> TX packets 439 bytes 74044 (72.3 KiB) >>>>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>>>>> device interrupt 48 >>>>>> >>>>>> lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 >>>>>> inet 127.0.0.1 netmask 255.0.0.0 >>>>>> inet6 ::1 prefixlen 128 scopeid 0x10<host> >>>>>> loop txqueuelen 0 (Local Loopback) >>>>>> RX packets 24 bytes 2316 (2.2 KiB) >>>>>> RX errors 0 dropped 0 overruns 0 frame 0 >>>>>> TX packets 24 bytes 2316 (2.2 KiB) >>>>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>>>>> >>>>>> So here it is R1 is working via the built in port . One further >>>>>> clarification : The kernel driver on its own is enough to get the >>>>>> Ethernet port working . You do not need anything else . However >>>>>> if you >>>>>> want to start using the inbuilt switch for things like VLAN >>>>>> tagging , >>>>>> then you need to have a utility called swconfig . I have used this >>>>>> approach in my home router setup to create two virtual interfaces on >>>>>> different subnets. This is the only way to do it since we only >>>>>> have one >>>>>> physical NIC . But more on this later . >>>>>> >>>>>> Best Regards >>>>>> Milorad >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Arm-dev mailing list >>>>>> Arm-dev at centos.org >>>>>> https://lists.centos.org/mailman/listinfo/arm-dev >>>>>> >>>>> did the r1 support get rolled into the centos images /kernel ? >>>>> >>>> >>>> _______________________________________________ >>>> Arm-dev mailing list >>>> Arm-dev at centos.org >>>> https://lists.centos.org/mailman/listinfo/arm-dev >>> >> >> > > _______________________________________________ > Arm-dev mailing list > Arm-dev at centos.org > https://lists.centos.org/mailman/listinfo/arm-dev >