[Arm-dev] More questions on BPi - Re: Kernel for BananaPi R1 (Lamobo R1) - Success
Robert Moskowitz
rgm at htt-consult.com
Wed May 10 12:13:30 UTC 2017
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-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
>>
>
>
More information about the Arm-dev
mailing list