This article describes using a Mac as a workstation for remote login and
console connection. A Mac is probably one of the easiest clients to get
started with, but it should be pretty much the same procedure with a
Linux or Windows workstation (using PuTTY).
| Article || Price || Comment |
| Intel Edison breakout board with CPU || 70 € || Note the breakout board is also available without the CPU |
| 2 x Micro-USB Cable || 5 € || One for console and one for disk access (Regular USB cable with one end Micro USB) |
| Optional: Power Supply || 13 € || Wall plug transformer for DC main power DC 7-15 V 500 mA (I used 1000 mA) |
| Optional: Battery || 10 € || Rechargeable battery 3.7 V (Lithium-ion or Lithium polymer battery) 1200 mAh |
Please note: A mobile phone Micro USB charger (5 V min. 500 mA) for 6
Euro connected to the Edison USB 2 port to supply power and to charge a
connected battery will work. However it is not recommended because it
takes away the USB port.
The CPU board must be plugged into the breakout board (if not already
delivered this way). Press the CPU board very carefully into the
breakout board on the PCB, where the white label is located, until it
- Connect the console cable between the Edison (upper USB port) and a Mac
- Open a Mac Terminal window
- Connect to the console called via:
// Find out the serial device name (in my case /dev/cu.usbserial-AJ035WVG)
$ ls -l /dev/cu.usbserial*
// Get a root shell
$ sudo sh
// Connect your Mac with the Edison console port with 115200 baud
// Edison is still without any power
# screen /dev/cu.usbserial-AJ035WVG 115200
// A blank screen without error message proves you are connected to the Edison console port
// When unplugging the console terminal the screen sessions ends.
// Sometimes the Mac Terminal window is in a weird tty state after unplugging, this can be fixed via
# stty sane # (and enter)
The Edison initially already has a Linux operating system (Yocto Linux
v1.6) installed on its flash drive which is fine for the first try.
However, it is outdated and the latest version should be installed
- Console port should be connected (see description above)
- Power can be provided via USB 2 or via the Main DC connector; choose one or use both:
- Powering via USB: add the second USB 2 port with your your Mac
- Powering via DC adapter: Main power DC 7-15 V (J21)
The console output now shows the boot process and finally the login screen.
[ OK ] Reached target Login Prompts.
[ OK ] Started Network Name Resolution.
[ OK ] Started WPA supplicant service.
Poky (Yocto Project Reference Distro) 1.6 edison ttyMFD2
// Login as "root" with empty password
// For initial password and WiFi setup issue configure_edison
// Newer Linux versions require "configure_edison --server" for the initial setup.
The pre-installed Linux OS (firmware) on the new delivered Edison is
outdated, here are instructions how to install the latest version.
- Download the latest Firmware from Intel
- URL: https://communities.intel.com/docs/DOC-23242 File: "Edison Yocto complete image"
- In my case the latest Yocto image link was: edison-image-rel1-maint-rel1-ww42-14.zip
- Unzip the Zip image file (Safari may do it automatically)
- Console port should be connected (see description above)
- Stable power should be provided the via USB 2 or via the Main DC connector, or a fully charged battery
- Eject EDISON drive if it appears on the Mac
- Issue the following commands:
// Log in as root and re-format update disk with VFAT32 format
# mkfs.vfat -F 32 -n EDISON_F32 /dev/disk/by-partlabel/update
- Unplug USB 2 (if plugged) and plug it in a few seconds later
- A new empty drive named "EDISON_F32" should appear
- Copy all files from the unzipped image folder to the new "EDISON_F32" disk volume. (About 30 files and a folder.)
- Eject the "EDISON_F32" volume (drag it into the trash to unmount, or right click Eject "EDISON_F32")
- Finally start the flashing process via:
// Log in as root
# reboot ota
The flashing process takes about two minutes, the system reboots multiple times until it is done and offers a login.
Please note that the root partition is entirely new after the flashing
process and therefore the "configure_edison" as described above needs to
reinitialize the password, WiFi and all other custom settings. The
Edison Linux "/home" partition is untouched, therefore I recommend to
save private files only in "/home" because there they will survive the
Recovering from Linux problems can easily be done by re-flashing the Linux:
- Disable all power inputs
- Connect a console
- Turn the power on
- Quickly press any key to interrupt the auto boot.
U-Boot 2014.04 (Oct 14 2014 - 15:19:04)
DRAM: 980.6 MiB
MMC: tangier_sdhci: 0
Hit any key to stop autoboot: 0
// to re-flash the Linux version which resides on the update VFAT-32 partition run
boot > run do_ota
This will re-install the Linux on the root partition, all configuration
and passwords are lost, however the /home content will survive. I
recommend to save all configuration files and other stuff into /home
which allows easy restoration if the Linux gets re-installed.
- Please note: This works only if the update partition contains the
Edison installation firmware described in the installation procedure
earlier. If you have used this extra space already via the "Get
additional 800 MB disk space" instruction, and Edison Linux is still
running, you have a second chance. Connect the console port to a Mac or
PC, format the update disk with FAT32 and copy the firmware files to the
- There should also be a Linux single-user boot option in the u-boot,
which just boots the kernel without any startup scripts but I haven't
found this yet.
Some additional information about booting can be found here: http://wiki.openwrt.org/doc/techref/bootloader/uboot.config
There is another option for recovering. Switch the Edison via a 3 second click on the power button into a so called APM (Access Point Mode) mode. This creates its own WiFi setup with the factory serial number for password and the option to connect via http://edison.local
to the device. In our configuration the password is not working
therefore I don't describe it further. Intel documentation regarding APM
mode can be found here: https://communities.intel.com/docs/DOC-23137. The APM can be turned off via the console by entering "configure_edison --disableOneTimeSetup".
For these commands issued from the Mac client via the Terminal, we
assume that the Edison host name has been set to "edison" and is
available via WiFi. Use the edison.local, DNS name, or IP address:
// Remote login
# ssh -l root edison.local
// File transfer via sftp (use put or get)
# sftp firstname.lastname@example.org
Commands issued directly on the Edison as root (via the ssh remote login):
// to shutdown and power off the system. (Don't use "halt" because it will not turn off power resulting in the Edison getting hot.)
# systemctl poweroff
// The main configuration script
// Limit logging space to avoid running out of disk space
# vi /etc/systemd/journald.conf
//sets it to max 20 Mbytes. Reboot to activate it
// Show the logging disk usage
# journalctl --disk-usage
// View system messages
# journalctl --since=today # or use --since=yesterday
// Use 'systemctl' to 'stop' or 'start' a service. It can also be used to 'disable' or 'enable' a service,
// or check a service via the 'is-enabled' argument
# systemctl stop mdns
# systemctl start mdns
By default the update process works via an extra 800 MB VFAT partition
where the new Linux installation files are copied to and which get
flashed later on. However, this space is unutilized. Here I describe how
to format and use it within the Edison Linux.
- Eject the drive from your Mac/PC if it is mounted.
- Issue the following commands as root on the Edison:
// Create a file system
# mkfs.ext4 /dev/disk/by-partlabel/update
// add the following single line at the end of 'fstab'
# vi /etc/fstab
/dev/disk/by-partlabel/update /mnt auto noauto,x-systemd.automount,,
nosuid,nodev,noatime,discard,barrier=1,data=ordered,noauto_da_alloc 1 1
// Another option is to duplicate the line "/dev/disk/by-partlabel/home..." and replace home
// with update, and replace the mount point from /home with /mnt
// These commands will mount the drive and show the new disk space
# mount /mnt
# df -k
/dev/mmcblk0p9 757680 776 701856 0% /mnt
The Edison is pretty compatible with the Linux x86 32-bit operating
system. I downloaded and installed the regular 32-bit Oracle Java
runtime and it works great with our applications.
// On the Mac:
// get or put the Java (jre-8u25-linux-i586.tar) to your Edison
$ sftp email@example.com
sftp> cd /home
sftp> put jre-8u25-linux-i586.tar
// On the Edison:
# umask 0
# cd /home
# tar xvf jre-8u25-linux-i586.tar
# ln -s jre1.8.0_25 java
The Java 'bin' path was added into the root.profile file via "PATH=$PATH:/home/root/bin:/home/java/bin"
The Intel Edison Yocto comes with a stripped down Linux runtime where
common UNIX utilities are provided via limited BusyBox counterparts. As
disk space and memory are no big issue on the Edison, additional
packages can be downloaded and installed from sites hosting opkg
packages for the Edison.
- Install additional Linux packages:
// Sample how to install a downloaded package
opkg install bash_4.3-r0_core2-32.ipk
More information on the OPKG Package Manager is available here: http://wiki.openwrt.org/doc/techref/opkg
PS: I copied some frequently used tools from an existing SELS 32-bit Linux to the Edison and they work fine.
I tested the breakout board with the Intel Edison powered by a 3.7 V
rechargeable battery and measured the power consumption provided by the
battery. I don't know how much power overhead the breakout board has but
I don't believe it is much because it is probably only the power light.
| Power || Edison Operating Mode || Temp || Comment |
| 0.8 mA || After shutdown || - || The BQ24074 chip eats some power when off! |
| 50 mA || Running and idle || cold || WiFi is active but no traffic |
| 80 mA || One CPU 100% busy (loop.c) || <35 °C || WiFi is active but no traffic |
| 87 mA || Two CPUs 100% busy (loop.c) || <35 °C || WiFi is active but no traffic |
| 90 mA || One CPU 99% busy via imageconv || <37 °C || HELIOS 1 GB image sample-images processing |
| 120 mA || WiFi file transfer via sftp || cold || 2 MB/s file transfer |
| 125 mA || Two CPUs 99% busy via imageconv || <38 °C || HELIOS 2 x 1 GB image sample-images processing |
| 190 mA || Two CPUs 99% busy via imageconv + WiFi sftp || <38 °C || 2 MB/s file transfer |
- Loop was a simple endless loop in C
- The “imageconv” tool utilizes the HELIOS image processing
capabilities converting image files with ICC color transformation, PDF
rendering and bitmap conversion and scaling, generating TIFF, PSD,
JPEG200, PNG, EPSF and JPEG images. The total image output written to
disk is about 1 GB per conversion task
- During all tests small power spikes may add 50-70 mA for a fraction of a second
The power consumption is pretty much in line with the Intel
documentation. It is interesting that an idle Edison needs about 50-60
mA, whether or not WiFi is configured. I believe there is more power
saving potential but I haven't figured out everything yet. Here are some
- How to turn off the WiFI chip completely to save power?
- How to reduce the CPU speed or change the power state?
- How to put the CPU into a suspend or hibernate mode? (systemctl suspend does not work)
- Is there a clock wakeup or resume option to power up the Edison?
I verified the power consumption by checking how long a fully charged
battery runs. It confirms my basic power consumption measurements listed
in the table. In general the Edison needs between 50 and 300 mA
depending on load and WiFi traffic. The breakout board optionally needs
an additional 200 mA for battery charging, which totals to a maximum of
The breakout board uses a Texas Instruments charging chip (BQ24074)
which supports Lithium-ion and Lithium polymer batteries. Power source
input can be the USB 2 port providing 5 V with 500 mA or the main DC
power which allows voltages between 7-15 V. The battery must be a 3.7 V
battery and should deliver the required Edison power of 300 mA for the
maximum power utilization. Here are some helpful links:
The following table provides some battery configurations I tested.
| Battery Type || Power || Charging power || Charging until full || Comment |
| Lithium Polymer 3.7 V || 600 mAh || 200 mA || 3 hours || Works fine for breakout board, charging light turns off when full |
| Lithium-Ion 3.7 V || 1200 mAh || 200 mA || 6 hours || Works best for breakout board, charging light turns off when full |
| Lithium-Ion 3.7 V || 2200 mAh || 200 mA || 11 hours || Charging aborts after 6 hours, charging blinks for error |
The TI BQ24074 chip is pretty clever, it has configuration resistors on
the breakout board which specify the charging power and charging
duration. It detects when the battery is full and switches to trickle
charging. When the battery charging exceeds the maximum configured
duration (via resistor) it stops charging and blinks to avoid damages.
An input power OFF/ON resets the chip and charging continues. The
current breakout board charges about 6.5 hours with up to 200 mA. This
means a battery should not have more than 1200 mA to avoid that charging
aborts with a blinking LED indicating an error.
Details regarding the charging chip configuration:
| BQ24074 Pin || Function || Ω || Units || Comment |
| TMR || Charging duration || 47k || 6.5 hours || Specifies the charging duration |
| ISET || Charging power || 4.7k || 200 mA || Specifies the charging power |
USB 2 high power offers only up to 500 mA total power, The Edison SoC (System on a Chip)
needs max. 300 mA, the charging needs an additional 200 mA which sums
up to 500 mA. Assuming that USB 2 powering option should be preserved,
charging with more than 200 mA makes little sense. Charging with less
than 200 mA may take too long but could be feasible for solar input
power where high power may not be available.
The TMR resistor can be changed to accommodate batteries with a capacity of more than 1200 mAh:
| Battery || Hours@mA || TMR (Ω) |
| 1300 mAh || 6.5 x 200 mA || 48.75k |
| 1400 mAh || 7 x 200 mA || 52.5k |
| 1500 mAh || 7.5 x 200 mA || 56.25k |
| 1600 mAh || 8 x 200 mA || 60k |
| 1800 mAh || 9 x 200 mA || 67.5k |
| 2000 mAh || 10 x 200 mA || 75k |
| 2200 mAh || 11 x 200 mA || 82.5k |
| 2400 mAh || 12 x 200 mA || 90k |
| 4000 mAh || 20 x 200 mA || 150k |
Resistor configurations which charge a little bit longer are no problem
because the charger will stop once the battery is full. Here is a
picture of the breakout board which identifies the location of the TMR
The second is the 2k ITERM resistor, the third is the 4.8k ISET resistor configuring the 200 mA charging power output.
The built-in antenna works pretty well, there is an optional antenna
port on the Edison board. The biggest problem I had is to find out the
parts needed because I didn't know the connector type. Here is some
information about it.
- U.FL antenna connector
- WLAN antenna 2.5 / 5.8 GHz
I have not installed the antenna so far because the connector is so
small and I expect plugging/un-plugging cannot be done many times. I
also don't know if the antenna is good for all WiFi modes.
The flash drive has about 2.4 GB available in /home. The disk
performance has been measured, and it is the same, regardless of whether
the /etc/fstab barrier is 1 or 0. Testing has been done with the
included dd program.
| Test in 1 MB blocks || Throughput || Command used |
| Write 512 MB || 17.58 MB/s ||time dd if=/dev/zero bs=1024k count=512 of=xx|
| Read 512 MB || 98.68 MB/s ||time dd if=xx bs=1024k of=/dev/null|
After the writing the Edison was rebooted to ensure that the data is not
in the cache anymore. The almost 100 MB/s read performance is very
impressive, the write performance is probably related to the flash
writing which takes time. However, with a 1 GB memory the write
performance should complete immediately and the kernel needs to write
stuff in the background. It looks like async writes are somehow turned
off the in Linux kernel.
HELIOS UB2 on the Edison
The latest software release HELIOS UB64 is only 64-bit. Therefore we
used the previous UB2 release for proof of concept testing. Here are
some status notes:
- Cron support must be installed: cronie_1.4.11-r0_core2-32.ipk
- Perl FileHandle.pm is missing and must be installed: perl-module-filehandle_5.14.3-r1_core2-32.ipk
- psyslog does not log the systemd logs
- Existing mdnsd is in conflict with the HELIOS supplied Bonjour
server (mdnssrv). A symbolic link from /var/run/mdnsd to
/home/helios/var/run/mdnssrv allows HELIOS services to use the Linux
mdnsd. The HELIOS mdnssrv can be removed via "prefvalue -dr -k
Services/mdnssrv" The next start will do a proper startup
- The HELIOS MachID detection must be enhanced to use the /factory/serial_number
- Automatic startup script from systemd must be done
- Issue start-helios on the console or via remote login/a remote
shell will kill all HELIOS background services during logout. A
workaround is issuing "nohup /home/helios/bin/start-helios"
- The included Bonjour service mdnsd is doing extensive logging and
fills up the root partition within a single day. We reported the issue
in the Intel Forum