TS-4700

TS-4700

Released Mar. 2011
Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
CPU Series Website
PXA16X Software Guide

Overview

The TS-4700 is a TS-Socket Macrocontroller Computer on Module based on the Marvell PXA166 ARM9 CPU running at 800 MHz. The TS-4700 features 10/100 Ethernet, high speed USB host and device (OTG), microSD card, and 256 MB XNAND drive.

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-4700 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-4700 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.n 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 Aug  4 2011 12:52:20
 >> Copyright (c) 2010, Technologic Systems
 >> Booting from microSD card ...
 .
 .
 .
 >> Booted from: SD card                 Booted in: 1.78 seconds
 >> SBC Model number: TS-4700            SBC Sub-model number: 0
 >> CPU clock rate: 797MHz               RAM size: 256MB
 >> NAND Flash size: 256MB               NAND Flash Type: 0xdcec (Samsung)
 >> MAC number: 00:D0:69:44:1A:E9        SBC FPGA Version: 4
 >> CPU Temperature: 49 degC             MODE1 bootstrap: OFF
 >> RTC present: YES                     Date and Time: Nov 17 2015 00:57:09
 >> Base board type: 62 RevD             Base board FPGA Version: 0x0
 >> MODE2 bootstrap: ON                  SD card size: 7788MB
 >> XUARTs detected: 7                   CAN present: NO
 >> Linux kernel version: 2.6.29-ts4700- Linux kernel date: Aug 23 2011
 >> Bootrom date: unknown                INITRD date: Sep 1 2011
 >> ts4700ctl date: Aug 22 2011          sdctl date: not present
 >> canctl date: not present             nandctl date: Aug 24 2011
 >> spiflashctl date: not present        xuartctl date: Aug 22 2011
 >> dioctl date: Aug 5 2010              spictl date: not present
 >> dmxctl date: Jul 23 2010             busybox date: Aug 12 2011 (v1.18.3)
 >> ts4700.subr date: Aug 23 2011        daqctl date: not present
 >> linuxrc date: Aug 23 2011            rootfs date: Sep 1 2011
 >> MBR date: Aug 23 2011
 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 '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. 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-nandmount	Same as the linuxrc-fastboot script, but will mount and boot the debian partition from NAND.
linuxrc-sdmount	Same as the linuxrc-fastboot script, but will mount and boot the debian partition from SD.
linuxrc-sdroot	Boots immediately to the Debian stored on either SD or NAND depending on which device you have currently selected.
linuxrc-sdroot-readonly	Same as linuxrc-sdroot, except it will mount the Debian partition read only while creating a unionfs with a ramdisk. Changes will only happen in memory and not on disk.
linuxrc-usbroot	Mounts the first partition of the first detected USB mass storage device and boots there.

Note:

Keep in mind the boot medium is selected by the pinout on your baseboard, not through software.

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

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

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.18.3 (2011-08-11 15:25:09 MST) multi-call binary.
 Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko
 and others. Licensed under GPLv2.
 See source distribution for full notice.
 
 Usage: busybox [function] [arguments]...
    or: busybox --list[-full]
    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, chrt,
         cmp, cp, cpio, cttyhack, cut, date, dc, dd, depmod, devmem, df,
         dirname, dmesg, dnsdomainname, du, echo, egrep, env, expr, false,
         fdisk, fgrep, find, free, grep, gunzip, gzip, halt, head, hostname,
         hush, hwclock, ifconfig, insmod, ipcrm, ipcs, kill, killall, ln, login,
         ls, lsmod, lsusb, md5sum, mdev, microcom, mkdir, mkfifo, mknod,
         modinfo, modprobe, more, mount, mv, netstat, nohup, ping, pivot_root,
         poweroff, printf, ps, pwd, rdate, reboot, rm, rmdir, rmmod, route, rx,
         sed, seq, setconsole, setsid, sh, sha1sum, sha256sum, sha512sum, sleep,
         stty, sync, sysctl, tail, tar, tee, telnetd, test, tftp, time, top,
         touch, tr, true, udhcpc, umount, uname, unxz, unzip, uptime, usleep,
         uudecode, uuencode, vi, watch, wget, xargs, xz, xzcat, yes, zcat

