Espressobin support development efforts

[umiddelb]

You may consider to create a symbolic link in /boot/kernel.d/default pointing to e.g. /boot/kernel.d/linux-4.13.0-rc3-ebin-129859-ga19e2f6 and modify the u-boot paths for Image, Initrd and fdt in a way that filenames refer to this link (or just have a look here).  

 

[lupus]

I have tested kernel 4.4.79-mvebu64 from beta.armbian.com - it runs fine and is rock stable. 

 

Thanks to @umiddleb I have access to mainline kernels for the espressobin - I tried 4.12.1-ebin and 4.13.0-rc4-ebin. They are booting from SD and SATA ( see i.e. https://pastebin.com/jYsrkypw ). 

 

Unfortunately the Helios LanTest crashes renders the system on both 4.12 and 4.13 unresponsive. (I have recompiled Netatalk, but to no avail)

Could this be related to clock frequencies selected ?

 

Booting the Armbian Ubuntu Image with any kernel is very often interrupted by a job for raising network interfaces: "[**    ] A start job is running for Raise ne... interfaces (1min 41s / 5min 4s)".  Could this be fixed ?

 

Update:

As a stability test I compiled squid3 on 4.13.0-rc4-ebin without any problems (both cpus fully loaded for about an hour).

Helios LanTest does not complete since espressobin stops responding over the network but it is still accessible via the console.

Mainline kernels seem to work well, but network interfaces need to be fixed.

Ubuntu 16.04.3 LTS espressobin ttyMV0

espressobin login: root
Password: 
Last login: Mon Aug 14 11:47:57 CEST 2017 on ttyMV0
 _____                                   _     _       
| ____|___ _ __  _ __ ___  ___ ___  ___ | |__ (_)_ __  
|  _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ 
| |___\__ \ |_) | | |  __/\__ \__ \ (_) | |_) | | | | |
|_____|___/ .__/|_|  \___||___/___/\___/|_.__/|_|_| |_|
          |_|                                          

Welcome to ARMBIAN 5.32 user-built Ubuntu 16.04.3 LTS 4.13.0-rc4-ebin-130271-gabe3c92   
System load:   0.04 0.18 0.14   Up time:       8 min
Memory usage:  16 % of 992MB    IP:            192.168.240.42
HDD temp:      30??C           
Usage of /:    5% of 110G       storage/:      5% of 110G   

[ General system configuration: armbian-config ]

root@espressobin:~# ping google.com
ping: unknown host google.com

 

[aldzune]

On 2017/8/14 at 4:09 PM, lupus said:

Helios LanTest does not complete since espressobin stops responding over the network but it is still accessible via the console.

Mainline kernels seem to work well, but network interfaces need to be fixed.

It seems to related with Samba. ArchlinuxARM has same problem which use mainline kernel. I copy file from espressobin then it losses network connection, and I can't find any log.

 

Quote

Booting the Armbian Ubuntu Image with any kernel is very often interrupted by a job for raising network interfaces: "[**    ] A start job is running for Raise ne... interfaces (1min 41s / 5min 4s)".  Could this be fixed ?

This problem can be fixed by disabling networking service. However, you need to configure your network by other manager like systemd-networkd or NetworkManager.

 

Btw, can you check SD card is available in U-Boot after reboot with mainline kernel? My SD card can't be read by U-Boot after reboot. You can check the post here.

[lupus]

On 8/17/2017 at 6:32 PM, aldzune said:

It seems to related with Samba.

Netatalk is configured to use the afp protocol - I do not use samba. The networking issue in Ubuntu 16.04. occurs independent of the protocol used to connect to espressobin.

 

