[Arm-dev] More questions on BPi - Re: Kernel for BananaPi R1 (Lamobo R1) - Success

Fri May 12 02:21:44 UTC 2017
OM Ugarcina <mo.ucina at gmail.com>

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>