TS-7400 Preliminary Manual

Documentation from February-2008

Introduction:

The TS-7400 is a small, extremely low power embedded engine designed for running Linux "out of the box".

Hardware features include:

• 200Mhz ARM9 CPU
• 32-128 MByte integrated 100Mhz SDRAM
• 32-128 MByte integrated high-speed flash with hardware ECC
• 10/100 Ethernet
• 2 USB 1.1 (12 Mb/s) Host ports
• 3 TTL serial UARTs
• SD Flash card connector
• Optional battery-backed realtime clock
• 20 general purpose in/out pins with Schmitt trigger.
• Extreme low power (350 mA @ 5V)
• FCC certification
• Flexible 40 pin expansion connector

Software features include:

• Boots Linux out-of-the-box in 1.10 seconds (to shell prompt).
• Flexible booting options (SD card, NAND flash or offboard SPI flash)
• SD card pre-installed with standard Debian Linux distribution.
• Firmware has ability to verify boot medium CRC before allowing bootup.
• Ability to boot password-locked SD cards.
• Startup Linux miniroot scripts allows flexible root and backup
filesystem selection (SD, flash, NFS, USB flash) as well as software field upgrade support.
• Linux "bootload" program allows booting of Linux kernels and
other OS' from within Linux itself.

Manufacturer (Technologic Systems) features include:

• Long-term availability and short lead-times (20 year history).
• Engineers on free technical support.
• Each board undergoes many production tests and burn-in prior to shipment.
• Board customizations available with no minimum order.
• Factory loading of customer supplied software available.
• Readily available hardware and software professional services
for hire.

Getting Started:

The TS-7400 board has Linux installed by default on onboard flash. Upon bootup, The board will boot within 1.1 seconds to a Linux prompt on UART #0 (/dev/ttyAM0). Note that the TS-7400 only has TTL uarts and to connect to the serial console with a PC's serial port you need to use the TS-9441 or external RS232 level converters. The serial port will be set to 115200 baud, 8N1, with no flow control by default. The board will also answer telnet connections to IP address 192.168.0.50.

The default fastboot shell has available several standard Linux commands accommodated by the "busybox" program. Technologic Systems has made several modifications to the busybox source code to keep bootup as fast and simple as possible. The modified source code is available to Technologic Systems customers at ftp://ftp.embeddedARM.com. Upon bootup, you should see out of your serial port:

>> TS-FLASHBOOT - built Sep 27 2006
>> Copyright (c) 2006, Technologic Systems
.
.
.
Finished booting in 1.10 seconds
Type 'tshelp' for help
$

At this point, if you type 'exit' from the serial shell, the TS-7400 will then attempt a full Debian Linux bootup from the SD card on partition #3. If the SD card is not present or the EXT2 filesystem does not pass a basic sanity test or the special file "/notrootfs" exists, a demonstration version of a miniature Linux distribution contained on the onboard flash itself is instead booted. This version of Linux contains Apache, SSH, PPP, and FTP server and many other common utilities and libraries and is identical to the distribution installed by default on the TS-7200, TS-7250, and TS-7260 line of single board computers. Other community- supported embedded Linux distributions are available. For instance, the "Buildroot" project at http://buildroot.uclibc.org/ allows one to easily build custom filesystems and cross-toolchains.

Should you wish to automatically bypass the fastboot and proceed directly into starting the SD card version of Linux, you can do so with the following command issued to the fastboot shell:

ln -sf /linuxrc-sdroot /linuxrc; save

For the onboard flash the command is:

ln -sf /linuxrc-mtdroot /linuxrc; save

For the USB flash dongle or USB hard drive:

ln -sf /linuxrc-usbroot /linuxrc; save

To get back to the fastboot shell, you can do so by placing the file "/fastboot" in the root directory of the filesystem.

The '/linuxrc' file is a shell script that is the very first thing run by the kernel on startup. Several sample startup scripts are included and can either be used directly ("ln -sf /linuxrc-XXX /linuxrc" command) or modified to include custom bootup logic. These shell scripts were designed to be as fast and simple as possible (approximately 45 lines of code) for easy customer modifications. It is anticipated that this shell script be modified from the default to implement things in the customer's product such as backup configurations, software field updates, conditional booting/verification of SD cards, etc. Technologic Systems professional services is available should you need help in implementing a specific feature.

