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. 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 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. 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-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 set the linuxrc 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
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.
| 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
| 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/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.
Backup
Entire Image
# Compressed
dd if=/dev/nbd0 bs=131072 count=2048 | bzip2 > backup.dd.bz2
# or uncompressed
dd if=/dev/nbd0 bs=131072 count=2048 of=backup.dd
Kernel
dd if=/dev/nbd1 bs=512 count=5119 of=/path/to/backup/zImage
Initrd
dd if=/dev/nbd2 bs=512 count=5120 of=/path/to/backup/initrd
Restore
Entire Image
# Compressed
bzcat 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/nbd1 bs=512 count=5119 if=/path/to/backup/zImage
Initrd
dd of=/dev/nbd2 bs=512 count=5120 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.
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 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.
Offboard SD Card Interface
The SD card pins that are run to the Socket header are in parallel with the pins used by the on-board microSD card. This allows end products to use either socket, however both cannot be used at the same time.
LCD Interface
This interface presents a standard 24 bit LCD video output.
Touchscreen Backlight Control
A PWM signal on this line is used to control the brightness of the LCD backlight. In the ts4700.subr file we implement several commands for controlling this backlight.
backlight_on() backlight_off() backlight_low() backlight_medium() backlight_high()
See #CPU DIO for more information on MFP_85 and the CPU GPIO.
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. |
CPU DIO
The CPU DIO can be used as general purpose IO, or many of them provide alternative functionality as well.
| WARNING: | CPU DIO pins are 3.3v tolerant, driving them above 3.3v can cause irreparable damage. |
| DIO | Function |
|---|---|
| MFP_43 | GPIO_43 |
| MFP_49 | GPIO_49 |
| MFP_51 | GPIO_51 |
| MFP_52 | GPIO_52 |
| MFP_84 | GPIO_84 or PWM2 or One Wire Interface |
| MFP_85 | GPIO_85 or PWM1 |
| 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 |
One Wire Interface
The PXA166 brings out a 1 wire interface.
PWM
Some of these DIO can be used to control PWM. We implement this for control of the backlight.
I2C
todo
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.
I2S Audio
These pins can be connected to an I2S CODEC for an audio output channel.
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.
FPGA Functionality
While most common functionality for the TS-4700 is accessed through layers of software that are already written, some features may require talking directly to the FPGA. The TS-4700 provides access to the FPGA in an 8 bit region and a 16 bit region. The 8 bit base address is 0x81000000. The 16 bit base address is 0x80000000. All registers inside the TS-4700 FPGA are 16 bit registers and should be accessed via the 16 bit space. The 8 bit space is only needed for off-board 8 bit devices on the MUXBUS. To access hardware cores in the FPGA, add the offset in the table below to the base address.
| Offset | Usage |
|---|---|
| 0x0000 | 16KB blockram access (for XUART buffer) |
| 0x4000 | Syscon registers |
| 0x4400 | ADC registers (for off-board ADC) |
| 0x4800 | SPI interface |
| 0x4C00 | CAN controller interface |
| 0x4D00 | 2nd CAN controller (not implemented) |
| 0x5000 | Touchscreen registers |
| 0x5400 | XUART IO registers |
| 0x8000 | 32KB MUXBUS space |
Syscon
The registers listed below are all 16 bit registers and must be accessed with 16 bit reads and writes. This register block appears at base address 0x80004000.
| Offset | Bits | Usage |
|---|---|---|
| 0x00 | 15:0 | Model ID: Reads 0x4700 |
| 0x02 | 15 | Reset switch enable (Use DIO 9 input) |
| 14 | Enable touchscreen (override DIO 30-35) | |
| 13 | Enable UART4 TXEN (override DIO 14) | |
| 12 | Enable UART0 TXEN (override DIO 12) | |
| 11 | Enable 12.5MHz base board clock (override DIO 3) | |
| 10 | Enable SPI (override DIO 17-20) | |
| 9 | Enable 2nd CAN (override DIO 10,11) | |
| 8 | Enable CAN (override DIO 15,16) | |
| 7:6 | Scratch Register (used by bootrom) | |
| 5:4 | Mode2, Mode1 | |
| 3:0 | FPGA revision | |
| 0x04 | 15:0 | External bus config register |
| 0x06 | 15:0 | Watchdog feed register |
| 0x08 | 15:0 | Free running 1MHz counter LSB |
| 0x0a | 15:0 | Free running 1MHz counter MSB |
| 0x0c | 15:0 | Hardware RNG LSB |
| 0x0e | 15:0 | Hardware RNG MSB |
| 0x10 | 15 | Reserved |
| 14:0 | DIO group 1 output data | |
| 0x12 | 15:13 | Reserved |
| 12 | Red LED (1 = on) | |
| 11 | Green LED (1 = on) | |
| 10:0 | DIO group 2 output data | |
| 0x14 | 15:0 | DIO group 3 output data |
| 0x16 | 15 | Enable UART2 TXEN (override DIO 10) |
| 14 | Enable UART1 TXEN (override DIO 8) | |
| 13 | Enable UART5 TXEN (override DIO 7) | |
| 12 | Enable UART3 TXEN (override DIO 13) | |
| 11:0 | DIO group 4 output data | |
| 0x18 | 15 | Reserved |
| 14:0 | DIO group 1 data direction | |
| 0x1a | 15:11 | Reserved |
| 10:0 | DIO group 2 data direction | |
| 0x1c | 15:0 | DIO group 3 data direction |
| 0x1e | 15:12 | Reserved |
| 11:0 | DIO group 4 data direction | |
| 0x20 | 15 | Reserved |
| 14:0 | DIO group 1 input data | |
| 0x22 | 15:11 | Reserved |
| 10:0 | DIO group 2 input data | |
| 0x24 | 15:0 | DIO group 3 input data |
| 0x26 | 15:12 | Reserved |
| 11:0 | DIO group 4 input data | |
| 0x28 | 15:4 | Reserved |
| 3:0 | TAG memory access | |
| 0x2a | 15:0 | Custom load ID register (reads 0 on standard load) |
| 0x2c | 15:6 | Reserved for future IRQs |
| 5 | Offboard IRQ 7 | |
| 4 | Offboard IRQ 6 | |
| 3 | Offboard IRQ 5 | |
| 2 | CAN2 IRQ | |
| 1 | CAN IRQ | |
| 0 | XUART IRQ | |
| 0x2e | 15:0 | IRQ mask register: 1 disables the corresponding IRQ. |
| 0x30 | 15:0 | Edge Counter 0 |
| 0x32 | 15:0 | Edge Counter 1 |
Watchdog
The watchdog is manipulated via the ts4700ctl utility. The default INITRD linuxrc autofeeds the watchdog by daemonizing and feeding it in the background via userspace. It can be armed in 3 modes (0 - .4s, 1- 2.7s, 2 - 10.8s). It can be either auto-fed from a background process that continually feeds the watchdog while running (--autofeed option), or via a /dev/watchdog UNIX named pipe which receives single ASCII characters which are written to feed it from another application.
| Value | Result |
|---|---|
| 0 | feed watchdog for another .338s |
| 1 | feed watchdog for another 2.706s |
| 2 | feed watchdog for another 10.824s |
| 3 | disable watchdog |
Watchdog by default comes out of reset armed for .338 seconds. TS-BOOTROM firmware feeds for 10.824 and OS code has 10.824 seconds to take over.
You can feed the watchdog from your application by poking a register:
#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/mman.h>
int main()
{
int mem;
uint16_t *syscon;
mem = open("/dev/mem", O_RDWR|O_SYNC);
syscon = mmap(0,
getpagesize(),
PROT_READ|PROT_WRITE,
MAP_SHARED,
mem,
0x80004000);
for(;;) {
// This feeds the watchdog for 10s.
syscon[0x6/sizeof(syscon)] = 2;
sleep(5);
}
return 0;
}
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.
| WARNING: | FPGA DIO pins are 3.3v tolerant, driving them above 3.3v can cause irreparable damage. |
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.
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.
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 |
LED
All standard base boards connect these lines to LEDs for basic user feedback.
XUARTS
The xuarts can be managed with xuartctl. See the xuartctl page for more details.
Connectors
EN_LCD_3.3V
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.
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.
CPU Voltage Testing
CPU core voltages are provided for troubleshooting purposes only. On most base boards these should not be connected.
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
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
Script to make directory and install modules
./build-module-bundles.sh
The build-module-bundles.sh script is meant to be run as a user (not root) and will create directories and install modules to them. The directory structure is created at /home/`whoami`/src/ts-4700/dist/<ts4700 kernel release number>/modules-install/. In that directory is initrd-modules/, lib/, and modules-<ts4700 kernel release number>.tgz.
initrd-modules/modules.tar.gz is a tarball that contains a minimal number of modules. This tarball needs to be copied to the initrd partition of the boot media. The boot process of the board will automatically un'tar this and insert any necessary modules.
Now the contents of lib/ can be copied to the root of the TS-4700. It is also possible to copy over modules-<ts4700 kernel release number>.tgz to the TS-4700 and unpack it in the root linux directory. 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.