Also on the initrd are the TS specific applications: dioctl, dmxctl, nandctl, ts4700ctl, and xuartctl. We also provide the ts4700.subr which provides the following functions:

 printbin()
 usbload()
 save()
 sdsave()
 nandsave()
 sd2nand()
 nand2sd()
 setdiopin()
 getdiopin()
 setout()
 getin()
 tshelp()
 gettemp()
 backlight_on()
 backlight_off()
 backlight_low()
 backlight_medium()
 backlight_high()
 speaker()
 do_splash()

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 ts4700.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.

You can find the latest SD card image here. Make sure you decompress the image first before writing.

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

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-4700-latest.dd of=/dev/mmcblk0

Kernel

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

Initrd

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

XNAND

This needs to be done directly on the SBC. Please note that all NBD partitions from the NAND card must be dismounted before attempting to image the NAND on the SBC.

WARNING:

Since there is no locking mechanism, it is not safe to run 2 copies of nandctl on this board. Make sure you unmount your filesystems and stop running nandctl if you prefer to backup/write data with that. These examples use 'dd' which is safe to use while nandctl is running.

You can find the latest xnand image here. Make sure you decompress the image first before writing.

Backup

Entire Image

# Compressed
dd if=/dev/nbd0 bs=131072 count=2048 | gzip > backup.dd.gz
# or uncompressed
dd if=/dev/nbd0 bs=131072 count=2048 of=backup.dd

Kernel

dd if=/dev/nbd2 bs=4096 count=512 of=/path/to/backup/zImage

Initrd

dd if=/dev/nbd3 bs=4096 count=512 of=/path/to/backup/initrd

Restore

Entire Image

# Compressed
gunzip xnand-4700-latest.dd.bz2 | dd bs=131072 count=2048 of=/dev/nbd0
# or uncompressed
dd if=xnand-4700-latest.dd bs=131072 count=2048 of=/dev/nbd0

Kernel

dd of=/dev/nbd2 bs=4096 count=512 if=/path/to/backup/zImage

Initrd

dd of=/dev/nbd3 bs=4096 count=512 if=/path/to/backup/initrd

Operating System

Our boards boot a standard Debian Squeeze (EABI) distribution 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.

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.

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.

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 or Cygwin environment. For this board you will want to use this toolchain. This directory contains a gcc suite in 'arm-2008q3/bin/arm-none-linux-gnueabi-'. You can add this bin directory to your $PATH variable and then even call the compiler by 'arm-none-linux-gnueabi-gcc' (or any other gcc utility).

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]$ 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

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 hello root@192.168.0.50:/root/

After transferring the file to the board, execute it:

root@ts4700:~# ./hello 
Hello world!

CPU Functionality

The TS-4700 features a Marvell PXA166 CPU which provides much functionality. This is also known as the Armada 166, or 88AP166. The common features will be described below, but for more details see the CPU user guide.

Connectors

CN1

CN2

Name Pin Pin Name FPGA_JTAG_TMS 1 2 EXT_RESET# FPGA_JTAG_TCK 3 C 4 EN_USB_5V FPGA_JTAG_TDO 5 N 6 SDCARD_D2 FPGA_JTAG_TDI 7 1 8 SDCARD_D3 OFF_BD_RESET# 9 10 SDCARD_CMD Reserved 11 12 SDCARD_3.3V Reserved 13 C 14 SDCARD_CLK POWER 15 N 16 POWER Reserved 17 1 18 SDCARD_D0 LCD_D08 19 20 SDCARD_D1 LCD_D09 21 22 Reserved LCD_D10 23 C 24 LCD_D0 LCD_D11 25 N 26 LCD_D1 LCD_D12 27 1 28 LCD_D2 POWER 29 30 LCD_D3 LCD_D13 31 32 LCD_D4 LCD_D14 33 C 34 LCD_D5 LCD_D15 35 N 36 V_BAT LCD_D16 37 1 38 LCD_D6 LCD_D17 39 40 LCD_D7 LCD_D18 41 42 LCD_D21 LCD_D19 43 C 44 LCD_D22 LCD_D20 45 N 46 LCD_D23 POWER 47 1 48 EN_LCD_3.3V LCD_CLK 49 50 Reserved LCD_HSYNC 51 52 Reserved LCD_VSYNC 53 C 54 Reserved LCD_DE 55 N 56 Reserved LCD_PWM 57 1 58 Reserved Reserved 59 60 Reserved Reserved 61 62 GND DIO_14 63 C 64 MUX_AD_15 DIO_13 65 N 66 MUX_AD_14 DIO_12 67 1 68 MUX_AD_13 DIO_11 69 70 MUX_AD_12 DIO_10 71 72 MUX_AD_11 DIO_9 73 C 74 MUX_AD_10 GND 75 N 76 MUX_AD_9 DIO_8 77 1 78 MUX_AD_8 DIO_7 79 80 MUX_AD_7 DIO_6 81 82 MUX_AD_6 DIO_5 83 C 84 MUX_AD_5 DIO_4 85 N 86 MUX_AD_4 DIO_3 87 1 88 MUX_AD_3 DIO_2 89 90 MUX_AD_2 DIO_1 91 92 MUX_AD_1 DIO_0 93 C 94 MUX_AD_0 GND 95 N 96 BUS_ALE# BUS_WAIT# 97 1 98 BUS_DIR BUS_BHE# 99 100 BUS_CS#