Although it is easy to get your board into an unbootable state during development if you botch a modification, it is equally easy to use the TS-9441 to recover the default startup. To do so, place the "Boot" jumper on the TS-9441 and reset the board. In approximately 3 seconds, the board will have fastbooted to the TS-9441 flash and present a shell prompt. To recover the default initrd and linuxrc, enter the command "save", remove the Boot jumper, and reboot back to a restored to factory default TS-7400.

Software-update facility in factory configuration:

Although Technologic Systems can load the flash with customer supplied software from the factory, it is often more convenient to have a local production process for installing or updating the files and programs that make your product unique. The default software installation enables this by providing a hook to allow customer code to "hijack" the normal fast-boot bootup process. The default linuxrc (linuxrc-fastboot) will run a program "/bin/check-usb-update" in the background after bootup has completed. This program looks for a script "/tsinit" on the USB mass storage device (USB thumb-drive, or USB hard drive) connected to the bottom USB slot. If this script exists, it is then run automatically as the Linux "root" user-ID. A sample /tsinit script that copies a program "myprogram" to onboard flash, and then changes the default bootup to the SD card follows:

#!/bin/sh

ln -sf /linuxrc-sdroot /linuxrc
mount /dev/mtdblock/3 /onboardflash
cp /mnt/root/myprogram /onboardflash/bin
umount /onboardflash
save
reboot

While the "tsinit" script is run, the red LED will be on. After it is complete, the red LED will go off. A customer could mass-update many hundred TS-7400's easily by using a USB flash dongle with a custom "tsinit" and data files and applying power with the USB dongle on, wait for the LED to go off, then proceed to the next board. The "tsinit" script will begin to execute approximately 3 seconds after power-on.

Debian Linux SD card:

