Embest SBC6000X Review Notes

Note: 8 June 2013. This board is now rather dated, particularly with the release of the Raspberry Pi. Its major drawback is the limited amount of FLASH, just sufficient to run a minimal Linux.

In order to build a system for monitoring, storage and control of a number of data acquisition modules, as well as a (solar, aeolian) battery power regulating system, I became interested in the possibility of having a small micropower controller that could run embedded Linux. One that seemed to be suitable was the Embest SBC6000X board, available through Element14 (formerly Farnell) for about $AU160. The documentation provided is quite poor but sufficient, after some work, to enable the board to be used. This page aims to give a better understanding of the processes involved in programming and using the board.

Board Features

  1. Small size (105mm by 95mm).

  2. Atmel AT91SAM9261S ARM v5TEJ controller (ARM926EJ-S based) with MMU and 200MHz operation possible.

  3. Power supply that can range from 7 to 30V at 24W.

  4. 64MB SDRAM.

  5. 128MB NAND flash.

  6. TFT LCD support.

  7. 4 channel 12-bit ADC suitable for touch panel.

  8. 100Mbps Ethernet connector.

  9. Debug serial port connector 3-wire RS232.

  10. Two USB 2.0 host connectors and one USB device connector.

  11. SD Card connector (mounted underside). Supports 4G SDIO mode and is hot-swappable.

  12. Audio in/out jacks.

  13. Battery Backed RTC.

  14. One reset and two user definable press buttons.

  15. Regulated +12V and +5V (500mA) power output connector.

  16. Buzzer for annoyance value.

In addition there are a number of extension connectors and headers for the following interfaces:

  1. 2 by 20 pin LCD header connector. The LCD is not provided but a number of different types are obtainable as an option.

  2. Ext Bus (also given as sysbus interface). This is given as a 60 pin "special" (i.e. proprietary?) edge type connector with very small pin spacing (appears to be 0.05 inch). There is no other information on this and it seems to be intended for use with some sort of proprietary extension modules.

  3. RS485 connector was shown in original specification documentation but had been moved to a header on the board I received.

  4. 40 pin general purpose header, referred to as J13, for SPI and additional USB and USART access. The board I received showed only one SPI, two additional 5-wire RS232 and an RS485 interface plus some related jumpers. See below for more information on this header.

  5. 20 pin GPIO header connector.

  6. 20 pin header for 4 by 4 keypad and 4 line touch screen.

  7. 20 pin JTAG header standard.

The presence of an Atmel processor is coincidental to my long standing interest in their AVR series.

Embest provides only specification and schematic documentation on their website. Detailed hardware documentation is only provided with the kit, which is unfortunate as this sort of documentation is sometimes essential to determine the suitability of a product. The documentation provides very sketchy information on header pinouts. I have added extra information from the documents that I consider important to know. Also provided with the kit is some vitally important HOWTO documentation for installing Linux and Wince (Windows CE - ugh!).

Support Software

Embest has provided Linux, Wince and boot loaders source code in a form that is already customized for the board, so that only compile and upload is necessary to obtain a working system. This is a big plus for this board. The kit provides a document "SBC6000X Linux User Manual" describing how to compile and install the embedded Linux. The document describes the booting process starting from the internal microcontroller code that looks for one of several bootable media (see the AT91SAM9261S datasheet for more information), passing on to Atmel's  AT91Bootstrap code in NAND flash that in turn moves the boot manager from NAND flash to SDRAM for execution. The boot manager used is the open source tool U-boot. The document leads through compilation of AT91Bootstrap and U-boot and the loading of these to the NAND flash using Atmel's provided SAM-BA (SAM Boot Assistant) tool.

Compilation uses a gcc-arm toolchain which is provided (arm-linux-gcc-3.4.5-glibc) dating from around 2007. It may be possible to install an updated version from the gcc site but I didn't try it. This toolchain is precompiled and installs to /usr/crosstool (indicating that the Crosstool suite was probably used to build it). I ran into trouble on one machine wherein the toolchain couldn't find some unspecified file. It turned out to be the embedded GNU C library loader /lib/ld-linux.so.2 from either libc6-386 or libc6:i386 (the latter obtainable from Ubuntu partner repositories). The toolchain was built in 32 bit thus requiring the 32 bit support to be installed on 64 bit installations.

