Oh course there is an R2: http://www.banana-pi.org/r2.html It would be interesting to see if this runs without patches with the 4.9 kernel. I would be interested if it does. Also if it can boot from the sata. Perhaps ask on the Fedora-arm list? More board activity there than here. :( On 05/10/2017 07:50 AM, 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 > >