The typical way of doing Linux development on the TS-7400 is actually on the board itself. Since the TS-7400 CPU is a PC-class processor in everything but power consumption and performance, it has no problem running real PC-class operating systems such as Linux. By running the full version of Linux (and not scaled-down microcontroller project OS's such as ucLinux), the TS-7400 can run the entire suite of applications contained in the Debian Linux distribution including the compilers. Since almost every open source program available for Linux is contained within the Debian Linux binary distribution, one rarely has to compile the large code-bases that would otherwise have forced integrators to a complicated cross-compilation environment due to the limited RAM/Mhz of the embedded computer. All too often, open-source projects do not anticipate the possibility of cross-compilation in their build systems, leaving issues for the system integrator to resolve.

The default SD card contains compilers and everything needed for developing applications in C, C++, PERL, PHP, and SH. Java, BASIC, TCL, Python and others are available for Debian, but not installed by default. More information on using and configuring Debian Linux can be found at http://www.debian.org.

One can still use cross-compilers hosted on just about any platform if there is a specific need. Technologic systems includes binary versions of the popular Linux "crosstool" project at http://www.kegel.com/crosstool/ to allow cross-compiling on Windows/cygwin or a Linux/i386 PC on the http://www.embeddedARM.com website.

Updating/Recovering the bootloader kernel:

Although usually not necessary, customers wanting to build and install their own bootloader kernels can do so from the fastboot environment by using NFS and an internal busybox utility "mtdcp". To mount an NFS filesystem from the fastboot shell, type:

mount 192.168.0.1:/tsarm-nfsroot /mnt/root

You may have to change the server IP and server mount point to whats appropriate on your network. The default TS-7400 IP address is 192.168.0.50, but this could be changed with the command:

ifconfig eth0 <NEW_IP_ADDRESS>

Then, assuming /mnt/root/zImage is your new kernel. Issue the command:

insmod /ts7xxx_nand.o; mtdcp /mnt/root/zImage 1 0

This copies the zImage kernel binary to /dev/mtdblock/1, with appropriate handling of any potentially bad flash sectors. /dev/mtdblock/1 is the first MBR partition of the TS-7400 NAND flash chip. Do not use the 'dd' command to copy as it does not do the right thing when presented with bad NAND flash sectors.

Note that changing the default bootloader kernel should be limited to only when absolutely necessary. Instead, you should keep the known-good, factory default Linux kernel as the bootloader kernel and then use the facilities of the "bootload" Linux command to reboot into your custom kernel as described in the following section.

Booting custom kernels and OS images from within Linux:

Technologic Systems has developed a Linux application "bootload" that allows arbitrary booting of Linux and other OS kernels within Linux itself. The power-on bootloader contained in the MBR of the flash chip is not extremely flexible as it was instead designed to be very fast (1.1 second Linux bootup) and small (fits in the 443 bytes of empty space in the MBR). The "bootload" program allows one to use the full facilities of Linux to retrieve kernel files. Doing so also allows the use of standard shell scripts for the programmatic selection of appropriate kernels, Linux initrd's, and kernel command line arguments for maximum flexibility.

By default, the "linuxrc-mtdroot" sample startup script will look for a file in the YAFFS2 NAND flash filesystem named "/vmlinux.bin" and attempt to load and boot it. You can modify the kernel command line parameters or image file by changing the respective line in the startup script. By using a file in the YAFFS2 filesystem in this way for the kernel, it is possible to atomically and safely field update the kernel from, e.g., ftp with a command such as:

wget ftp://mycompany.com/newvmlnx.bin && mv newvmlnx.bin /vmlinux.bin

Command usage information follows:

Usage: bootload [OPTION] FILE

Linux to Linux bootloader - (re)boots a TS-7xxx board to another kernel, OS image, or raw executable by replacing the running Linux kernel.

General options:
-c, --cmdline=CMD Use CMD as the Linux kernel boot args
-r, --initrd=FILE Use FILE for Linux initial ramdisk
-s, --initrdsz=SZ Only read SZ bytes from the initrd file
-b, --base=ADDR Load the image at ADDR instead of 0x218000
--version Print version and copyright information
-h, --help This help

When FILE is -, reads from standard input.

Some "one-line" examples of usage:

# Boot a compressed kernel image:
bunzip -c vmlinux.bin.bz2 | bootload -

# Reboot a kernel, but pass the 1MB running ramdisk to the new kernel:
mount -o remount,ro /dev/rd/0 /
bootload -c "console=ttyAM0,115200 root=/dev/ram0" -r /dev/rd/0 \
-r 0x100000

# Boot one of 2 kernels based on the state of DIO line #7:
if dio_data_get 7; then bootload vmlinux.backup.bin; else \
bootload vmlinux.bin; fi

The bootload application requires a kernel module "bootloader.o"
to be installed using "insmod" prior to invocation. This module,
as well the the "bootload" application itself are installed on the
default onboard YAFFS2 NAND flash Linux filesystem (/dev/mtdblock/3).

Accessing internal TS-7400 registers from Linux userspace:

Linux applications run in a protected and separate environment where they can do no damage to either the kernel or other applications running simultaneously. This protected environment does not allow arbitrary manipulation of hardware registers by default. Applications may be allowed temporary access through memory space windows granted by the mmap() system call applied to the /dev/mem device node. For instance, to set up access to the GPIO registers at 0x12c00000, the following snippet of C code is provided as an example:

#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

{
int fd = open("/dev/mem", O_RDWR|O_SYNC);
char *gpioregs;

gpioregs = (char *)mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED,
fd, 0x12c00000);

gpioregs[0] = 0xff; /* data direction register set to all outputs */
gpioregs[2] = 0x12; /* output high to DIO_01 and DIO_4, all else low */
}

Some notes about the preceding code:

• Make sure to open using O_SYNC, otherwise you may get a cacheable MMU
mapping which unless you know what you're doing, probably is not what you want when dealing with hardware registers.
• mmap() must be called only on pagesize (4096 byte) boundaries and size must at least have pagesize granularity.
• mmap() of /dev/mem is only allowed for processes with UID 0 (root)
• More information on mmap() and open() system calls can be had by running "man mmap" or "man open" from most any Linux shell prompt.
• When working with char * types to registers, make sure to compile with the "-mcpu=arm9" option otherwise the wrong ARM opcodes will be used and your byte reads/writes may be turned into 32-bit reads and writes.

Default Low-level Bootup Process for the TS-7400:

The processor first runs code from the dedicated EEPROM chip containing the TS-FLASHBOOT bootup program. TS-FLASHBOOT sets up bus timing, SDRAM, and other low-level hardware initialization. It also loads sector 0 from the NAND flash chip at 0x1000 physical address. Once its loaded, it jumps (in ARM Thumb mode) to the first instruction, with register r0 containing a function pointer to a routine to read sectors from the boot media (NAND flash) and in r1 a routine to a function to print a character string to the serial port. The routines have the following C signature:

void read(unsigned int sector, unsigned char *buf, unsigned int nsectors)
void puts(unsigned char *buf)

