2018/11/09 - Three ports, even though they are labelled as wan, lan0, and lan1, all three exist on the same Topaz switch. Layer 3 functions on each port will probably work, but trying to make something like Open vSwitch handle packet switching between ports will not work (unless the hardware offload works, which I doubt). The Topaz switch takes care of all mac-learning and line forwarding. The three ports are not independent of each other.
Following along the Software HowTo information page, I was able to:
With those steps, I was able to get a successful boot to ensure the board was functional. I used 'screen /dev/ttyUSB0 115200' as a console connection command to the EspressoBIN.
Ultimately, I want a Debian bootable system. So, for experiment #2.... GitHub armbian/build has the instructions for building from scratch. But I opted for instant gratification with downloading and installing a pre-built image. Even though the instructions at armbian espressobin are terse, they are accurate in terms of what is needed to get a (as of this writing) Debian Stretch v4.18.y kernel installed on EspressoBIN. The FAQ describes how to burn an image to an SDCard (in my case Etcher on Linux). I disable NetworkManager.service, NetworkManager-wait-online.service, systemd-networkd and systemd-resolved. I then manually adjust /etc/network/interfaces. Armbian Documentation talks about special optimizations as part of the build.
Commands to try:
- armbianmonitor -m
- iperf3
- lspc sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo)
- isysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo
- cat /proc/cpuinfo
- cpufreq-info
- lsblk
- hdparm -tT /dev/sda
- ethtool --offload eth0 rx on tx on sg on tso on gso on gro on
- apt install armbian-config
- ls /sys/class/leds/
- cat /etc/default/cpufrequtils
- ls -al /sys/class/net
- udevadm info -q all -p /sys/class/net/wan
- cat /proc/version
- systemd --v
- cat /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table
- cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
From Armbian Ubuntu / Debian, be aware that:
manpage for systemd.netdev
reads, in the part concerning the MACAddress= entry in the [NETDEV] section: If none is given, one is generated based on the interface name and the machine-id(5)
manpage for dbus-uuidgen, it says that the D-Bus machine-id should not be changed on
a running machine or as they write: it will probably result in bad things happening. The machine-id
should remain constant at least until next reboot.
- remove the SD card from the EspressoBin,
- mount it on a different Linux system
- delete /the/mounting/point/var/lib/dbus/machine-id
- generate a random new machine id using dbus-uuidgen –ensure=/the/mounting/point/var/lib/dbus/machine-id
- copy /the/mounting/point/var/lib/dbus/machine-id to /the/mounting/point/etc/machine-id
- put the SD card back to the EspressoBin
- use serial console to get the newly generated MAC address for br0
- use this MAC address in the dnsmasq configuration of my LeDe router
A few special projects to consider:
ust for the record: We have a SoC talking via RGMII to the onboard switch (currently with 1GbE but maybe 2.5GbE possible). We use DSA to tell the switch to not act as a switch on layer 2 anymore but separate downstream ports to get 3 individual interfaces just to bridge them again at the kernel layer above. Doing this at the DSA layer (telling the switch to be a dumb layer 2 switch accessible as eth0) might save CPU resources and result in better performance if I'm not wrong?
so it looks like the topaz switch needs to be talking to soc via SGMII instead of RGMII to achieve 2.5G.
..and I think i'm officially convinced that the max bandwidth between topaz switch and cpu is in fact 1gigabit... The connection is using a seperate RGMII lane. (eth0)
eth1 -- would be the interface capable of of SGMII, but the 3 fast lanes are occupied with USB, MiniPCI and SATA
Use HELIOS LanTest for file testing across network.
I/O Related Testing: "keep in mind that we've tested there 'advanced' stuff with mPCIe SATA controllers. On the onboard SATA port EspressoBin should in a single disk configuration easily exceed 500 MB/s (or in other words: Fast enough for any HDD imaginable) "
finding bottlenecks
beta sources
bootlin (formerly Free Electrons) - it was confirmed that support for the Marvell 3720 security engine is available in the crypto tree of 4.16-rc1 and that some known bugs will be fixed until the final release of 4.16.
I had a quick look over the diff for 4.16-rc1 and it looks like there's progress on support for DVFS too
These problems seem to arise (after some time) if your board is powered simultaneously by two sources with different GND potentials (check DC and AC).
In this case your board will be exposed to severe electrical and thermal strain causing hardware issues after some time.
It can be avoided if you access the serial console using a laptop that is not connected to a power supply itself (see usb/main power ).
IO Crest SI-MPE15047 4 Port Serial Mini PCIe Controller Card (RS-232) - could be used as console server.
IO Crest 4 Port SATA III Mini Pci-E Controller Card Components Other SI-MPE40125
M.2 form factor
Inside Secure, a SafeXcel EIP-97/197 cryptographic engine designed by Inside Secure, installed with 'modprobe crypto_safexcel'. More info at
in a forum posting. The Kernel has some docs. Intelectual property sheet for EIP-97 - References IPsec, MACsec, SRTP, SSL, TLS, and DTLS.
From Reverse-engineering the ESPRESSObin’s GPIO pins:
| P9 Header |
P8 Header |
| left column |
right column |
left column |
right column |
20: 477 (default 1.8V)
24: 494 (default 1.8V)
26: 495 (default 1.8V)
28: 493 (default 1.8V)
|
15: 484 (default 0.8V)
19: 476 (default 1.8V)
23: 485 (default 0.8V)
25: 486 (default 0.8V)
35: 481 (default 1.8V)
37: 482 (default 0.8V)
39: 483 (default 0.8V)
41: 491 (default 1.8V)
|
6: 504 (default 1.8V)
20: 507 (default 1.8V)
22: 506 (default 1.8V)
|
5: 503 (default 1.8V)
7: 492 (default 1.8V)
23: 505 (default 1.8V)
|
