From Technologic Systems Manuals
Jump to: navigation, search
Note: The TS-4100 is currently under development. This means software and features are very likely to change on the TS-4100. There may also be some features that are currently not implemented or not fully tested, please see the Revisions and changes for more information.


TS-4100
ts-4100.gif
Product Page
Product Images
Specifications
Documentation
REV A Schematic
Mechanical Drawing
FTP Path
Processor
Freescale i.MX6ul 528MHz or 696MHz
i.MX6ul Product Page
CPU Documentation

Contents

1 Overview

The TS-4100 is a TS-SOCKET Macrocontroller Computer on Module designed for low power applications. It is based around an NXP i.MX6UL 696 MHz CPU with 512 MB or 1GB DDR3 RAM. The TS-4100 can be ordered with soldered down WiFi which includes built in Bluetooth 4.0LE. There is also support for USB Gadget via a micro USB AB OTG connector and eMMC flash for a robust soldered down flash solution.

The TS-4100 can run standalone, powered via the micro USB AB connector. This allows for a small, low power device with built in Wi-Fi and 4.0LE interfaces and a combination of soldered down flash as well as support for microSD cards. Additionally, the same micro USB AB connector for power is also an OTG port, allowing for USB ethernet or other gadget connections to be made to the device.

In addition to running standalone, the TS-4100 is primarily intended to be seated on a CoM baseboard in order to add additional functionality. See the TS-4100 product page for a complete list of compatible baseboards and links to their manuals. Compatible baseboards have schematics available to aid in development of custom solutions.

2 Getting Started

A Linux PC is recommended for development, and will be assumed for this documentation. For users in Windows or OSX we recommend virtualizing a Linux PC. Most of our platforms run Debian and if there is no personal distribution preference this is what we recommend for ease of use.

Virtualization

Suggested Linux Distributions

It may be possible to develop using a Windows or OSX system, but this is not supported. Development will include accessing drives formatted for Linux and often Linux based tools.

2.1 Booting up the board

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.

If using our off-the-shelf baseboards, please refer to that baseboard's manual here. Different baseboards use different power connectors, voltage ranges, and may have different power requirements.

Power input to the TS-4100 TS-SOCKET requires a single 5 V source from the baseboard (which may be regulated from other voltage ranges). Refer to the TS-SOCKET Connector section for information on power pins.

The unit can also be powered standalone from 5 V via the micro USB AB port labeled "P1" when in standalone and not attached to a baseboard. This connector is mechanically locked out on many of our baseboards to prevent powering the device from multiple sources.

Once power is applied to the whole device, there will be output on the debug console port. The following section of the manual provides information on getting the serial console connected. The first output is from U-Boot and will resemble the following when booting from SD card:

U-Boot 2016.03-00367-gb3ce405827 (Jul 02 2019 - 16:40:10 -0700)

CPU:   Freescale i.MX6UL rev1.1 at 396 MHz
Reset cause: POR
Board: Technologic Systems TS-4100
FPGA:  Rev 11
Silab: Rev 2
I2C:   ready
DRAM:  1 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Baseboard ID: 0x8
Baseboard Rev: 0
Net:   FEC0 [PRIME]
Press Ctrl+C to abort autoboot in 1 second(s)
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
No storage devices, perhaps not 'usb start'ed..?
Booting from the SD card ...
** File not found /boot/boot.scr **
** File not found /boot/ts4100-fpga.vme **
29205 bytes read in 146 ms (195.3 KiB/s)
8 detected
5244088 bytes read in 390 ms (12.8 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x5004b8 ]
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 83000000, end 8300a214

Starting kernel ...
Note: The "*** Warning - bad CRC, using default environment" message can be safely ignored when the unit is first booted. This means that no environment variables have been saved to disk, and U-Boot is falling back to the default. If "env save" is run, this will save the environment to disk, and this message will go away unless there is a further issue.


The default U-Boot boot process will check for USB updates, and then will check the "SD Boot" jumper state if it exists. If the "SD boot" jumper is set, it will boot to the Linux on the SD card, otherwise it will boot to the eMMC. Details about the bootup process, features, and other U-Boot information can be found in the U-Boot sections.

2.2 Get a Console

The TS-4100 offers two options for interfacing with the console UART. A TTL interface present on the TS-SOCKET headers, or a direct USB serial interface via the micro USB B port labeled "P2". This USB serial interface is provided by the on-board supervisory microcontroller which behaves as a USB serial device. Either port can safely be used without causing any issues or data corruption; the RX path to the CPU is gated to prevent drive conflicts on either source.

The USB serial device is CP210x compatible. This means most operating systems will support it out of the box. However, if not, drivers are available directly from Silicon Labs.

Note that due to the placement of the micro USB B connector on the TS-4100, the USB serial interface may not be viable for all applications. Some cable types may not fit in the available space when the TS-4100 is paired with our compatible baseboards.

The TTL interface is present on pins CN2_93 (TX) and CN2_95 (RX). They are 3.3 V logic level and must not exceed that voltage. On many of our compatible baseboards, this interface is run through an RS-232 transceiver and is broken out to a DB-9 connector. See the TS-4100 product page for a list of compatible baseboards as well as their manuals to see how they allow access to this console UART.

In both cases, the UART runs at 115200 baud, 8n1 (8 data bits, no parity, 1 stop bit), with no flow control at all.


Console from Linux

There are many serial terminal applications for Linux, three common used applications are 'picocom', 'screen', and 'minicom'. These examples demonstrate all three applications and assume that the serial device is "/dev/ttyUSB0" which is common for USB adapters. Be sure to replace the serial device string with that of the device on your workstation.

'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 but requires some setup:

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.

Device Manager Putty Configuration


3 U-Boot

Note: This section is incomplete at this time.

This platform includes U-Boot as the bootloader to load and boot the full operating system. The i.MX6UL processor loads U-Boot from the eMMC flash at power-on. U-Boot allows booting images from the microSD, eMMC, NFS, or USB. U-Boot is a general purpose bootloader that is capable of booting into common Linux distributions, Android, QNX, or others.

On a normal boot, output from U-Boot will be similar to the following:

U-Boot 2016.03-00367-gb3ce405827 (Jul 02 2019 - 16:40:10 -0700)

CPU:   Freescale i.MX6UL rev1.1 at 396 MHz
Reset cause: POR
Board: Technologic Systems TS-4100
FPGA:  Rev 11
Silab: Rev 2
I2C:   ready
DRAM:  1 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Baseboard ID: 0x8
Baseboard Rev: 0
Net:   FEC0 [PRIME]
Press Ctrl+C to abort autoboot in 1 second(s)
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
No storage devices, perhaps not 'usb start'ed..?
Booting from the SD card ...
** File not found /boot/boot.scr **
** File not found /boot/ts4100-fpga.vme **
29205 bytes read in 146 ms (195.3 KiB/s)
8 detected
5244088 bytes read in 390 ms (12.8 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x5004b8 ]
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 83000000, end 8300a214

Starting kernel ...

When running standalone, the TS-4100 will default to booting from eMMC. This behavior can be changed by modifying the U-Boot environment variable "force_jpsdboot". Normally this variable does not exist in the U-Boot environment, if it does exist, setting it to a value of 1 will force U-Boot to attempt to boot from microSD. If it is set to a value of 0, then U-Boot will attempt to boot from eMMC. Additionally, running U-Boot commands are used direct booting to another source such as NFS, USB, or microSD.

Many of our compatible baseboards offer an "SD Boot" jumper to control the behavior between SD and eMMC. See the specific baseboard manual for the combination being used for more detailed information. If designing a custom baseboard, we recommend reviewing our custom baseboard design recommendations for better controlling boot flow with U-Boot.


3.1 Entering U-Boot Shell

The U-Boot shell is a powerful tool. It allows modification of the environment, as well as the ability to run commands directly.

When the TS-4100 is booted standalone, a prompt is provided by U-Boot to press "ctrl+c" followed by a 1 second window. If "ctrl+c" is found incoming on the serial terminal within this time window then U-Boot will drop to its shell. This behavior can be modified by setting the U-Boot environment variable "force_bootdelay". Normally this variable does not exist in U-Boot environment, if it does, it will force the timeout for pressing "ctrl+c" to be however many seconds the variable is set to. If it is set to 0, then the "ctrl+c" prompt is skipped.

Note: Use caution when setting "force_bootdelay", a value of 0 means it is no longer possible to enter the U-Boot shell without booting the device on a compatible baseboard that has a "U-Boot" jumper!


On our compatible baseboards or custom designed baseboards there are two ways to break in to the U-Boot shell. Note that some compatible baseboards may still offer a prompt as outlined above. See the specific baseboard manual for the combination being used for more detailed information.


The baseboard has a "U-Boot" jumper. When set, this will cause U-Boot to read a script file from an attached USB mass storage device before dropping to the U-Boot shell. When the jumper is not set, the unit will boot as normal. See our custom baseboard design recommendations for information on how the U-Boot jumper should be set up in order to be supported by our default U-Boot configuration.


The baseboard offers a push switch. This button can be held down before applying power, and at least 5 seconds after power is applied. Doing do will cause U-Boot to read a script file from an attached USB mass storage device before dropping to the U-Boot shell.

This allows for out of the box functionality and customized production via a USB drive. In order to provide increased security, the push switch entry to U-Boot can be disabled via the U-Boot environment variable "rstuboot". The following U-Boot commands can be used to disable the push switch check, thereby preventing it from entering the U-Boot shell.

env set rstuboot 0
env save

Removing the U-Boot environment variable, or setting it to a 1, will re-enable the ability for the push switch to interrupt U-Boot and drop to its shell. See our custom baseboard design recommendations for information on how the push switch should be set up in order to be supported by our default U-Boot configuration.


On baseboards that support both a jumper and the push switch, disabling the push switch will still allow the jumper method of entering the U-Boot shell.


3.2 U-Boot Environment

The eMMC flash contains both the U-Boot executable binary and U-Boot environment. Our default build has 2 MiB of environment space which can be used for variables and boot scripts. The following commands are examples of how to manipulate the U-Boot environment:

# Print all environment variables
env print -a
 
# Sets the variable bootdelay to 5 seconds
env set bootdelay 5;
 
# Variables can also contain commands
env set hellocmd 'led red on; echo Hello world; led green on;'
 
# Execute commands saved in a variable
env run hellocmd;
 
# Commit environment changes to the SPI flash
# Otherwise changes are lost
env save
 
# Restore environment to default
env default -a
 
# Remove a variable
env delete emmcboot


3.3 U-Boot Commands

# The most important command is 
help
# This can also be used to see more information on a specific command
help i2c
 
# This is a command added to U-Boot by TS to read the baseboard ID on our 
# Computer on Module devices
bbdetect
echo ${baseboard} ${baseboardid} 
# The echo will return something similar to:
# TS-8390 2
 
# Boots into the binary at $loadaddr.  The loaded file needs to have
# the U-Boot header from mkimage.  A uImage already contains this.
bootm
# Boots into the binary at $loadaddr, skips the initrd, specifies
# the FDT addrress so Linux knows where to find the device tree
bootm ${loadaddr} - ${fdtaddr}
 
# Boot a Linux zImage loaded at $loadaddr
bootz
# Boot in to a Linux zImage at $loadaddr, skip initrd, specifies
# the FDT address to Linux knows where to find the device tree
bootz ${loadaddr} - ${fdtaddr}
 
# Get a DHCP address
dhcp
# This sets ${ipaddr}, ${dnsip}, ${gatewayip}, ${netmask}
# and ${ip_dyn} which can be used to check if the dhcp was successful
 
# These commands are used for scripting:
false # do nothing, unsuccessfully
true # do nothing, successfully
 
# This command can set fuses in the processor
# Setting fuses can brick the unit, will void the warranty,
# and should not be done in most cases
fuse
 
# GPIO can be manipulated from U-Boot.  Keep in mind that the IOMUX 
# in U-Boot is only setup enough to boot the device, so not all pins will
# be set to GPIO mode out of the box.  Boot to the full operating system
# for more GPIO support.
# GPIO are specified in bank and IO in this manual.  U-Boot uses a flat numberspace,
# so for bank 2 DIO 25, this would be number (32*2)+25=89
# Note that on some products, bank 1 is the first bank
# Set 2_25 low
gpio clear 83
# Set 2_25 high
gpio set 83
# Read 2_25
gpio input 83
 
# Control LEDs
led red on
led green on
led all off
led red toggle
 
# This command is used to copy a file from most devices
# Load kernel from SD
load mmc 0:1 ${loadaddr} /boot/uImage
# Load Kernel from eMMC
load mmc 1:1 ${loadaddr} /boot/uImage
# Load kernel from USB
usb start
load usb 0:1 ${loadaddr} /boot/uImage
# Load kernel from SATA
sata init
load sata 0:1 ${loadaddr} /boot/uImage
 
# View the FDT from U-Boot
load mmc 0:1 ${fdtaddr} /boot/imx6q-ts4900.dtb
fdt addr ${fdtaddr}
fdt print
 
# It is possible to blindly jump to any memory location
# This is similar to bootm, but it does not require
# the use of the U-Boot header
load mmc 0:1 ${loadaddr} /boot/custombinary
go ${loadaddr}
 
# Browse fat, ext2, ext3, or ext4 filesystems:
ls mmc 0:1 /
 
# Access memory like devmem in Linux, read/write arbitrary memory
# using mw and md
# write
mw 0x10000000 0xc0ffee00 1
# read
md 0x10000000 1
 
# Test memory.
mtest
 
# Check for new SD card
mmc rescan
# Read SD card size
mmc dev 0
mmcinfo
# Read eMMC Size
mmc dev 1
mmcinfo
 
# The NFS command is like 'load', but used over the network
dhcp
env set serverip 192.168.0.11
nfs ${loadaddr} 192.168.0.11:/path/to/somefile
 
# Test ICMP
dhcp
ping 192.168.0.11
 
# Reboot
reset
 
# SPI access is through the SF command
# Be careful with sf commands since
# this is where U-Boot and the FPGA bitstream exist
# Improper use can render the board unbootable
sf probe
 
# Delay in seconds
sleep 10
 
# Load HUSH scripts that have been created with mkimage
load mmc 0:1 ${loadaddr} /boot/ubootscript
source ${loadaddr}
 
# Most commands have return values that can be used to test
# success, and HUSH scripting supports comparisons like
# test in Bash, but much more minimal
if load mmc 1:1 ${fdtaddr} /boot/uImage;
	then echo Loaded Kernel
else
	echo Could not find kernel
fi
 
# Commands can be timed with "time"
time sf probe
 
# Print U-Boot version/build information
version


3.4 Modify Linux Kernel cmdline

The Linux kernel cmdline can be customized by modifying the cmdline_append variable. If new arguments are added, the existing value should also be included with the new arguments.

env set cmdline_append rw rootwait console=ttymxc0,115200 quiet
env save

The kernel command line can also be modified from from within Linux by creating a U-Boot script. From the Linux shell prompt run the following commands to install the necessary tools and create the script:

apt-get update && apt-get install u-boot-tools -y
echo "env set cmdline_append rw rootwait console=ttymxc0,115200 quiet" > /boot/boot.source
mkimage -A arm -T script -C none -n 'tsimx6ul boot script' -d /boot/boot.source /boot/boot.scr

The boot.source includes the plain text commands to be run in U-Boot on startup. The mkimage tool adds a checksum and header to the output file which then can be loaded by U-Boot. The .scr file should not be edited directly.

By default, every boot to SD, eMMC, and NFS will look for the file "/boot/boot.scr" and attempt to load and run it if it exists. This allows for modification of the boot process dynamically every boot without having to enter the U-Boot shell and modify it.


3.5 Linux NFS Boot

U-Boot's NFS support can be used to load a kernel, device tree binary, and root filesystem. The default scripts include an example NFS boot script. Because of the way U-Boot tries to infer server data, the script we use will bypass this, making it more straightforward to use an NFS root that will not be heavily dependent on a particular network configuration.

# Set this to your NFS server IP
env set nfsip 192.168.0.1
# Set this to your NFS root path
env set nfsroot /path/to/nfs/rootfs/
env save

To boot to NFS root once the server details are set:

# Boot to NFS once
run nfsboot;
 