Name Pin Pin Name ETH_RX+ 1 2 ETH_LEFT_LED ETH_RX- 3 C 4 ETH_RIGHT_LED ETH_CT 5 N 6 RED_LED# ETH_TX+ 7 2 8 GREEN_LED# ETH_TX- 9 10 MFP_105 ETH_CT 11 12 MFP_106 3.3V 13 C 14 MFP_122 GND 15 N 16 Reserved Reserved 17 2 18 Reserved Reserved 19 20 Reserved GND 21 22 Reserved Reserved 23 C 24 Reserved Reserved 25 N 26 MFP_49 Reserved 27 2 28 TWI_CLK HOST_USB_M 29 30 TWI_DAT HOST_USB_P 31 32 MFP_104 CPU_CORE 33 C 34 AUD_MCLK USB_OTG_M 35 N 36 AUD_CLK USB_OTG_P 37 2 38 AUD_FRM 3.3V 39 40 AUD_TXD Reserved 41 42 AUD_RXD Reserved 43 C 44 CPU_JTAG_TMS GND 45 N 46 CPU_JTAG_TCK Reserved 47 2 48 CPU_JTAG_TDI Reserved 49 50 CPU_JTAG_TDO GND 51 52 ONE_WIRE Reserved 53 C 54 MFP_51 Reserved 55 N 56 CAM_MCLK DDR_1.8V 57 2 58 CAM_D0 Reserved 59 60 CAM_D1 Reserved 61 62 CAM_D2 AVDD_OSC 63 C 64 CAM_D5 SPI_FRM 65 N 66 CAM_D6 SPI_MOSI 67 2 68 CAM_D7 SPI_MISO 69 70 CAM_HSYNC SPI_CLK 71 72 CAM_VSYNC GND 73 C 74 USB_OTG_ID Reserved 75 N 76 USB_5V_LINE Reserved 77 2 78 UART0_TXD CPU_JTAG_VCC 79 80 UART0_RXD CAM_D3 81 82 UART1_TXD CAM_D4 83 C 84 UART1_RXD CAM_PCLK 85 N 86 UART2_TXD CAM_VCLK 87 2 88 UART2_RXD MFP_52 89 90 UART3_TXD MFP_43 91 92 UART3_RXD DEBUG_TXD 93 C 94 UART4_TXD DEBUG_RXD 95 N 96 UART4_RXD DIO_15/CAN_TXD 97 2 98 UART5_TXD DIO_16/CAN_RXD 99 100 UART5_RXD

FPGA JTAG

The four FPGA JTAG pins should be left floating on most base boards. Using these pins to program the macrocontroller FPGA in the field is not supported.

OFF_BD_RESET

OFF_BD_RESET# is an output from the macrocontroller that automatically sends a reset signal when the unit powers up or reboots. It can be connected to any IC on the base board that requires a reset.

Offboard SD Card Interface

SD Card pins are in parallel with the microSD card slot on the macrocontroller. For systems that require a removable SD, MiniSD, or microSD card, the base board connects these lines to the SD connector and the on-board microSD slot cannot be used.

LCD Interface

This interface presents a standard 24 bit LCD video output.

EN_LCD_3.3V

This is a DIO used to switch power to an LCD display.

EXT_RESET