SAM-BA works over the board's USB device interface with the provided cable. It is provided on the Embest CD but only for Windows (as part of an IDE). Fortunately Atmel does have a Linux version of SAM-BA which can be accessed from the Atmel website. Simply unzip the downloaded file into a suitable directory. No installation is needed but read the README.linux to note which packages need to be installed and also the instructions for the different distributions. Ignore the instructions for the CDC Serial driver mount procedure. Also for Ubuntu the symlink doesn't seem to be required. SAM-BA must not be run as root.

The SAM-BA User Guide seems to be available only in the Windows help file format which can be read through WINE. The AT91SAM9261S datasheet briefly describes the simple communication protocol used by SAM-BA.

Boot Code Compile and Upload

If you connect the RS232 cable, invoke a terminal on the relevant COM port at 115200 baud with hardware handshake disabled, and reset the board, you may see that AT91Bootstrap and U-boot are already installed. This was the case with the board I received, but I tried the compile and upload exercise anyway. This is useful if updated versions of these are desired (the version 1.3.4 of U-boot as provided dates from August 2008 while the AT91Bootstrap is itself a few versions old). For a terminal I used putty at first but minicom can be used equally well and seemed to be easier to use for uploading files, once its pecularities were mastered. I originally used a USB to RS232 adapter which normally sits on the Linux port /dev/ttyUSB0 (provided no other device has grabbed it earlier), so the terminal program had to be set to use that port.

Before invoking SAM-BA, open the jumper J8 (NAND flash enable) and ensure the other jumpers are also open (J16 BMS and J11 dataflash enable). I was unable to find any direct documentation concerning these jumpers, however the schematic diagrams provided show J8 and J11 connecting the CS pin of the two memory chips to general purpose I/O port pins on the microcontroller. These jumpers therefore appear to enable or disable access to the onboard NAND flash and dataflash memory banks. Dataflash by the way is a proprietary Atmel SPI compatible serial flash memory, but is not installed by default. There is a solderable pad underneath the board (U8) intended to take a suitable dataflash chip. The AT91SAM9261S datasheet gave BMS as "boot mode select" which selects, on reset, whether booting is done from an internal ROM or externally. If BMS is at logic high then the internal ROM is used and this will be the normal case for the moment. This internal ROM does some basic hardware configuration, and checks for an executable program in dataflash or NAND flash. If these are not found (i.e. the board jumpers are open) then the ROM provides a small monitor program to interface with the SAM-BA application, either over the USB interface using a CDC protocol, or over the debug interface using an x-modem protocol.

Now start the SAM-BA program. The USB port to use should appear automatically as /dev/ttyACM0 in the top edit box. Then click "Connect". The SAM-BA main window should appear. Now close the jumper J8 before continuing on so that the NAND flash memory is re-enabled. Follow the documentation in the "SBC6000X Linux User Manual" to complete the upload process (see also Linux4SAM). There was a hiccup wherein SAM-BA would only look for .bin files and couldn't find uImage. I simply entered this by hand into the "Send File" text box. I didn't make a symlink to /dev/ttyUSB0 as suggested in the README that came with SAM-BA, but it still worked fine.

I didn't have an LCD so I omitted the Logo section.

Close SAM-BA and remove the USB cable (this may interfere with booting).

The Linux4SAM website has a lot of information about this process. Their procedure matches that in the provided documentation. They also provide precompiled binaries for at91bootstrap and u-boot although the latter is the same version as that provided with the board (1.3.4). The binaries for at91bootstrap however couldn't find NANDFLASH so they were of no value. From the source code provided it turned out that an additional entry for the board's NANDFLASH manufacturer ID was added to the file include/nand_ids.h in the array SNandInitInfo NandFlash_InitInfo:

{0xecf1, 0x400, 0x20000, 0x800, 0x40, 0x0, "Samsung K9F1G08U0B 128Mb\0"},

To install another version of at91bootstrap, copy board/at91sam9261ek/nandflash/Makefile from the provided version (1.11) across to replace the one in the corresponding directory in the new source tree, change include/nand_ids.h as above, and 'make' the new bin file.

When u-boot has been loaded, on the first run it may print the scary message:

"*** Warning - bad CRC or NAND, using default environment".

From the u-boot FAQ:

"The message is printed because the flash sector or EPROM containing the environment variables has not been initialized yet. The message will go away as soon as you save the environment variables using the 'saveenv' command." Whew!


I was unable to find in the supplied documentation, descriptions of the locations of the board's various external memories in the AT91SAM9261S address space.