By default, whats contained in sector 0 of the NAND flash is a DOS-style partition table at offset 446 and a 446 byte Linux-specific kernel bootloader at offset 0. This mini-bootloader contains code to parse the partition table looking for 2 partitions marked with partition ID '0xda'. It uses the start sector and size parameters of the partition table to load the first partition (Linux kernel) at offset 0x2180000 and the second partition (if it exists) at 0x1000000 (Linux initrd). If a bad sector or a sector failing an ECC check is detected, it skips to the next 16kbyte boundary and continues-- in this way, NAND chips with bad sectors remain bootable. Next, it composes up the necessary pre-boot ATAG data structures required by Linux kernels and jumps to address 0x2180000 at which point the Linux kernel takes over.

One of the first things the Linux kernel does is disable the hardware watchdog. The watchdog is armed for 8 second expiry before automatic reboot and will be constantly fed as long as the firmware or MBR Linux bootloader is reading from flash. The board will appear to constantly reboot every 8 seconds should something go wrong. The TS-7400 uses an external watchdog implemented in the CPLD instead of the CPU internal watchdog to guarantee proper reset operation in the case of a severely malfunctioning CPU. The CPU internal watchdog is also available should you choose to use it.

Changing/Updating the TS-BOOTROM:

Normally, the TS-7400 boot firmware is loaded with the TS-FLASHBOOT bootup program. This program bootstraps the CPU by loading the first 512 bytes from the NAND flash and jumping into it. This program then loads the kernel and initrd from the NAND flash. Once the kernel has booted and mounted the initrd, it can "pivot_root" and give the illusion it actually booted directly from SD, NAND, NFS, etc file systems. Should you wish to actually load the kernel and fastboot initrd from an SD card, the TS-FLASHBOOT bootup program must be replaced with TS-SDBOOT. This can be done with the "tsbootrom-update" program available from ftp://ftp.embeddedARM.com/. Usage and command line help for this command follows:

Usage: tsbootrom-update [OPTION] ...
Updates TS-BOOTROM bootup program stored on EEPROM

General options:
-n Do not actually write EEPROM
-s, --sdboot Write TS-SDBOOT bootup program
-f, --flashboot Write TS-FLASHBOOT bootup program
-u, --burninboot Write TS-BURNINBOOT bootup program
-p, --spiflashboot Write TS-SPIFLASHBOOT bootup program
-b, --blastboard Write to blast board EEPROM instead of SBC
-h, --help This help

EEPROM security block options:
-m, --mac=X Write X as ethernet MAC address
-l, --verifylen=N Checksum includes first N 512 byte sectors
-d, --device=FILE Use FILE to re-compute checksum value
-V, --verifydat=N Use N as pre-computed checksum value
-L, --lockdat=X Use X for the SD unlock data token from
previous "sdlock --set" command
-k, --verifylock Do not boot to an unlocked SD card
-c, --noconsole Disable serial console bootup messages

TS-production specific options:
-a, --alloc-mac Get MAC address from /var/ts-production/mac

TS-SDBOOT contains several features for high security. One feature is the ability to store a checksum of the SD card on the board to verify before bootup. If the checksum fails, the bootup firmware will refuse to boot the inserted SD card. Another feature is the ability to boot a password protected SD card. With this, it is possible to make an SD unreadable to any device except the TS-7400 to which it is assigned. Although not directly a function of TS-SDBOOT, an SD card can also be made permanently write-protected through a software command. The combination of these features allows product designers several options on the security of their software and of their deployed TS-7400 based devices.

The TS bootup programs will by default print a banner message on bootup to the serial port displaying its build date, etc. If you wish to use all serial ports for your application and do not wish to have a serial console, the tsbootrom-update program can be used to silence early bootstrap banner messages so as to not confuse any potential external device UART #0 may be connected to.

Other bootstrap programs are available for-pay from Technologic Systems should you need them and custom ones may be designed for volume customers. For instance, the TS-ETHBOOT bootup program may be used to completely boot Linux from the network without NAND flash or SD card installed.

SD flash card security features:

Technologic Systems provides a "sdlock" Linux command which can be used to manipulate SD card hardware-enforced password locks and set the card's permanent write-protect feature. Using a password protected SD card is a great way to ensure software security and/or to make sure your TS-7400 based product cannot be used in an unintended matter once deployed. The latest version of the "sdlock" command is available at ftp://ftp.embeddedARM.com/sdlock

Usage: sdlock [OPTION] ...
Controls SD card lock and permanent write-protect features.

