Espressobin support development efforts
11 11

246 posts in this topic

Recommended Posts

On 13.10.2017 at 11:26 AM, ebin-dev said:


Some environment settings were posted earlier in this thread - they include the real MAC address of the devices (ethaddr= ...) preset by the manufacturer. 

If users are manually flashing their devices from 17.02 to currently 17.10 the environemt variables are lost and we should ask users to set at least their MAC address again before pressing the reset button:

Marvell>> setenv ethaddr=..:..:..:..:..:..
Marvell>> saveenv

(... until we find out how to flash SPI from linux)

Sorry. Doesn't work. :(

I'm using these  environment vars. (mac address is only masked in this post, not in real setting).


mmc rescan
env print

setenv verbosity 2
setenv boot_interface mmc
setenv image_name boot/Image
setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb
setenv fdt_high "0xffffffffffffffff"
setenv rootdev "/dev/mmcblk0p1"
setenv rootfstype "ext4"
setenv verbosity "1"
setenv initrd_addr "0x1100000"
setenv initrd_image "boot/uInitrd"
setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr'

setenv ethaddr 0F:AD:4e:xx:xx:xx
setenv eth1addr 0F:AD:4e:xx:xx:xx
setenv eth2addr 0F:AD:4e:xx:xx:xx
setenv eth3addr 0F:AD:4e:xx:xx:xx

env save



the driver/kernel wont use those macs after reset and reboot.
I always get some randomized mac adresses for all other interfaces
every reboot.


If I force the mac-adress in /etc/network/interfaces manually like this

auto eth0
iface eth0 inet manual
hwaddress ether f0:ad:4e:xx:xx:xx

then, the interface is working with this mac.
but this is a no-go. the default mac address should
not to be set by the OS, and the mac address of the nic
should not change every reboot.

is it possible to set the mac in the kernel cmdline at least?




Share this post

Link to post
Share on other sites
17 hours ago, FoodGenius said:

the driver/kernel wont use those macs after reset and reboot.


To use the MAC address set in the environment is not implemented yet.


17 hours ago, FoodGenius said:

If I force the mac-adress in /etc/network/interfaces manually like this


Your bridge is configured with systemd-networkd - as a temporary solution you can edit the bridge 10-br0.netdev settings as shown in my earlier posting:


On 10/13/2017 at 10:20 AM, ebin-dev said:

What needs to be done is to edit  /etc/systemd/network/10-br0.netdev to include the real MAC address of your EspressoBin:

cat /etc/systemd/network/10-br0.netdev 


 You may need to delete any existing MAC/IP assignement of your EspressoBin in your router (to avoid any "hiccups") and then reboot your EspressoBin.

Share this post

Link to post
Share on other sites



thank you. I know that. At least for me it is a problem if I only can set macs address
after boot process in the OS.

if you use the same image for different boards, you can't simply change those files in rootfs or
in flashed image. e.g. if you deliver the same rootfs by nfs or nbd. etc.  running script for
autogenerate keys and setting ip after well-know mac address as id.
your mac is not well-known then. that is the problem.

I'm using the vendor given unique mac address for internal autoprovisioning.
So... at first run, I won't have these settings in /etc/network or /etc/system/network..
any other config-file in my delivered rootfs can't know the mac of the board.

normally your nic gets this from bootenv/board vendor defined, before ip setting.
later you're writing those network config files and change settings.

if mac-address is changing at every reboot, I won't get such a auto configure.
even for ipv6 or other stuff it is relevant to get all well defined mac address when
initializing the nic... even at boot-time it is to late... you have to do this
before parsing or setting any config-files in rootfs.

so I have to fix autoprovisioning and get a board serial number.. send this
to an autoprov server to get a mac.. and then reset those mac address at boot-time.
but even this is a problem

in some configurations its also a severe problem, if you allow only a bunch of mac adresses...

e.g. your switch is configured to block unknown mac-adresses and setting whole port down if a
foreign mac address is detected...  as an intrusion detection.

