TS-4800

TS-4800

Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
Freescale i.MX515 Documentation
i.MX515 Product Page
Reference Manual

Overview

The TS-4800 is a TS-SOCKET macrocontroller board based on the Freescale i.MX515 ARM Cortex-A8 CPU running at 800MHz. The TS-4800 features 10/100 Ethernet, high speed USB host and device (OTG), microSD card, and 256MB XNAND drive.

This page is still very much under construction. Refer to the TS-Socket manual for information for now.

Getting Started

A Linux PC is recommended for development. For developers who use Windows, virtualized Linux using VMWare or similar are recommended in order to make the full power of Linux available. The developer will need to be comfortable with Linux anyway in order to work with embedded Linux on the target platform. The main reasons that Linux is useful are:

• Linux filesystems on the microSD card can be accessed on the PC.
• More ARM cross-compilers are available.
• If recovery is needed, a bootable medium can be written.
• A network filesystem can be served.
• Builds such as Linux kernel, buildroot, yocto, distro-seed will not work from WSL1/2 on a case insensitive filesystem.

WARNING:

Be sure to take appropriate Electrostatic Discharge (ESD) precautions. Disconnect the power source before moving, cabling, or performing any set up procedures. Inappropriate handling may cause damage to the board.

The TS-4800 receives power through several pins on the socket connector. Refer to your baseboard documentation or schematics for locating the power in on your board.

Get a Console

Console on the TS-4800 will by default come out of the CPU UART (ttyS0). If you hold the power button for 5 seconds it will redirect Console to xuart port 1 (the red LED will turn on when you have held it long enough). You can find more details about where these UARTS are brought from your baseboard COM ports section. Either console will use 8n1, no flow control, and a 115200 baud rate.

You can also telnet to the board with the default network configuration, though this will omit the TS-BOOTROM messages which can be helpful for diagnostics.

Use a null modem cable to connect the ARM system to your workstation. If you do not have a COM port on your system (as many newer systems do not), you can find a USB serial adapter that will bring out RS232.

Console from Linux

There are many serial clients for Linux, but 3 simple ones would be picocom, screen, and minicom. These examples assume that your COM device is /dev/ttyUSB0 (common for USB adapters), but replace them with the COM device on your workstation.

Linux has a few applications capable of connecting to the board over serial. You can use any of these clients that may be installed or available in your workstation's package manager:

Picocom is a very small and simple client.

picocom -b 115200 /dev/ttyUSB0

Screen is a terminal multiplexer which happens to have serial support.

screen /dev/ttyUSB0 115200

Or a very commonly used client is minicom which is quite powerful:

minicom -s

• Navigate to 'serial port setup'
• Type "a" and change location of serial device to '/dev/ttyUSB0' then hit "enter"
• If needed, modify the settings to match this and hit "esc" when done:

     E - Bps/Par/Bits          : 115200 8N1
     F - Hardware Flow Control : No
     G - Software Flow Control : No

• Navigate to 'Save setup as dfl', hit "enter", and then "esc"

Console from Windows

Putty is a small simple client available for download here. Open up Device Manager to determine your console port. See the putty configuration image for more details.

Initrd / Busybox / Fastboot

When the board first boots you should see output similar to this:

 >> TS-BOOTROM - built Jan 24 2011 12:40:54
 >> Copyright (c) 2010, Technologic Systems
 >> Booting from SD card...
 .
 .
 .
 Finished booting in 1.11 seconds
 Type 'tshelp' for help

This is a busybox shell which presents you with a very minimalistic system. This filesystem is loaded into memory, so none of the changes will be saved unless you type the command

save

or mount a filesystem as read/write. This can also provide a simple mechanism for running your application in an entirely read-only environment. The linuxrc script will be the first thing executed as soon as the kernel is loaded. This sets the default IP address, loads a reloadable FPGA bitstream if one is present, starts the userspace ctl applications, and more. Read the linuxrc for more information.