# To make the NFS boot the persistent default
env set bootcmd run nfsboot;
env save
Note: 'bootcmd' is used to test for whether the system should stop at the U-Boot shell or continue, the above will make it difficult to get back to the U-Boot shell as it will always attempt to boot regardless of jumper status.

On the TS-4100, U-Boot will only boot to the network from the first physical port. The port that Linux considers to be "eth1".


3.6 Linux USB Boot

In standalone mode, this process is attempted on every boot unless it is disabled. It can be disabled by modifying the U-Boot environment variable "usbboot". If "usbboot" is set to 0 then this step will be bypassed. It is enabled by default to allow for a custom production process to be used. If the U-Boot shell is entered, this process can always be manually started with the command 'run usbprod'.

By default, U-Boot will attempt to read a U-Boot script from a USB drive when the U-Boot jumper is set or the reset button is enabled and held down. It copies "/tsinit.scr" into memory and jumps in to the script. To make a bootable drive, create a single ext3 partition on a USB drive and unpack the rootfs tarball located here

To make a bootable drive, create a single ext3 partition on a USB drive and unpack the rootfs tarball located here

Additionally, a U-Boot script file, "tsinit.scr", must be created and placed in the root folder of this partition. In order to do this, a script must be created and converted to the U-Boot .scr format. This process requires a set of U-Boot specific tools. These tools are available on most every Linux distribution, the instructions below are for Debian, either on a host PC or on the device itself. See the package installation documentation for other respective distributions.

Install U-Boot tools in Debian

apt-get update && apt-get install u-boot-tools -y

Create the file "tsinit.source" in the root of the USB drive with the Linux filesystem:

# Prepare with:
# mkimage -A arm -T script -C none -n 'imx6ul usb' -d tsinit.source tsinit.scr
 
# DO NOT MANUALLY EDIT THE .scr FILE
 
if load usb 0:1 ${loadaddr} /boot/ts${model}-fpga.vme;
        then fpga load 0 ${loadaddr} ${filesize};
fi;
 
if load usb 0:1 ${fdtaddr} /boot/imx6ul-ts${model}-${baseboardid}.dtb;
        then echo "${baseboardid} detected;"
else echo "Booting default device tree";
        load usb 0:1 ${fdtaddr} /boot/imx6ul-ts${model}.dtb;
fi;
 
load usb 0:1 ${loadaddr} /boot/zImage;
setenv bootargs root=/dev/sda1 rootwait rw ${cmdline_append} bbid=0x${baseboardid} bbrev=0x${baseboardrev};
run silowaitcharge;
bootz ${loadaddr} - ${fdtaddr};
fi;

Then in the same directory generate the tsinit.scr file:

mkimage -A arm -T script -C none -n 'imx6ul usb' -d tsinit.source tsinit.scr

3.7 Update U-Boot

WARNING: Installing a custom U-Boot is not recommended and may cause the device to fail to boot.

The TS-4100 uses slightly different U-Boot binaries for the 512 MB and 1 GB RAM variants. This is due to different DDR timing that needs to be set up at the start of U-Boot. When updating U-Boot, be sure to use the script that exists in U-Boot discussed below as it will use the correct file name and will reduce any potential issues

The latest U-Boot binary can be downloaded from the TS-4100 FTP site. Copy these files to /boot/ on the 1st partition of the SD card (or eMMC). The U-Boot binary can be updated by inserting that SD card in to the TS-4100, setting the jumpers to boot from SD, power up the unit, and enter the U-Boot shell. At the U-Boot prompt, the following command can be used:

run update-uboot

The above script will use the /boot/u-boot-${imx_type}.imx file from the SD card or eMMC, depending on the state of the SD Boot jumper.

Note that when running the TS-4100 standalone, the "update-uboot" command will default to searching the eMMC. Setting the environment variable "jpsdboot" to "on" (do not save the environment to disk otherwise it may cause booting issues later!), and then running the 'run update-uboot' command will cause U-Boot to look in "/boot" on the first SD card partition for the update files necessary.


3.8 U-Boot Development

We do provide our U-Boot sources, but we do not recommend rebuilding a custom U-Boot binary as it can leave the system in an unbootable state.

If you still want to proceed with building a custom U-Boot, use the "tsimx_v2016.03_4.1.15_2.0.0_ga" branch from our github repo: https://github.com/embeddedarm/u-boot-imx

When compiling, we recommend using ONLY this cross-compiler, the use of any other compiler may cause issues. Specifically, we have experienced RAM problems when using a more recent cross compiler to build this version of U-Boot. The use of any other compiler may leave the system in an unbootable state!

export ARCH=arm
export CROSS_COMPILE=/path/to/folder/bin/arm-tsimx6ul-linux-gnueabihf-
 
./build-imx6ul.sh ts4100

This will output a binaries for 1 GB and 512 MB RAM variants that can be written to the device using the steps in Update U-Boot.


3.9 POST

The TS-4100 U-Boot includes a simple POST test. This is normally used in production to verify basic functionality rapidly before continuing to more thorough testing. By default, this is not enabled on every boot, but it can be added via U-Boot scripting if there is a need for additional confidence in the application. The POST test quickly verifies basic functionality of: USB, RTC (if present), Ethernet PHY, WiFi/BT module (if present), eMMC (see warning below), RAM, and the supervisory microcontroller.

The post test can be run with the following command in U-Boot:

post
WARNING: The 'post' command has an optional "-d" argument; when this argument is passed it does a write and readback test of the eMMC and any other soldered down flash media on the TS-4100 or baseboards which is DESTRUCTIVE to the data on the disk! Note that it will not modify the boot sector contents of the eMMC which is needed by U-Boot. The eMMC chip is still tested for basic functionality without the argument passed, but no data is read or written from the disk itself.


4 Debian

4.1 Debian Stretch(9)

4.1.1 Getting Started

The stock image uses a Debian Stretch distribution and Linux kernel version 4.9. The latest image can be downloaded below.

This image can then be written to a microSD card or the on-board eMMC flash in order to be booted on the TS-4100.

4.1.2 Debian Networking

Note: The first physical port on the TS-4100 (or on Baseboards with a single port) is given the name "eth1", while the second port is "eth0".


By default, Debian Stretch does not configure or bring up any interfaces.

Debian can automatically set up the networking based on the contents of "/etc/network/interfaces.d/" files. For example, to enable DHCP for "eth0" by default on startup:

echo "auto eth0
iface eth0 inet dhcp" > /etc/network/interfaces.d/eth0

To set up a static IP:

echo "auto eth0
iface eth0 inet static
    address 192.168.0.50
    netmask 255.255.255.0
    gateway 192.168.0.1" > /etc/network/interfaces.d/eth0
echo "nameserver 1.1.1.1" > /etc/resolv.conf

To make this take effect immediately:

service networking restart

To configure other interfaces, replace "eth0" with the other network device name. Some interfaces may use predictable interface names. For example, the traditional name for an ethernet port might be "eth1", but some devices may use "enp1s0" for PCIe, or "enx00D069C0FFEE" (the MAC address appended) for USB ethernet interfaces. Run 'ifconfig -a' or 'ip a' to get a complete list of interfaces, including the ones that are not configured.


4.1.2.1 Debian Wi-Fi Client

Wireless interfaces are also managed with configuration files in "/etc/network/interfaces.d/". For example, to connect as a client to a WPA network with DHCP.

Install wpa_supplicant:

apt-get update && apt-get install wpasupplicant -y

Run:

wpa_passphrase youressid yourpassword

This command will output information similar to:

 network={
 	ssid="youressid"
 	#psk="yourpassword"
 	psk=151790fab3bf3a1751a269618491b54984e192aa19319fc667397d45ec8dee5b
 }

Use the hashed PSK in the specific network interfaces file for added security:

echo "auto wlan0
iface wlan0 inet dhcp
    wpa-ssid youressid
    wpa-psk 151790fab3bf3a1751a269618491b54984e192aa19319fc667397d45ec8dee5b" > /etc/network/interfaces.d/wlan0

To have this take effect immediately:

service networking restart

For more information on configuring Wi-Fi, see Debian's guide here.


4.1.2.2 Debian Wi-Fi Access Point

This section will discuss setting up the WiFi device as an access point that is bridged to an ethernet port. That is, clients can connect to the AP and will be connected to the ethernet network through this network bridge. The ethernet network must provide a DHCP server; this will be passed through the bridge to WiFi client devices as they connect.

The 'hostapd' utility is used to manage the access point of the device. This is usually installed by default, but can be installed with:

apt-get update && apt-get install hostapd -y

Note: The install process may start an unconfigured 'hostapd' process. This process must be killed before moving forward.


Modify the file "/etc/hostapd/hostapd.conf" to have the following lines:

ssid=YourWiFiName
wpa_passphrase=Somepassphrase
interface=wlan0
bridge=br0
auth_algs=3
channel=7
driver=nl80211
hw_mode=g
logger_stdout=-1
logger_stdout_level=2
max_num_sta=5
rsn_pairwise=CCMP
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
Note: Refer to the kernel's hostapd documentation for more wireless configuration options.


The access point can be started and tested by hand:

hostapd /etc/hostapd/hostapd.conf


Systemd auto-start with bridge to eth0

It is possible to configure the auto-start of 'hostapd' through systemd. The configuration outlined below will set up a bridge with "eth0", meaning the Wi-Fi connection is directly connected to the ethernet network. The ethernet network is required to have a DHCP server present and active on it to assign Wi-Fi clients an IP address. This setup will allow Wi-Fi clients access to the same network as the ethernet port, and the bridge interface will allow the platform itself to access the network.


Set up hostapd

First, create the file "/etc/systemd/system/hostapd_user.service" with the following contents:

[Unit]
Description=Hostapd IEEE 802.11 AP
Wants=network.target
Before=network.target
Before=network.service
After=sys-subsystem-net-devices-wlan0.device
After=sys-subsystem-net-devices-br0.device
BindsTo=sys-subsystem-net-devices-wlan0.device
BindsTo=sys-subsystem-net-devices-br0.device
 
[Service]
Type=forking
PIDFile=/run/hostapd.pid
ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B
 
[Install]
WantedBy=multi-user.target

Then enable this in systemd:

systemctl enable hostapd_user.service
systemctl enable systemd-networkd


Set up bridging

Create the following files with the listed contents.


"/etc/systemd/network/br0.netdev"

[NetDev]
Name=br0
Kind=bridge


"/etc/systemd/network/br0.network"

[Match]
Name=br0
 
[Network]
DHCP=yes


"/etc/systemd/network/bridge.network"

[Match]
Name=eth0
 
[Network]
Bridge=br0

4.1.3 Debian Application Development

4.1.3.1 Debian Stretch Cross Compiling

Debian Stretch provides cross compilers from its distribution. An install on a workstation can build for the same release on other architectures. A Linux desktop or laptop PC, virtual machine, or chroot will need to be used for this. Debian Stretch for a workstation can be downloaded from here.

From a Debian workstation (not the target), run these commands to set up the cross compiler:

# Run "lsb_release -a" and verify Debian 9.X is returned.  These instructions are not
# expected to work on any other version or distribution.
su root
# Not needed for the immediate apt-get install, but used
# so we can install package:armhf for cross compiling
dpkg --add-architecture armhf
apt-get update
apt-get install curl build-essential crossbuild-essential-armhf -y

This will install a toolchain that can be used with the prefix "arm-linux-gnueabihf-". The standard GCC tools will start with that name, eg "arm-linux-gnueabihf-gcc".

The toolchain can now compile a simple hello world application. Create hello-world.c on the Debian workstation:

#include <stdio.h>
int main(){
    printf("Hello World\n");
}

To compile this:

arm-linux-gnueabihf-gcc hello-world.c -o hello-world
file hello-world

This will return that the binary created is for ARM. Copy this to the target platform to run it there.

Debian Stretch supports multiarch which can install packages designed for other architectures. On workstations this is how 32-bit and 64-bit support is provided. This can also be used to install armhf packages on an x86 based workstation.

This cross compile environment can link to a shared library from the Debian root. The package would be installed in Debian on the workstation to provide headers and libraries. This is included in most "-dev" packages. When run on the arm target it will also need a copy of the library installed, but it does not need the -dev package.

apt-get install libcurl4-openssl-dev:armhf
 
# Download the simple.c example from curl:
wget https://raw.githubusercontent.com/bagder/curl/master/docs/examples/simple.c
# After installing the supporting library, curl will link as compiling on the unit.
arm-linux-gnueabihf-gcc simple.c -o simple -lcurl

Copy the binary to the target platform and run on the target. This can be accomplished with network protocols like NFS, SCP, FTP, etc.

If any created binaries do not rely on hardware support like GPIO or CAN, they can be run using 'qemu'.

# using the hello world example from before:
./hello-world
# Returns Exec format error
apt-get install qemu-user-static
./hello-world


4.1.4 Debian Installing New Software

Debian provides the apt-get system which allows management of pre-built applications. The apt tools require a network connection to the internet in order to automatically download and install new software. The update command will download a list of the current versions of pre-built packages.

apt-get update

A common example is installing Java runtime support for a system. Find the package name first with search, and then install it.

root@ts:~# apt-cache search openjdk
default-jdk - Standard Java or Java compatible Development Kit
default-jdk-doc - Standard Java or Java compatible Development Kit (documentation)
default-jdk-headless - Standard Java or Java compatible Development Kit (headless)
default-jre - Standard Java or Java compatible Runtime
default-jre-headless - Standard Java or Java compatible Runtime (headless)
jtreg - Regression Test Harness for the OpenJDK platform
libreoffice - office productivity suite (metapackage)
openjdk-8-dbg - Java runtime based on OpenJDK (debugging symbols)
openjdk-8-demo - Java runtime based on OpenJDK (demos and examples)
openjdk-8-doc - OpenJDK Development Kit (JDK) documentation
openjdk-8-jdk - OpenJDK Development Kit (JDK)
openjdk-8-jdk-headless - OpenJDK Development Kit (JDK) (headless)
openjdk-8-jre - OpenJDK Java runtime, using Hotspot JIT
openjdk-8-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-8-jre-zero - Alternative JVM for OpenJDK, using Zero/Shark
openjdk-8-source - OpenJDK Development Kit (JDK) source files
uwsgi-app-integration-plugins - plugins for integration of uWSGI and application
uwsgi-plugin-jvm-openjdk-8 - Java plugin for uWSGI (OpenJDK 8)
uwsgi-plugin-jwsgi-openjdk-8 - JWSGI plugin for uWSGI (OpenJDK 8)
uwsgi-plugin-ring-openjdk-8 - Closure/Ring plugin for uWSGI (OpenJDK 8)
uwsgi-plugin-servlet-openjdk-8 - JWSGI plugin for uWSGI (OpenJDK 8)
java-package - Utility for creating Java Debian packages

In this case, the wanted package will likely be the "openjdk-8-jre" package. Names of packages can be found on Debian's wiki pages or the packages site.

With the package name apt-get install can be used to install the prebuilt packages.

apt-get install openjdk-8-jre
# More than one package can be installed at a time.
apt-get install openjdk-8-jre nano vim mplayer

For more information on using apt-get refer to Debian's documentation here.


4.1.5 Debian Setting up SSH

To install the SSH server, install the package with apt-get:

apt-get install openssh-server


Debian Stretch by default disallows logins directly from the user "root". Additionally, SSH will not allow remote connections without a password or valid SSH key pair. This means in order to SSH to the device, a user account must first be created, and a password set:

useradd --create-home --shell /bin/bash newuser
passwd newuser


After this setup it is now possible to connect to the device as user "newuser" from a remote PC supporting SSH. On Linux/OS X this is the "ssh" command, or from Windows using a client such as PuTTY.


4.1.6 Debian Starting Automatically

A systemd service can be created to start up headless applications. Create a file in /etc/systemd/system/yourapp.service

[Unit]
Description=Run an application on startup
 
[Service]
Type=simple
ExecStart=/usr/local/bin/your_app_or_script
 
[Install]
WantedBy=multi-user.target

If networking is a dependency add "After=network.target" in the Unit section. Once you have this file in place add it to startup with:

# Start the app on startup, but will not start it now
systemctl enable yourapp.service
 
# Start the app now, but doesn't change auto startup
systemctl start yourapp.service
Note: See the systemd documentation for in depth documentation on services.


5 Backup / Restore

5.1 Creating A Production Image