The microcontroller's internal memories are placed in the lower 7MB of the the first 256MB address block, at addresses 0x00,0000 to 0x6F,FFFF. This is divided into seven blocks of 1MB each, with the boot ROM at 0x40,0000 (remapped to 0x0000 on reset if BMS is high), SRAM at 0x30,000 which can also be remapped by software command to 0x0000, USB host port at 0x50,0000 and LCD at 0x60,0000. The chip's BMS pin set to logic 0 allows the internal memories to be replaced by an external memory located normally at the second 256MB address block. This pin (via jumper J11) however is normally set high for loading and running Linux.

The documentation doesn't state where the 128MB NAND flash resides. This is probably not really necessary to know but it helps to have complete understanding. The schematic indicates that the NAND memory on the board is controlled by the microcontroller's dedicated NAND write and output enable control signals. The AT91SAM9261S datasheet states that the internal memory controller allocates the fifth 256MB address block 0x4000,0000 to 0x4FFF,FFFF to NAND memory support, and the control pins are activated only when an address request falls in that range.

The external SDRAM is addressed by the CS signal NCS1 which places it in the lower 64MB of the third 256MB address block at addresses 0x2000,0000 to 0x23FF,FFFF. This is the block that is allocated to SDRAM support by the internal RAM controller and is consistent with various hints in the documentation and boot log.

The SD card slot on the board uses the built-in Multimedia Card Interface support of the AT91SAM9261S. It is a stream or block device.

The board has an empty pad U8 underneath for dataflash to be installed (soldered on if desired). This is enabled with J11 (which of course would only have effect if the dataflash were installed).


This open source bootloader program has the following command set in the supplied version:

  • ? - alias for 'help'

  • base - print or set address offset

  • boot  - boot default, i.e., run 'bootcmd'

  • bootd - boot default, i.e., run 'bootcmd'

  • bootm - boot application image from memory

  • bootp - boot image via network using BOOTP/TFTP protocol

  • cls - clear screen

  • cmp - memory compare

  • coninfo - print console devices and information

  • cp - memory copy

  • crc32 - checksum calculation

  • dhcp - boot image via network using DHCP/TFTP protocol

  • echo - echo args to console

  • erase - erase FLASH memory

  • flinfo  - print FLASH memory information

  • go - start application at address 'addr'

  • help - print online help

  • imxtract- extract a part of a multi-image

  • itest - return true/false on integer compare

  • loadb - load binary file over serial line (kermit mode)

  • loady - load binary file over serial line (y-modem mode)

  • loop - infinite loop on address range

  • md - memory display

  • mm - memory modify (auto-incrementing)

  • mtest - simple RAM test(Ctl-C stops it)

  • mw - memory write (fill)

  • nand - NAND sub-system. This supports reading and writing to and from NAND memory and SDRAM.

  • nboot - boot from NAND device

  • nfs - boot image via network using NFS protocol

  • nm - memory modify (constant address)

  • ping - send ICMP ECHO_REQUEST to network host

  • printenv - print environment variables

  • protect - enable or disable FLASH write protection

  • rarpboot - boot image via network using RARP/TFTP protocol

  • reset - Perform RESET of the CPU

  • run - run commands in an environment variable

  • saveenv - save environment variables to persistent storage

  • setenv - set environment variables, notably IP settings.

  • sleep - delay execution for some time

  • tftpboot - boot image via network using TFTP protocol

  • usb - USB sub-system. This allows reading from a USB device to SRAM (but not writing).

  • usbboot  - boot from USB device.

  • version - print monitor version

Comparison with the U-boot website documentation shows a number of commands missing. This may be a reflection of the age of the provided version, or to save space, or because they have no use in the particular processor.


The kernel is compiled and uploaded to NANDFLASH as described in the "SBC6000X Linux User Manual" using the same procedure for as the boot utilities. There is an extensive configuration section which I started to follow but soon discovered that the provided source code already had settings in accordance with the document.

On my board Linux took up 13MB out of 124.5MB of available Flash and 10MB of the 61MB available RAM.

Upload Root Filesystem

The root filesystem is uploaded using a different method. The "SBC6000X Linux User Manual" describes the use of a tftp program over the ethernet connection. My ancient laptop however has a faulty ethernet port and as a result I couldn't use this method. By studying the U-boot command set I found I could upload over the serial connection by invoking the appropriate commands. The one I chose uses the y-modem protocol. The downside to this was that it took about 30 minutes to upload the 13MB filesystem, but at least it gave an alternative.

I found that U-boot has a command "fatload" that allows upload from a FAT formatted USB memory, but unfortunately the version of U-boot provided did not have this command (possibly to conserve space).