so with changing mac adresses at every reboot (even if you change them later in system config) would mean,
those board gets disconnected from net, because it reports nonsense mac adresses first.. an the switch
denies any further access - or at least is sending false-positive intrusion detection messages.

so here - it is a no-go (at least for me), if I have only can define the mac-adresses in config-files
in the rootfs and if there ist no way to set a fix mac address already before booting the kernel to
get a clean initialization.



Share this post

Link to post
Share on other sites

sorry. my fault.


setenv ethaddr 0F:AD:4E:xx:xx:xx
setenv eth1addr 0F:AD:4E:xx:xx:xx
setenv eth2addr 0F:AD:4E:xx:xx:xx
setenv eth3addr 0F:AD:4E:xx:xx:xx

was a dumb typo, since
the mac vendor id of globalscale inc.  is F0:AD:4E...
so this would be the correct setting...


setenv ethaddr F0:AD:4E:xx:xx:xx

and with this environment setting the mac address ist also
recognized correctly without any further changes in the system.
this mac-address is set for all devices: lan0,lan01,wan,eth0,br0

unfortunately the dumb typo 0F instead of F0
also set the unicast/multicast bit... so I intiallty
thought the env setting would'nt work. rubbish.

I found this out, while doing a ugly hack as a workaround
Nevertheless... I'll share this obsolet workaround with you

1. changing environment in uboot once again... for passing
a custom kernel parameter "hackmac=F0:AD:4E:xx:xx:xx"
defined for the current board:

setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name; setenv bootargs $console root=$rootdev hackmac=F0:AD:4e:XX:XX:XX rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr'

2. this is my changed /etc/network/interfaces  in rootfs

auto lo
iface lo inet loopback

auto wan
iface wan inet dhcp

auto eth0
iface eth0 inet manual

auto lan0
iface lan0 inet manual

auto lan1
iface lan1 inet manual

auto br0
iface br0 inet static
	pre-up /usr/bin/hackmac br0
	bridge_ports lan0 lan1
	bridge_fd 0
	bridge_stp off
	dns-domain xxxxxxxxxxx
	post-up ifconfig lan0 up
	post-up ifconfig lan1 up

3. and this script  /usr/bin/hackmac for getting und setting mac-adress out of the custom kernel cmdline


hackmac="$(tr " " "\n" < /proc/cmdline | \
grep -m1 "^hackmac=" | cut -d"=" -f2 | \
tr -dc "0-9a-fA-F:" | tr "A-F" "a-f" | head -c 17)"

[ "$#" -gt 0 ] && [ "$hackmac" != "" ] && \
ip link set dev $1 address $hackmac

exit 0


Share this post

Link to post
Share on other sites

Hi there,

I am trying  to enable gpio on Espressobin Armbian and realised that the kernel that the offical Espressobin has ( 4.4.8) , is different from the current armbian ( I might be wrong ) and therefore I need a guide in how to do this. Since this requires rebuilding the kernel, I am a bit lost on how to actually rebuild and put in the correct place once done.


Last login: Sat Oct 21 00:25:29 ACDT 2017 on ttyMV0
 _____                                   _     _
| ____|___ _ __  _ __ ___  ___ ___  ___ | |__ (_)_ __
|  _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \
| |___\__ \ |_) | | |  __/\__ \__ \ (_) | |_) | | | | |
|_____|___/ .__/|_|  \___||___/___/\___/|_.__/|_|_| |_|

Welcome to ARMBIAN 5.34.171017 nightly Ubuntu 16.04.3 LTS 4.4.91-mvebu64
System load:   0.07 0.14 0.26   Up time:       18 min
Memory usage:  11 % of 1932MB   IP:  
Usage of /:    57% of 7.2G      storage/:      98% of 932G

[ 0 security updates available, 7 updates total: apt upgrade ]
Last check: 2017-10-18 00:00

[ General system configuration: armbian-config ]

Share this post

Link to post
Share on other sites
31 minutes ago, inwchaos said:

is different from the current armbian

It is not. It's only in a slightly better shape and added functionality. Most if not all of their guides should apply here as well.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

11 11

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.