It is usually desired to create a golden image to use for unit production after development is complete. This process can vary greatly from application to application but there are a few steps that are going to be most often wanted. These include cleaning up temporary files, removing files that should be unique and re-generated on the first boot (SSH keys, machine-id files, etc.), setting up the hostname, and so on. We have created a script that will automate most of this process and provides hooks for additionally scripts to be called as well. The script is simply passed the device node of the development disk or an existing .dd file. From this, it will create a new .dd file based on the partition scheme with all modifications made to the new image. The image source is left completely untouched and is only read. The script also assumes that the last partition on the disk is the bootable linux partition. If this is not the case or there are multiple partitions that are used in the end application, the script will need to be modified in order to accommodate this fact.

Note: The script uses output from various commands. The output format of linux utilities can vary greatly from distribution to distribution, or even within versions of the distribution. It is strongly recommended to verify the final processed image contains everything necessary for the application and that all processes completed without issue.


The simplest use of the script is:

./prep_customer_image /dev/sdX <output base name>

Note that "/dev/sdX" will need to be changed accordingly. Be sure to pass the whole disk and not just a partition.

The "<output base name>" is used as the base for all files output. For example, if "TechnologicSystems-latest" was used, then the compressed tarball output would be named "TechnologicSystems-latest.tar.bz2" (or it may end with ".tar.xz" depending on the compression used by the script). If no base name is provided, then the current date is used.

Additionally, there are two hooks available in the 'prep_customer_image' script, "prep" and "post". The top of the file has two variables, `PREP_SCRIPTS=""` and `POST_SCRIPTS=""`. Adding in a space separated list of script names to those variables will cause them to be called in order. For example, setting `PREP_SCRIPTS="add_application change_hostname"` will cause the 'prep_customer_image' script to run through its initial steps, then call './add_application', then call './change_hostname', and then will continue with the rest of the script steps.

Every script for "prep" and "post" is called with a single argument, the name of the image file. This specifically will be "<output base name>.dd". At the time of calling the prep scripts, the folder "./mount_point/" will have the last partition of the image file mounted as read/write. It is not wise to modify the image file directly since it is already mounted. All of the post scripts are called after the last partition of the image file is unmounted. This can be useful for creating additional file outputs, extracting specific partition images, etc., from the image itself. We have used these hooks in the past to remove special files and create additional images for our DoubleStore based devices.

It is also possible to run this script directly on the device when booted. This can be used to take an image of eMMC for example, when booted from the SD card. We always recommend doing initial development on SD, creating an image from that on a host PC, and then transferring it to the eMMC. This process makes development and image creation faster. If using the 'prep_customer_image' script from a booted device, be sure there is enough free space as the script creates a disk image of the target disk and then copies that in to a tarball, compressing everything as the final step.

The "prep_customer_image" script can be found in the TS-4100 utilities github.


5.2 microSD Card

MicroSD8GB.png Click to download the latest tarball.

These instructions assume an SD card with one partition. Most SD cards ship this way by default, but if there are modified partitions, a utility such as 'gparted' or 'fdisk' may be needed to remove the existing partition table and recreate it with a single partition. Note that the partition table must be "MBR" or "msdos", the "GPT" partition table format is not supported by U-Boot.

Plug the SD card into a USB reader (or native port if the host PC offers one) and connect it to a Linux workstation PC. Newer distributions include a utility called 'lsblk' which lists all block devices like a USB SD card adapter:

lsblk
 NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
 sdY      8:0    0   400G  0 disk 
 ├─sdY1   8:1    0   398G  0 part /
 ├─sdY2   8:2    0     1K  0 part 
 └─sdY5   8:5    0     2G  0 part [SWAP]
 sr0     11:0    1  1024M  0 rom  
 sdX      8:32   1   3.9G  0 disk 
 ├─sdX1   8:33   1   7.9M  0 part 
 ├─sdX2   8:34   1     2M  0 part 
 ├─sdX3   8:35   1     2M  0 part 
 └─sdX4   8:36   1   3.8G  0 part  

In this case the SD card is 4GB, so sdX is the target device. Note that "sdX" is not the real device name, it could be sda, sdb, mmcblk0, etc., so be sure to match up the real device name with the SD card. Technologic Systems is not responsible for any damages cause by using the improper device node for imaging an SD card.

Alternatively, after plugging in the device after Linux has booted, the command 'dmesg' can be used to print out the kernel log. When a new device is added to the system, information about it will be appended to the kernel logs. For example:

dmesg | tail -n 100
 scsi 54:0:0:0: Direct-Access     Generic  Storage Device   0.00 PQ: 0 ANSI: 2
 sd 54:0:0:0: Attached scsi generic sg2 type 0
 sd 54:0:0:0: [sdX] 3862528 512-byte logical blocks: (3.97 GB/3.84 GiB)

In this case, sdX is shown as a 3.97GB card. Note that "sdX" is not the real device name, it could be sda, sdb, mmcblk0, etc., so be sure to match up the real device name with the SD card. Technologic Systems is not responsible for any damages cause by using the improper device node for imaging an SD card.

Running these commands will write the SD card to our default latest image.

# Verify nothing else has the disk mounted with 'mount'
# If partitions are mounted automatically, they can be unmounted with
sudo umount /dev/sdX1
 
sudo mkfs.ext3 /dev/sdX1
sudo mkdir /mnt/sd
sudo mount /dev/sdX1 /mnt/sd/
wget http://ftp.embeddedarm.com/ftp/ts-socket-macrocontrollers/ts-4100-linux/distributions/debian/ts4100-armhf-stretch-latest.tar.xz
 
sudo tar -xJf ts4100-armhf-stretch-latest.tar.xz -C /mnt/sd
sudo umount /mnt/sd
sync
Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3.


After the image is written, the files can all be verified on disk against the original files created in the tarball. Reinsert the disk to verify any block cache is gone, then run the following:

mount /dev/sdX1 /mnt/sd
cd /mnt/sd/
sudo md5sum --quiet -c md5sums.txt
umount /mnt/sd
sync

The 'md5sum' command will report any differences between files and their checksums. Any differences are an indication of failure to write data or a damaged disk.

5.3 eMMC

5.3.1 U-Boot UMS (USB mass storage)

U-Boot on the TS-4100 supports the "ums" command to allow the eMMC device (or SD card, or USB device for that matter) to be accessible directly on a host PC via USB mass storage. This method is generally slower than direct access from Linux on the TS-4100 itself, but it allows for direct updating of the flash media.

Note: It is recommended to use a host PC with a native linux install. It has been observed that some VMs fail to correctly pass-through the USB device created in U-Boot for UMS.


In order to use this method, enter the U-Boot shell while connected to the TS-4100 via the USB serial interface. Insert the proper USB cable between the host PC and the USB OTG port, and enter the U-Boot command:

ums 0 mmc 1

The USB mass storage device provided by the TS-4100 will begin to enumerate. The following commands can then be used to set up the eMMC and unpack the latest image on to it. Note that the instructions refer to /dev/sdX, please verify the correct device node that is created on the host and adjust the instructions as necessary.

# Verify nothing else has the disk mounted with 'mount'
# If partitions are mounted automatically, they can be unmounted with
umount /dev/sdX1
 
mkfs.ext3 /dev/sdX1
mkdir /mnt/emmc
mount /dev/sdX1 /mnt/emmc
wget http://ftp.embeddedarm.com/ftp/ts-socket-macrocontrollers/ts-4100-linux/distributions/debian/ts4100-armhf-stretch-latest.tar.xz
tar -xJf debian/ts4100-armhf-stretch-latest.tar.xz -C /mnt/emmc
umount /mnt/emmc
sync
Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3.

After the image is written, the files can all be verified on disk against the original files created in the tarball. Reinsert the disk to verify any block cache is gone, then run the following:

mount /dev/sdX1 /mnt/emmc
cd /mnt/emmc/
sudo md5sum --quiet -c md5sums.txt
umount /mnt/emmc
sync

The 'md5sum' command will report any differences between files and their checksums. Any differences are an indication of failure to write data or a damaged disk.


UMS can also be used to create an image from an existing device. However, we recommend using the image prep script to complete this process for its ease of use, removal of temporary or unique files, and generation of MD5 hashes for each file.

Manual process:

dmesg | tail -n 30
# Look for the last /dev/sd* device connected.  This should also match the eMMC
# size of around 3.78GiB.
sudo mkdir /mnt/emmc/
sudo mount /dev/sdX1 /mnt/emmc/
cd /mnt/emmc/
tar -cjf /path/to/ts4100-backup-image.tar.bz2
cd ../
umount /mnt/emmc/
sync


5.3.2 Booted from SD

These instructions assume the TS-4100 is booted from SD card all the way to Linux. They also assume that the eMMC is unmodified, with a single partition. If the partition table has been modified, a utility such as 'gparted' or 'fdisk' may be needed to remove the existing partition table and recreate it with a single partition. Note that the partition table must be "MBR" or "msdos", the "GPT" partition table format is not supported by U-Boot.

# Verify nothing else has the partition mounted
umount /dev/mmcblk1p1
 
mkfs.ext3 /dev/mmcblk1p1
mount /dev/mmcblk1p1 /mnt/emmc
wget http://ftp.embeddedarm.com/ftp/ts-socket-macrocontrollers/ts-4100-linux/distributions/debian/ts4100-armhf-stretch-latest.tar.xz
tar -xf ts4100-armhf-stretch-latest.tar.xz -C /mnt/emmc
umount /mnt/emmc
sync
Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3.

Once written, the files on disk can be verified to ensure they are the same as the source files in the archive. To do so, run the following commands:

mount /dev/mmcblk1p1 /mnt/emmc
cd /mnt/emmc/
md5sum --quiet -c md5sums.txt
cd -
umount /mnt/emmc
sync

The 'md5sum' command will report any differences between files and their checksums. Any differences are an indication of failure to write data or a damaged disk.

6 Compile the Kernel

Compiling the kernel requires an armhf toolchain. We recommend development under Debian Stretch which includes an armhf compiler in the repositories. See the Debian Stretch cross compilation section for instructions on installing a proper cross compiler.

git clone git clone https://github.com/embeddedarm/linux-4.9.y
cd linux-4.9.y
 
# These next commands set up some necessary environment variables
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
export LOADADDR=0x80800000
 
# This sets up the default configuration that we ship with
make tsimx6ul_defconfig
 
## Make any changes in "make menuconfig" or driver modifications, then compile
make && make zImage && make modules

To install the kernel and modules to an SD card, attach it to the PC and assuming the the SD card shows up as "/dev/sdc", run the following:

export DEV=/dev/sdc1
sudo mount "$DEV" /mnt/sd
sudo cp arch/arm/boot/zImage  /mnt/sd/boot/zImage
sudo cp arch/arm/boot/dts/imx6ul*ts*.dtb /mnt/sd/boot/
INSTALL_MOD_PATH="/mnt/sd" sudo -E make modules_install 
sudo -E make headers_install INSTALL_HDR_PATH="/mnt/sd/usr"
sudo umount /mnt/sd/
sync

7 Production Mechanism

The TS-4100's U-Boot has the ability to locate and run a U-Boot script file named "/tsinit.scr" on the root of a USB drive. This process occurs when attempting to boot to the U-Boot shell or when booting to USB. If this script exists, U-Boot will load and run it automatically. This is intended for the initial production of units and allows mass programming various media from a USB mass storage device. See the U-Boot USB booting section for information on how this process starts.

The USB blasting image can be downloaded here. This includes a basic linux kernel and a small initramfs that will mount the USB drive at /mnt/usb/ and execute /mnt/usb/blast.sh.

The blast image and scripts require a minimum of 50 MB; this plus any disk images or tarballs used dictate the minimum disk size required. The USB drive must have at least 1 partition, with the first partition being formatted ext2/3 or fat32/vfat.

Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3.
# This assumes USB drive is /dev/sdc:
sudo mkfs.ext3 /dev/sdc1
sudo mkdir /mnt/usb/
sudo mount /dev/sdc1 /mnt/usb/
sudo tar --numeric-owner -xf /path/to/tsimx6ul_usb_blaster-latest.tar.bz2 -C /mnt/usb/

At this point, disk images or tarballs would be copied to the /mnt/usb/ folder and named as noted below. The latest disk images we provide can be downloaded from our FTP site, see the backup and restore section for links to these files. Note that the script expects images and tarballs to have specific names as outlined below. When using an ext2/3/4 filesystem, symlinks can be used. This allows for unpacking the same image to multiple locations. Note that fat32/vfat does not support symlinks and will require a copy of the file for each name.

The formatted USB drive boots into a small buildroot initramfs environment with filesystem and partitioning tools installed. This can be used to format SD, eMMC, or other disks. The buildroot starts up and calls /blast.sh on the USB device. By default this script is set up to look for a number of of specific files on the USB disk and write to media on the host device. Upon completion of the script the green or red LEDs will blink to visually indicate a pass or fail of the script. This script can be used without modification to write images from USB with these filenames:

SD Card sdimage.tar.xz Tarball of the filesystem. This will re-partition the SD card to 1 single ext4 partition and extract this tar to the filesystem. If present inside of the tarball, a "/md5sums.txt" file will be checked and every file can be verified on the filesystem. This md5sums file is optional and can be omitted, but it must not be blank if present.
sdimage.dd.xz Disk image of the SD card. This will be written to mmcblk0 directly. If present, a "sdimage.dd.md5" file will cause the written data on the SD card to be read back and verified against this checksum.
eMMC emmcimage.tar.xz Tarball of the filesystem. This will re-partition the eMMC to 1 single ext4 partition and extract this tar to the filesystem. If present inside of the tarball, a "/md5sums.txt" file will be checked and every file can be verified on the filesystem. This md5sums file is optional and can be omitted, but it must not be blank if present.
emmcimage.dd.xz Disk image of the eMMC. This will be written to mmcblk1 directly. If present, an "emmcimage.dd.md5" will cause the written data on the eMMC to be read back and verified against this checksum.

Most users should be able to use the above script without modification. Our buildroot sources are available from our github repo. To build the whole setup and create a USB drive, the following commands can be used. This will wipe any data on the specified partition and replace it with an ext2 formatted filesystem. This filesystem will have all of the necessary files written to it to create a bootable USB drive. Note that this must be the first partition of the disk.

# Assuming /dev/sdc1 is your usb drive's first partition
make ts4100_defconfig && make && sudo ./make_usb_prog.sh /dev/sdc1 tsimx6ul

8 Features

8.1 Baseboard ID

All of our off the shelf baseboards contain a hard-wired 8-input multiplexer to indicate the baseboard model. This is not required to implement in custom baseboards, but it can be useful to identify the board model in software. The baseboard model is determined in the bootloader and the proper device tree is selected for the respective baseboard. For example, the TS-8551-4100 would use the "imx6ul-ts4100-16.dtb" device tree file. In U-Boot the device tree IDs are specified in hex, so 0x16 (U-Boot defaults to using base 16 for number representations) will match baseboard ID 22. If a board does not have a specific device tree, it will fall back to the default device tree which is "imx6ul-ts4100.dtb".

4 DIO pins are used to obtain the baseboard model ID. The red LED (CN2_06), green LED (CN2_08), BUS_DIR (CN1_98), and BD_ID_DATA (CN1_83) are used for this purpose. All of these IO pins can be used normally outside of acquiring the ID number.


The 6 least significant input pins (Y0 - Y5) are used to define the baseboard model. The upper two inputs (Y6 and Y7) define board revision.

For custom baseboards we have reserved the address 42 which will never be used by our standard products.

TS-8160 baseboard ID resulting in ID 6, rev 0.


TS-Baseboard IDs
ID Baseboard
0 TS-8200
1 Reserved, do not use
2 TS-TPC-8390
4 TS-8500
5 TS-8400
6 TS-8160
7 TS-8100
8 TS-8820-BOX
9 TS-8150
10 TS-TPC-8900
11 TS-8290
13 TS-8700
14 TS-8280
15 TS-8380
16 TS-AN20
17 TS-TPC-8920
19 TS-8550
20 TS-TPC-8950
22 TS-8551
42 Reserved for customer use, never used by us
255 TS-8200


8.2 Bluetooth

The Wi-Fi option for the unit also includes a bluetooth 4.0 LE module. Both Wi-Fi and Bluetooth can be active at the same time. However, in order for bluetooth to function the Wi-Fi device must first be brought up to load the necessary firmware. After the Wi-Fi is active, the Bluetooth module can be activated with the following commands:

