Hello Guys,
I have been compiling the Fedora 4.4.2-300 kernel for Centos , using the new Centos image for the Banana-pi . I have used the Fedora src rpm and then added the patch for the switch drivers specific for R1 (Lamobo R1) , then compiled it within the Centos dev arm environment I have . I ran into a couple of things : one cosmetic , the other one not so . Firstly the cosmetic one is that my packages came out looking like this :
-rw-rw-r-- 1 user user 49332 Feb 26 07:27 kernel-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 87721969 Feb 26 07:27 kernel-4.4.2-300.LR1.el7.centos.src.rpm -rw-rw-r-- 1 user user 18785384 Feb 26 07:29 kernel-core-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 10452672 Feb 26 07:30 kernel-devel-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 1012496 Feb 26 07:27 kernel-headers-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 11844188 Feb 26 07:31 kernel-modules-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 925980 Feb 26 07:31 kernel-modules-extra-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 105452 Feb 26 07:27 kernel-tools-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 65356 Feb 26 07:27 kernel-tools-libs-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 52160 Feb 26 07:27 kernel-tools-libs-devel-4.4.2-300.LR1.el7.centos.armv7hl.rpm
They all have "centos" as part of the name , which I did not expect . I did not get that when compiling in Fedora. How do you remove that ?
Second observation , a one that is a bit of a concern is that , after installing the new kernel I am missing bits :
user@bananapi /boot $ ls -l total 43611 drwxr-xr-x. 5 root root 1024 Feb 25 22:21 38f5ec9e217b471e8adee477d933f640 -rw-r--r--. 1 root root 171924 Nov 26 00:43 config-4.2.3-200.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 1024 Dec 3 14:47 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 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 -rwxr-xr-x. 1 root root 5866104 Nov 26 00:43 vmlinuz-4.2.3-200.el7.armv7hl
I expected that I would be missing 'initramfs' as the install prog is still work-in-progress. And I was prepared to create it with dracut . However I did not expect not to be missing all the other bits such as : config , dtb, system.map, vmlinuz . I did find my new kernel it was in that dir with a hex name :
user@bananapi /boot $ ls -l 38f5ec9e217b471e8adee477d933f640/* 38f5ec9e217b471e8adee477d933f640/0-rescue: total 40652 -rw-r--r--. 1 root root 35427302 Dec 3 14:43 initrd -rwxr-xr-x. 1 root root 6033128 Feb 25 22:26 linux
38f5ec9e217b471e8adee477d933f640/4.2.3-200.el7.armv7hl: total 39995 -rw-r--r--. 1 root root 34923169 Dec 3 14:40 initrd -rw-r--r--. 1 root root 5866104 Dec 3 14:44 linux
38f5ec9e217b471e8adee477d933f640/4.4.2-300.LR1.el7.centos.armv7hl: total 41061 -rw-r--r--. 1 root root 35844934 Feb 25 22:24 initrd -rw-r--r--. 1 root root 6033128 Feb 25 22:36 linux
So my question is how do I go from these 2 files above , to the situation where I can boot into the new kernel 4.4.2-300.LR1.el7.centos.armv7hl .
Best Regards Milorad
PS Once I have verified that the switch driver works , I will post it here .
On 26/02/16 11:27, mo.ucina wrote:
Hello Guys,
I have been compiling the Fedora 4.4.2-300 kernel for Centos , using the new Centos image for the Banana-pi . I have used the Fedora src rpm and then added the patch for the switch drivers specific for R1 (Lamobo R1) , then compiled it within the Centos dev arm environment I have . I ran into a couple of things : one cosmetic , the other one not so . Firstly the cosmetic one is that my packages came out looking like this :
<snip>
They all have "centos" as part of the name , which I did not expect . I did not get that when compiling in Fedora. How do you remove that ?
It's actually coming from the default dist tag (in the /etc/rpm/macros.dist) : %dist .el7.centos
So when you build with mock , you can define yourself a specific dist tag with "--define 'dist .el7' "
Second observation , a one that is a bit of a concern is that , after installing the new kernel I am missing bits :
<snip>
So my question is how do I go from these 2 files above , to the situation where I can boot into the new kernel 4.4.2-300.LR1.el7.centos.armv7hl .
Well, still something we need to find a workaround for , and I wrote initially a mail for the newer kernels to be tested : https://lists.centos.org/pipermail/arm-dev/2016-January/001597.html (see the part about generating initramfs with dracut and then editing /boot/extlinux.conf)
Best Regards Milorad
PS Once I have verified that the switch driver works , I will post it here .
Cool. I have also already rebuilt it (kernel-4.4.2-300.el7.armv7hl.rpm) Are the patches under GPL licenses and somewhere to be seen ? If you have to patch the Fedora kernel, that means that even Fedora doesn't have it at the moment, so wondering why.
Thanks a lot for having a look at this ! I'm pretty sure that a lot of people will find that useful
Hello Fabian,
My compilation of the kernel 4.4.2-300 , with the patch went fine . Here is my package list :
user@home1 /home/user/Downloads/ARM_Centos/RPMS $ ls -l total 127920 -rw-rw-r-- 1 user user 49288 Feb 27 20:06 kernel-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 87721962 Feb 27 20:06 kernel-4.4.2-300.LR1.el7.src.rpm -rw-rw-r-- 1 user user 18781728 Feb 27 20:07 kernel-core-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 10420020 Feb 27 20:08 kernel-devel-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 1012436 Feb 27 20:06 kernel-headers-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 11841384 Feb 27 20:09 kernel-modules-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 925624 Feb 27 20:09 kernel-modules-extra-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 105420 Feb 27 20:06 kernel-tools-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 65348 Feb 27 20:06 kernel-tools-libs-4.4.2-300.LR1.el7.armv7hl.rpm -rw-rw-r-- 1 user user 52120 Feb 27 20:06 kernel-tools-libs-devel-4.4.2-300.LR1.el7.armv7hl.rpm
I have given it %define buildid .LR1 in the spec , so that I can tell my kernels apart from the originals . However when it came to the installation , I am finding that there must be more steps involved . After installation in my /boot directory I have :
root@bananapi /boot # ls -l total 43611 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 drwxr-xr-x. 2 root root 15360 Dec 3 14:37 dtb-4.2.3-200.el7.armv7hl drwxr-xr-x. 2 root root 1024 Dec 3 14:47 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 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 -rwxr-xr-x. 1 root root 5866104 Nov 26 00:43 vmlinuz-4.2.3-200.el7.armv7hl
Then I did the command : dracut /boot/initramfs-4.4.2-300.LR1.el7.armv7hl.img 4.4.2-300.LR1.el7.armv7hl
which created just the initramfs-4.4.2-300.LR1.el7.armv7hl.img file . Now I have :
root@bananapi /boot # ls -l total 78753 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 drwxr-xr-x. 2 root root 15360 Dec 3 14:37 dtb-4.2.3-200.el7.armv7hl drwxr-xr-x. 2 root root 1024 Dec 3 14:47 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 35842525 Feb 27 09:30 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 -rwxr-xr-x. 1 root root 5866104 Nov 26 00:43 vmlinuz-4.2.3-200.el7.armv7hl
Then I edited the extlinux.conf , and changed the references to the kernel/initrd , followed by systemctl reboot . However the board did not boot . I am sure it is because I am missing : config-4.4.2-300.LR1.el7.armv7hl dtb-4.4.2-300.el7.LR1.armv7hl System.map-4.4.2-300.LR1.el7.armv7hl vmlinuz-4.4.2-300.el7.LR1.armv7hl
My question is how are those files created, and where (which package ) do they come from . Because I need to create them manually .
By the way , I am attaching the switch patch . To me it looks GPL , or GPL like , so I think it should be fine . To answer your question why Fedora has not used it? My guess the expectation would be that someone needs to have it submitted up stream to Linus T, before it can be considered .
Best Regards Milorad
PS Patch is latest pull done today . And it has been zipped up . So if file extension is not zip , just rename it to zip , and should extract fine .
Hello Guys,
Almost forgot . The kernel config that needs to be done to make drivers work is as follows :
CONFIG_B53=y CONFIG_B53_SPI_DRIVER=y CONFIG_B53_PHY_DRIVER=y CONFIG_B53_SRAB_DRIVER=y CONFIG_B53_PHY_FIXUP=y CONFIG_SWCONFIG=y CONFIG_SWCONFIG_LEDS=y
One more thing . The start of the patch includes the Lamobo R1 specific dtb , which is slightly different from the Bananapi . It enables the SATA power , so you can use the on board SATA socket (otherwise it will be power less - or on reduced voltage) . Also the current uboot-tools has additional Lamobo performance tuning such as different PHY delay , this is because of the different board layout , and track length compared with the banana . All this additional stuff is just icing-on-top , as the R1 will still work happily on the generic banana uboot settings . I have had it running on the generic banana setting for over a year without any major issue (on Fedora 21) . It was just recently - since last Dec , that I moved over to the specific Lamobo uboot settings .
So if you plan just to run it on the bananapi settings , you can leave the lamobo bit out .
Best Regards Milorad
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
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 ?
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 ?
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 Knaackknaack.h@gmx.de Signed-off-by: Florian Fainellif.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
Update , the RGMII patch has finally mad 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 Knaackknaack.h@gmx.de Signed-off-by: Florian Fainellif.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
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 Knaackknaack.h@gmx.de Signed-off-by: Florian Fainellif.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
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 Knaackknaack.h@gmx.de Signed-off-by: Florian Fainellif.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
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 Knaackknaack.h@gmx.de Signed-off-by: Florian Fainellif.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
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-cel...
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 Knaackknaack.h@gmx.de Signed-off-by: Florian Fainellif.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-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@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
Oh course there is an R2:
http://www.banana-pi.org/r2.html
It would be interesting to see if this runs without patches with the 4.9 kernel. I would be interested if it does.
Also if it can boot from the sata.
Perhaps ask on the Fedora-arm list? More board activity there than here. :(
On 05/10/2017 07:50 AM, 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 Knaackknaack.h@gmx.de Signed-off-by: Florian Fainellif.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
-
Fabian Arrotin -
Karanbir Singh -
mo.ucina -
OM Ugarcina
-
Robert Moskowitz