General options:
-p, --password=PASS Use PASS as password
-c, --clear Remove password lock
-s, --set Set password lock
-u, --unlock Unlock temporarily
-e, --erase Erase entire device (clears password)
-w, --wprot Enable permanent write protect
-h, --help This help

When the TS-7400 is configured with the TS-SDBOOT bootup firmware, the SD unlock password can be stored in onboard EEPROM for automatic unlocking and booting of password protected SD cards. By default, TS-SDBOOT will still boot unlocked cards, but this behavior can be changed with the "--verifylock" option to the "tsbootrom-update" command described above-- with the "--verifylock" option the TS-7400 will only boot locked SD cards.

TS-SDBOOT can also verify an arbitrary number of sectors of the SD flash card before allowing bootup. If the stored CRC does not match the actual CRC, the board will refuse to boot and blink the red LED continuously.

The various SD commands that manipulate the password lock are marked as "optional" in the SD card specification. This means that not all SD card vendors may implement them in their devices. If they are not implemented, you will not be able to set the SD lock with the "sdlock" command.

TS-7400 specific Linux devices:

Although working with the TS-7400 Linux is identical in most ways to working with a PC version Linux, one does need to be aware of some driver differences.

• The serial ports device nodes are /dev/ttyAM0, /dev/ttyAM1, and /dev/ttyTS0, respectively. The default PC uses /dev/ttyS* as device names. The software API to these devices is the same as on the PC.
• The onboard flash is broken up into partitions and accessed through the Linux driver framework known as "MTD", or (M)emory (T)echnology (D)evice. The partitioning is dynamic and depends on the DOS-style MBR found at sector 0 of the flash. This MBR can be changed by using the "fdisk" command on the /dev/mtdblock/0 device, but doing so is not recommended.

/dev/mtdblock/0 - Whole disk block device driver.
/dev/mtdblock/1 - First MBR partition (bootloader kernel binary)
/dev/mtdblock/2 - Second MBR partition (bootloader initrd)
/dev/mtdblock/3 - Third MBR partition (Linux YAFFS2 filesystem)
/dev/mtdblock/4 - 4th MBR partition (unused in default load)

Note that the MBR installed by default on the TS-7400 contains a 443 byte bootloader program that loads the initial power-on kernel and initrd from the first and second partitions. Replacing it with a MBR found on a PC would not work as a PC MBR contains an x86 code bootup program. Doing so would cause the device to constantly reset itself every 8 seconds as the hardware watchdog expires.

• Linux uses a NAND flash filesystem called YAFFS2 for general
  purpose file storage. This filesystem is a log-structured filesystem
  which is safe against corruption caused by system crashes and
  power loss without the need for consistency checking on next boot.
  A normal PC cannot use this filesystem as it is specifically designed
  for NAND flash which a PC does not have.
• The TS version of Linux uses a special device driver at
  /dev/misc/bootloader to accommodate the hooks needed by the "bootload"
  program to allow Linux to act as a bootloader and boot other
  Linux kernels and operating systems

Where to go for additional help:

Technologic Systems makes available several engineers to provide free technical support regarding the TS-7400 hardware. To request support, email to support@embeddedARM.com or call 480-837-5200. For general Linux questions not specific to the TS-7400 (such as, "How to configure the Apache web server"), you may be referred to the TS professional services group, which is well equipped to research just about any level of question from kernel development to web server configuration.

Since Linux is open-source, support may also be received from the individual development communities throughout the internet. Several projects have internet posted FAQs, HOWTOs, and community supported mailing lists providing users of their authored programs free help. There is also a general web based forum for Technologic Systems customers containing discussions, sample code, and several years of searchable questions and answers on the TS-7000 series of products at http://groups.yahoo.com/group/ts-7000.

TS-7400 production lifetime:

The TS-7400, as shipped by default from Technologic Systems will never be altered significantly from its originally introduced state. By the same token, the board also has an intended infinite production lifetime, meaning Technologic Systems will build and sell TS-7400's in as low as single piece quantities as long as its constituent parts are readily available. This typically means a production lifetime of 10-15 years. A stable hardware platform and default install keeps unexpected surprises from cropping up down the road when products must be retested or redesigned because of manufacturer introduced hardware/software design changes or obsolescence.

The 802.11g card for the TS-7400 is not manufactured by Technologic Systems. 802.11 wireless ethernet is tightly coupled to the consumer electronics and desktop computer industries and as such products tend to be more transient (though also less expensive). Often times manufacturers change chipsets or discontinue products with little or no notice. Although usually there are many alternatives and Technologic Systems can seamlessly transition to a new supplier, TS-7400 integrators should be aware of the possibility of different 802.11 type devices being used on the default product in the future.