# Ensure that the Wi-Fi device is active
ifconfig wlan0 up 
 
# Enable Bluetooth, and load the driver firmware
echo BT_POWER_UP > /dev/wilc_bt
echo BT_DOWNLOAD_FW > /dev/wilc_bt
echo BT_FW_CHIP_WAKEUP > /dev/wilc_bt
 
hciattach /dev/ttymxc2 any 115200 noflow
hciconfig hci0 up
hcitool cmd 0x3F 0x0053 00 10 0E 00 01
stty -F /dev/ttymxc2 921600 crtscts

The Bluetooth module is now set up, and is running at 921600 baud with full flow control. At this point, the device is fully set up and can be controlled with various components of bluez-tools. For example, to do a scan of nearby devices:

hcitool lescan

This will return a list of devices such as:

3C:A3:08:XX:XX:XX Device_Name

Bluez has support for many different profiles for HID, A2DP, and many more. Refer to the Bluez documentation for more information.

Please note that the Bluetooth module requires the modem control lines CTS and RTS as flow control.

The module supports some other commands as well:

# Allow the BT chip to enter sleep mode
echo BT_FW_CHIP_ALLOW_SLEEP > /dev/wilc_bt
 
# Power down the BT radio when not in use
echo BT_POWER_DOWN > /dev/wilc_bt


8.3 CAN

In order to take advantage of CAN on the TS-4100, a baseboard with proper CAN transceivers installed is necessary. Running the TS-4100 standalone will not be able to support connection to a CAN network. See the specific baseboard manual for more detailed instructions with that combination. We recommend using the TS-8551-4100 as an example for designing a custom baseboard.

The i.MX6UL CPU has two FlexCAN ports that use the linux SocketCAN implementation. The ports can be set up and used with the following commands:

ip link set can0 up type can bitrate 1000000
ip link set can1 up type can bitrate 1000000

At this point the ports can be used with standard SocketCAN libraries. The default Debian distribution ships with "can-utils" installed by default in order to test the ports or as a simple packet send/receive tool. The 'candump' utility can be used to dump all data packets from the CAN network, while the 'cansend' utility will send out packets.

# To print all incoming CAN packets
candump can0
 
# To send out a CAN packet
cansend can1 7Df#03010c

The above example packet is designed to work with the Ozen Elektronik myOByDic 1610 ECU simulator to read the RPM speed. In this case, the ECU simulator would return data from candump with:

 <0x7e8> [8] 04 41 0c 60 40 00 00 00 
 <0x7e9> [8] 04 41 0c 60 40 00 00 00 

In the output above, columns 6 and 7 are the current RPM value. This shows a simple way to prove out the communication before moving to another language.

The following example sends the same packet and parses the same response in C:

#include <stdio.h>
#include <pthread.h>
#include <net/if.h>
#include <string.h>
#include <unistd.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <assert.h>
#include <linux/can.h>
#include <linux/can/raw.h>
 