BTW - The new "Armbian_5.32.170817_Espressobin_Debian_stretch_default_4.4.82.7z" image boots from SD ( https://pastebin.com/pHbvcQ39 ).  The boot process of Debian stretch is not interrupted by a process for raising network interfaces.

 

Update:

Espressobin boots Debian stretch from SD with mainline kernel 4.12.1-ebin from @umiddelb (see https://pastebin.com/GXH7fLNF )

The following environment was used:  https://pastebin.com/hbYA6p7B 

 

Update2:

The system also boots from ssd ( https://pastebin.com/9KZRK2Cj ).

I used the following environment: https://pastebin.com/mAVY3Hut 

The following options need to be used under Debian stretch for formatting the SATA device in order to be accessible by u-boot (thanks to @umiddelb):

sudo mkfs.ext4 -O '^64bit' -O '^metadata_csum' /dev/sdaX

 

Update3:

Espressobin still stops responding over the network with 4.12.1-ebin (while Helios LanTest reads data from it) but remains accessible via the console.

[aldzune]

19 hours ago, lupus said:

Netatalk is configured to use the afp protocol - I do not use samba. The networking issue in Ubuntu 16.04. occurs independent of the protocol used to connect to espressobin.

I doubt it occurs when you read data from storage and send to network. This problem also happening in copying file through NFS. You can check by put a large file to the board and transfer it through network share.

 

19 hours ago, lupus said:

The system also boots from ssd ( https://pastebin.com/9KZRK2Cj ).

I used the following environment: https://pastebin.com/mAVY3Hut 

The following options need to be used under Debian stretch for formatting the SATA device in order to be accessible by u-boot (thanks to @umiddelb):

Yeah, since mmc breaks booting, I use my usb flash driver as root media.

 

Marvell releases a new BSP uboot which can read full features ext4. I compiled and flashed it to my board. What the new uboot cause mmc failed to read after reboot? Or maybe related to those patchs using by ArchlinuxArm?

 

Rasing network problem is related to network configure file. You need to check and modified it below /etc/network/. Usually I will disable networking service and use NetworkManager instead.

[tkaiser]

@Igor can you please elaborate on what works already with next after your last commit? Or too early?

[Igor]

Just now, tkaiser said:

@Igor can you please elaborate on what works already with next after your last commit? Or too early?

Just patches and config that have already been collected and partially prepared - packaging needs to be fixed before it will be possible to boot ... tested only for building.

[lupus]

Openssl speed performance of Espressobin with kernel 4.12.1-ebin and security offload enabled:

 

Configuraton options used for the kernel are: 'CONFIG_CRYPTO_HW=y'  and  '# CONFIG_CRYPTO_DEV_MARVELL_CESA is not set'

(CPU frequency is assumed to be 1000MHz, cpufreq support is currently not enabled)

root@ebin:~# cat /proc/version
Linux version 4.12.1-ebin-g4b13ed5-dirty (ubuntu@ebin) (gcc version 6.3.0 20170519 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) ) #1 SMP PREEMPT Wed Jul 12 16:25:39 UTC 2017

root@ebin:~# openssl speed -elapsed -evp aes-128-cbc
root@ebin:~# openssl speed -elapsed -evp aes-192-cbc
root@ebin:~# openssl speed -elapsed -evp aes-256-cbc

OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) 
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" 
The 'numbers' are in 1000s of bytes per second processed.

combined output:
Espressobin / Marvell 3720 @ 1000MHz:
type             16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes   16384 bytes
aes-128-cbc      68509.24k   216097.11k   453277.35k   649243.99k   741862.06k   748459.35k
aes-192-cbc      65462.17k   194529.30k   375030.70k   503817.22k   559303.34k   563014.31k
aes-256-cbc      63905.67k   181436.03k   328664.06k   423431.51k   462012.42k   464972.46k

I wonder how the results will change if the Marvell Security Engine is enabled ...

 

Update:

Please find attached the content of /proc/crypto : https://pastebin.com/ub4J4AiG 

[Patrick]

Love to see all the work you guys are doing. I would like to help but this stuff is above my knowledge

 

But.... If there's anything I can do, please contact me.

 

Like to see OMV running on the Espressobin.

 

Kr.,

Patrick

 

 

Verzonden vanaf mijn iPhone met Tapatalk

 

[Igor]

@Patrick Project needs help in different areas. Not just badass hardware geeks ... 

http://espressobin.net/forums/topic/u-boot-says-non-posted-pio-response-status-ur-to-mpcie-device/#post-1049
It looks like it's possible to run Atheros cards with changing u-boot.

[xauser]

I'm using the latest armbian debian image on this board and have a hard time getting network interfaces up and running on boot time. I've configured network via /etc/network/interfaces and it seems to me that lan0 isn't working. After a ifdown lan0, ifup lan0 cycle lan0 comes up and works. At the moment the board is too unstable for me to do any serious projects with it.

[umiddelb]

1 hour ago, xauser said:

I'm using the latest armbian debian image on this board and have a hard time getting network interfaces up and running on boot time. I've configured network via /etc/network/interfaces and it seems to me that lan0 isn't working. After a ifdown lan0, ifup lan0 cycle lan0 comes up and works. At the moment the board is too unstable for me to do any serious projects with it.

 

You may try the network configuration, I'm using for the espressobin (individual ports, no bridging):

 

auto eth0
iface eth0 inet manual
  hwaddress ether f0:ad:4e:03:6a:9f

auto lan0
iface lan0 inet dhcp
  pre-up /sbin/ifup eth0
  hwaddress ether f0:ad:4e:03:6a:a1

 

Btw. has anyone succeeded to do the networking setup with pure nmcli ?

 

Cheers

Uli

[lupus]

u-boot 17.08.1 flash images for all combinations of Marvell supported CPU/DDR3 frequencies (600/600, 800/800, 1000/800, 1200/750)

 

With kind support of @Igor and @aldzune I could build and test u-boot 17.08.1 and 17.06.3 flash images for all frequency combinations indicated above (boot snippets 17.08: https://pastebin.com/kKTvP5sx and 17.06: https://pastebin.com/8DZ37Wti , available functions: https://pastebin.com/kN5WBjW9 ). 

 

The flash-image.bin files (u-boot-images.tar.gz are attached below) just have to be resident in the root directory of a USB stick attached to the Espressobin and they can be flashed at the u-boot prompt:

 

Marvell>> bubt flash-image-XXX_YYY.bin spi usb       

(XXX: CPU Frequency, YYY: DDR3 Frequency)

 

'ARMBIAN 5.32.170817 nightly Debian GNU/Linux 9 (stretch) 4.4.82-mvebu64' boots smoothly in all 4 scenarios (see i.e. https://pastebin.com/KkZsU8sk ). (A static IP address is assigned in /etc/network/interfaces to get rid of the 'raise network interface' issue)

 

EDIT:

With the new firmware I receive I/O errors after some time while accessing the sd card.

The firmware needs to be properly tested by Marvell / Globalscale Technologies and made available by them.

Please contact Globalscale Technologoies / Marvell if you are interested in a more recent firmware.

 

[lanefu]

i got a new build host going so got to tinker a bit... I was having trouble with the toolchain not being in path when building espressobin using latest armbuild build tools checkout.

 

I set UBOOT_USE_GCC='> 7.0'   in mvbe64.conf and that took care of it......  I send a PR later this weekend after i tinker some more.

 

What's everyone's preferences on u-boot?  Are most using the built in u-boot on SPI, or using u-boot from sdcard?  

 

[SmashGuy]

On 14.8.2017 at 10:09 AM, lupus said:

Booting the Armbian Ubuntu Image with any kernel is very often interrupted by a job for raising network interfaces: "[**    ] A start job is running for Raise ne... interfaces (1min 41s / 5min 4s)".  Could this be fixed ?

 

 

I ran into the same problem while waiting for eth0 with no network cable plugged in.

 

The workaround is to edit /etc/systemd/system/network-online.target.wants/networking.service. Change the timeout in the final line to something shorter, like "5sec".

__

Regarding the heat test, I shot a laser thermometer at the SOC and get a reading of around 58C. Has been idling at 1000Mhz all day.

 

I'm running into a different problem. I have an Edimax 7811Un wifi adapter plugged into the USB 2.0 port and it works fine. If I plug an identical unit into the USB 3.0 port, I run into a insufficient power error (error -110). The first device is recognized with lsusb, the second isn't. Any ideas?

 

[ 5.697291] usb 1-1: new high-speed USB device number 2 using orion-ehci
[ 5.787901] usb 2-1: new high-speed USB device number 2 using xhci-hcd
[ 10.900013] usb 2-1: device descriptor read/64, error -110
[ 26.120022] usb 2-1: device descriptor read/64, error -110
[ 26.339981] usb 2-1: new high-speed USB device number 3 using xhci-hcd
[ 31.456008] usb 2-1: device descriptor read/64, error -110
[ 46.676011] usb 2-1: device descriptor read/64, error -110
[ 46.895982] usb 2-1: new high-speed USB device number 4 using xhci-hcd
[ 51.904033] xhci-hcd d0058000.usb3: Timeout while waiting for setup device command
[ 57.120025] xhci-hcd d0058000.usb3: Timeout while waiting for setup device command
[ 57.331950] usb 2-1: device not accepting address 4, error -62
[ 57.503982] usb 2-1: new high-speed USB device number 5 using xhci-hcd
[ 62.512038] xhci-hcd d0058000.usb3: Timeout while waiting for setup device command
[ 67.727928] xhci-hcd d0058000.usb3: Timeout while waiting for setup device command
[ 67.935954] usb 2-1: device not accepting address 5, error -62
[ 67.942290] usb usb2-port1: unable to enumerate USB device
[ 72.523525] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 72.586801] usbcore: registered new interface driver rtl8192cu
[ 105.334452] usb 2-1: new high-speed USB device number 6 using xhci-hcd
[ 110.446365] usb 2-1: device descriptor read/64, error -110
[ 110.666355] usb 2-1: device descriptor read/64, error -71
[ 110.886321] usb 2-1: new high-speed USB device number 7 using xhci-hcd
[ 110.998338] usb 2-1: device descriptor read/64, error -71
[ 116.218213] usb 2-1: device descriptor read/64, error -110
[ 116.438191] usb 2-1: new high-speed USB device number 8 using xhci-hcd
[ 116.438321] usb 2-1: Device not responding to setup address.
[ 116.642321] usb 2-1: Device not responding to setup address.
[ 116.846188] usb 2-1: device not accepting address 8, error -71
[ 117.018181] usb 2-1: new high-speed USB device number 9 using xhci-hcd
[ 122.030090] xhci-hcd d0058000.usb3: Timeout while waiting for setup device command
[ 127.245971] xhci-hcd d0058000.usb3: Timeout while waiting for setup device command
[ 127.449951] usb 2-1: device not accepting address 9, error -62
[ 127.455901] usb usb2-port1: unable to enumerate USB device

Edited September 5, 2017 by chwe
merged 2 posts

[valant]

Did i understand right, that getting PM on the SoC of this rig without a couple of thousand bucks for NDA is a hopeless dream?

[SmashGuy]

Ok, I've run into one more problem that maybe someone here can comment on. And my apologies in advance because I'm not really a hardware guy so linux kernels are beyond my current skillset.

 

In an effort to get the USB 3.0 port to recognize the Edimax wifi card, I performed an upgrade (apt-get upgrade). Worked fine, supposedly. However, now I cannot boot because the SD card is not recognized. It gets to the end of the boot process and gives me this:

 

Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mmcblk0p1 does not exist.  Dropping to a shell!
[   43.350941] usbcore: registered new interface driver usbhid
[   43.356740] usbhid: USB HID core driver

A quick check on /dev shows that there are no files starting with either mmc* or sd*.

 

Any clues on how to get the SD card recognized again? And are upgrades hopeless at this point?

 

Edit: Just checked /proc/devices and mms is showing up:

 

133 sd
134 sd
135 sd
179 mmc
252 nvme
253 virtblk
254 mdp

 

Fix: I solved it and the upgrade worked! The problem is that the Armbian /boot directory contains the directory dtb-4.4.84-mvebu64/*. My environment variables were pointing to an earlier version (dtb-4.4.73) so the drivers weren't being loaded. To fix this, I aborted autoboot and while in uboot, changed the fdt_name environment variable to point to the correct version. It booted up just fine.

[SmashGuy]

Ok, I don't recommend that anyone upgrades as it appears that none of the beta drivers are included when upgrading, so you lose core functionality (such as cpufreq support).

 

I'm wiping and reverting back to the original version. The upgrade didn't fix the Edimax problem anyway.

 

[lanefu]

On 8/24/2017 at 4:51 PM, umiddelb said:

 

You may try the network configuration, I'm using for the espressobin (individual ports, no bridging):

 

auto eth0
iface eth0 inet manual
  hwaddress ether f0:ad:4e:03:6a:9f

auto lan0
iface lan0 inet dhcp
  pre-up /sbin/ifup eth0
  hwaddress ether f0:ad:4e:03:6a:a1

 

Btw. has anyone succeeded to do the networking setup with pure nmcli ?

 

Cheers

Uli

 

So i did some digging on this a while back.. Essentially network manager is unable to classify the device type of the DSA-based ethernet ports, and consequently fails.    The bridge configuration is a nice hack that gets around that constraint.      Sorry I thought i had some notes posted on here about it.. can't find it now.

[reverend_t]

Network manager's so frustratingly limited, it always pushes me back to using /etc/network/interfaces, especially when I'm using VLANs and doing any kind of complex routing/masquerading.

 

I'm really interested in these devices coming along with hardware gigabit switch chips (especially the Marvell and Broadcom BCM5XXX chips that can be configured using the Switchdev/DSA process), has anyone experimented with STP on the espressobin?

[SmashGuy]

I'm using /etc/network/interfaces right now. Got wifi and wan working, but I'm not having any luck getting a connection through lan0 or lan1 to my local PC.

 

This is the output of /var/log/syslog when I plug in the cable:

 

Sep  6 13:44:44 espressobin kernel: [  830.336999] dsa dsa@0 lan1: Link is Up - 100Mbps/Full - flow control r
Sep  6 13:44:44 espressobin kernel: [  830.341862] br0: port 2(lan1) entered blocking state
Sep  6 13:44:44 espressobin kernel: [  830.341879] br0: port 2(lan1) entered forwarding state
Sep  6 13:44:44 espressobin NetworkManager[1494]: <info>  [1504705484.0595] device (lan1): link connected
Sep  6 13:44:44 espressobin NetworkManager[1494]: <info>  [1504705484.0598] device (br0): link connected
Sep  6 13:44:45 espressobin ntpd[2680]: Listen normally on 4 br0 192.168.101.1:123
 

And here's my /etc/network/interfaces:

 

auto lo
        iface lo inet loopback

auto eth0
        iface eth0 inet manual
        #hwaddress ether f0:ad:4e:03:6a:9f

auto wan
        iface wan inet dhcp
        pre-up /sbin/ifconfig wan up

auto wlan0

        iface wlan0 inet dhcp
        wpa-ssid "xxxx"
        wpa-psk "xxxx"

auto lan0
        iface lan0 inet manual
        pre-up /sbin/ifconfig lan0 up

auto lan1
        iface lan1 inet manual
        pre-up /sbin/ifconfig lan1 up

auto br0
        iface br0 inet static
        bridge_ports lan0 lan1
        bridge_waitport 0
        address 192.168.101.1
        network 192.168.101.0
        netmask 255.255.255.0
        dns-nameservers 192.168.101.1

 

And finally ifconfig br0:

 

br0       Link encap:Ethernet  HWaddr f0:ad:4e:03:64:7f  
          inet addr:192.168.101.1  Bcast:192.168.101.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:316 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:61758 (61.7 KB)  TX bytes:2646 (2.6 KB)

 

Seems the devices are seeing each other but nothing else happens after that. Anyone have any ideas?

 

Edit: Looks like DHCP queries are coming in but dnsmasq is not receiving (or not responding) to them.

 

Edit: Resolved! The /etc/network/interfaces file above works fine and I can now connect via lan1. The problem was a configuration setting in dnsmasq that was not allowing it to respond to that interface.

[lanefu]

10 hours ago, reverend_t said:

Network manager's so frustratingly limited, it always pushes me back to using /etc/network/interfaces, especially when I'm using VLANs and doing any kind of complex routing/masquerading.

 

I'm really interested in these devices coming along with hardware gigabit switch chips (especially the Marvell and Broadcom BCM5XXX chips that can be configured using the Switchdev/DSA process), has anyone experimented with STP on the espressobin?

 

What's  STP?

 

I was really excited about the switch as well.. currently disappointed about its single gig bus to the board.  But this board is a HUGE bang for buck so I can't complain. it just needs time and contributions.

[Patrick]

 
What's  STP?
 
I was really excited about the switch as well.. currently disappointed about its single gig bus to the board.  But this board is a HUGE bang for buck so I can't complain. it just needs time and contributions.

STP is probably https://en.m.wikipedia.org/wiki/Spanning_Tree_Protocol


Verzonden vanaf mijn iPhone met Tapatalk

[reverend_t]

 

16 hours ago, Patrick said:

STP is probably https://en.m.wikipedia.org/wiki/Spanning_Tree_Protocol

 

 

Yup indeed. So one way to think about it is like follows.

 

The switch chips found in commodity wireless routers are often the very same that are in expensive managed routers, however the stock firmware provided gives no way to manipulate the powerful features possible on these chips.

 

Openwrt uses a process called swconfig to configure the switch chips in these routers to support VLAN tagging. However, it only exposes the switch as a single network interface so that means that many things are impossible, such as per port/per vlan stats and STP (used to prevent loops from disabling large parts of your network). This is still immensely powerful. A £20 openwrt capable wireless router board from Aliexpress can be made to act as a gigabit managed switch running Linux. The possibilities that just VLAN tagging controlled by Linux provides are amazing!

 

Switchdev/DSA go one step further for compatible switch chips. They expose each port to the OS. Therefore they take advantage of the ability of the switch to perform hardware intra-VLAN routing, but also allow the rest of the system to get involved with inter-VLAN routing/STP/IGMP snooping and other higher level functions, including the use of the hardware accelerators as found in Marvell/Broadcom/Cavium/Mediatek SOCs.This would allow Linux-based switches to be as performant as the proprietary mnged switches from Cisco etc.

[reverend_t]

In essence what I'm waiting for is a board that uses a Marvell or Broadcom switchdev compatible switch chip, 2-4 gigabit ports and a cheap Allwinner SOC. In fact, the Banana Pi R1 was close, but it had an insane boot up mode for the switch (all ports switchable) and was overpriced by a factor of 3. I don't want on board Wi-Fi, SATA or any other of that BS. This should be possible for $20

[lanefu]

12 hours ago, reverend_t said:

 

Openwrt uses a process called swconfig to configure the switch chips in these routers to support VLAN tagging. However, it only exposes the switch as a single network interface so that means that many things are impossible, such as per port/per vlan stats and STP (used to prevent loops from disabling large parts of your network). This is still immensely powerful. A £20 openwrt capable wireless router board from Aliexpress can be made to act as a gigabit managed switch running Linux. The possibilities that just VLAN tagging controlled by Linux provides are amazing!

 

Switchdev/DSA go one step further for compatible switch chips. They expose each port to the OS. Therefore they take advantage of the ability of the switch to perform hardware intra-VLAN routing, but also allow the rest of the system to get involved with inter-VLAN routing/STP/IGMP snooping and other higher level functions, including the use of the hardware accelerators as found in Marvell/Broadcom/Cavium/Mediatek SOCs.This would allow Linux-based switches to be as performant as the proprietary mnged switches from Cisco etc.

 

I've been super fascinated with the DSA stuff since my espressobin first exposed me to it's existence.      The thing I don't quite grok with DSA is if I'm trying to do any layer 3 stuff on the switch ports,  such as inter vlan routing is whether or not I'm always limited by the RGMII or whatever link the DSA chip is using to connect to the SoC.    

 

You have described a pretty ideal board.   A DSA with a cheap 4 core SoC is enough horsepower to brute force doing all sorts of cool network stuff without being so reliant on hardware offloading like on my EdgeRouter Lite.     Now that VyOS has ported their build over to supporting Jessie, I've been hoping to eventually rig up a VyOS installer armbian similar to the OMV userpatches installer.    

[reverend_t]

5 hours ago, lanefu said:

 

I've been super fascinated with the DSA stuff since my espressobin first exposed me to it's existence.      The thing I don't quite grok with DSA is if I'm trying to do any layer 3 stuff on the switch ports,  such as inter vlan routing is whether or not I'm always limited by the RGMII or whatever link the DSA chip is using to connect to the SoC.    

 

You have described a pretty ideal board.   A DSA with a cheap 4 core SoC is enough horsepower to brute force doing all sorts of cool network stuff without being so reliant on hardware offloading like on my EdgeRouter Lite.     Now that VyOS has ported their build over to supporting Jessie, I've been hoping to eventually rig up a VyOS installer armbian similar to the OMV userpatches installer.    

 

Ha, hadn't thought of it like that. The use of that 1Gb interconnector between the Armada 37xx and the Topaz switch rather than the 2.5Gb line negates one of the main benefits of those comms specific chips over an Allwinner/Broadcom alternative  And given that I want to almost always perform Codel/Cake over a saturated link then what use is the fancy hardware NAT acceleration offload? I haven't as yet seen any QoS benchmarks with quad-core A53 chips. If the dual-core 880MHz mips in an ER-X can push 120Mbps then surely we'd get much more puff from a modest H5. If you want to get really fancy you could use an RK3288 and turn its usb3 into a symmetrical 2.5Gb lane to the switch. Now how do we get someone to make these boards

 

Good question about the limitation. I would say yes, unless there is hardware capability on that Topaz for the layer 3 features you want. I guess that if the switch handles all the intra-VLAN stuff at line-rate then you'll have that limitation applied to only the layer-3 stuff? Don't know, need to get my hands on some of this stuff.

[SmashGuy]

On 9/6/2017 at 4:18 PM, lanefu said:

I was really excited about the switch as well.. currently disappointed about its single gig bus to the board.  But this board is a HUGE bang for buck so I can't complain. it just needs time and contributions.

 

It would get a lot more contributions if there was a step-by-step guide to setting up Armbian on the EspressoBin and getting more than just a minimally viable install going. For instance, not being able to upgrade right now due to the different Armada driver is a big deal. Everyone seems to have problems getting the LAN and WAN ports working independently (having both wan and eth0 interfaces is unique to this board, as far as I know). CPUFreq needs to be faster out of the box... defaulting to 200Mhz is crazy. I haven't experienced any overheating at all running at 1000Mhz. The bootup timeout on the eth0 interface defaults to 5 minutes as well.

 

These are just the problems I encountered so far. Not insurmountable by any means, but I bet there are a ton of people who tried to boot up their EspressoBin and just set it aside because of things like this.

 

 

[lanefu]

19 minutes ago, Richard Stokes said:

 

It would get a lot more contributions if there was a step-by-step guide to setting up Armbian on the EspressoBin and getting more than just a minimally viable install going. For instance, not being able to upgrade right now due to the different Armada driver is a big deal. Everyone seems to have problems getting the LAN and WAN ports working independently (having both wan and eth0 interfaces is unique to this board, as far as I know). CPUFreq needs to be faster out of the box... defaulting to 200Mhz is crazy. I haven't experienced any overheating at all running at 1000Mhz. The bootup timeout on the eth0 interface defaults to 5 minutes as well.

 

These are just the problems I encountered so far. Not insurmountable by any means, but I bet there are a ton of people who tried to boot up their EspressoBin and just set it aside because of things like this.

 

 

 

I agree we need something clearer....  I made a gist a long time ago.. I'd welcome your CPUfreq tips....    I hadnt messed with the project in a while, so I'm trying to get a good picture of where things currently stand.

 

https://gist.github.com/lanefu/d7c0349a3efd63570798462a45fe0e34

[SmashGuy]

3 hours ago, lanefu said:

 

I agree we need something clearer....  I made a gist a long time ago.. I'd welcome your CPUfreq tips....    I hadnt messed with the project in a while, so I'm trying to get a good picture of where things currently stand.

 

https://gist.github.com/lanefu/d7c0349a3efd63570798462a45fe0e34

 

This is a pretty good start! A little cryptic for the uninitiated though. I have a lot of additional tips and settings I could add.

 

I now have a working router with dnsmasq which supports both wireless and ethernet wan connections. I'm able to connect lan0/1 by cable but I have not succeeded in getting a second wireless card to work due to the error -110 issue noted above (very strange that USB 2.0 is fine but USB 3.0 is not, I would have expected the opposite).

 

Right now it seems to be really stable, though I still experience seemingly random issues when I dis/reconnect cables. That's rare though so a very good start.