While busybox itself doesn't contain much functionality, it does mount the Debian partition under /mnt/root/. It will also add common paths and load libraries from the Debian system. Many of the Debian applications will work by default. For example, if you are using the TS-4800 with a video interface (or a touchpanel like the TS-TPC-8390), you will see icewm startup. The linuxrc will determine if the baseboard is one that is recognized with video, and start X11 with icewm from Debian. This is why it has the Debian logo since it uses their theme files, but is not usable as Debian. This is also only provided as a demo of X11 and not intended to be used for development. Whether or not a Debian application will work in fastboot needs to be judged per application. If an application relies on certain paths being in certain places, or running services, you should instead boot to Debian to run them.

This shell when started on the COM port is what is blocking a Debian boot. If you close it by typing

exit

the boot process will continue. If you are connected through telnet, this will instead open up its own instance of the shell so typing

exit

will only end that session. Through any connection method you can relink the linuxrc to change it to boot by default to Debian.

The initrd has these boot scripts available:

Script	Function
linuxrc-fastboot (default)	Boots immediately to a shell in ramdisk. This will mount whichever boot medium you have selected to /mnt/root/. When you type 'exit', it will boot to that medium.
linuxrc-sdroot	Boots immediately to the Debian stored on SD.
linuxrc-xnandroot	Boots immediately to the Debian stored on the XNAND.
linuxrc-sdroot-ubuntu	Boots immediately to the first partition which contains Ubuntu. This is only available on the 8GB SD cards.

Note:

Keep in mind the boot medium is selected by the pinout on your baseboard, not through software. The ramdisk and kernel will be loaded before the linuxrc begins execution.

For example, to set the linuxrc to boot immediately to Debian on SD or NAND, you would run this:

rm linuxrc; ln -s /linuxrc-sdroot /linuxrc; save

You can edit the linuxrc-4800 to create more booting methods (NFS, USB, etc).