Hardware/Software Customization:

Should your embedded project approach quantities between 500-1000 boards per year, it may be a good time to talk to TS engineer about specific hardware or software customizations that become available to you. There may be modifications we can do to reduce cost or add specific features to directly accommodate your specific requirements. Several options are available:

1. TS can load your software directly onto the boards you order. Often times this can save you from creating your own production and software loading process. This type of service is available no matter the quantity.
2. CPLD's/FPGA's can be reprogrammed to include specific customer-specified functionality. For instance, a magic register your software can verify before enabling certain features of your product or extra serial ports in the CPLD.
3. Simple daughter-boards can be designed. Often, a low-cost 2-layer companion board can be created to add functionality to the board without actually changing the more expensive multi-layer TS-7400 circuit board.
4. The TS-7400 board can be given new features and/or physical dimensions. This is the most expensive, but most powerful form of customization. Often times, TS may subsidize the development costs of a new board if it has general appeal to our broader customer base. Much of our COTS product line (including the TS-7400 itself) was a joint development between TS and another company. Allowing TS to generally market a design is a great way to achieve economies of scale (thereby reducing per-unit cost) and to ensure stock and commercial-off-the-shelf (COTS) status for your custom board.

Interfaces:

Besides the 10/100 ethernet jack, SD card socket, and USB host
ports, the TS-7400 also includes a .1" pin spacing external header
for board-to-board interfacing. The TS-7400 external interface
uses a total of 66 pins which are broken up between a 40 pin lower
header (closest to board edge) and a 26 pin upper header. Pin
numbering is arranged as follows:

Upper header:

Lower header:

The combination of these two headers provides the following functionality:

