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@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@gmx.de>
Signed-off-by: Florian Fainelli<f.fainelli@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@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@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@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@bananapi /home/user # nmcli con
NAME  UUID                                  TYPE DEVICE
eth0  a19cdd55-f428-40cb-baf7-8c0e9221bc66 802-3-ethernet eth0

root@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@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@centos.org
https://lists.centos.org/mailman/listinfo/arm-dev




_______________________________________________
Arm-dev mailing list
Arm-dev@centos.org
https://lists.centos.org/mailman/listinfo/arm-dev