<div dir="ltr">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...<div><br></div><div>I have been looking at something like this :</div><div><br></div><div><a href="https://www.aliexpress.com/item/NEW-Mini-pc-X86-4-Lan-Qotom-Q190G4N-with-celeron-J1900-quad-core-4-usb-VGA/32785346279.html">https://www.aliexpress.com/item/NEW-Mini-pc-X86-4-Lan-Qotom-Q190G4N-with-celeron-J1900-quad-core-4-usb-VGA/32785346279.html</a><br></div><div><br></div><div>with this I can run the stock C7 installation since the cpu is 64 bit x86 . And the power consumption is 10W .</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 6:39 AM, Robert Moskowitz <span dir="ltr"><<a href="mailto:rgm@htt-consult.com" target="_blank">rgm@htt-consult.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No support for the BPi-R2 even in Fedora-26.<br>
<br>
I was told to look at:<br>
<br>
<a href="https://www.solid-run.com/product/clearfog-pro/" rel="noreferrer" target="_blank">https://www.solid-run.com/prod<wbr>uct/clearfog-pro/</a><br>
<br>
But it is pricey.<div class="HOEnZb"><div class="h5"><br>
<br>
On 05/10/2017 08:13 AM, Robert Moskowitz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
<br>
On 05/10/2017 08:06 AM, mo.ucina wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 ?<br>
<br>
Regards<br>
<br>
Milorad<br>
<br>
<br>
On 10/05/17 21:50, mo.ucina wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Guys,<br>
<br>
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<wbr>.d/pre-up.d/ . In there the configuration is is set up such as this :<br>
<br>
#!/bin/bash<br>
<br>
# VLAN config for BCM53125<br>
<br>
ifconfig eth0 up<br>
<br>
/usr/local/bin/swconfig dev eth0 set reset<br>
/usr/local/bin/swconfig dev eth0 set reset_mib 1<br>
/usr/local/bin/swconfig dev eth0 set enable_vlan 1<br>
/usr/local/bin/swconfig dev eth0 vlan 101 set ports '3 8t'<br>
/usr/local/bin/swconfig dev eth0 vlan 102 set ports '4 8t'<br>
/usr/local/bin/swconfig dev eth0 set apply<br>
<br>
<br>
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 :<br>
<br>
cat /etc/NetworkManager/dispatcher<wbr>.d/pre-up.d/bcm53125-config<br>
<br>
#!/bin/bash<br>
<br>
# Network and VLAN config for BCM53125 router<br>
<br>
/usr/sbin/ip link add br1 type bridge<br>
/usr/sbin/ip link set dev br1 up<br>
/usr/sbin/ip link set lan1 master br1<br>
/usr/sbin/ip link set lan2 master br1<br>
/usr/sbin/ip link set lan3 master br1<br>
/usr/sbin/ip link set lan4 master br1<br>
/usr/sbin/ip link set wan master br1<br>
/sbin/bridge vlan add vid 2 dev wan pvid untagged<br>
/sbin/bridge vlan del vid 1 dev wan<br>
/usr/sbin/ip link set lan1 up<br>
/usr/sbin/ip link set lan2 up<br>
/usr/sbin/ip link set lan3 up<br>
/usr/sbin/ip link set lan4 up<br>
/usr/sbin/ip link set wan up<br>
<br>
<br>
<br>
This will set up a config where in my case :<br>
<br>
eth0.1 vlanid 1 connects to LAN and has 192.168.1.1 address<br>
eth0.2 vlanid 2 connects to WAN and has 192.168.0.10 address<br>
<br>
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 :<br>
<br>
The CPU port of the BCM53125 is configured with RGMII (no delays) but<br>
this should actually be RGMII with transmit delay (rgmii-txid) because<br>
STMMAC takes care of inserting the transmitter delay. This fixes<br>
occasional packet loss encountered.<br>
<br>
Fixes: d7b9eaff5f0c ("ARM: dts: sun7i: Add BCM53125 switch nodes to the lamobo-r1 board")<br>
Reported-by: Hartmut Knaack<<a href="mailto:knaack.h@gmx.de" target="_blank">knaack.h@gmx.de</a>><br>
Signed-off-by: Florian Fainelli<<a href="mailto:f.fainelli@gmail.com" target="_blank">f.fainelli@gmail.com</a>><br>
---<br>
arch/arm/boot/dts/sun7i-a20-l<wbr>amobo-r1.dts | 2 +-<br>
1 file changed, 1 insertion(+), 1 deletion(-)<br>
<br>
diff --git a/arch/arm/boot/dts/sun7i-a20-<wbr>lamobo-r1.dts b/arch/arm/boot/dts/sun7i-a20-<wbr>lamobo-r1.dts<br>
index 72ec0d5ae052..bbf1c8cbaac6 100644<br>
--- a/arch/arm/boot/dts/sun7i-a20-<wbr>lamobo-r1.dts<br>
+++ b/arch/arm/boot/dts/sun7i-a20-<wbr>lamobo-r1.dts<br>
@@ -167,7 +167,7 @@<br>
reg = <8>;<br>
label = "cpu";<br>
ethernet = <&gmac>;<br>
- phy-mode = "rgmii";<br>
+ phy-mode = "rgmii-txid";<br>
<br>
However the patch has not made it yet upstream . SO I am waiting until it does .<br>
<br>
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?<br>
<br>
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 .<br>
<br>
<br>
Best Regards<br>
<br>
Milorad<br>
<br>
<br>
On 25/04/17 03:39, Robert Moskowitz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It looks from this that he did not get the LAN ports working, only the WAN (eth0)?<br>
<br>
I believe Fedora25 fully supports the WAN port, the LAN might be another challenge.<br>
<br>
And what of the R2 quad processor?<br>
<br>
If I had some more boards, I could test them. But I don't have ready money to buy different boards for different testing :(<br>
<br>
On 02/26/2017 02:33 AM, Karanbir Singh wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 28/02/16 05:40, mo.ucina wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Guys,<br>
<br>
After a bit of fiddling around I found my missing files and copied them<br>
over to /boot . The procedure that I used is as follows (first install<br>
home-made kernel) :<br>
<br>
- yum localinstall kernel*<br>
<br>
Then /boot files:<br>
<br>
rsync -av /usr/lib/modules/4.4.2-300.LR1<wbr>.el7.armv7hl/dtb/<br>
/boot/<a href="http://dtb-4.4.2-300.LR1.el7.ar">dtb-4.4.2-300.LR1.el7.ar</a><wbr>mv7hl<br>
cp /usr/lib/modules/4.4.2-300.LR1<wbr>.el7.armv7hl/System.map<br>
/boot/System.map-4.4.2-300.LR1<wbr>.el7.armv7hl<br>
cp /usr/lib/modules/4.4.2-300.LR1<wbr>.el7.armv7hl/config<br>
/boot/config-4.4.2-300.LR1.el7<wbr>.armv7hl<br>
cp /usr/lib/modules/4.4.2-300.LR1<wbr>.el7.armv7hl/vmlinuz<br>
/boot/vmlinuz-4.4.2-300.LR1.el<wbr>7.armv7hl<br>
dracut /boot/initramfs-4.4.2-300.LR1.<wbr>el7.armv7hl.img<br>
4.4.2-300.LR1.el7.armv7hl<br>
<br>
/boot dir now looks like this :<br>
<br>
root@bananapi /boot # ls -l<br>
total 87757<br>
drwxr-xr-x. 5 root root 1024 Feb 27 09:17<br>
38f5ec9e217b471e8adee477d933f6<wbr>40<br>
-rw-r--r--. 1 root root 171924 Nov 26 00:43 config-4.2.3-200.el7.armv7hl<br>
-rw-r--r--. 1 root root 176632 Feb 28 05:03<br>
config-4.4.2-300.LR1.el7.armv7<wbr>hl<br>
drwxr-xr-x. 2 root root 15360 Dec 3 14:37 dtb-4.2.3-200.el7.armv7hl<br>
drwxr-xr-x. 2 root root 17408 Feb 27 09:11 dtb-4.4.2-300.LR1.el7.armv7hl<br>
drwxr-xr-x. 2 root root 1024 Feb 27 10:33 extlinux<br>
drwxr-xr-x. 2 root root 1024 Jan 1 1970 grub<br>
-rw-r--r--. 1 root root 34922581 Dec 3 14:46<br>
initramfs-4.2.3-200.el7.armv7h<wbr>l.img<br>
-rw-r--r--. 1 root root 35844383 Feb 28 05:08<br>
<a href="http://initramfs-4.4.2-300.LR1.el7.ar">initramfs-4.4.2-300.LR1.el7.ar</a><wbr>mv7hl.img<br>
-rw-r--r--. 1 root root 592347 Dec 3 14:37 initrd-plymouth.img<br>
drwxr-xr-x. 3 root root 1024 Dec 3 14:44 loader<br>
drwx------. 2 root root 12288 Dec 3 14:31 lost+found<br>
-rw-------. 1 root root 2879429 Nov 26 00:43<br>
System.map-4.2.3-200.el7.armv7<wbr>hl<br>
-rw-------. 1 root root 2945068 Feb 28 04:58<br>
System.map-4.4.2-300.LR1.el7.a<wbr>rmv7hl<br>
-rwxr-xr-x. 1 root root 5866104 Nov 26 00:43 vmlinuz-4.2.3-200.el7.armv7hl<br>
-rwxr-xr-x. 1 root root 6032808 Feb 28 05:04<br>
vmlinuz-4.4.2-300.LR1.el7.armv<wbr>7hl<br>
<br>
then modify extlinux.conf :<br>
<br>
root@bananapi /boot # cat extlinux/extlinux.conf<br>
#Created by RootFS Build Factory<br>
ui menu.c32<br>
menu autoboot centos<br>
menu title centos Options<br>
#menu hidden<br>
timeout 60<br>
totaltimeout 600<br>
label centos<br>
kernel /vmlinuz-4.4.2-300.LR1.el7.arm<wbr>v7hl<br>
append enforcing=0 root=UUID=9359b607-7331-40ef-9<wbr>8d7-556faebff04d<br>
fdtdir /dtb-4.4.2-300.LR1.el7.armv7hl<br>
initrd /initramfs-4.4.2-300.LR1.el7.a<wbr>rmv7hl.img<br>
<br>
then reboot:<br>
systemctl reboot<br>
<br>
Once rebooted the new kernel loaded :<br>
root@bananapi /home/user # uname -a<br>
Linux bananapi 4.4.2-300.LR1.el7.armv7hl #1 SMP Sat Feb 27 01:39:09 UTC<br>
2016 armv7l armv7l armv7l GNU/Linux<br>
<br>
And the switch driver was detected , from dmesg:<br>
<br>
[ 22.138529] b53_common: found switch: BCM53125, rev 4<br>
[ 22.147309] RX IPC Checksum Offload disabled<br>
[ 22.154566] No MAC Management Counters available<br>
[ 22.207713] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready<br>
[ 22.553164] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready<br>
[ 22.632139] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready<br>
[ 24.143962] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -<br>
1Gbps/Full - flow control off<br>
<br>
Because the eth0 was set for dhcp , it automatically came up , since I<br>
had the Ethernet cable plugged into the "WAN" port :<br>
<br>
root@bananapi /home/user # nmcli con<br>
NAME UUID TYPE DEVICE<br>
eth0 a19cdd55-f428-40cb-baf7-8c0e92<wbr>21bc66 802-3-ethernet eth0<br>
<br>
root@bananapi /home/user # ifconfig<br>
eth0: flags=4163<UP,BROADCAST,RUNNIN<wbr>G,MULTICAST> mtu 1500<br>
inet 192.168.1.166 netmask 255.255.255.0 broadcast 192.168.1.255<br>
inet6 fe80::c7:6ff:fec2:f2eb prefixlen 64 scopeid 0x20<link><br>
inet6 fdc1:4e49:af09:1:c7:6ff:fec2:f<wbr>2eb prefixlen 64 scopeid<br>
0x0<global><br>
ether 02:c7:06:c2:f2:eb txqueuelen 1000 (Ethernet)<br>
RX packets 537 bytes 46072 (44.9 KiB)<br>
RX errors 0 dropped 0 overruns 0 frame 0<br>
TX packets 439 bytes 74044 (72.3 KiB)<br>
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0<br>
device interrupt 48<br>
<br>
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536<br>
inet 127.0.0.1 netmask 255.0.0.0<br>
inet6 ::1 prefixlen 128 scopeid 0x10<host><br>
loop txqueuelen 0 (Local Loopback)<br>
RX packets 24 bytes 2316 (2.2 KiB)<br>
RX errors 0 dropped 0 overruns 0 frame 0<br>
TX packets 24 bytes 2316 (2.2 KiB)<br>
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0<br>
<br>
So here it is R1 is working via the built in port . One further<br>
clarification : The kernel driver on its own is enough to get the<br>
Ethernet port working . You do not need anything else . However if you<br>
want to start using the inbuilt switch for things like VLAN tagging ,<br>
then you need to have a utility called swconfig . I have used this<br>
approach in my home router setup to create two virtual interfaces on<br>
different subnets. This is the only way to do it since we only have one<br>
physical NIC . But more on this later .<br>
<br>
Best Regards<br>
Milorad<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Arm-dev mailing list<br>
<a href="mailto:Arm-dev@centos.org" target="_blank">Arm-dev@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/arm-dev" rel="noreferrer" target="_blank">https://lists.centos.org/mailm<wbr>an/listinfo/arm-dev</a><br>
<br>
</blockquote>
did the r1 support get rolled into the centos images /kernel ?<br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Arm-dev mailing list<br>
<a href="mailto:Arm-dev@centos.org" target="_blank">Arm-dev@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/arm-dev" rel="noreferrer" target="_blank">https://lists.centos.org/mailm<wbr>an/listinfo/arm-dev</a><br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Arm-dev mailing list<br>
<a href="mailto:Arm-dev@centos.org" target="_blank">Arm-dev@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/arm-dev" rel="noreferrer" target="_blank">https://lists.centos.org/mailm<wbr>an/listinfo/arm-dev</a><br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>