• High speed dedicated (Up to 14.7Mhz) SPI bus
• USB 2.0 full-speed (12 Mb/s) port
• 3 TTL-level serial UART ports (1 with tx-enable output for RS485)
• Simple 8-bit multiplexed general purpose parallel bus with 14.7Mhz clock, IRQ and DMA support and capable of 10Mbyte/sec operation.
• 20 bidirectional schmitt-trigger GPIO pins
• 1.8V, 3.3V, and 5V power supply pins (5V power can optionally be input to the TS-7400 through this connector)
• 4 12-bit 0-3.3V analog input (ADC) pins
• I2S/AC97 audio codec interface
• external reset input
• low-level bootup hijack facility to recover dead boards. (Used in TS-9441 production blast/test/recovery boards

Upper header pin table:

Lower header pin table:

TS-7400 specific registers:

0x1200_0000: TS-7400 control register
bit 0 - if set, enables UART #0 on DIO_18 and DIO_19 pins
bit 1 - if set, enables IRQ on DIO_11 pin
bit 2 - if set, enables DRQ on DIO_12 pin
bit 3 - if set, enables 14.7456Mhz clock on DIO_12 pin
bit 7:4 - reserved

0x1200_0001: GPIO direction/data for DIO_16 to DIO_19
bit 3:0 - data register
bit 7:4 - data direction register ('1' means 'output')

0x12c0_0000: GPIO direction for DIO_0 to DIO_7 ('1' means output)
0x12c0_0001: GPIO direction for DIO_8 to DIO_15 ('1' means output)
0x12c0_0002: GPIO data register for DIO_0 to DIO_7/GPBUS address register
0x12c0_0003: GPIO data register for DIO_8 to DIO_15

0x1240_0000: UART #2 (/dev/ttyTS0 in Linux) STAT register
bit 0 - TBRE, Transmit buffer empty (RO)
bit 1 - DR, Receive data ready (RO)
bit 2 - OERR, Overflow error (RO)
bit 4:3 - reserved
bit 7:5 - MODE, baud rate (RW)
0 - 115200 8N1
1 - 57600 8N1
2 - 38400 8N1
3 - 19200 8N1
4 - 9600 8N1
5 - 4800 8N1
6 - 2400 8N1
7 - UART off, IRQ disabled
0x1240_0001: UART #2 (/dev/ttyTS0 in Linux) DAT register

0x1300_0000-0x1300_0003: SD card controller (/dev/sdcard0/disc0 in Linux)

0x2380_0000: Watchdog timeout register (normally locked, must feed watchdog
before changing)
bit 3:0 - timeout value
0 - watchdog disabled
1 - armed for 250 millisecond expiry
2-6 - reserved
7 - armed for 8 second expiry
bit 7:4 - reserved

0x23c0_0000: Watchdog feed - write any value to feed watchdog/unlock
timeout reg

0x2340_0000: TS-CPLD revision register
bit 2:0 - CPLD revision number
bit 7:3 - reserved

0x2200_0000: TS-Model register
bit 2:0 - returns id '4' to identify TS-7400
bit 7:3 - reserved

0x2300_0000: SPI EEPROM chipselect control
bit 0 - reserved
bit 1 - onboard SPI EEPROM chip-select enable
bit 2 - offboard (boot hijacker) SPI EEPROM chip-select
bit 7:3 - reserved

0x6000_0000: NAND flash data register

0x6040_0000: NAND flash control register
bit 0 - ALE signal
bit 1 - CLE signal
bit 2 - CS signal
bit 4:3 - reserved
bit 5 - flash busy signal
bit 7:6 - reserved
0x6040_0001: ECC bits 7-0
0x6040_0002: ECC bits 15-8
0x6040_0003: ECC bits 21-16, read/write of this register resets ECC bits
bit 5:0 - ECC bits 21-16
bit 7:6 - reserved
* ECC is fed by read or write data to the flash data register at 0x6000_0000

0x62c0_0002: GPBUS address register (write only)

0x60c0_0000: GPBUS data register (read/write of this register initiates
GPBUS bus cycle)
0x60c0_0002: GPBUS data register with address auto-increment (read/write
of this register initiates GPBUS bus cycle with automatic increment
of 8-bit address register at 0x12c0_0002)

Using the general purpose IO pins (GPIO):

There are 20 individually configurable GPIO pins available on the TS-7400. Each of these pins can be configured as a floating input (high impedance, no internal pull-up/pull-down) or as an output driving a 0 or 1 logic signal. When configured as an input, the voltage thresholds are nominally at standard 3.3V LVCMOS levels, but with 400 mV of hysteresis (Schmitt triggers) for better noise immunity with slow slew signals. As an output, GPIO pins can drive 8mA while still presenting valid LVCMOS thresholds as measured at the output pin. More current can be sourced/sunk from output pins (2-3x more is typically safe) but the resulting output voltage will no longer be within LVCMOS thresholds-- e.g. attempting to source 30 mA out of a pin set to logic '1' will result in voltage of 1.0V instead of the nominal 3.3V.

The 20 GPIO pins are NOT 5V tolerant. This means if you drive any GPIO pin configured as input to above 3.3V, you may cause permanent damage to the device. A common workaround for 5V tolerance is to use external Schottky diode clamps with series current limiting resistors. A better workaround is to use LVC245 or equivalent buffer chips. With diode clamps or external buffers guaranteeing 5V tolerance on input pins, one can safely interface to 5V TTL logic devices since in every other way 3.3V LVCMOS is compatible with 5V TTL logic. Note that 5V CMOS is NOT compatible with 3.3V LVCMOS as the logic '1' threshold for 5V CMOS is 3.5V. Since this is 0.2V above the 3.3V the TS-7400 is capable of, reliable operation cannot be guaranteed although the interfacing may actually seem to work some of the time.

Some GPIO pins have dual functionality. This includes the pins used for the GPBUS and the serial UART. GPBUS is a simple 8-bit multiplexed address/data bus and is described below. The serial UART on pins DIO_15, DIO_16, and DIO_17 are available for GPIO manipulation when the UART baud rate is set to '0' (disabled). If the UART is configured for operation with a non-zero baud rate, the GPIO pins are taken over by the UART core.

Using the GPIO pins in Linux involves getting access to the GPIO data direction register and data register (listed above). In general userspace applications, this involves opening the "/dev/mem" driver and using the mmap() system call to acquire a memory window where direct pointer manipulation of the hardware registers can occur. One may also write a kernel driver and interface to user applications through a defined API. Because it is difficult to anticipate the needs for a kernel driver API and the performance implications involved in even the simplest of userspace to kernelspace API's, Technologic Systems does not provide such a driver. Moving GPIO logic to the kernel may still be preferable if the bulk of GPIO client code is in the kernel or if there are strict real-time requirements to be met.

Using the general purpose 8-bit multiplexed bus (GPBUS):

To use the general purpose bus, GPIO pins 7-0 first MUST be programmed as general purpose outputs by writing an 0xff to 0x12c0_0000. Also, GPIO pins 8-10 must also be programmed as outputs if all 3 strobes will be used (ALE, RD, and WR). A strobe pin set up as a GPIO input will not be toggled at the appropriate times during a GPBUS bus cycle-- this can save GPIO pins in the case of a read-only or write-only bus, but is probably not what you want. GPIO #8 is the ALE, #9 is RD, and #10 is WR. The typical usage of ALE is an active high signal representing the period of time during which the address/data bus is driving the address. The read and write strobes are typically active low and signified as RD# and WR#. The polarity of each strobe is programmed by the contents of the GPIO data register for pins 8, 9, and 10. Knowing the data register bit locations of ALE, RD, and WR, you should then program them to default output ALE asserted with RD and WR deasserted. In the case of ALE active high, WR/RD active low, the value written to bits 2-0 at 0x12c0_0003 should be 7 (binary 111). For the purposes of the timing diagrams below, we will assume this configuration.

The default timing of the GPBUS cycle uses a 55 nS read/write pulse when reading/writing the data register at 0x60c0_0000. This is with the EP9302 bus cycles programmed for 60nS operation. (EP93xx SMCBCR6 register value 0x34c2). Although you may not change this value since the NAND flash chip is on the same EP93xx chip select, you may change the SMCBCR7 register for slower or faster operation and use the data register alias at 0x70c0_0000. The GPBUS waveform for 0x60c0_0000 accesses looks like this:

#1 - address hold - 13nS
#2 - address to data transition time - 6nS
#3 - RD# or WR# pulse - 55nS
#4 - data hold, RD#/WR# deassert to ALE assert - 6nS

The above timing should be compatible with a standard 74HC373 octal latch chip should you wish to de-multiplex the address/data bus into something more similar to ISA/PC104 externally. If you have questions about whether a particular design will work or not, please feel free to contact Technologic Systems with your schematic for review.

For fast back-to-back accesses to consecutive addresses, you should use the the data register at 0x60c0_0002. This is very useful for reading contiguous memory quickly without having to interleave updates to the address register. Although there is only an 8-bit address register, it is trivial to use other free GPIO lines as high address lines should you need more than 256 bytes of address space for the GPBUS.

Should you require it, a 14.7456Mhz clock can be output from the TS-7400 on DIO_12. To enable this, set bit 3 of the 8-bit register at address 0x12000000 and set the data direction for DIO_12 as output. External IRQ is also available on DIO_11 by similarly setting bit 1. One can also enable DMA with the EP9302 CPU M2M DMA controller by allowing DRQ on DIO_12 (bit 2).

If you choose to use DMA or IRQ support for the GPBUS, you will likely want to write a kernel driver. Simple userspace applications can not directly set up interrupt handler functions or translate the virtual addresses of process data structures to the physical addresses needed by the DMA controller. When writing a kernel driver in C, one should be aware of certain details:

• To set a handler on the GPBUS IRQ, you must request IRQ #33 and allow IRQ sharing (the UART and SD drivers also generate the same IRQ). This means calling the request_irq() kernel function with SA_SHIRQ in the 'flags' parameter.
• To use DMA, you must manipulate the M2M1 EP9302 DMA channel. Details on its programming can be found in the EP9301 CPU User Manual from Cirrus Logic at http://www.cirrus.com
• To access various registers in arbitrary physical address space, use the __ioremap() function and not the ioremap() kernel function. ioremap() does not expect physical addresses and will apply an offset to your requested address on the EP9302 ARM Linux kernel.
• If you are unable to write a driver yourself, you may consider contracting Technologic Systems to write one for you. Often times, TS engineers can accommodate your requirements for less cost than it takes to accomplish internally.

Errata:

Rev 1 -> Rev 2: Production changed to produce Rev 2 TS-7400s on 1/11/2007

• CPLD revision 1 failed to decode GPBUS address register alias at 0x62c00002.
• GPBUS timing changed to delay reassertion of ALE after data cycle by an extra 4ns

Document History:

10/06/2006 - Initial release - joff
10/23/2006 - Added sections on SD locking, security features, and GPIO - joff
10/24/2006 - Added mention of "/fastboot" file autoboot abort - joff
01/11/2007 - Errata for Rev B CPLD
05/18/2007 - Modified UART naming convention for consistency - EWD
07/03/2007 - Fixed GPBUS clock output pin typo - EWD