Invoke "minicom -o" (to skip the modem preamble) and set the serial parameters of the board (115200 baud) ensuring that hardware flow control is off (as the board's COM0 port is only three wire). In U-boot issue the command:

U-boot> loady 20400000

This begins the upload using y-modem. Then in minicom, type Ctl-A Z and select S to send (or just use CTL-A S), select the y-modem protocol and then tag with the space bar the file to send (rootfs.yaffs2). Press enter. A progress box appears which should show the file download progress. This presumably goes into the board's SDRAM. Follow the instructions to clear NAND flash and copy over the rootfs.

U-boot> nand erase 0x3a0000
U-boot> nand write.yaffs 20400000 3a0000 $(filesize)
U-boot> boot

Linux boots up but hangs at the final stage point where the profile is executed. There appears to be code for configuring an LCD, which was not present on my board. To fix this, use vi to edit the file /etc/profile and add # to the beginning of the last line to comment out the call to /bin/sbc6000x.sh

You should now have a command prompt.

Verify that plugging in a USB memory stick or disk drive will result in automount of the device. This will allow simplified program development for the board. The FAT formatted USB memory stick worked effortlessly but the disk drive, while detected, failed to mount. This was fixed by reformatting the disk drive with the FAT filesystem.


There are a number of strange "features" of the root filesystem not necessarily related to the desire to limit its size. The file /etc/init.d/rcS is executed on startup as the only initialization script, common in embedded Linux. It contains a call, commented out, to /etc/init.d/rcS.local, but that file as it stands should not be used as it appears to be some sort of test file. rcS also contains explicit mount commands rather than relying on /etc/fstab, which exists but doesn't match the mount requirements. Perhaps it is best deleted. Also /dev/pts is missing so telnet will not work (see below for resolution).


The embedded Linux provided uses BusyBox 1.4.2 (March 2007) for its preinstalled command utilities. This is a multi-entry program implementing the reduced Linux command set as parameters. The filesystem uses aliases to call BusyBox for each invoked command. The command set provided consists of the following 238 commands (compared to 310 given on the BusyBox website for the latest version 1.19.3).  Note that commands do not necessarily recognize all command line switches.

[, [[, adjtimex, ar, arp, arping, ash, awk, basename, bunzip2, bzcat, cal, cat, catv, chattr, chgrp, chmod, chown, chpst, chroot, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cut, date, dc, dd, deallocvt, devfsd, df, dhcprelay, diff, dirname, dmesg, dnsd, dos2unix, dpkg, dpkg-deb, du, dumpkmap, dumpleases, echo, ed, egrep, eject, env, envdir, envuidgid, ether-wake, expr, fakeidentd, false, fbset, fdflush, fdformat, fdisk, fgrep, find, fold, free, freeramdisk, fsck, fsck.minix, ftpget, ftpput, fuser, getopt, grep, gunzip, gzip, halt, hdparm, head, hexdump, hostid, hostname, httpd, hush, hwclock, id, ifconfig, ifdown, ifup, inetd, init, insmod, install, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute, iprule, iptunnel, kill, killall, killall5, klogd, lash, last, length, less, linux32, linux64, linuxrc, ln, loadfont, loadkmap, logger, logname, logread, losetup, ls, lsattr, lsmod, lzmacat, makedevs, md5sum, mdev, mesg, mkdir, mkfifo, mkfs.minix, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint, msh, mt, mv, nameif, nc, netstat, nice, nmeter, nohup, nslookup, od, openvt, patch, pidof, ping, ping6, pipe_progress, pivot_root, poweroff, printenv, printf, ps, pwd, raidautorun, rdate, readlink, readprofile, realpath, reboot, renice, reset, resize, rm, rmdir, rmmod, route, rpm, rpm2cpio, run-parts, runlevel, runsv, runsvdir, rx, sed, seq, setarch, setconsole, setkeycodes, setlogcons, setsid, setuidgid, sh, sha1sum, sleep, softlimit, sort, start-stop-daemon, stat, strings, stty, sum, sv, svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tail, tar, taskset, tee, telnet, telnetd, test, tftp, time, top, touch, tr, traceroute, true, tty, udhcpc, udhcpd, umount, uname, uncompress, uniq, unix2dos, unlzma, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, watch, watchdog, wc, wget, which, who, whoami, xargs, yes, zcat, zcip

BusyBox invoked with parameter --help followed by a command will give basic information for that command.

I upgraded this without dramas by downloading a prebuilt binary from http://busybox.net/downloads/binaries/. The one to use is busybox-armv4l despite the architecture being v5. Version 1.19.0 works fine. This was copied across to the root directory on a USB stick and tested with a few commands before replacing the original binary. Symlinks for extra commands can be added as desired. Interestingly this lacked the alias command that the older BusyBox had.


The IP parameters for the board are preset to the subnet This is NOT a reserved subnet. It is wise to change these to one of the subnets reserved for local communications within a private network (see RFC 1918). These are,, 10.0.0/8. This can be done with the following U-boot commands followed by "saveenv" to make the changes permanent:

U-Boot> set ipaddr
U-Boot> set serverip
U-Boot> set gatewayip
U-Boot> saveenv

These are for my local subnet of course, with the IP address of the board chosen as a random unallocated address. In Linux edit the file /etc/init.d/rcS to change the line for "ifconfig eth0" to

/sbin/ifconfig eth0 netmask broadcast
/sbin/route add default gw

The second line adds the gateway address to allow access to the Internet if desired (this is my modem/router). Create a file /etc/resolv.conf and add the following line to identify a nameserver that is on the local network. Most modern modem/routers will act as relay nameservers.


Reboot the board and verify that it is correct with the command ifconfig. Ping a machine on the local subnet or Internet to verify that it is working, e.g.

~$ ping google.com


The embedded Linux runs the Apache webserver httpd. The html files can be placed in /opt/apache/www/.


Telnet is provided by BusyBox to enable (insecure but who cares) login over ethernet. The telnetd command starts the daemon. It was not possible with the vanilla install to login with telnet from outside because the /dev/pts/ directory was missing. Simply create and mount this directory and telnet will work. The daemon can be started by invocation in the file /init.d/rcS by adding the following commands (/dev/pts must be recreated on each reboot):

mkdir /dev/pts

mount devpts /dev/pts -t devpts

For the later version of BusyBox create a symlink in /bin from busybox to "login", and use

mkdir /dev/pts

mount devpts /dev/pts -t devpts
/usr/sbin/telnetd -l login


This section documents various information missing from or ambiguous in the provided documentation.

Serial Cable

It's important to note that the serial cable provided is a 3-wire null modem. Pins 2 and 3 are interchanged but all other pins are connected pin to pin. This varies from the defacto standard for a null modem based on DB9 connectors. The cable would not be suitable for a 5-wire RS232 interconnection. A suitable cable would be wired as described in many places, for example here.

Header J13

The documentation for this header is confusing at best. It carries three USART ports which can be configured as RS232 voltage levels or (some at least) RS485 balanced line. There are also TTL levels provided. An amount of experimentation and perusal of the supplied schematic (thankfully provided) is needed to determine how to use this header.

The first 4 pins hold the COM0 port, which is the same as the debug port brought out to the DB9 connector. Tests show that pins 2 and 4 hold the TTL level (3.3V) Tx and Rx signals respectively while pins 1 and 3 hold the RS232 levels.

The pins 5,6 are grounds.

Once it is realised that the R in front of the signal names on the odd numbered pins refers to RS232 levels, the next set of signals up to pin 22 can be easily identified as those for two additional 5-wire serial ports labelled COM1 and COM2.

The AT91SAM9261S device datasheet shows that PA12 and PA13 are used for RTS1 and CTS1, PA15 and PA16 are used for RTS2 and CTS2 while PC8 to PC15 carry the Rx and Tx signals for all three ports, and RTS0 and CTS0. The dedicated serial debug port Rx and Tx are carried on the pins PA9 and PA10 respectively.

COM1 is USART0 and COM2 is USART1, while USART2 is not provided on the board.

It also appears that USART1 is brought out at RS485 balanced line levels in the J13 header pins 29-32. This is controlled by the mysterious jumper pins 29-36. The schematic shows the most likely mode of operation. Rx2 is taken to pins 36 and 40 while Tx2 is taken to pins 34 and 38. The opposing pins are taken to the RS232 and RS485 driver chips. Therefore connect pins 33-34 and 35-36 to use RS232 from USART1 (COM2) on pins 15, 17, 19, 21. Alternatively connect pins 37-38 and 39-40 to use RS485 on pins 29-32. Do not connect both of these sets of jumpers at the same time as the receive function will most likely be impaired or even damaged. The TTL level pins are unaffected.

The SPI1 signals are brought out to pins 25 to 28, which include the clock, read, write and one of the available chip selects. These are 3.6V signal levels. So far it is not clear if the board can handle 5V input levels, although the schematic does show limiting resistors between the header and microcontroller pins. The AT91SAM9261S device itself is specified only to 4V absolute maximum on input port pins.

First created 20 January 2012
Last Modified 8 June 2013
© Ken Sarkies 2012