int main(void)
{
	int s;
	int nbytes;
	struct sockaddr_can addr;
	struct can_frame frame;
	struct ifreq ifr;
	struct iovec iov;
	struct msghdr msg;
	char ctrlmsg[CMSG_SPACE(sizeof(struct timeval)) + CMSG_SPACE(sizeof(__u32))];
	char *ifname = "can0";
 
	if((s = socket(PF_CAN, SOCK_RAW, CAN_RAW)) < 0) {
		perror("Error while opening socket");
		return -1;
	}
 
	strcpy(ifr.ifr_name, ifname);
	ioctl(s, SIOCGIFINDEX, &ifr);
	addr.can_family  = AF_CAN;
	addr.can_ifindex = ifr.ifr_ifindex;
 
	if(bind(s, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
		perror("socket");
		return -2;
	}
 
 	/* For the ozen myOByDic 1610 this requests the RPM guage */
	frame.can_id  = 0x7df;
	frame.can_dlc = 3;
	frame.data[0] = 3;
	frame.data[1] = 1;
	frame.data[2] = 0x0c;
 
	nbytes = write(s, &frame, sizeof(struct can_frame));
	if(nbytes < 0) {
		perror("write");
		return -3;
	}
 
	iov.iov_base = &frame;
	msg.msg_name = &addr;
	msg.msg_iov = &iov;
	msg.msg_iovlen = 1;
	msg.msg_control = &ctrlmsg;
	iov.iov_len = sizeof(frame);
	msg.msg_namelen = sizeof(struct sockaddr_can);
	msg.msg_controllen = sizeof(ctrlmsg);  
	msg.msg_flags = 0;
 
	do {
		nbytes = recvmsg(s, &msg, 0);
		if (nbytes < 0) {
			perror("read");
			return -4;
		}
 
		if (nbytes < (int)sizeof(struct can_frame)) {
			fprintf(stderr, "read: incomplete CAN frame\n");
		}
	} while(nbytes == 0);
 
	if(frame.data[0] == 0x4)
		printf("RPM at %d of 255\n", frame.data[3]);
 
	return 0;
}

See the Kernel's CAN documentation here. Other languages have bindings to access CAN such as Python using C-types, Java using JNI.


8.4 CPU

This device uses the i.MX6UL CPU running at 528MHz or 696MHz using a Cortex-A7 core targeting low power consumption.

Refer to NXP's documentation for more detailed information on the CPU.


8.4.1 CPU Frequency Scaling

The i.MX6UL CPU has a number of power management features to scale the CPU speed. The maximum speed of the i.MX6UL is 696 MHz; other frequencies possible are 528 MHz, 396 MHz, and 198 MHz. By default, the "ondemand" frequency governor is used. This allows the CPU to run at its lowest speed and increase it when there is computation demand. Other governors are available, see the kernel documentation for a list of these governors and their operation.

The current CPU frequency as well as the governor used are modified by a set of files within the folder "/sys/bus/cpu/devices/cpu0/cpufreq". Some key files are outlined below:

 /sys/bus/cpu/devices/cpu0/cpufreq/cpuinfo_cur_freq - Lists the current frequency
 /sys/bus/cpu/devices/cpu0/cpufreq/scaling_governor - Lists/sets the current frequency governor
 /sys/bus/cpu/devices/cpu0/cpufreq/scaling_setspeed - When govenor is "userspace", set current frequency
 /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies - List all available frequencies
 /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_governors - List all available governors

In order to manually specify a frequency, the frequency governor must be set to userspace. For example, to force the lowest CPU frequency all the time:

echo "userspace" > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_governor
echo "198000" > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_setspeed

8.5 eMMC

TS-4100 eMMC Placeholder


8.6 Ethernet

This platform includes two ethernet devices using the dual in-CPU MACs and external PHYs. The MAC addresses are assigned from the Technologic System's OUI of 00:D0:69:xx:xx:xx, and the two MAC addresses assigned will always be sequential. These MAC addresses are burned into the CPU's fuses during production.

U-Boot supports only the ethernet port on CN1_01-11 (odd numbered pins). Once booted to Linux, this is "eth1", and CN2_16-24 (even numbered pins) provide "eth0".

Our baseboards may bring out one or both ethernet ports. See the specific manual for compatible baseboards for detailed information. For adding ethernet to custom baseboard designs, see our guidelines for custom baseboard design information.

8.7 FPGA

8.7.1 FPGA Registers

The TS-4100 FPGA provides additional DIO (that are connected to a Crossbar MUX), some miscellaneous system peripherals, and the 32-bit ZPU microcontroller. The FPGA is a Lattice MachXO2.

See the GPIO section for information on accessing the FPGA DIO.

The FPGA registers are accessed via an I2C bus. The FPGA emulates an I2C EEPROM, allowing for a simple and standard communication protocol to the FPGA. The FPGA is available at I2C addresses 0x28-0x2F. Accessing individual registers requires a chip address write, a 16-bit register address write, then 8-bit data values. A read or write stream can occur; every every byte read or written the internal register pointer moves to the next sequential register. This allows for reading or writing multiple registers without having to re-issue the chip and register address sequence.

We provide a simple access mechanism to the FPGA using the 'tshwctl' utility. This utility can read or write arbitrary registers, return some information about the FPGA, as well as configure the Crossbar MUX. Sources for 'tshwctl' and other utilities specific to the TS-4100 can be found in the TS-4100 utilities github repository.

The register map is broken in to a few different sections:

Section Address Bits Description
GPIOn 0x0000-0x00FF 7:3 Reserved (Write 0)
2 GPIOn Input Data
1 GPIOn Output Data
0 GPIOn Output Enable
CROSSBARn 0x0080-0x00FF 7 CROSSBARn GPIO mode
6:0 CROSSBARn Value
BANKn 0x0100-0x010F 7:0 GPIOn Bank Input
0x0110-0x011F 7:0 GPIOn Bank Output Data
0x0120-0x012F 7:0 GPIOn Bank Output Enable
Misc 0x0130 7:0 Model Number MSB (0x41)
0x0131 7:0 Model Number LSB (0x00)
0x0132 7:0 FPGA Rev
0x0133-0x1FFF 7:0 Reserved
ZPU 0x1FFF-0x2FFF 7:0 ZPU RAM access

GPIOn

Registers 0x00-0x7F provide DIO control. The GPIO can be manipulated via the sysfs GPIO interface, information on this can be found in the GPIO section which is the recommended way to manipulate these pins. Each register in this section manipulates a different DIO pin. See the "FPGA I/O" table below for the register offset for this section. For example, to set "DIO_1" to a low output, the value 0x1 would be written to FPGA register 0x26 (the I/O number of "DIO_1").

Note: The sysfs GPIO interface is recommended because it guarantees a clean state transition. When setting a GPIOn register, modifying multiple bits simultaneously creates a race condition between the output and output enable bits. This may result in a short glitch on the pin as it transitions. The sysfs GPIO driver will only manipulate a single bit at a time resulting in a clean and guaranteed transition.


CROSSBARn

Registers 0x80-0xFF provide control for the Crossbar MUX. Like GPIOn above, each register represents a single DIO pin which are listed in the "FPGA I/O" table below. In order to change the MUX setting of any individual pin, its corresponding register is written to. For example, to set "UARTA_TXD" to output the data from "UART2_TXD", write the value of 0x5 (the I/O number of "UART2_TXD") to register (0x80+0x21) = 0xA1 (the I/O number of "UARTA_TXD" plus the CROSSBARn section starting register). The 'tshwctl' utility provides an easy abstraction for this process. See the Crossbar MUX section for more information on this process as well as a breakdown of Crossbar assignments.


BANKn

Registers 0x100-0x12F provide banked DIO access. The banked DIO allows for manipulating multiple pins simultaneously. Each bank register has 8 bits that represent 8 DIO pins. There are 48 bank registers total, 16 for GPIO input, 16 for GPIO output, and 16 for GPIO output enable. The bank and bit position of any given DIO listed in the "FPGA I/O" table below can be calculated by dividing the I/O number by 8 to get the bank number and then taking the modulus of that same calculation to get the bit position. The BANKn registers are not intended for normal use and exist to allow the ZPU to readily manipulate GPIO pins.


Misc

Registers 0x130-0x132 provide the model number and FPGA software revision. Registers 0x133-0x1FFF are reserved.


ZPU

Registers 0x2000-0x3FFF are RAM intended for use by the ZPU. Normally unused unless the ZPU is loaded and run, these registers can be used for volatile storage if wanted.


FPGA I/O
I/O Number Signal name Direction
0x01 SPARE_1 I/O
0x02 SPARE_2 I/O
0x03 SPARE_3 I/O
0x04 SPARE_4 I/O
0x05 UART2_TXD Input
0x06 UART2_CTS# Input
0x07 UART3_TXD Input
0x08 UART6_TXD Input
0x09 UART2_RXD Output
0x0A UART2_CTS# Output
0x0B UART3_RXD Output
0x0C UART6_RXD Output
0x0D WIFI_RXD Input
0x0E WIFI_RTS Input
0x0F WIFI_IRQ# Input
0x10 WIFI_TXD Output
0x11 WIFI_CTS Output
0x12 ZPU_BREAK Input
0x13 ZPU_RESET Output
0x14 EN_WIFI_PWR Output
0x15 WIFI_RESET# Output
0x16 EN_USB_HOST_5V Output
0x17 EN_LCD_3V3 Output
0x18 ETH_PHY_RESET# Output
0x19 OFF_BD_RESET# Output
0x1B GREEN_LED# Output
0x1C RED_LED# Output
0x1D UARTA_RXD I/O
0x1E UARTB_RXD I/O
0x1F UARTC_RXD I/O
0x20 UARTD_RXD I/O
0x21 UARTA_TXD I/O
0x22 UARTB_TXD I/O
0x23 UARTC_TXD I/O
0x24 UARTD_TXD I/O
0x25 DIO_0 I/O
0x26 DIO_1 I/O
0x27 DIO_2 I/O
0x28 DIO_3[1] I/O
0x29 DIO_4 I/O
0x2A DIO_5 I/O
0x2B DIO_6 I/O
0x2C DIO_7 I/O
0x2D DIO_8 I/O
0x2E DIO_9 I/O
0x31 DIO_12 I/O
0x32 DIO_13 I/O
0x33 DIO_14 I/O
0x34 DIO_15 I/O
0x35 DIO_16 I/O
0x36 DIO_17 I/O
0x37 DIO_18 I/O
0x38 DIO_19 I/O
0x39 DIO_20 I/O
0x3A DIO_21 I/O
0x3B DIO_22 I/O
0x3C DIO_23 I/O
0x3D DIO_24 I/O
0x3E DIO_25 I/O
0x3F DIO_26 I/O
0x40 DIO_27 I/O
0x41 DIO_28 I/O
0x42 DIO_29 I/O
0x43 DIO_30 I/O
0x44 DIO_31 I/O
0x45 DIO_32 I/O
0x46 DIO_33 I/O
0x47 DIO_34 I/O
0x48 DIO_35 I/O
0x49 DIO_36 I/O
0x4A DIO_37 I/O
0x4B DIO_38 I/O
0x4C DIO_39 I/O
0x4E DIO_41 I/O
0x4F DIO_42 I/O
0x50 DIO_43 I/O
0x51 DIO_44 I/O
0x52 DIO_45 I/O
0x53 DIO_46 I/O

DIO_3 Clock Override

DIO_3 has special modes that override the normal output and places a clock frequency on it. This is required for compatibility with certain TS-8XXX baseboards with MUXBUS functionality. See the ZPU section for more information on MUXBUS and TS-8XXX baseboards. The override consists of two registers, and only the Output Data bits in each register.

0x57:0x58 OD bit DIO_3 output
b00 DIO_3
b01 14.3 MHz clock
b10 12.5 MHz clock
b11 12.5 MHz clock
  1. For compatibility with various TS-8XXX baseboards, this pin has a special mode that allows it to output a clock. See I/O register 0x57 and 0x58.


8.7.2 Crossbar

The TS-4100 implements a limited crossbar MUX. This allows functional reassignment of pins to serve other purposes. For example, it is possible to connect different UARTs to different locations which can be used to repurpose otherwise unused UART ports. Additionally it can be used to connect a passthrough from a CPU GPIO to a pin that is only otherwise available from the FPGA.

Due to space constraints of the FPGA, there is a limitation of how pins can be assigned. The "Crossbar Assignable" column of the FPGA I/O table below lists the type of input assignment a pin will accept. The table also lists the default assignment of every pin.

  • All FPGA I/O pins listed in the table can have their input assigned as "GPIO". Note that even with an input assignment of "GPIO", some pins are still limited to being an input or output only GPIO. Pins assigned to an input of "GPIO" are controlled by the standard GPIO interface and numbered according to the FPGA GPIO table. Also note that if an invalid assignment is given to a pin, it will default back to the "GPIO" assignment.
  • An input of "GPIO" means that the logical input to the switching block comes directly from its associated pin. For example, the "UART2_TXD" signal is set to "GPIO" as its input. This means that the input to this switchable signal comes from the pin, which is connected to the CPU UART2_TXD signal. The "WIFI_TXD" signal has its input set to "UART2_TXD", with the "WIFI_TXD" physical pin connecting directly to the UART input of the Wi-Fi/BT module. This full path connects the CPU UART output, to the FPGA pin, to the "UART2_TXD" switching block, to the "WIFI_TXD" output pin, to the UART RX on the Wi-Fi/BT module.
  • No matter which FPGA I/O is assigned, the output signal must have its data direction set to out and the input signal must have its data direction set to in. Without these set properly the physical pins themselves will be unable to properly MUX signals.
  • The FPGA I/O pins compatible with an "Any" input assignment can be assigned any other pin in the table as an input.
  • The FPGA I/O pins compatible with "Input only" assignment can only be assigned "GPIO" as an input. They can, however, be used as inputs in to other pins that are able to accept it as an input. Attempting to set this pin to any other input assignment will result it in automatically reverting to "GPIO".
  • The FPGA I/O pins compatible with "UART only" assignments can only be assigned I/O numbers 0x01 through 0x08 inclusive. Attempting to assign any other input will automatically set the pin to "GPIO".


FPGA I/O
I/O Number Signal name Crossbar Assignable Default Input Assignment
0x01 SPARE_1 Any GPIO
0x02 SPARE_2 Any GPIO[1]
0x03 SPARE_3 Any GPIO[2]
0x04 SPARE_4 Any WIFI_IRQ#
0x05 UART2_TXD Input only GPIO
0x06 UART2_CTS# Input only GPIO
0x07 UART3_TXD Input only GPIO
0x08 UART6_TXD Input only GPIO
0x09 UART2_RXD Any WIFI_RXD
0x0A UART2_RTS# Any WIFI_RTS#
0x0B UART3_RXD Any UARTA_RXD
0x0C UART6_RXD Any UARTB_RXD
0x0D WIFI_RXD Input only GPIO
0x0E WIFI_RTS# Input only GPIO
0x0F WIFI_IRQ# Input only GPIO
0x10 WIFI_TXD UART only UART2_TXD
0x11 WIFI_CTS# UART only UART2_CTS#
0x12 ZPU_BREAK Input only GPIO
0x13 ZPU_RESET Input only GPIO
0x14 EN_WIFI_PWR Input only SPARE_2
0x15 WIFI_RESET# Input only SPARE_3
0x16 EN_USB_HOST_5V Input only GPIO
0x17 EN_LCD_3V3 Input only GPIO
0x18 ETH_PHY_RESET# Input only GPIO
0x19 OFF_BD_RESET# Input only GPIO
0x1B GREEN_LED# Input only GPIO
0x1C RED_LED# Input only GPIO
0x1D UARTA_RXD UART only GPIO
0x1E UARTB_RXD UART only GPIO
0x1F UARTC_RXD UART only GPIO
0x20 UARTD_RXD UART only GPIO
0x21 UARTA_TXD UART only UART3_TXD
0x22 UARTB_TXD UART only UART6_TXD
0x23 UARTC_TXD UART only GPIO
0x24 UARTD_TXD UART only GPIO
0x25 DIO_0 UART only GPIO
0x26 DIO_1 UART only GPIO
0x27 DIO_2 UART only GPIO
0x28 DIO_3 UART only GPIO
0x29 DIO_4 UART only GPIO
0x2A DIO_5 UART only GPIO
0x2B DIO_6 UART only GPIO
0x2C DIO_7 UART only GPIO
0x2D DIO_8 UART only GPIO
0x2E DIO_9 UART only GPIO
0x31 DIO_12 UART only GPIO
0x32 DIO_13 UART only GPIO
0x33 DIO_14 UART only GPIO
0x34 DIO_15 UART only GPIO
0x35 DIO_16 UART only GPIO
0x36 DIO_17 UART only GPIO
0x37 DIO_18 UART only GPIO
0x38 DIO_19 UART only GPIO
0x39 DIO_20 UART only GPIO
0x3A DIO_21 UART only GPIO
0x3B DIO_22 UART only GPIO
0x3C DIO_23 UART only GPIO
0x3D DIO_24 UART only GPIO
0x3E DIO_25 UART only GPIO
0x3F DIO_26 UART only GPIO
0x40 DIO_27 UART only GPIO
0x41 DIO_28 UART only GPIO
0x42 DIO_29 UART only GPIO
0x43 DIO_30 UART only GPIO
0x44 DIO_31 UART only GPIO
0x45 DIO_32 UART only GPIO
0x46 DIO_33 UART only GPIO
0x47 DIO_34 UART only GPIO
0x48 DIO_35 UART only GPIO
0x49 DIO_36 UART only GPIO
0x4A DIO_37 UART only GPIO
0x4B DIO_38 UART only GPIO
0x4C DIO_39 UART only GPIO
0x4E DIO_41 UART only GPIO
0x4F DIO_42 UART only GPIO
0x50 DIO_43 UART only GPIO
0x51 DIO_44 UART only GPIO
0x52 DIO_45 UART only GPIO
0x53 DIO_46 UART only GPIO
  1. While assigned to GPIO by default, this is used as an input to EN_WIFI_PWR
  2. While assigned to GPIO by default, this is used as an input to WIFI_RESET#

8.7.2.1 Modify Crossbar Assignments

All of the crossbar assignments are managed through the FPGA syscon registers, in the bank of registers labeled as "CROSSBARn". However, this can more easily be managed through the 'tshwctl' utility. The 'tshwctl' utility provides a pair of flags that make it quick to assign an input to an FPGA I/O. For example, normally UART 2 is set up to connect to the on-board Bluetooth module. However, if a model of TS-4100 does not have this module present, or it is not needed in a particular application, it can be assigned to another unused set of UART pins on the TS-SOCKET interface, like UARTC:

tshwctl --out 0x9 --in 0x1f  # Set UART2_RXD's input assignment to be UARTC_RXD. The UART2_RXD signal in the FPGA is connected directly to UART2_RXD on the CPU.
tshwctl --out 0x23 --in 0x5  # Set UARTC_TXD's input assignment to be UART2_TXD. The UART2_TXD signal in the FPGA is connected directly to UART2_TXD on the CPU.
tshwctl --out 0x10 --in 0x80 # Set WIFI_TXD's input assignment to GPIO. This prevents UART2_TXD data from appearing on this pin when unwanted.
tshwctl --out 0x11 --in 0x80 # Set WIFI_CTS's input assignment to GPIO. This prevents UART2_RTS data from appearing on this pin when unwanted.
Note: Using 'tshwctl' to set crossbar assignments also sets the the GPIO direction. The I/O number passed as --out is set to a low output, and the I/O number passed as --in is set to an input.


The latest sources for 'tshwctl' and other utilities can be found in the TS-4100 utilities github repository.


8.8 GPIO

The i.MX6UL CPU and FPGA GPIO are exposed using a kernel character device. This interface provides a set of files and directories for interacting with GPIO which can be used from any language that interact with special files in linux using ioctl() or similar. For our platforms, we pre-install the "libgpiod" library and binaries. Documentation on these tools can be found here. This section only covers using these userspace tools and does not provide guidance on using the libgpiod library in end applications. Please see the libgpiod documentation for this purpose.

A user with suitable permissions to read and write /dev/gpiochip* files can immediately interact with GPIO pins. For example, to read the push switch on the TS-8551-4100 which is connected to FPGA DIO_9:

gpioget 5 46

Multiple pins in the same chip can be read simultaneously by passing multiple pin numbers separated by spaces.

To write to a pin, the 'gpioset' command is used. For example, to set LCD_D02:

gpioset 2 7=0

Multiple pins in the same chip can be set simultaneously by passing multiple pin=value pairs separated by spaces.

If a call with 'gpioset' or 'gpioget' fails with "Device or resource busy," that means that specific GPIO is claimed by another device. The command 'cat /sys/kernel/debug/gpio' can be used to get a list of all of the system GPIO and what has claimed them.

The 'gpiomon' tool can be used to monitor pins for changes.


8.8.1 CPU GPIO Table

The GPIO table below is for all usable GPIO pins from the CPU of the TS-4100. The chip and pin numbers are listed for use with the GPIO control outlined above. Some pins can have additional functions outside of GPIO. Not every possible function is listed but we have tried to list the most useful functions. The default kernel assigned function is surrounded by parenthesis. See the CPU documentation for a full list of functions that can be assigned to GPIO pins. Note that changing any of the functions requires kernel device-tree modifications to reassign the CPU's IOMUX for any given pin.

Chip Pin Functions Location
0 0 (USB1 OTG ID) / GPIO CN2_074
0 1 (GPIO) / ADC input CN2_012
0 8 (PWM0) / ADC input / GPIO CN1_057
0 9 (PWM1) / ADC input / GPIO CN2_091
0 10 (Ethernet PHY power en.) / GPIO CN2_046
0 11 (I2S Master Clock) / GPIO CN2_054
0 12 (I2S TX Sync) / GPIO CN2_038
0 13 (I2S TX Bit Clock) / GPIO CN2_036
0 14 (I2S RX Data) / GPIO CN2_042
0 15 (I2S TX Data) / GPIO CN2_040
0 16 (Console UART TXD) / GPIO CN2_093 / Microcontroller
0 17 (Console UART RXD) / GPIO CN2_095 / Microcontroller
0 18 (GPIO) FPGA Crossbar SPARE_1
0 19 (GPIO) FPGA Crossbar SPARE_2
0 20 (UART1 TXD) / GPIO CN2_082
0 21 (UART1 RXD) / GPIO CN2_084
0 22 (CAN1 TX) / GPIO CN1_071
0 23 (CAN1 RX) / GPIO CN1_069
0 24 (UART2 TXD) / GPIO FPGA Crossbar UART2_TXD
0 25 (UART2 RXD) / GPIO FPGA Crossbar UART2_RXD
0 26 (UART2 CTS) / GPIO FPGA Crossbar UART2_CTS
0 27 (UART2 RTS) / GPIO FPGA Crossbar UART2_RTS
0 28 (UART3 TXD) / GPIO FPGA Crossbar UART3_TXD
0 29 (UART3 RXD) / GPIO FPGA Crossbar UART3_RXD
0 30 (UART4 TXD) / GPIO CN2_090
0 31 (UART4 RXD) / GPIO CN2_092
2 0 (GPIO) / LCD CLK CN1_049
2 1 (GPIO) / LCD DE CN1_055
2 2 (GPIO) / LCD HSYNC CN1_051
2 3 (GPIO) / LCD VSYNC CN1_053
2 7 (GPIO) / LCD D02 CN1_028
2 8 (GPIO) / LCD D03 CN1_030
2 9 (GPIO) / LCD D04 CN1_032
2 10 (GPIO) / LCD D05 CN1_034
2 11 (GPIO) / LCD D06 CN1_038
2 12 (GPIO) / LCD D07 CN1_040
2 13 (CAN0 TX) / GPIO CN2_097
2 14 (CAN0 RX) / GPIO CN2_099
2 15 (GPIO) / LCD D10 CN1_023
2 16 (GPIO) / LCD D11 CN1_025
2 17 (GPIO) / LCD D12 CN1_027
2 18 (GPIO) / LCD D13 CN1_031
2 19 (GPIO) / LCD D14 CN1_033
2 20 (GPIO) / LCD D15 CN1_035
2 21 (UART6 TXD) / GPIO FPGA Crossbar UART6_TXD
2 22 (UART6 RXD) / GPIO FPGA Crossbar UART6_RXD
2 23 (PWM4) / GPIO / LCD D18 CN1_041
2 24 (PWM5) / GPIO / LCD D19 CN1_043
2 25 (GPIO) / LCD D20 CN1_045
2 26 (GPIO) / LCD D21 CN1_042
2 27 (GPIO) / LCD D22 CN1_044
2 28 (GPIO) / LCD D23 CN1_046
3 10 (SPI2 Offboard CS#) / GPIO CN2_065 / HD1_13
3 11 (GPIO) FPGA_RESET#
3 12 (SPI2 FPGA CS#) / GPIO FPGA
3 13 (SPI2 CLK) / GPIO CN2_071 / HD1_15 / FPGA
3 14 (SPI2 MOSI) / GPIO CN2_067 / HD1_11 / FPGA
3 15 (SPI2 MISO) / GPIO CN2_069 / HD1_9 / FPGA
3 16 (GPIO) FPGA Crossbar SPARE_3
3 17 (GPIO) / Camera MCLK CN2_034
3 18 (GPIO) / Camera PIXCLK CN2_032
3 19 (GPIO) / Camera VSYNC CN2_072
3 20 (GPIO) / Camera HSYNC CN2_070
3 21 (GPIO) / Camera D0 CN2_052
3 22 (GPIO) / Camera D1 CN2_056
3 23 (GPIO) / Camera D2 CN2_058
3 24 (GPIO) / Camera D3 CN2_060
3 25 (GPIO) / Camera D4 CN2_062
3 26 (GPIO) / Camera D5 CN2_064
3 27 (GPIO) / Camera D6 CN2_066
3 28 (GPIO) / Camera D7 CN2_068
4 0 POWER_FAIL[1] N/A
4 1 ZPU IRQ FPGA
4 8 (Wi-Fi IRQ) / GPIO FPGA Crossbar SPARE_4
  1. Asserted when external power input falls below valid input range.


8.8.2 FPGA GPIO Table

The GPIO table below is for all usable GPIO pins from the FPGA of the TS-4100. The chip and pin numbers are listed for use with the GPIO control outlined above. The FPGA pins have an internal Crossbar MUX that can be used to re-assign pin functions. When the pin is set to have a crossbar input of "GPIO" then the FPGA GPIO can be controlled as standard GPIO. Note that some FPGA pins can only be inputs while others can only be outputs. See the FPGA register and crossbar sections for more information on this.

Chip Pin Signal Name Location[1] Default Crossbar Input
5 1 SPARE_1 CPU GPIO 0_18 GPIO
5 2 SPARE_2 CPU GPIO 0_19 GPIO
5 3 SPARE_3 CPU GPIO 3_16 GPIO
5 4 SPARE_4 CPU GPIO 4_8 WIFI_IRQ
5 5 UART2_TXD CPU UART2_TXD GPIO
5 6 UART2_CTS# CPU UART2_CTS# GPIO
5 7 UART3_TXD CPU UART3_TXD GPIO
5 8 UART6_TXD CPU UART6_TXD GPIO
5 9 UART2_RXD CPU UART2_RXD WIFI_RXD
5 10 UART2_RTS# CPU UART2_RTS# GPIO
5 11 UART3_RXD CPU UART3_RXD UARTA_RXD
5 12 UART6_RXD CPU UART6_RXD UARTB_RXD
5 13 WIFI_RXD Wi-Fi/BT Module TXD GPIO
5 14 WIFI_RTS# Wi-Fi/BT Module RTS# GPIO
5 15 WIFI_IRQ# Wi-Fi/BT Module IRQ GPIO
5 16 WIFI_TXD Wi-Fi/BT Module RXD UART2_TXD
5 17 WIFI_CTS# Wi-Fi/BT Module CTS# UART2_CTS#
5 18 ZPU_BREAK ZPU Output GPIO
5 19 ZPU_RESET ZPU Input GPIO
5 20 EN_WIFI_PWR Wi-Fi/BT Module CHIP_EN GPIO
5 21 WIFI_RESET# Wi-Fi/BT Module WIFI_RESET# GPIO
5 22 EN_USB_HOST_5V CN1_004 GPIO
5 23 EN_LCD_3V3 CN1_048 GPIO
5 24 ETH_PHY_RESET# Ethernet PHY GPIO
5 25 OFF_BD_RESET# CN1_009 GPIO
5 27 GREEN_LED# CN2_008 GPIO
5 28 RED_LED# CN2_006 GPIO
5 29 UARTA_RXD CN2_078 GPIO
5 30 UARTB_RXD CN2_088 GPIO
5 31 UARTC_RXD CN2_096 GPIO
5 32 UARTD_RXD CN2_100 GPIO
5 33 UARTA_TXD CN2_082 UART3_TXD
5 34 UARTB_TXD CN2_086 UART6_TXD
5 35 UARTC_TXD CN2_094 GPIO
5 36 UARTD_TXD CN2_098 GPIO
5 37 DIO_00 CN1_093 GPIO
5 38 DIO_01 CN1_091 GPIO
5 39 DIO_02 CN1_089 GPIO
5 40 DIO_03 CN1_087 GPIO
5 41 DIO_04 CN1_085 GPIO
5 42 DIO_05 CN1_083 GPIO
5 43 DIO_06 CN1_081 GPIO
5 44 DIO_07 CN1_079 GPIO
5 45 DIO_08 CN1_077 GPIO
5 46 DIO_09 CN1_073 GPIO
5 49 DIO_12 CN1_067 GPIO
5 50 DIO_13 CN1_065 GPIO
5 51 DIO_14 CN1_063 GPIO
5 52 DIO_15 CN1_061 GPIO
5 53 DIO_16 CN1_059 GPIO
5 54 DIO_17 CN1_097 GPIO
5 55 DIO_18 CN1_099 GPIO
5 56 DIO_19 CN1_100 GPIO
5 57 DIO_20 CN1_098 GPIO
5 58 DIO_21 CN1_096 GPIO
5 59 DIO_22 CN1_094 GPIO
5 60 DIO_23 CN1_092 GPIO
5 61 DIO_24 CN1_090 GPIO
5 62 DIO_25 CN1_088 GPIO
5 63 DIO_26 CN1_086 GPIO
5 64 DIO_27 CN1_084 GPIO
5 65 DIO_28 CN1_082 GPIO
5 66 DIO_29 CN1_080 GPIO
5 67 DIO_30 CN1_078 GPIO
5 68 DIO_31 CN1_076 GPIO
5 69 DIO_32 CN1_074 GPIO
5 70 DIO_33 CN1_072 GPIO
5 71 DIO_34 CN1_070 GPIO
5 72 DIO_35 CN1_068 GPIO
5 73 DIO_36 CN1_066 GPIO
5 74 DIO_37 CN1_064 GPIO
5 75 DIO_38 CN1_060 GPIO
5 76 DIO_39 CN1_058 GPIO
5 78 DIO_41 CN1_024 GPIO
5 79 DIO_42 CN1_026 GPIO
5 80 DIO_43 CN1_019 GPIO
5 81 DIO_44 CN1_021 GPIO
5 82 DIO_45 CN1_037 GPIO
5 83 DIO_46 CN1_039 GPIO
  1. GPIO pins are formatted in "<chip>_<pin>" notation.


8.9 I2C

The i.MX6UL supports standard I2C at 100khz, or using fast mode for 400khz operation. The CPU has 2 I2C buses used on the TS-4100.

I2C 1 is internal to the TS-4100 and only connects to the on-board supervisory microcontroller.

/dev/i2c-0
Address Device
0x4A Supervisory Microcontroller

The second I2C bus is brought out on CN2_28 (SCL) and CN2_30 (SDA). This bus is shared with the on-board FPGA and runs at 400 kHz by default.

/dev/i2c-2
Address Device
0x28-0x2F FPGA
Note: It is also possible to request the kernel to use arbitrary GPIO pins as an I2C interface. See an example here.

The kernel makes the I2C busses available at /dev/i2c-#. The "i2c-tools" (i2cdetect, i2cget, i2cset) package can be used to interact with the bus. Or a specific application can be created.


8.10 I2S Audio

TS-4100 I2S Audio


8.11 Interrupts

Note: This section is incomplete at this time

The i.MX6UL CPU GPIO are also able to function as interrupts on rising and falling edges. This is accessible from the kernel as well as userspace. Userspace IRQs and handled via libgpiod.


8.12 LCD Interface

TS-4100 LCD Interface


8.13 LEDs

The kernel provides access to control the LEDs using the sysfs:

# Set Red led on
echo 1 > /sys/class/leds/red-led/brightness
# Set Red led off
echo 0 > /sys/class/leds/red-led/brightness
 
# Set Green led on
echo 1 > /sys/class/leds/green-led/brightness
# Set Green led off
echo 0 > /sys/class/leds/green-led/brightness

The kernel provides various triggers that can be useful for debugging purposes. The trigger for a given LED is in its directory:

echo "heartbeat" > /sys/class/leds/red-led/trigger
Trigger value LED toggles on
none Default, no action
rc-feedback IR Reciever trigger [1]
can0-tx CAN0 transmit activity
can0-rx CAN0 receive activity
can0-rxtx CAN0 activity
can1-tx CAN1 transmit activity
can1-rx CAN1 receive activity
can1-rxtx CAN1 activity
mmc0 MicroSD activity
mmc1 eMMC activity
timer 2hz blink
oneshot Blinks after delay. [2]
heartbeat Similar to timer, but varies the period based on system load
backlight Toggles on FB_BLANK
gpio Toggle based on a specified gpio. [3]
cpu0 Blink on CPU core 0 activity
default-on Only turns on by default. Only useful for device tree.
transient Specify on/off with time to turn off. [4]
  1. There is no IR directly on the TS-4100, this would be from a USB peripheral.
  2. See the Kernel documentation for more details on "oneshot" operation.
  3. When this trigger is set, a "gpio" file appears in the same directory which can be used to specify what GPIO to follow when it blinks
  4. See the Kernel documentation for more details on "transient" operation.


8.14 microSD Card Interface

The i.MX6UL SDHCI driver supports microSD (0-2 GB), microSDHC (2-32 GB), and microSDXC(32-2048 GB). The cards available on our website on average support up to 16MB/s read, and 22MB/s write using this interface. Sandisk Extreme cards with UHS support have shown 58MB/s Read and 59MB/s write. The Linux driver provides access to this socket at /dev/mmcblk0 as a standard Linux block device.

This graph shows our SD write endurance test for 40 TS-7553 boards running a doublestore stress test on 4GB Sandisk microSD cards. A failure is marked on the graph for a card once a single bit of corruption is found.

See the i.MX6UL reference manual for more information on this controller.

We have performed compatibility testing on the Sandisk microSD cards we provide, and we do not suggest switching brands/models without performing qualification testing. Though SD cards in theory will all follow the standard and just work, in practice cards vary significantly and can fail in subtle ways. We do not recommend ATP or Transcend microSD cards specifically due to known corruption issues that can occur after many GB of written data.

Our testing has shown that on average microSD cards will last between 6-12 TB of written data before showing a single bit of corruption. This is enough for most applications to write for years and not see any issues, but for more reliable consider the eMMC which is expected to last over 100 TB of writes. Higher end SD cards can also extend this, but industrial grade SD cards typically carry a cost much higher than the eMMC.

SD cards in general should not be powered down during a write/erase cycle, doing so will eventually lead to disk corruption. It is not always possible for 'fsck' to recover from the types of failures that will be seen with SD power loss. The system should be designed to avoid power loss to SD cards, or the eMMC module should be used for storage instead which can be configured to be resilient to power loss.


8.15 PWM

Note: This section is incomplete at this time

The TS-4100 has up to 4 available PWM channels. Their availability and use are dependent on the baseboard that is used. The four channels are located:

Channel Location
pwmchip0 CN1_57
pwmchip1 CN2_91
pwmchip4 CN1_41
pwmchip5 CN1_43

PWM devices are available though the sysfs filesystem, they will appear at "/sys/class/pwm/pwmchipX/" where X is the PWM channel number. Due to the layout of the PWM controller, each PWM channel is on a separate chip. Normally a single PWM chip can support multiple PWM devices through linux, however in this case each chip only has a single device; pwm0. This device is not enabled by default and must be turned on manually: can be used to control the PWM.

# Each PWM controller has "1" PWM device which will be PWM channel 0
echo 0 > /sys/class/pwm/pwmchipX/export

This will create a pwm0/ directory under each pwmchipX/ directory which will contain the following relevant files.:

period Total period, inactive and active time in the PWM cycle specified in nanoseconds.
duty_cycle Active time of the PWM signal specified in nanoseconds. Must be less than the period.
enable Write 1 to enable, 0 to disable

As an example, this will set a 50khz signal with 50 percent duty cycle on PWM channel 1:

# 20us is the period for 50khz
echo 20000 > /sys/class/pwm/pwmchip1/pwm0/period
echo 10000 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle
echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable


8.16 RTC

On this platform, the NXP SNVS Low Power Realtime Clock (RTC) module inside of the i.MX6UL CPU is used at the hardware clock. This is presented as "/dev/rtc0" from the Linux kernel and is accessed using the standard hwclock command. In order to keep time, there must be a constant 3.3 V provided on CN1_36 to keep the RTC active.

When run as standalone, the RTC is functional, but only when the TS-4100 is actively powered. Once external power is removed there is no power to the RTC module of the CPU.

When designing a custom baseboard, it is recommended to use an external RTC on the baseboard rather than the internal CPU module. This is because the internal CPU RTC consumes greater power than most dedicated ICs. This leads to a longer battery life. Additionally, a rechargeable cell could be used instead; wired to slowly charge when external power is applied.


8.17 SPI

Note: This section is incomplete at this time.

The default kernel sets up two SPI controllers. One to the Onboard WIFI, and the other to the FPGA and offboard chip selects. SPI is accessible through either specific kernel drivers, or userspace using the /dev/spi interface. See the kernel compile guide here for more details.

Open the baseboard dts from arch/arm/boot/dts/imx6ul-ts4100-<baseboardid>.dtsi, or the generic imx6ul-ts4100.dtsi. The kernel requires a spidev device be added to the relevant ECSPI controller. For example:

&ecspi3 {
	fsl,spi-num-chipselects = <2>;
	cs-gpios = <&gpio4 12 0>, <&gpio4 10 0>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_ecspi3>;
	status = "okay";
 
	spidevfpga: spi@0 {
		compatible = "spidev";
		reg = <0>;
		spi-max-frequency = <1000000>;
	};
 
	spioffbd: spi@1 {
		compatible = "spidev";
		reg = <1>;
		spi-max-frequency = <1000000>;
	};
};

In this case the two spidev devices are set to 1MHz. To adjust this further you will need to modify the kernel for your device. Linux will create two devices for the above spidev nodes:

  • /dev/spidev2.0 #FPGA
  • /dev/spidev2.1 #offboard

The FPGA SPI is left to custom ZPU code. You can also add additional CPU GPIO to the cs-gpios section to create more chip selects. For further information on the SPI programming see the kernel example code and documentation:

8.18 Supervisory Microcontroller

The TS-4100 includes an on-board supervisory microcontroller. It is an 8051 based device that has a number of operational responsibilities. It creates a USB serial UART for the debug UART, manages power-up and reset sequencing which includes deep sleep mode, manages charging the TS-SILO SuperCaps, is the system WDT, and has a number of ADC inputs of various system voltages.

Information about the microcontroller as well as output from its internal ADCs can be retrieved with the command:

tsmicroctl -i


Since the microcontroller handles power-up and reset, it includes a low power "sleep" mode that removes power from the CPU and all peripherals for a predefined period of time. Note that as soon as the sleep command is issued, the microcontroller will more power from all peripherals. Care must be taken to ensure there is no damage to peripherals or datalosses occurring during this sudden power-off event. It is recommended to run this command as the last step after a proper Linux shutdown sequence.

Sleep mode can be entered with the command:

tsmicroctl --sleep <time in seconds>

After the internal timer expires, the microcontroller will run the power-up sequence and boot the whole system back up normally.


On platforms that support TS-SILO supercapacitor backup, 'tsmicroctl' can be used to control that charging from userspace. The microcontroller itself has been carefully tuned to charge the supercapacitors at a safe rate, these parameters are not adjustable. However charging can be enabled and disabled from the command line:

# Enable charging
tsmicroctl --tssiloon
 
# Disable charging
tsmicroctl --tssilooff


8.19 TS-SILO Supercapacitors

This device can optionally support our TS-SILO technology. This consists of a charge and feedback monitor in the supervisory microcontroller on the TS-4100, a dedicated charging circuit on the TS-4100, and a pair of 2.7 V, 25 F supercapacitors in series on a TS-4100 baseboard. This full application provides up to 60 seconds of back up power if external power is removed from the device. Additionally, a notification of power failure is asserted on a CPU GPIO pin when external power has fallen below a valid input level. Monitoring this signal can be used to initiate a proper shutdown and ensure that all data is flushed from cache to disk, and all disks are unmounted properly.

Supercaps 4100 revB.png

The supercapacitor charge and discharge are monitored by the microcontroller on the TS-4100. A charge cycle is initiated automatically at startup by U-Boot, and can be disabled via a jumper setting on the baseboard. U-Boot can also be configured to load the kernel and FDT, but delay starting them until the supercapacitors are at a specified charge level. This can allow for a guaranteed available amount of reserve power in the case of external power being disconnected once the kernel starts booting.

Manual enabling and disabling of charging can be handled in U-Boot or Linux userspace:

# Enable the supercapacitor charging cycle in U-Boot or Linux userspace
tsmicroctl -e
 
# Disable the supercapacitor charging cycle in U-Boot or Linux userspace
tsmicroctl -d
 
# Get current charge level information from Linux userspace tools
tsmicroctl --info


U-Boot Settings

When the "No Charge" jumper is removed from the baseboard, U-Boot will automatically start charging the supercapacitors at startup. It is also possible to to configure U-Boot to delay booting Linux until the capacitors are at a certain charge level. This is automatically manged with the environment variable "chrg_pct". If the baseboard supports TS-SILO and the "No Charge" jumper is not set, then U-Boot will begin charging, load the kernel and FDT, and then delay executing them until the supercapacitors are charged to a level equal to or greater than the value of chrg_pct. Additionally, if the environment variable "chrg_verb" is set to 1, then U-Boot will print out the current charge level once every second.

Our monitor script, "/usr/local/bin/tssilomon", will issue a reboot if the external power is removed and the supercapacitor charge drops below a set threshold. This threshold can be tuned. Since a reboot is issued, when U-Boot starts up again it will wait for a valid power input before attempting to load any data from media to reduce power loss during media access. Once external power is restored, U-Boot will continue booting as it would normally. If the supercapacitors charge falls below the valid input threshold before power is restored, the TS-4100 microcontroller will cut power to the CPU and peripherals which will be resumed when external power is restored.

We recommend a chrg_pct value of 60. 60% is enough of a charge level in most applications to be able to boot up fully, have our background monitor script detect that external power has been removed, and shut down the system with about 10 seconds of remaining power to handle any potential variances. We strongly recommend testing in a final application to ensure a safe process.

An example of this process:

# From the U-Boot shell
env set chrg_pct 60
env set chrg_verb 1
env save
 
# Now, boot unit without stopping at U-Boot prompt
U-Boot 2016.03-00372-g92371f4445 (Jul 16 2019 - 12:01:04 -0700)
 
CPU:   Freescale i.MX6UL rev1.1 at 396 MHz
...
Booting from the SD card ...
...
Waiting until SuperCaps are charged to 60%
0%
...
55%
57%
59%
60%
...
Starting kernel ...
Note: The maximum achievable charge of the supercapacitors is dependent on input voltage of the 5 VDC power input. It may not be possible for a specific application to see 100% supercapacitor charge. Setting "chrg_pct" to a value higher than is achievable will cause an infinite wait state.


It is not possible for the TS-4100 in standalone mode to utilize TS-SILO supercapacitors; a supported baseboard with the proper components is required.

See the specific baseboard manual for more information on if TS-SILO is supported as well as more detailed instructions for that platform.

For adding TS-SILO to a custom baseboard, see our guidelines for designing a custom baseboard.


8.20 UARTs

The FPGA includes a crossbar to select where UARTs are routed so these can be changed. Below are the default mappings.

UART TX RX TXEN
ttymxc0 CN2_93 CN2_95 N/A
ttymxc1 CN2_82 CN2_84 N/A
ttymxc2 Onboard Bluetooth RX Onboard Bluetooth TX N/A
ttymxc3 CN2_78 CN2_80 N/A
ttymxc4 CN2_90 CN2_92 N/A
ttymxc6 CN2_86 CN2_88 N/A


8.21 USB

8.21.1 USB OTG

The platform includes a single USB OTG port. The default kernel build includes several device profiles. Additional devices can be compiled into the kernel. Some device usage examples are outlined below.

USB Serial

modprobe g_serial use_acm=1

This will create a "/dev/ttyGS0" device on the platform itself. The host PC connected to it will appear as a CDC-ACM device. See the kernel documentation for more information:

USB Ethernet

modprobe g_ether

This provides a "usb0" network interface device to both the platform and the host PC which simulates an ethernet network connection between them. IP addresses can be statically assigned, or either computer can run its own DHCP server.

Mass Storage

modprobe g_mass_storage file=/dev/mmcblk0

This will present the SD card to the host PC connected to the USB port. Example of connection to a host PC:

[85421.087855] scsi 4:0:0:0: Direct-Access     Linux    File-Stor Gadget 0401 PQ: 0 ANSI: 2
[85421.088486] sd 4:0:0:0: Attached scsi generic sg2 type 0
[85421.089546] sd 4:0:0:0: [sdc] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
[85421.196213] sd 4:0:0:0: [sdc] Write Protect is off
[85421.196218] sd 4:0:0:0: [sdc] Mode Sense: 0f 00 00 00
[85421.306216] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[85421.530556]  sdc: sdc1
[85421.746283] sd 4:0:0:0: [sdc] Attached SCSI disk

With "g_mass_storage" whole disks can be exposed, partitions, or even just files on a disk. Note that it is generally not safe to export a mounted disk in this way.

The USB OTG port of the TS-4100 itself is the micro USB AB port labeled "P1". This is the same port used for powering the TS-4100 when running in standalone mode. This means a connected host PC can provide power to the TS-4100 and be able to connect to it via USB gadgets once Linux had booted. Note that on most compatible baseboards, this port is mechanically locked out to prevent plugging in multiple cables to the same port. See the specific baseboard manual for information on how each baseboard allows access to this port. For integrating USB OTG in to a custom baseboard, see our guidelines on custom baseboard design.


8.21.2 USB Host

The TS-4100 provides a standard USB 2.0 host supporting 480Mb/s. Typically this is interfaced with by using standard Linux drivers, but low level USB communication is possible using libusb.


8.22 Watchdog

The kernel provides an interface to the watchdog driver at /dev/watchdog. Refer to the kernel documentation for more information:


8.23 WIFI

This board uses an ATWILC3000-MR110CA IEEE 802.11 b/g/n Link Controller Module With Integrated Bluetooth® 4.0. Linux provides support for this module using the wilc3000 driver.

Summary features:

  • IEEE 802.11 b/g/n RF/PHY/MAC SOC
  • IEEE 802.11 b/g/n (1x1) for up to 72 Mbps PHY rate
  • Single spatial stream in 2.4GHz ISM band
  • Integrated PA and T/R Switch Integrated Chip Antenna
  • Superior Sensitivity and Range via advanced PHY signal processing
  • Advanced Equalization and Channel Estimation
  • Advanced Carrier and Timing Synchronization
  • Wi-Fi Direct and Soft-AP support
  • Supports IEEE 802.11 WEP, WPA, and WPA2 Security
  • Supports China WAPI security
  • Operating temperature range of -40°C to +85°C


8.24 ZPU

The on-board FPGA contains a ZPU core.

The ZPU is a 32-bit stack based CPU with a full gcc compiler available for it. Our specific implementation gives it a single length of contiguous FPGA BlockRAM for code and data storage. The ZPU can be used to offload processing tasks, perform real-time operations, or facilitate communication between the ZPU and external peripherals. The ZPU is controlled completely from userspace using the 'tszpuctl' utility. This utility can load binaries, compile and load from source code, control reset of the ZPU, dump the entire memory space, or connect stdin and stdout from the terminal to the ZPU.

The ZPU has a total of 8192 bytes of RAM for shared code, data, and stack space. After exiting from reset, it begins execution from the lowest address with the stack starting from the highest address of RAM. The entire RAM address space is accessible through the FPGA interface. This is how applications are loaded in to the ZPU. It is also used for the communication FIFO and can be used as a way to quickly extract the entire contents of the ZPU for debugging or other purposes.


8.24.1 ZPU FIFO

A RAM based communication channel can be created to facilitate data transmission between the running ZPU and the main CPU. This channel is agnostic of the connection between the FPGA and the CPU. So long as the CPU can read and write any arbitrary address in the ZPU memory space, this channel is available. It is a bidirectional communication channel for arbitrary data between the ZPU and CPU.

The FIFO is implemented in software. There is an API for code running on the ZPU as well as a separate API for userspace software running on the CPU.

The ZPU reserves 256 bytes for TX and 16 bytes for RX at runtime in a structure. The base of this structure is placed at a known memory location. The CPU can then read from this memory location which contains the size of each FIFO, the head and tail of each FIFO, and other options for the FIFO.

When the ZPU needs to send data to the CPU it writes the bytes to the next free TXFIFO entries, updates the TXFIFO head pointer, and then raises the IRQ to the CPU. In order to assert an IRQ, the ZPU writes an address to the IRQ register. The IRQ remains asserted until the CPU reads from the address written to the IRQ register, or the ZPU is reset. For this reason, the FIFO implementation writes the address of the current TXFIFO head to the IRQ register. Once the CPU reads from the head address, the IRQ will deassert. The CPU sees the interrupt, reads from the current tail through the head of the TXFIFO, and then updates the new tail address when completed. There is an option for "flow control" which will prevent the ZPU from writing additional data to the TXFIFO if it is full.

When the CPU needs to send data to the ZPU, it writes data directly in to the ZPU RXFIFO and then changes the head. The ZPU is required to poll for changes in the head position in its RXFIFO. Once it sees a difference, it reads a byte from the RXFIFO and then changes the tail position.


8.24.2 ZPU Demo

We have included a demo ZPU application that simply shows how the ZPU can interact directly with FPGA I/O, as well as an example of the ZPU FIFO implementation. The ZPU can be loaded and started with one command, and the FIFO can be connected to with another:

tszpuctl --load /usr/local/bin/zpu/zpu_demo.bin
tszpuctl --connect

The 'tszpuctl --connect' connects the ZPU FIFO directly to the terminal's stdin and stdout. The "zpu_demo.bin" application will toggle the red and green LEDs with every character typed, as well as echo every character back. When enter/return is pressed, the ZPU will display the number of timer ticks since the last character the ZPU received. The standard "ctrl+c" escape sequence is used to exit from 'tszpuctl'.


8.24.3 Building ZPU Applications

Note: This section is incomplete at this time


Source code for 'tzpuctl' as well as our ZPU applications and APIs are available in the TS-4100 utilities repository.


9 Specifications

9.1 Power Specification

The TS-4100 module accepts a nominal 5 VDC input.

Input Min. Voltage Max. Voltage
5 VDC 4.7 VDC [1][2] 5.3 VDC
  1. Some USB peripherals will not function below 5 VDC.
  2. The TS-SILO supercapacitors on compatible baseboards are not able to fully charge with less than 5 VDC input.


9.2 Power Consumption

Note: This section is incomplete at this time.


9.3 I/O Specifications

The GPIO external to the TS-4100 are all nominally 3.3 V, but will have differences depending on if they are CPU/FPGA pins.

The CPU pins can be adjusted in software and will have initial values in the device tree. This allows for an adjustment of the drive strength and pull strength of the I/O. See the device tree for information and details about specific I/O.

The FPGA I/O cannot be adjusted further in software.

IO Typical Range Absolute Range Logic Low Max. Input Logic High Min. Input Drive Strength
External CPU GPIO 0 V to 3.3 VDC -0.5 V to 3.6 V 0.99 V 2.31 V 50 mA
External FPGA GPIO 0 V to 3.3 VDC -0.5 V to 3.75 V 0.8 V 2.0 V 8 mA

Refer to the MachXO2 Family Datasheet for more detail on the FPGA I/O. Refer to the CPU datasheet for further details on the CPU I/O.

Note: Do not drive any I/O externally until the 3.3 V rail is valid. Doing so can violate the power sequencing causing boot failures or damage to the device.


9.4 Power Output

The TS-4100 generates all internally used voltages from the supplied 5 V input. In addition to that, it outputs a 3.3 V source on the TS-SOCKET connector to provide a reference to the attached baseboard or supply power to some baseboard peripherals.

Rail Current Source Location
3.3 V 500 mA CN2_13, CN2_39


10 External Interfaces

10.1 TS-SOCKET

The TS-SOCKET macrocontrollers all use two high density 100 pin connectors for power and all I/O. These follow a common pinout for various external interfaces so new modules can be dropped in to lower power consumption or use a more powerful processor. The male connector is on the baseboard, and the female connector is on the macrocontroller. You can find the datasheet for the baseboard's male connector here. This can be ordered from the TS-SOCKET Macrocontroller product page as CN-TSSOCKET-M-10 for a 10 pack, or CN-TSSOCKET-M-100 for 100 pieces, or from the vendor of your choice, the part is an FCI "61083-102402LF".

TS-Socket

In our schematics and our table layout below, we refer to pin 1 from the male connector on the baseboard.

For designing a custom carrier board for the TS-4100 we recommend using the TS-8551 as a base: https://www.embeddedarm.com/documentation/ts-8551-schematic-reva.pdf


Example Baseboard

CN1 CN2
Name Pin Pin Name
FPGA_JTAG_TMS [1] 1 2 EXT_RESET# [2]
FPGA_JTAG_TCK [1] 3 C 4 EN_USB_5V [3]
FPGA_JTAG_TDO [1] 5 N 6 NC
FPGA_JTAG_TDI [1] 7 1 8 NC
OFF_BD_RESET# [4] 9 10 NC
Microcontroller C2 CLK [5] 11 12 NC
Microcontroller C2 DAT [5] 13 C 14 NC
5 V Power Input [6] 15 N 16 5 V Power Input [6]
CPU SPARE_1, FPGA SPARE_1 [7] 17 1 18 NC
DIO_43 19 20 NC
DIO_44 21 22 FORCE_PWR_ON# [8]
LCD_D10 23 C 24 DIO_41
LCD_D11 25 N 26 DIO_42
LCD_D12 27 1 28 LCD_D02
5 V Power Input [6] 29 30 LCD_D03
LCD_D13 31 32 LCD_D04
LCD_D14 33 C 34 LCD_D05
LCD_D15 35 N 36 V_BAT
DIO_45 37 1 38 LCD_D06
DIO_46 39 40 LCD_D07
LCD_D18 41 42 LCD_D21
LCD_D19 43 C 44 LCD_D22
LCD_D20 45 N 46 LCD_D23
5 V Power Input [6] 47 1 48 EN_LCD_3.3V [9]
LCD_CLK 49 50 USB_OTG_5V [10]
LCD_HSYNC 51 52 BOOT_MODE_0 [11]
LCD_VSYNC 53 C 54 NC
LCD_DE 55 N 56 NC
PWM 57 1 58 DIO_39
DIO_16 59 60 DIO_38
DIO_15 61 62 Ground
DIO_14 63 C 64 DIO_37 / MUX_AD_15
DIO_13 65 N 66 DIO_36 / MUX_AD_14
DIO_12 67 1 68 DIO_35 / MUX_AD_13
CAN1 RXD 69 70 DIO_34 / MUX_AD_12
CAN1 TXD 71 72 DIO_33 / MUX_AD_11
DIO_09 73 C 74 DIO_32 / MUX_AD_10
Ground 75 N 76 DIO_31 / MUX_AD_09
DIO_08 77 1 78 DIO_30 / MUX_AD_08
DIO_07 79 80 DIO_29 / MUX_AD_07
DIO_06 81 82 DIO_28 / MUX_AD_06
DIO_05 83 C 84 DIO_27 / MUX_AD_05
DIO_04 85 N 86 DIO_26 / MUX_AD_04
DIO_03 / Offboard Clock 87 1 88 DIO_25 / MUX_AD_03
DIO_02 89 90 DIO_24 / MUX_AD_02
DIO_01 91 92 DIO_23 / MUX_AD_01
DIO_00 93 C 94 DIO_22 / MUX_AD_00
Ground 95 N 96 DIO_21 / BUS_ALE#
DIO_17 / BUS_WAIT# 97 1 98 DIO_20 / SD Boot Jumper / BUS_DIR
DIO_18 / BUS_BHE# 99 100 DIO_19 / BUS_CS#
Name Pin Pin Name
eth1 RX+ 1 2 eth1 ACT_LED
eth1 RX- 3 C 4 eth1 SPEED_LED
eth1 CT 5 N 6 RED_LED#
eth1 TX+ 7 2 8 GREEN_LED#
eth1 TX- 9 10 eth0 ACT_LED
eth1 CT 11 12 CPU GPIO 0_1
3.3 VDC output 13 C 14 Ground
Ground 15 N 16 eth0 RX+
NC 17 2 18 eth0 RX-
NC 19 20 eth0 CT
Ground 21 22 eth0 TX+
NC 23 C 24 eth0 TX-
NC 25 N 26 Ground
NC 27 2 28 I2C CLK
USB_HOST_M 29 30 I2C DAT
USB_HOST_P 31 32 Camera PIXCLK
Ground 33 C 34 Camera MCLK
USB_OTG_M 35 N 36 I2S CLK
USB_OTG_P 37 2 38 I2S FRM
3.3 VDC output 39 40 I2S TXD
NC 41 42 I2S RXD
NC 43 C 44 Ground
Ground 45 N 46 En. ethernet PHY pwr
NC 47 2 48 NC
NC 49 50 Ground
Ground 51 52 Camera D0
NC 53 C 54 I2S MCLK
NC 55 N 56 Camera D1
NC 57 2 58 Camera D2
NC 59 60 Camera D3
NC 61 62 Camera D4
NC 63 C 64 Camera D5
Off-board SPI CS# 65 N 66 Camera D6
Off-board SPI MOSI 67 2 68 Camera D7
Off-board SPI MISO 69 70 Camera HSYNC
Off-board SPI CLK 71 72 Camera VSYNC
Ground 73 C 74 USB_OTG_ID
SuperCap V+ 75 N 76 USB_OTG_5V [10]
SuperCap V+ 77 2 78 UART3 TXD (UARTA TXD) [12]
Reserved 79 80 UART3 RXD (UARTA RXD) [12]
SuperCap V+ 81 82 UART1 TXD
SuperCap V+ 83 C 84 UART1 RXD
Ground 85 N 86 UART6 TXD (UARTB TXD) [12]
SuperCap Junction 87 2 88 UART6 RXD (UARTB RXD) [12]
SuperCap Balance Drive 89 90 UART4 TXD
CPU GPIO 0_9 91 92 UART4 RXD
DEBUG TXD 93 C 94 UARTC TXD
DEBUG RXD 95 N 96 UARTC RXD
CAN0 TXD 97 2 98 UARTC TXD
CAN0 RXD 99 100 UARTC RXD
  1. 1.0 1.1 1.2 1.3 The FPGA JTAG pins are not recommended for use and are not supported.
  2. EXT_RESET# is an input used to reboot the CPU. Do not drive active high, use open drain.
  3. This is an output which can be manipulated as a GPIO. This pin can optionally be connected to control a FET to a separate 5 V rail for USB to allow software to reset USB devices. Many of our baseboards implement this.
  4. OFF_BD_RESET# is an output from the CoM 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.
  5. 5.0 5.1 This interface is for programming the on-board microcontroller, this should be left unconnected on a baseboard.
  6. 6.0 6.1 6.2 6.3 The power pins should each be provided with a 5 V source.
  7. This is a multi-purpose pin, part of the FPGA Crossbar MUX. The CPU and FPGA pins are connected in parallel.
  8. When low, overrides the microcontroller power control and enables 5 V rail on the TS-4100. Leave unconnected for normal use.
  9. This is an output that can be manipulated as a GPIO.
  10. 10.0 10.1 Allows the supervisory microcontroller to measure USB VBUS for the OTG port.
  11. When held high during CPU startup, enables i.MX6UL USB Boot bootloader.
  12. 12.0 12.1 12.2 12.3 This pin is part of the FPGA Crossbar MUX. Its default Crossbar assignment is listed first, with the Crossbar name in parenthesis.

11 Designing a Custom Baseboard

Our Computer-on-Module line of devices are required or best utilized when set on a baseboard / carrier board. We offer a number of off the shelf baseboards that we have designed to try to meet as many goals and design purposes as possible. However, some applications may require customized baseboards in order to better meet the design requirements.

This is one of the advantages of our CoM devices; end applications do not need to worry about designing and laying out the critical sections of a CPU and its peripherals. Baseboards simply break out I/O and peripherals from the module. The dual high-density connectors between the CoM and the baseboard provide a secure connection for high vibration environments.

There are a few guidelines that should be followed when laying out a custom baseboard to ensure smooth bringup and proper operation. This is divided in to multiple sections for easier access. Note that this information is purely a guideline. There may be other details required for specific applications, or some of these may not apply to every application. Technologic Systems offers custom design services, our design expertise can be used to create a custom baseboard to meet your requirements.


The TS-8200 TS-SOCKET development platform and the TS-8551 TS-SOCKET development baseboard are our recommended baseboards to use as design reference for a custom baseboard.


11.1 General CoM Guidelines

Power

  • Observe the input voltage specifications. All of our CoM devices only require a single 5 VDC voltage rail input. Ensure this rail is within operational specifications of the CoM, that each 5 V power pin on the TS-SOCKET interface has a connection to this rail, and that all ground pins are connected as well. The majority of our devices can safely tolerate 5 VDC ±0.2 VDC. Be sure to not apply any other voltage to any other rails. Other voltage rails present on the TS-SOCKET connector are sequenced and output by the CoM itself. Applying voltages to these rails can cause issues at bootup or damage to the CoM.
  • Observe output power specifications. Many of our CoM devices have output rails for 3.3 VDC, some even providing 1.8 VDC as well. These can and are recommended to be used by the baseboard rather than a separate power rail on the baseboard itself if possible. However, these voltage rails should not be relied upon for heavy power draw. The majority of our devices can support around 500 mA draw from the 3.3 V rail, if not more.
  • Our CoMs are designed with a suitable amount of bypassing and noise suppression for most applications. However, in environments with noisy power or high EMI, extra protection should be added to the baseboard.


I/O

  • Ensure no CoM I/O pins are driven from the baseboard before the CoM power rails are valid. This is why we suggest using the CoM 3.3 VDC rail for powering devices on the baseboard where possible. If separate rails must be used, ensure that a reset circuit is created to prevent CoM I/O from being driven until the 3.3 VDC rail from the CoM is valid.
  • Ensure all external I/O on the baseboard has proper ESD protection. For example, USB data lines should have TVS diodes situated near the USB host jack. Any I/O that is subject to interaction should be considered for this purpose.
  • Observe maximum ratings for I/O pins. The majority of CoM I/O is 3.3 VDC with some special exceptions. However, the drive strength and trigger voltage levels may differ depending on where the I/O is routed on the CoM. The majority of I/O are able to output >= 8 mA @ 3.3 VDC, have input hysteresis, and are able to tolerate input ranges from -0.1 VDC to 3.4 VDC.


Ethernet

  • Ethernet breakout requires magnetics. We recommend using jacks (Ethernet uses 8P8C modular jacks, commonly referred to as RJ45 jacks) with built-in magnetics as this is what we use on nearly all of our designs. When placing magnetics, be sure to place them as close to the TS-SOCKET interface with as little trace length variance as possible between all of the required connections.
  • Ensure the correct magnetics and ethernet jack are used for the appropriate PHY. For example, CoMs with Gigabit Ethernet support require magnetics and jacks designed for Gigabit applications, even if the connected Ethernet network will only be 100BASE-T. Likewise, CoMs that support only 100 Mbit and lower require magnetics and jacks designed for 100BASE-T applications.


SD / microSD

  • Many CoM devices either mirror the microSD socket that is on-board, or break out a second interface via the TS-SOCKET connector. In the case of mirrored connections, ensure that the application prevents connecting multiple SD cards to this same bus. There will likely be no damage from doing so, however it can cause headaches when debugging.
  • Ensure the SD or microSD socket is placed as close as possible to the TS-SOCKET connector and that all of the SD signal lines have as little length variance as possible between them.


USB

  • Run all USB lines according to USB best practices. Most CoM devices have no other components connected to the USB data lines.
  • USB connectors do not need to be placed immediately next to the TS-SOCKET connector, however the data lines do need to be matched in trace length and impedance in accordance with USB standards.
  • USB Host:
    • Devices can be powered from the same 5 VDC rail as the CoM. Power can optionally be controlled via a dedicated pin from the CoM. Many of our CoM devices expect to have USB device power control set on CN1_4. This pin would be connected to an electronic switch on the baseboard that can enable and disable power to the USB device.
  • USB Device/OTG:
    • On CoM devices that support USB OTG, ensure the ID line is properly connected.
    • In applications where the USB OTG interface is only used as a host or a device, the ID line may still need to be connected or left floating, depending on the USB role. Additionally, it is possible in kernel configuration to force most USB OTG peripherals to be always in a single role, thereby ignoring the ID line.
    • Some CoM devices have a separate USB OTG 5 VDC line that can power devices or be used as a detect circuit for connected devices in a host role. Be sure to take precautions to not damage any USB peripherals or the CoM module/baseboard by incorrectly handling USB power.


No Connect (NC) / Unused / Reserved / JTAG Pins

  • A number of pins in the TS-SOCKET pinout are marked as No Connect (NC), Reserved, Unused, as JTAG, or other programming interfaces. In most applications these pins should remain disconnected on the baseboard. Connecting them may cause issues.


RTC

  • Many CoM devices have a soldered down RTC. RTC battery power is expected to come from the baseboard itself. This allows for application flexibility. e.g. A readily replaceable coin cell, a soldered down rechargeable cell, or supercapacitor solution. Note that rechargeable solutions require the baseboard design to handle charging safely. The CoM expects a constant 3.3 V source on the V_BAT pin.
  • Some CoMs may require the baseboard to implement the RTC as well as the battery; with the RTC being connected via I2C or SPI. Keep this in mind while designing a custom baseboard.


Jumpers

  • Many of our baseboards implement various pin jumpers. These jumpers include (but are not limited to): controlling boot flow, controlling the boot device, and adding termination resistors to bus based networks. Confirm relevant jumpers and locations for the specific CoM device when designing the baseboard.


Transceivers

  • Many interfaces supported by CoM devices may require external transceivers. These include but are not limited to: CAN, RS-232 UART, and RS-485 / RS-422. The CoM I/O in most cases provides the necessary signaling at 3.3 VDC TTL levels, the baseboard is required to add any necessary transceivers to connect these signals to the bus safely.
  • Some of these interfaces support or require an enable of some kind. In many cases this is a hardware assisted process like in the case of automatic TXEN on RS-485 from our FPGAs. In some cases it is software based as kernels can support using GPIO as a regulator enable or TXEN. Be sure to consider the sources of these signals when designing a custom baseboard.


Baseboard ID and Revision

  • All of our off-the-shelf baseboards implement software readable ID and revision via a shift register. While not necessary for an application, it can help the bootloader identify the baseboard model as well as a specific revision. This can be used to load different kernels or behave differently for different revisions. The ID value 42 is reserved for customer use; using other values may cause issues in the future as we develop more baseboards. If it is needed, generally any ID value greater than 42 would likely also be safe.
  • See the Baseboard ID section for information this mechanism and an example of how this shift register needs to be designed in to a custom baseboard.


High-Density TS-SOCKET Connectors

  • The interface between a CoM and its baseboard is through a pair of gendered, keyed, high-density, 100 pin connectors. The male side needs to be installed on the baseboards as the CoM devices have the female socket. We sell the male connector directly through our store: https://www.embeddedarm.com/products/CN-TSSOCKET-M. They are from the manufacturer FCI, and the part number is "61083-102402LF"
  • Note that pin 1 of the plug connector (as indicated on the plastic of the connector) may not line up with pin 1 of the TS-SOCKET specification. Be sure to properly orient the connector on the baseboard so that the silk screened pin 1 indicator on the CoM device lines up with pin 1 of the TS-SOCKET.
  • See the CoM mechanical drawing for exact sizing of the module, as well as location of the high-density connectors and the mounting holes.


11.2 TS-4100 CoM Guidelines

The following guidelines outline any special considerations or exceptions to our CoM guidelines above that are specific to the TS-4100. As above, this information is still a set of general guidelines for the TS-4100. There may be other details required for specific applications, some of these may not apply to every application, and many of the general guidelines already cover topics that are not exclusive to the TS-4100. Technologic Systems offers custom design services, our design expertise can be used to create a custom baseboard to meet your requirements.


Ethernet

  • The TS-4100 Ethernet PHYs are rated for 100BASE-T operation, be sure to use magnetics and jacks designed for 100BASE-T operation.
  • If using a single Ethernet port, be sure to use the Ethernet pins marked as "eth1" (on pins CN2_001-011, odd pins, and CN2_002 and CN2_004). Linux sees this port as "eth1", but it is connected to the first Ethernet MAC in the CPU. This is the only port that U-Boot supports for its network operations as well.


Baseboard ID, U-Boot, and Flattened Device Tree

  • While implementing a baseboard ID indicator is not necessary for booting the TS-4100, it is highly recommended. By default, U-Boot will read the baseboard ID and attempt to locate a Linux Flattened Device Tree (FDT) based on this information. For example, we recommend using the ID value of 42 for custom baseboards; U-Boot would attempt to load the file "/boot/imx6ul-ts4100-2a.dtb" The ID 42 represented in base 16 is 0x2a; U-Boot expects the hex value to use lowercase letters. This allows for creating a customized Device Tree file that fully supports the TS-4100 CoM on a custom baseboard. On baseboards without an ID indicator implemented, U-Boot will read this ID as 63. If the FDT file "/boot/imx6ul-ts4100-3f.dtb" does not exist, then U-Boot will fall back to the default "/boot/imx6ul-ts4100.dtb" file which is also used for the TS-4100 standalone.
  • If deriving from an existing baseboard design, be sure to update the associated Device Tree file to match any changes that have been made.
  • See the TS-8551 latest schematic for an example of how this circuit should be designed.


Jumpers

  • U-Boot on the TS-4100 expects the following jumpers. These are not required for operation since U-Boot can be reconfigured, however, any changes or modifications to this should be made with caution.
    • An "SD Boot" jumper on CN1_098. When logic low, U-Boot will default to booting to Linux on the SD card. When logic high, it will default to booting to Linux from the on-board eMMC.
    • A "U-Boot" jumper on CN1_019. When logic low, U-Boot will attempt to boot from a USB device before dropping to the U-Boot shell. When high, the unit boots normally through U-Boot.
    • A "No Charge" jumper on CN1_091 (Only required if implementing TS-SILO Supercapacitors on the baseboard!). When logic low, disables the automatic charge process. When logic high, automatic charge process is started by U-Boot. Note that the charge process can be started manually from U-Boot or Linux userspace tools, see the TS-SILO section of the manual for more information.
      • If TS-SILO is unused, it is recommended to add a weak pull-down on this pin to prevent U-Boot from starting the charging process automatically. If this DIO is unused, it can be directly connected to ground.
    • Some baseboards implement a tactile push switch on CN1_073. The ability for U-Boot to use this for entering the U-Boot shell is whitelisted. That is, U-Boot maintains a short list of compatible baseboard IDs that implement the push switch. Baseboards not using an ID on this whitelist will cause U-Boot to ignore this input for controlling its boot flow.
  • See the TS-8551 latest schematic for an example of how these jumpers could be set up.


TS-SILO

  • Due to the size constraints of the TS-4100, TS-SILO operation requires components added to the baseboard.
  • A pair of 2.7 V, 25 F supercapacitors must be used in series. The supervisory microcontroller handles the charging circuit and is tuned for these parameters. The TS-8551 uses a pair of Maxwell Technologies "BCAP0025P270X01" devices. Equivalent parts may be substituted, but it is recommended to verify the operation of them completely before putting them in production.
  • The highest potential of the series as well as the junction point of the two supercapacitors must be connected to the TS-SOCKET connector in order for the microcontroller to monitor the charge rate. Additionally, a balanced driving circuit must be present on the baseboard; this consists of a pair of transistors and high-precision resistors.
  • See the TS-8551 latest schematic for an example of how this circuit needs to be designed.


CAN

  • The baseboard is required to have a CAN transceiver if CAN from the TS-4100 is to be used. Be sure to use a transceiver that is compatible with the bus speeds being used. We recommend and use NXP "TJA1050" transceiver ICs.
  • CAN enable can be set up on a GPIO pin if desired. The kernel is able to use this pin to enable and disable the transceiver when the interface is brought up or down in Linux. This enable pin can be shared by both CAN buses if both interfaces are used.
  • See the TS-8551 latest schematic for an example of how this circuit should be designed.


RS-485

  • The baseboard needs to implement an RS-485 transceiver for RS-485 communication. Be sure to use a transceiver that is compatible with the bus speeds being used. We recommend and use Sipex "SP485EEN" transceiver ICs.
  • The kernel handles RS-485 half-duplex TX enable via a CPU GPIO pin. On our stock compatible baseboards, this defaults to SPARE_1 and requires crossbar MUX setup to assign the SPARE_1 input to the DIO_12 output. This is simply to accommodate how we have set up the TS-SOCKET standard in the past and allowing the TS-4100 CoM to be compatible with it.
  • When placing an RS-485 transceiver on a custom baseboard, the TX enable can be wired to DIO_12 (CN1_067), and the paradigm above can be followed. However, it is also possible to connect this pin to any unused CPU GPIO pin, and specify this pin in the Device Tree file for TX enable control. This no longer follows our standard pinout, but it does eliminate the need to set up the crossbar MUX on every boot.


RTC

  • While the TS-4100 includes an RTC inside of the SNVS block of the CPU, we do not recommend using it for most cases. The CPU based RTC consumes more power from the backup battery than other off the shelf devices. We recommend using an STMicroelectronics "M41T00S" I2C RTC on the baseboard connected to the I2C pins CN2_028 and CN2_030, with a backup battery also on the baseboard connected directly to the RTC, and the V_BAT pin (CN1_036) left unconnected on the baseboard. This design and layout has been proven on the TS-8551 development baseboard.
  • If using the CPU RTC, we suggest using a rechargeable coin cell or supercapacitor to increase the lifetime of the backup power source. Note that charging logic must all be situated on the baseboard, and that V_BAT (CN1_036) never receives more than its nominal 3.3 V input.
  • See the TS-8551 latest schematic for an example of how this circuit should be designed.


12 Revisions and Changes

12.1 TS-4100 PCB Revisions

Revision Changes
A
  • Initial Release
B
  • Removed power toggle for FPGA_3.3V
  • Added additional resistor straps to determine build type
  • ETH_PHY_IRQ disconnected
  • Added pullups to phy pins 19/30 for correct strapping
  • PHY uses FPGA DIO for reset
  • Added supercap fixes
  • Remove U19 FPGA reset IC, using CPU GPIO instead
  • Allow power to be switched to the eMMC
  • Added pulldown on SPI MOSI to identify REV B boards
  • OFF_BD_RESET# has 47K pulldown resistor
  • No CHRG jumper moved to FPGA IO
C
  • Add pullup to eMMC enable
  • Adjust RAM voltage to 1.5 V to be compatible with standard and low power
  • EXT_RESET# now able to cause microcontroller reset
  • SD pullup to SD_POWER rail, allows for proper 1.8 V UHS operation
  • Removed SD traces to TS-SOCKET, caused signal integrity issues


12.2 U-Boot Changelog

Revision Changes
July 2, 2019 Initial pre-production release


12.3 FPGA Changelog

Revision Changes
0x0A Initial pre-production release
0x0B
  • Disconnect PHY_RESET# from crossbar SPARE_3
  • SPARE_3 and SPARE_2 assigned as crossbar inputs to wifi control signals (needed for 4.9 kernel driver)


12.4 Software Images

12.4.1 Debian Changelog

Revision Changes
ts4100-armhf-stretch-20190702.tar.xz Initial pre-production release.


13 Product Notes

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


13.2 Limited Warranty

Technologic Systems warrants this product to be free of defects in material and workmanship for a period of one year from date of purchase. During this warranty period Technologic Systems will repair or replace the defective unit in accordance with the following process:

A copy of the original invoice must be included when returning the defective unit to Technologic Systems, Inc. This limited warranty does not cover damages resulting from lightning or other power surges, misuse, abuse, abnormal conditions of operation, or attempts to alter or modify the function of the product.

This warranty is limited to the repair or replacement of the defective unit. In no event shall Technologic Systems be liable or responsible for any loss or damages, including but not limited to any lost profits, incidental or consequential damages, loss of business, or anticipatory profits arising from the use or inability to use this product.

Repairs made after the expiration of the warranty period are subject to a repair charge and the cost of return shipping. Please, contact Technologic Systems to arrange for any repair service and to obtain repair charge information.

WARNING: Writing ANY of the CPU's One-Time Programmable registers will immediately void ALL of our return policies and replacement warranties. This includes but is not limited to: the 45-day full money back evaluation period; any returns outside of the 45-day evaluation period; warranty returns within the 1 year warranty period that would require SBC replacement. Our 1 year limited warranty still applies, however it is at our discretion to decide if the SBC can be repaired, no warranty replacements will be provided if the OTP registers have been written.