EXT_RESET# is an input to the macrocontroller that can be used to reset the system. It is open drain.

EN_USB_5V

This is a DIO used by convention to switch 5V USB power on base boards.

Power

TS-SOCKET base boards must provide a regulated voltage between 4.5V and 5.5V on POWER pins. All other power rails required by the macrocontroller are provided by regulators on the macrocontroller.

LCD PWM

A PWM signal on this line is used to control the brightness of the LCD backlight.

V_BAT

A base board may include a 3.3V battery. If so, this line provides a battery voltage to the macrocontroller. This battery power is used to maintain the time in the RTC.

GND

Base boards must connect all GND lines to a common ground.

FPGA DIO

DIO 0 through DIO 14 are 15 DIO lines that are guaranteed to be available on any macrocontroller. Many of these IO can be repurposed with other functionality in the FPGA (UARTS for example), but GPIO is the default. DIO 15 and 16 are used for CAN communication, or as DIO if CAN is not in use.

DIO	Function
0	Off-board IRQ #5
1	Off-board IRQ #6
2	Off-board IRQ #7
3	Base board CLK (For base board CPLD/FPGA)
4	UART 5 CTS#, edge counter 0 input
5	BD_ID_DATA (Standard base boards use this line along with an 8:1 mux chip to provide an 8 bit base board ID code)
6	ADC_DAT (Used for off-board MCP3428 ADC), Edge counter 1 input
7	ADC_CLK (Used for off-board MCP3428 ADC), UART 5 TX_EN
8	AN_SEL (Used for off-board MCP3428 ADC), UART 1 TX_EN
9	PUSH_SW# (Used for reset switch)
10	CAN2_TXD (2nd CAN port is usually not implemented in FPGA), UART 2 TX_EN
11	CAN2_RXD (2nd CAN port is usually not implemented in FPGA)
12	UART 0 TX_EN
13	UART 6 RXD (Can be used as a separate RX channel for RS-422), UART 3 TX_EN
14	UART 4 TX_EN
15	CAN TX
16	CAN RX

Ethernet Port

ETH pins are 10/100 Ethernet pins which are connected directly to an Ethernet connector on the base board.

Note:

Ethernet Magnetics should be placed as close to CN2 as possible on the base board.

LED

All standard base boards connect these lines to LEDs for basic user feedback.

CPU DIO

The CPU DIO can be used as general purpose IO, or many of them provide alternative functionality as well.

DIO	Function
MFP_43	GPIO_43
MFP_49	GPIO_49
MFP_51	GPIO_51
MFP_52	GPIO_52
MFP_104	GPIO_104 or PWM4
MFP_105	GPIO_105 or I2C_SDA
MFP_106	GPIO_106, I2C_SCL, PWM1
MFP_122	GPIO_122, PWM3

USB

The PXA166 provides 1 USB Host and 1 USB OTG port.

TWI

These pins provide a standard two-wire interface. This bus also connects to an RTC and temperature sensor on the macrocontroller. MFP105 and MFP106 can be used as a second TWI bus directly from the CPU.

CPU Voltage Testing

CPU core voltages are provided for troubleshooting purposes only. On most base boards these should not be connected.

I2S Audio

These pins can be connected to an I2S CODEC for an audio output channel.

One Wire Interface

The PXA166 brings out a 1 wire interface. See the CPU software guide for more details.

Camera Interface

On the TS-4700, a camera interface is available on these lines. Other unique features may be available -- see the schematics for more information.

CPU JTAG

Most TS-SOCKET systems run Linux, in which case the CPU JTAG bus is not useful and should not be connected. For developers who want to use another operating system, or write "bare-metal" microcontroller-style code, this CPU JTAG debugging interface is made available. If you need to use this interface, please contact Technologic Systems to order a TS-8200 base board with the CPU JTAG connector.

SPI

The TS-4700 brings out a SPI controller. See the CPU software guide for more details.

1.8V Rail

Maximum load on the 1.8V rail is 10mA.

3.3V Rail

All macrocontrollers have a 3.3V power rail which is provided to the base board on this pin. On the TS-4700 it is good for 700mA

XUARTS

The xuarts can be managed with xuartctl. See the xuartctl page for more details.

Debug Console

These pins are dedicated to a development console. Standard base boards typically have a "Console enable" jumper that makes this console available for development.

