I had a quick look at the R2 , and yes , support may be limited due to the fact that they are using a whole new suite of chips . So nothing would be reusable form the work done for the R1 . The clearfog in my use case would be a bit of an overkill , since SFP is not a requirement nor is the sim card etc... I have been looking at something like this : https://www.aliexpress.com/item/NEW-Mini-pc-X86-4-Lan-Qotom-Q190G4N-with-celeron-J1900-quad-core-4-usb-VGA/32785346279.html with this I can run the stock C7 installation since the cpu is 64 bit x86 . And the power consumption is 10W . On Thu, May 11, 2017 at 6:39 AM, Robert Moskowitz <rgm at htt-consult.com> wrote: > 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-9 >>>>>>> 8d7-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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20170512/77abd07e/attachment-0006.html>