The small default initrd is only 2Mbyte but there is space for approximately 300 Kbyte of additional user applications. The binaries on the initrd are dynamically linked against embedded Linux's "uclibc" library instead of the more common Linux C library "glibc". "uclibc" is a smaller version of the standard C library optimized for embedded systems and requires a different set of GCC compiler tools which are available here.

 The compiled instance of busybox includes several internal commands listed below:
 BusyBox v1.14.2 (2011-02-03 15:49:11 MST) multi-call binary
 Copyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenko
 and others. Licensed under GPLv2.
 See source distribution for full notice.
 
 Usage: busybox [function] [arguments]...
    or: function [arguments]...
 
         BusyBox is a multi-call binary that combines many common Unix
         utilities into a single executable.  Most people will create a
         link to busybox for each function they wish to use and BusyBox
         will act like whatever it was invoked as!
 
 Currently defined functions:
         [, [[, ar, ash, basename, cat, chat, chgrp, chmod, chown, chroot,
         cmp, cp, cpio, cttyhack, cut, date, dd, depmod, devmem, df, dirname,
         dmesg, du, echo, egrep, env, expr, false, fdisk, fgrep, find, grep,
         gunzip, gzip, halt, head, hostname, hush, ifconfig, insmod, kill,
         killall, ln, login, ls, lsmod, md5sum, mdev, mkdir, mknod, modprobe,
         more, mount, msh, mv, netstat, ping, pivot_root, poweroff, printf,
         ps, pwd, reboot, rm, rmdir, rmmod, route, rx, sed, setconsole,
         setsid, sh, sleep, stty, sync, tail, tar, telnetd, test, tftp,
         top, tr, true, udhcpc, umount, uname, unzip, usleep, uudecode,
         uuencode, vi, wget, xargs, yes, zcat

Also on the initrd are the TS specific applications: canctl, dioctl, nandctl, spictl, ts4800ctl, and xuartctl. We also provide the ts.subr which provides the following functions:

 bit_set()
 bit_clr()
 bit_get()
 gpio_dir_get()
 gpio_dir_set()
 gpio_data_get()
 gpio_data_set()
 dio_dir_get()
 dio_dir_set()
 dio_data_get()
 dio_data_set()
 usb_on()
 usb_off()
 usb_init()
 usb_numports()
 usb_port_devexists()
 usbload()
 bbclk_on()
 bbclk_off()
 led0()
 led1()
 lcd_on()
 lcd_off()
 backlite_on()
 backlite_off()
 backlite_high()
 backlite_medium()
 backlite_low()
 fix_display()
 touchscreen_on()
 touchscreen_off()
 tpc_up()
 can0_on()
 can0_off()
 can1_on()
 can1_off()
 xuart0_on()
 xuart0_off()
 xuart3_on()
 xuart3_off()
 xuart4_on()
 xuart4_off()
 xuart5_on()
 xuart5_off()
 spi_on()
 spi_off()
 motor_on()
 motor_off()
 snd_on()
 snd_off()
 irq5_on()
 irq5_off()
 irq6_on()
 irq6_off()
 irq7_on()
 irq7_off()
 spk_on()
 spk_off()
 is_ts4800
 mxtime()
 save2sd
 save2xnand
 save
 sd2xnand
 xnand2sd
 createxnandboot
 createxnandroot()
 get_2nd_mac()
 tshelp()
 sdmount()
 help()

By default, linuxrc will not insert the necessary modules into the kernel to mount and use USB devices within the initrd/busybox environment if there is no USB device present upon bootup (USB support is enabled by default within the Debian environment). The quickest way to get a USB device (like a USB thumb drive) to mount in the initrd/busybox environment is to ensure that it is plugged in before the SBC is powered up. In order to get hot-swappable USB devices regardless of device presence at bootup time, you must "modprobe" the necessary modules. This has been done for you in the ts.subr file with the usbload() function.

Boot Process

Boot Process

This board uses the TS-BOOTROM implemented in our FPGA. When the board is powered on the FPGA checks the state of the boot jumpers and then begins execution in the MBR of the selected storage device. By default any boot device will have a kernel, and a ramdisk with busybox. On the SD card and XNAND there is a copy of Debian.

Backup / Restore

If you are using a Windows workstation there is no support for writing directly to block devices. However, as long as one of your booting methods still can boot a kernel and the initrd you can rewrite everything by using a usb drive. This is also a good way to blast many stock boards when moving your product into production. You can find more information about this method with an example script here.

Note:

Note that the MBR installed by default on this board contains a 446 byte bootloader program that loads the initial power-on kernel and initrd from the first and second partitions. Replacing it with an MBR found on a PC would not work as a PC MBR contains an x86 code bootup program.

MicroSD Card

If backing up on a separate workstation, keep in mind windows does not have direct block device support needed to write these images. You will also need to determine the SD card device. You can usually find this in the output of 'dmesg' after inserting the SD card and you will typically see something like '/dev/sdb' as the block device and '/dev/sdb1' for the first partition. On some newer kernels you will see '/dev/mmcblk0' as the block device and '/dev/mmcblkop1' for the first partition. For these examples I will use the '/dev/mmcblk0' format.

If you are backing up directly on the board you will likely need to use some kind of offboard storage like a thumbdrive or external hard drive. Make sure you have any nbd devices unmounted before trying to restore new ones.

It is always recommended to use the latest image. You should use this 2GB SD image and this 8GB SD image.

Make sure you decompress the image first before writing.

Note:

Not all SD cards are created equally, over time they tend to shrink in size due to automatic retiring of bad blocks. All of Technologic System's images are 10% smaller than the target disc size. We STRONGLY recommend following that same practice on any mass-replicated images.

From Workstation

---

Backup

Entire SD card

dd if=/dev/mmcblk0 of=/path/to/backup.dd bs=32k

Kernel

dd if=/dev/mmcblk0p2 of=/path/to/zImage bs=32k

Initrd

dd if=/dev/mmcblk0p3 of=/path/to/initrd bs=32k

Restore

Entire SD card

dd if=/path/to/backup.dd of=/dev/mmcblk0 bs=32k

Kernel

dd if=/path/to/zImage bs=32k of=/dev/mmcblk0p2

Initrd

dd if=/initrd bs=32k of=/dev/mmcblk0p3

From SBC

---

Backup

Entire card

dd if=/dev/mmcblk0 of=/path/to/backup.dd

Note:

Not all SD cards are created equally, over time they tend to shrink in size due to automatic retiring of bad blocks. All of Technologic System's images are 10% smaller than the target disc size. We STRONGLY recommend following that same practice on any mass-replicated images.

Kernel

dd if=/dev/mmcblk0p2 of=/path/to/backup.dd

Initrd

dd if=/dev/mmcblk0p3 of=/path/to/backup.dd

Restore

The entire card from SBC

dd if=/path/to/2GB-mSD-4800-latest.dd of=/dev/mmcblk0

Kernel

dd if=/mnt/root/zImage of=/dev/mmcblk0p2

Initrd

dd if=/mnt/root/initrd of=/dev/mmcblk0p3

XNAND

The XNAND is restorable from the stock SD card. Boot the the initrd (not Debian) and you can run one command to restore the stock mini-lenny distribution:

# createxnandroot
Preparing XNAND flash drive...
Copying Kernel and ramdisk from SD to XNAND...
done
Creating root filesystem...
done

Operating System

Our boards boot a standard EABI Debian Squeeze on SD which provides a large amount of software that you can install with relatively little effort. See the Debian page for more general information on installing/removing software, and further documentation. The default image on the XNAND will be Debian Lenny as it provides a smaller base, but we have Squeeze for xnand available here

Software Development

Most of our examples are going to be in C, but Debian will include support for many more programming languages. Including (but not limited to) C++, PERL, PHP, SH, Java, BASIC, TCL, and Python. Most of the functionality from our software examples can be done from using system calls to run our userspace utilities. For higher performance, you will need to either use C/C++ or find functionally equivalent ways to perform the same actions as our examples. Our userspace applications are all designed to go through a TCP interface. By looking at the source for these applications, you can learn our protocol for communicating with the hardware interfaces in any language.

You can use the TS-4800 single precision FPU with these gcc arguments:

 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp

The most common method of development is directly on the SBC. Since Debian has space available on the SD card, we include the build-essentials package which comes with everything you need to do C/C++ development on the board.

Editors

Vim is a very common editor to use in Linux. While it isn't the most intuitive at a first glance, you can run 'vimtutor' to get a ~30 minute instruction on how to use this editor. Once you get past the initial learning curve it can make you very productive. You can find the vim documentation here.

Emacs is another very common editor. Similar to vim, it is difficult to learn but rewarding in productivity. You can find documentation on emacs here.

Nano while not as commonly used for development is the easiest. It doesn't have as many features to assist in code development, but is much simpler to begin using right away. If you've used 'edit' on Windows/DOS, this will be very familiar. You can find nano documentation here.

Compilers

We only recommend the gnu compiler collection. There are many other commercial compilers which can also be used, but will not be supported by us. You can install gcc on most boards in Debian by simply running 'apt-get update && apt-get install build-essential'. This will include everything needed for standard development in c/c++.

You can find the gcc documentation here. You can find a simple hello world tutorial for c++ with gcc here.

Build tools

When developing your application typing out the compiler commands with all of your arguments would take forever. The most common way to handle these build systems is using a make file. This lets you define your project sources, libraries, linking, and desired targets. You can read more about makefiles here.

If you are building an application intended to be more portable than on this one system, you can also look into the automake tools which are intended to help make that easier. You can find an introduction to the autotools here.

Cmake is another alternative which generates a makefile. This is generally simpler than using automake, but is not as mature as the automake tools. You can find a tutorial here.

Debuggers

Linux has a few tools which are very helpful for debugging code. The first of which is gdb (part of the gnu compiler collection). This lets you run your code with breakpoints, get backgraces, step forward or backward, and pick apart memory while your application executes. You can find documentation on gdb here.

Strace will allow you to watch how your application interacts with the running kernel which can be useful for diagnostics. You can find the manual page here.

Ltrace will do the same thing with any generic library. You can find the manual page here.

Cross Compiling

If your sources are large enough that compiling on the board is too encumbering, we provide toolchains that you can use from another Linux.

For this board you will want to use this toolchain. To compile your application, you only need to use the version of GCC in the cross toolchain instead of the version supplied with your distribution. The resulting binary will be for ARM.

[user@localhost]$ /opt/4800/arm-2008q3/bin/arm-none-linux-gnueabi-gcc hello.c -o hello
[user@localhost]$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

This is one of the simplest examples. If you want to work with a project, you will typically create a makefile. You can read more about makefiles [here]. Another common requirement is linking to third party libraries provided by Debian on the board. There is no exact set of steps you can take for every project, but the process will be very much the same. Find the headers, and the libraries. Sometimes you have to also copy over their binaries. In this example, I will link to sqlite from Debian (which will also work in the Ubuntu image).

Install the sqlite library and header on the board:

apt-get update && apt-get install -y libsqlite3-0 libsqlite-dev

This will fetch the binaries from the internet and install them. You can list the installed files with dpkg:

dpkg -L libsqlite3-0 libsqlite3-dev

The interesting files from this output will be the .so files, and the .h files. In this case you will need to copy these files to your project directory.

I have a sample example with libsqlite3 below. This is not intended to provide any functionality, but just call functions provided by sqlite.

#include <stdio.h>
#include <stdlib.h>
#include "sqlite3.h"

int main(int argc, char **argv)
{
	sqlite3 *db;
	char *zErrMsg = 0;
	int rc;
	printf("opening test.db\n");
	rc = sqlite3_open("test.db", &db);
	if(rc){
		fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
		sqlite3_close(db);
		exit(1);
	}
	if(rc!=SQLITE_OK){
		fprintf(stderr, "SQL error: %s\n", zErrMsg);
	}
	printf("closing test.db\n");
	sqlite3_close(db);
	return 0;
}

To build this with the external libraries I have the makefile below. This will have to be adjusted for your toolchain path. In this example I placed the headers in external/include and the library in external/lib.

CC=/opt/4800/arm-2008q3/bin/arm-none-linux-gnueabi-gcc
CFLAGS=-c -Wall

all: sqlitetest

sqlitetest: sqlitetest.o
        $(CC) sqlitetest.o external/lib/libsqlite3.so.0 -o sqlitetest
sqlitetest.o: sqlitetest.c
        $(CC) $(CFLAGS) sqlitetest.c -Iexternal/include/

clean:  
        rm -rf *o sqlitetest.o sqlitetest

You can then copy this directly to the board and execute it. There are many ways to transfer the compiled binaries to the board. Using a network filesystem such as sshfs or NFS will be the simplest to use if you are frequently updating data, but will require more setup. See your linux distribution's manual for more details. The simplest network method is using ssh/sftp. You can use winscp if from windows, or scp from linux. Make sure you set a password from debian for root. Otherwise the ssh server will deny connections. From winscp, enter the ip address of the SBC, the root username, and the password you have set. This will provide you with an explorer window you can drag files into.

For scp in linux, run:

#replace with your app name and your SBC IP address
scp sqlitetest root@192.168.0.50:/root/

After transferring the file to the board, execute it:

ts:~# ./sqlitetest 
opening test.db
closing test.db