Compiling a Kernel

WARNING:

BACKUP YOUR DATA FIRST

Prerequisites

RHEL/Fedora/CentOS:

yum install ncurses-devel ncurses
yum groupinstall "Development Tools" "Development Libraries"

Ubuntu/Debian:
apt-get install build-essential libncurses5-dev libncursesw5-dev

For other distributions, please refer to their documentation to find equivilant tools.

Set up the Sources and Toolchain

# Download the cross compile toolchain (OABI)from Technologic Systems:
wget ftp://ftp.embeddedarm.com/ts-socket-macrocontrollers/ts-4700-linux/cross-toolchains/arm-2008q3.tar.gz

# Extract to current working directory:
tar xvf crosstool-linux-arm-uclibc-3.4.6.tar.gz

# Download the Kernel sources
wget ftp://ftp.embeddedarm.com/ts-socket-macrocontrollers/ts-4700-linux/sources/linux-2.6.29-4700_latest.tar.gz

# Extract the Kernel Sources
gzip -dc linux-2.6.29-4700_latest.tar.gz | tar xf -

cd linux-2.6.29-4700/

Configure the Sources

The kernel sources need a few variables to be exported.

# Set the CROSS_COMPILE variable to the absolute path to the toolchain.  This will be different for your system:
export CROSS_COMPILE=/opt/4800/arm-2008q3/bin/arm-none-linux-gnueabi-

# Normally, ARCH will be set based on your build hosts architecture.
export ARCH=arm

This sets up the default configuration that we ship with for the TS-4700

make ts4700_defconfig

This will bring up a graphical menu where you can edit the configuration to include support for new devices. For Example, to include support for a Prolific USB to serial adapter you would go to 'Device Drivers -> USB Support-> USB Serial Support' and then select 'USB Prolific 2303 Single Port Serial Driver'. Since the kernel only has a limited space, build drivers as modules whenever possible.

make menuconfig

Build the kernel

Once you have it configured, start building. This usually takes a few minutes.

make && make modules

The new kernel will be at "arch/arm/boot" in a compressed format called zImage. The uncompressed version is simply called Image. With the default partitioning scheme it is REQUIRED that the kernel be < 2096640 bytes in size. If you need to shorten the size, try including your changes to the kernel as modules instead. Otherwise you will need to resize the kernel partition to account for the size difference.

Install the kernel

Now that you have a kernel you can install it as you would our stock. See the #Backup / Restore section for examples on writing this to disk.

Install Modules

Make a directory to install the modules.

mkdir newmodules
export INSTALL_MOD_PATH=newmodules 
make modules_install

Now you can copy the contents of newmodules/ to the root of the TS-4700. You may want to remove any old modules on the board in /lib/modules/* before copying them to the board to rule out any incompatibilities. Once you boot up to the board, you need to run 'depmod' once to calculate module dependencies. You can then run 'modprobe' with the device drivers you've added. For the Prolific adapter added in the example, this would be:

modprobe pl2303

Product Notes

FCC Advisory

This equipment generates, uses, and can radiate radio frequency energy and if not installed and used properly (that is, in strict accordance with the manufacturer's instructions), may cause interference to radio and television reception. It has been type tested and found to comply with the limits for a Class A digital device in accordance with the specifications in Part 15 of FCC Rules, which are designed to provide reasonable protection against such interference when operated in a commercial environment. Operation of this equipment in a residential area is likely to cause interference, in which case the owner will be required to correct the interference at his own expense.

If this equipment does cause interference, which can be determined by turning the unit on and off, the user is encouraged to try the following measures to correct the interference:

Reorient the receiving antenna. Relocate the unit with respect to the receiver. Plug the unit into a different outlet so that the unit and receiver are on different branch circuits. Ensure that mounting screws and connector attachment screws are tightly secured. Ensure that good quality, shielded, and grounded cables are used for all data communications. If necessary, the user should consult the dealer or an experienced radio/television technician for additional suggestions. The following booklets prepared by the Federal Communications Commission (FCC) may also prove helpful:

How to Identify and Resolve Radio-TV Interference Problems (Stock No. 004-000-000345-4) Interface Handbook (Stock No. 004-000-004505-7) These booklets may be purchased from the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402.

Limited Warranty

See our Terms and Conditions for more details.