The TS-7552 was released Jan. 2010. It is in a larger form factor than the TS-7550/TS-7500 but contains both XNAND and microSD socket, extra USB ports due to the inclusion of a onboard USB hub chip, an optional 802.11bg wifi radio, and a DB9 containing 2 RS232 serial ports, 1 RS485 port, and 1 CAN bus port. A metal enclosure with wifi antenna mount is also available for the TS-7552.
The KIT-7552 includes the items that are necessary for development with the TS-7552.
The RC-DB9 brings out the 10 pin connection to a DB9. See the RC-DB9 page for the exact pinout. The red line indicates pin 1 and should be lined up with the white dot on the board.
The TS-9448 console board allows you to control the boot media with the switch, reset the board, and you can even boot to the offboard flash by setting JP1 on this board. The TS-9448 also brings the TTL console (ttyS0) to RS232 on a standard 10 pin header. The RC-DB9 is also pictured to bring out console. For new development, you can also instead use the TS-9449 (not included in the kit) at the same cost which brings out a USB port that can be plugged into your workstation which eliminates the requirement for a serial on your workstation.
This is a 12V 1A DC power supply on a center pin positive barrel connector. Optionally type I or C adapters are available and will ship with the product if ordered to a country where this specific adapter is required. If you require one of these adapters it is recommended to put this in the comments for your order.
The TS-9449 console board is an alternative to the TS-9448. This board converts the TTL console to a USB serial device using an FTDI chip.
The WIFI-G-MINIPCI is a QCOM wifi adapter. See the WIFI-G-MINIPCI page for more details on using this device. Keep in mind that while this uses the mini PCI-E form factor, this device uses the USB pins on this header. The TS-7552 does not have any PCIE or PCI lanes.
The CB-ANT-MINIPCI includes an I-PEX connector to an RP-SMA female adapter, as well as an antenna.
The TS-ENC755 is a metal enclosure for the TS-7552.
The TS-ENC755-DIN is the TS-ENC755 with a DIN rail mount.
With the development kit you should have the TS-9448, or optionally the TS-9449. Either will connect to the 26 pin header labelled JTAG with the console board away from the board so it hangs off the board.
Note: You can also hold the button (SW1) on the TS-7552 for 5 seconds to redirect console to XUART port 0 on the DB9 on the TS-7552.
So in this case my device is "/dev/ttyUSB1". These are allocated numerically so if you do not have another usb serial device it may be "/dev/ttyUSB0". If you do not see this device you will need to see your distribution's support for adding the ftdi_sio driver. New versions of Ubuntu/Debian/Fedora and most popular distributions include this by default.
If you're in Windows XP or above the USB FTDI driver will be autodetected if you allow it to search for drivers on Windows Update. If you go into "Device Manager" you will see the COM# device that was allocated.
In this example, my COM device is COM5.
The TS-9448 board connects to your workstation through a db9 serial cable. Connect the RC-DB9 to the TS-9448 lining up the red wire with the white dot on the "Console" 10 pin header. The CB-705 null modem cable which crosses the RX/TX pairs included in the kit connects to the RC-DB9. On your workstation you will need to determine which UART you are using.
Under Linux these will typically show up as /dev/ttyS0 or a similar number if they are connected through pci, or embedded in a laptop. If you're using a USB to RS232 device these will show up as /dev/ttyUSB#. On Windows you will need to check the device manager to get the COM device from the "Ports" section.
The console from either UART will use 115200 baud, 8n1 (8 data bits 1 stop bit), and no flow control.
The TS-7552 has 3 ways that it can be powered. The development kit includes a wall wart power supply that can be connected to the barrel connector which provides 1A@12V. The barrel connector input supports 8-12V. There is a terminal block connector that can also provide 8-12V. The third option is to use the USB device port which can provide 500mA@5V.
WARNING: Do not use multiple power connections simultaneously or you may damage the board.
This output will only appear on the serial console on the 26 pin header and cannot be redirected like the rest of the booting messages. The "Booting From" message will indicate your boot media. The 3 dots after indicate steps of the booting procedure. The first dot means the MBR was copied into memory and executed. The next two dots indicate that the MBR executed and the kernel and initrd were found and copied to memory.
When you first apply power to the board, the logic values on the MODE1 and MODE2 pins are latched. These signals decide if you boot from the MicroSD, XNAND, or offboard flash. Keep in mind this only includes the initial boot of the kernel and initrd, but once the initrd is booted you can load the Debian partition from the XNAND, SD, USB drive, or an NFS root regardless of your initially booted media. Most common cases will boot from only one media.
The typical case for a production unit does not contain the development boards so you can just use the "SD Boot" jumper to control the boot device. If the SD boot jumper is on as expected it will boot to the MicroSD slot if there is a card available. If there is no jumper then it will boot to XNAND. If the SD card is not detected on boot, it will fall back to the XNAND. The XNAND however will not fall back to the SD card. Both the MODE1 and MODE2 signals are also available on the #26 Pin Header and can be influenced by the TS-9448/TS-9449 development boards.
The MODE1 and MODE2 signals both have 4.7k pull-ups. For a logic 0 these should be pulled to ground with a 680ohm resistor.
The offboard SPI flash is only present with the TS-9449/TS-9448. The TS-9449 shows the MODE signals with an LED. The TS-9448 controls the modes through the switch, and JP1.
Note: Your version dates may be different depending on ship date and the image used. On newer units, "Offboard SPI" and "Onboard SPI" flashes may show "unknown" for the type. This is purely cosmetic and is no cause for concern. The SPI flash can be queried with the 'spiflashctl' tool which will return a proper manufacturer and device ID.
This is a busybox shell which presents you with a very minimalistic system. While this has access to many Debian applications, it is important to note that this is not Debian. This environment will allow very fast boot times closer to 2-4 seconds, while Debian takes closer to 30-45 seconds but provides an init system and a more standard environment. As described in the previous section, the kernel and initrd are copied into RAM so any changes to this filesystem are temporary. You can commit changes using the "save" command.
linuxrc-fastboot (default) Boots immediately to a shell in ramdisk. This will mount whichever boot medium you have selected to /mnt/root/. When you type 'exit', it will boot to that medium.
linuxrc-nandmount Same as the linuxrc-fastboot script, but will mount and boot the debian partition from NAND.
linuxrc-sdmount Same as the linuxrc-fastboot script, but will mount and boot the debian partition from SD.
linuxrc-sdroot Boots immediately to the Debian stored on either SD or NAND depending on which media the SBC was booted from.
linuxrc-sdroot-readonly Same as linuxrc-sdroot, except it will mount the Debian partition read only while creating a unionfs with a ramdisk. Changes will only happen in memory and not on disk.
linuxrc-usbroot Mounts the first partition of the first detected USB mass storage device and boots there.
The small default initrd is only 2Mbyte but there is space for approximately 800 Kbyte of additional user applications. This constraint is important if you are running your application without Debian, but only from the initrd. If you have the Debian partition available you can access that partition under /mnt/root/ to run your application.
will act like whatever it was invoked as!
For development it is recommended to go boot to the full Debian where there is plenty of space for development work. Debian provides many more packages and a much more familiar environment for users already versed in Debian. Once here you can use apt-get to install/remove packages, configure the network, and perform other common tasks.
From almost any Linux system you can use "ip" or the ifconfig/route commands to initially set up the network. To configure the network interface manually you can use the same set of commands in the initrd or Debian.
To make your changes permanent in the initrd you will need to edit the linuxrc script. Use the same commands you would use to manually configure it and place them over the current ifconfig calls.
Debian provides the apt-get system which lets you manage prebuilt applications. Before you do this you need to update Debian's list of package versions and locations. This assumes you have a valid network connection to the internet.
For example, if you wanted to install picocom you could use the apt-cache command to search the local cache of Debian's packages.
You can often find the names of packages from Debian's wiki or from just searching on google as well.
To make your application startup from the initrd you only need to add the required lines (no need for the Debian init syntax) to the linuxrc script. Usually the best place to add in your application is right after /mnt/root/ is mounted so the Debian libraries and applications are available.
This board optionally supports 802.11 through the #WIFI-G-MINIPCI, or the #WIFI-N-USB module. Both of these use ralink chipsets which will show up as ra0 or rausb0. These examples will use rausb0, but replace this with your devices interface.
rausb0    RT73 WLAN  ESSID:off/any  Nickname:""
iwconfig rausb0 essid "default" key "yourpassword"
When you have successfully connected, it will list an "Access Point" bssid, and a "Link Quality" of greater than 0/100.
rausb0    RT73 WLAN  ESSID:"default"  Nickname:""
Now you are connected to the network, but this would be close to the equivilant of connecing a network cable. To connect to the internet or talk to your internal network you will need to configure the interface. See the #Configuring the Network for more information.
Click to download the latest 2GB SD card image.
The resulting file will be "2gbsd-noeclipse-latest.dd".
For imaging the SD card we recommend using a Linux or similar operating system that allows you to access a block device using dd. We do not support rewriting the SD card from Windows.
On this system my SD card block device is /dev/sdb, but your system will likely be different. The block devices are allocated in order by the letter so the next USB drive connected would be /dev/sdc. On some newer kernels you will see '/dev/mmcblk0' as the block device and '/dev/mmcblk0p1' for the first partition. For these examples I will use the '/dev/mmcblk0' format.
WARNING: Many distributions will name your hard drive something like /dev/sda or /dev/hda which will have the same naming scheme as an SD card or a USB drive. Make sure you are aware which device is which before writing the disk. Technologic Systems is not responsible for any data lost/destroyed because of improper command execution.
WARNING: If you are working with the SD card from your workstation, keep in mind that most Linux distributions will mount the partitions that they can as soon as the drive is inserted. This is desirable if you want to open the filesystem, but for dealing directly with the block device for performing backups or restoring an image this is dangerous to your data.
# look for your SD card block device to see if this is already mounted.
If the block device did automatically mount, you will need to refer to your distribution's documentation for disabling automounting. For example, this is Ubuntu's documentation on disabling automounting. If you are not using a graphical Linux system this should not be a concern, but make sure no filesystems are mounted read only or read write while writing or reading an image.
To write the latest image or restore to stock you would use the dd command. This will perform a byte for byte copy from our image. This contains the MBR boot code with the partition tables, the kernel, initrd, and Debian filesystem. No other formatting or partitioning is needed.
This will create a dd file the size of the card.
Note: A MicroSD card from one manufacturer will likely not be the exact same size as another manufacturer's MicroSD card of the same size. Our partition layouts by default leave the last 10% of the images unallocated to account for the size difference of various manufacturers MicroSD cards. As long as you use our partition layout you should not need to be concerned with this, but if you create your own layout we strongly recommend leaving 10% of the disk unallocated.
Keep in mind these numbers are an example and are not necessarily representative of your image.
If you would like to backup just the Kernel partition, you would grab partition 2.
This will create an image file the size of the card.
If there is no /mnt/root/ directory then the system is still booted to Debian and you should not proceed with the backup/restore sections. The image that is written or read back will be corrupt.
WARNING: Rewriting the XNAND from a Debian filesystem on the XNAND will result in a corrupted image.
The resulting file will be "xnandimg-latest.dd".
To create the image first connect a USB drive and then power the device on. Boot to the busybox environment and not the full Debian. The USB drive should be formatted with ext2/3 or fat32.
To write the image first connect a USB drive with the image and then power the device on. Boot to the busybox environment and not the full Debian. The USB drive should be formatted with ext2/3 or fat32.
Some of this series contains a 4MB SPIflash embedded on the board that can be written to by specifying lun 0, or "-l 0" which will use that chip select. The offboard flash found on various baseboards, or console boards like the TS-9448 or TS-9449 can be written to using lun 1, or "-l 1".
Since the Aug 5 2010 release, scripts have been added to the bash subroutine to ease in saving, recovering, and moving around images from one flash device to another. Below is a brief list of the commands that are provided as well as what they do. See the file /ts7500.subr (or /initrd/ts7500.subr from full Debian) for more information on the commands and what they do.
Most of our examples are going to be in C, but Debian will include support for many more programming languages. Including (but not limited to) C++, PERL, PHP, SH, Java, BASIC, TCL, and Python. Most of the functionality from our software examples can be done from using system calls to run our userspace utilities. For higher performance, you will need to either use C/C++ or find functionally equivalent ways to perform the same actions as our examples.
While the onboard tools are recommended for development, some applications can reach a size where the compile time is not feasible. An example of this is the Linux Kernel which will take 5-10 minutes to compile on a typical X86 workstation, but it can take 7-15 hours to compile on the SBC depending on several factors. A hello world application in comparison will take only a couple seconds on the board.
Cross compiling has a complication in that the onboard libraries do not exactly match the cross compiler environment. Debian has around 15,000 to 20,000 packages available in the apt repositories, and there is no way to feasibly build a cross compiler to account for all of these libraries. If you are cross compiling you will need to have your application entirely self contained and linking to any third party libraries in your build system.
Note: We do not support third party cross compilers.
Note: The provided cross compilers are only for C development.
The TS kernel is built from the same Linux sources Cavium Networks has tested and used on their CPU evaluation boards. There are no Technologic Systems specific drivers or kernel support implemented. Instead, there has been userspace driver support implemented for the SPI NOR flash, MicroSD cards, XNAND drive, battery-backed real-time clock, XUART serial port channels, watchdog, and GPIO pins. This allows easy migration to newer kernels when either Cavium or the mainline Linux kernel community creates them. In the past, constant Linux-internal API redesign required rewriting and revisiting custom drivers with each new kernel revision, in effect locking customers in to whatever kernel version was released and tested during initial product release. Being free to update to newer kernels in the future allows easier support of the new USB devices as those drivers tend to only be developed for the newest kernel sources.
We provide Linux 2.6.24 as the supported kernel.
WARNING: Backup any important data on the board before replacing the kernel.
Note: If you get the message "Make: *** mixed implicit and normal rules. Stop." Then you may need to downgrade your version of make.
This will bring up a graphical menu where you can edit the configuration to include support for new devices. For Example, to include CIFS support, use the arrow and Enter keys to navigate to Filesystems -> Network File Systems -> CIFS Support. Press "y" to include CIFS support into the kernel (alternatively, you could modularize the feature with "m" so you can enable or disable the module on demand which will also enable you to simply copy/paste the cifs.ko into the correct path in the kernel instead of copying the entire kernel (outlined below in appendix)). Keep hitting "exit" until you're prompted to save changes, choose "yes".
Once you have it configured, start building. This usually takes a few minutes.
The new kernel will be at "arch/arm/boot" in a compressed format called "zImage". The uncompressed version is simply called "Image". With the default partitioning scheme it is REQUIRED that the kernel be < 2096640 bytes in size. If you need to shorten the size, try including your changes to the kernel as modules instead. Otherwise you will need to resize the kernel partition to account for the size difference.
Now that you have a kernel you can install it as you would our stock. See the #Backup / Restore section for examples on writing this to disk.
Now we need to install the modules.
After you install the new modules, you will need to boot the kernel and run "depmod -a" to rebuild the dependency map. You can them use modprobe to load the individual modules.
You can also copy individual modules to your existing kernel assuming the kernel is the exact same version as the installed one.
If you require functionality from a newer kernel, we also provide sources for the 2.6.36 kernel patched with support as-is. You can find the sources here. You will need to also use this toolchain. The rest of the steps for building the kernel are the same. This kernel should function the same as the other, however the USB device driver is not implemented. We strongly suggest using the 2.6.24 kernel unless you have a requirement for a later kernel as the 2.6.24 is supported and has gone through much more testing through various productions.
We also now have a copy of a 3.4.0 kernel source here. These same instructions are applicable but you will need to use this toolchain instead of the one used with 2.6.24.
This board features a CNS2132 250MHz ARM9 processor. For more details see the CPU Datasheet.
This board features a Lattice LFXP2 FPGA. The CPU connects to the FPGA using SPI, and since access to SPI is not atomic we have implemented the SBUS as a safe way for multiple processes to access FPGA registers.
If we do not have a configuration you need, you can build a new bitstream, or contact us for our engineering services.
The released FPGA has undergone minor bug fixes throughout the product liftime.
2 SPI controller supports lower speeds and CS# bit in reg. RS485 RX is now muted while transmitting.
Note: We do not provide support for the opencores under our free support, however we do offer custom FPGA programming services. If interested, please contact us.
The opencore FPGA sources are available here.
For more advanced changes you may look to opencores.org which has many examples of FPGA cores. To build the FPGA with your new changes, go to the 'Processes' tab and double-click 'JEDEC File'. This will build a jedec file in the project directory. On a linux system, either x86 compatible or ARM, we provide an application called jed2vme.
We also have the sources here.
WARNING: Do not use the 'jed2vme' provided by Lattice. Their version writes to flash and as the opencores do not contain the bootrom so this will brick your board.
As space is constrained in the initrd it is suggested to gzip the file as shown in the jed2vme example. To load this bitstream automatically you can place it in the root of the initrd and name it '/ts7500_bitstream.vme.gz'. The linuxrc script will by default load this bitstream immediately on startup (before the fastboot shell). You should first test it manually to make sure it loads ok.
The FPGA contains flash memory which contains Technologic System's default FPGA flash load. Using an SRAM bitstream generated by our "jed2vme" with "ts7500ctl --loadfpga" will not overwrite the flash memory of the FPGA and will only load the SRAM contents of the FPGA, making for an unbrickable system.
The RTC connects through I2C to the FPGA. Typically, the battery-backed real time clock is only set or read in the linuxrc bootup script by the ts7500ctl utility. It is only necessary to read the RTC once per bootup to initialize the Linux time of day. This is done with the command "ts7500ctl --getrtc". To set the RTC time, you simply set the Linux time of day (with e.g. the "date" utility) and then run ts7500ctl --setrtc. RTC's are already set before shipment to atomic UTC time and should hold time within 15 PPM while at room temperature.
WARNING: Be careful when handling board with a battery inserted -- the battery holder leads are through-hole and should the board be placed on a conductive surface and short the battery leads, the RTC will loose its track of time and need to be reset.
Note: NBD devices report their size as SIZE_MAX for more flexibility when using them with nandctl. If you are formatting a partition or using dd you will need to specify the size of the block device or partition.
XNAND2 is an innovation built upon its XNAND predecessor. This engineering effort was predicated by the NAND industry's falling quality standards and Technologic Systems' dedication to continued superior quality, long lifespan products. XNAND2 introduces a more robust system of redundant, error-corrected data storage, and a whole-device wear leveling system that ensures the longest possible lifespan for NAND media.
Please see our whitepaper on the subject for more detail and information.
To facilitate this new paradigm, a new 'nandctl' binary has been introduced. The features and output of this new utility are detailed in this section.
Technologic Systems NAND flash manipulation.
devices and partitions for the NBD servers starting at port 7525.
port 7526 serving the whole disc device of chip #1.
The --dmesg command will show a running event log since boot. This is useful for troubleshooting if a failure is suspected.
This --stats output is helpful for systems where monitoring long-term health is useful.
nbdpid: This is the process id of the nandctl process.
nbd_readreqs: This is the number of read requests received by nandctl since boot.
nbd_read_blks: This is the number of blocks read by the nbd client since boot.
nbd_writereqs: This is the number of write requests received by nandctl since boot.
nbd_write_blks: This is the number of blocks written by the nbd client since boot.
nbd_seek_past_eof_errs: This statistic should always read zero. It's the number of times the OS has asked nandctl to seek past the end of the media.
xnand2_most_worn: This is the number of writes that have been made to the most worn block on the NAND chip over the lifetime of the XNAND2 media.
xnand2_spares_used: This is the number of bad blocks marked by XNAND2 over the lifetime of the XNAND2 media.
xnand2_spares_remaining: This is the number of blocks not currently in active use by the disk block device or the RAID5 like redundant data backup. They are available to participate in wear-leveling activities (along with the blocks used by the disk block device and redundant data).
xnand2_total_erases: This is the number of erases over the lifetime of the XNAND2 media since boot.
xnand2_ecc_fixups: This is the total number of ecc correctable errors XNAND2 has corrected since boot.
xnand2_parity_recovers: This is the total number of blocks XNAND2 has had to recover from parity data.
read_seeks: This is the number of read seeks done since boot.
write_seeks: This is the number of write seeks done since boot.
You can find the new nandctl binary here.
An XNAND2 formatted NAND device will work on supported products with any bootrom date, whether or not the bootrom supports XNAND2. However, devices can only be booted from the XNAND technology that their bootrom supports. An XNAND2 formatted NAND cannot be booted from a bootrom that only supports XNAND1 and vice versa. This allows for application support of XNAND2, regardless of bootrom support, but only if NAND is not the boot media. Because of this, it is important to update all programming and production processes to support XNAND2. For other production preparation processes that do not re-image the entire device, it is still important to confirm the production process is using the XNAND2 nandctl binary dated October 2016 or later. The following section provides the necessary information to update an existing XNAND1 image with the new XNAND2 nandctl software.
The latest nandctl binary is compatible with both XNAND1 and XNAND2; however it will assume that disk initialization will be targeted at XNAND2 support and it is not possible to force XNAND1 formatting. Because of this, the bootrom should be updated to be compatible with XNAND2 before using '--xnandinit' against a NAND device using the latest nandctl binary. TS-BOOTROMs with a date after October 2016 are compatible with and able to boot XNAND2 devices.
This update will walk through the steps of updating the nandctl binary contained in a customized production image. These steps are not necessary when using our stock image, only if your production process is using an SD or NAND image that has been based on any of our previous shipping images. Note that both SD and NAND images should be updated to properly support XNAND2 in all situations.
To prepare this update, a workstation running linux is necessary, either in a virtual machine or native install. From the workstation, open a terminal window and copy your original production image file to a local working directory (this is done to limit working on production used images). This file will be referenced as diskimg.dd in the following instructions. The latest XNAND2 compatible nandctl binary (link to download is at the top of this section) should also be downloaded in the same working directory.
The above is the partition table of an XNAND disk. An image for an SD card will have 4 partitions rather than 3, but the same basic layout. The necessary information is the start sector of the second partition with the Id of "da," and the "Sector size" listed above the partition table. In this case it is partition 2 in which the start block is 5120 and the Sector size is 512. Multiply the two numbers to obtain the necessary offset: 5120 * 512 = 2621440.
The XUART ports will be controlled with xuartctl. By default they will not have devices in /dev/.
ttyS0 (console) TTL pins 7 (TX) and 8 (RX) of the #26 Pin Header.
XUART0 RS232 pins 3 (TX) and 2 (RX) of the #DB9 Port.
XUART1 RS232 pins 7 (TX) and 8 (RX) of the #DB9 Port.
XUART2 RS485 pins 1 as + and 6 as - on the #DB9 Port.
Note: NBD devices report their size as SIZE_MAX for more flexibility when using them with sdctl. If you are formatting a partition or using dd you will need to specify the size of the block device or partition.
The SPI flash is also implemented in userspace with NBD, however it is not mounted or running by default. Even when you are booted to SPI, it does not need to access it directly since the bootrom will load it into memory before the Linux kernel is even executing. If you want to mount any part of it see the spiflashctl page for usage.
The FPGA contains a SJA1000C compatible CAN controller that can be accessed using canctl which provides a CAN network service. Any application on the network can make use of this service to send or receive CAN packets using the API defined by canctl. Thus, it is possible to develop code written in other languages (java, python, etc.) and/or to run this code under other operating systems.
Technologic Systems CAN controller manipulation.
The canctl application implements network CAN functionality using the can_rx_remote() and can_tx_remote() functions. These functions which read and write one fixed-size packet of struct canmsg to a TCP socket descriptor. Writing your own canctl client in the language of your choice is as simple as doing the same thing. The format of the each CAN packet sent or received via the network interface is described below. The terms "Rx" and "Tx" are relative to the client, so "Rx" would describe packets read from CAN over the network and "Tx" would describe packets written to CAN over the network.
canctl server to allow control functionality.
CAN packets which pass the filter will be received.
id compared to corresponding bit in received id).
UINT32 values are sent in little-endian format.
See the SBUS page for more details on using the SBUS in your application.
0x64 15-0 Read Only 16-bits of random data changed every 1 second.
This board brings out only FPGA DIO. Since the FPGA is connected to the processor using SPI which is not atomic, we have created the SBUS which allows safe access from multiple processes. The SBUS mechanism of locking as well as it being a serial bus to the FPGA does put a limit on how fast the DIO can be read or set. Depending on the needs of the application the code can be structured to provide a bit of flexibility in speeds.
You can also interface with this DIO in C using the example here.
Using this method of an atomic read-modify-write will achieve about a 20KHz wave with a 50% duty cycle.
Using this method of atomic writes will achieve about a 30KHz wave with about a 20% duty cycle.
The SBUS link between the FPGA and CPU is SPI with a 16-bit data frame per bus cycle. When setting and reading one pin at a time, a whole 16-bit cycle is used to accomplish the needed goal. If multiple pins need to be set or read at once, a performance gain can be had from reading/writing entire 16bit registers at a time as opposed to iterating through each pin sequentially.
Other factors can contribute to speeds of the SBUS. Since the SBUS is shared across multiple peripherals there could be bus contention. It may also be that there are very few other applications wanting access to the bus, it all depends on usage. There is more overhead in doing a sbuslock() and sbusunlock() after every transaction than there would be to queue up transactions, lock the bus, and then do them all at once. There is also another function provided in sbus.c that is a smarter version of sbusunlock(), it is called sbuspreempt(). sbuspreempt() will check to see if any other applications are blocked in acquiring the lock, if there are, the SBUS is unlocked, giving other applications access to it. If there are no other applications waiting for the lock, the current application retains the lock. The benefit of this, is next time sbuslock() is called, the function returns almost instantly because the lock is already held. This greatly reduces overhead.
It may be necessary to "tune" an application with locking, unlocking, and preempting the SBUS to find what works best if speed is a factor.
The DIO registers are described in the #Syscon section. This board has 40 logical DIO registers on the FPGA to remain consistant with the series, but not all of the pins are brought out. DIO 9 by default is an external reset which is pulled high, and when it is set to 0 the board will reboot. You can disable this functionality by clearing bit 4 of 0x76 in the #Syscon.
The FPGA has a random number generator. On startup, ts7500ctl is called with the --setrng option to seed Linux's random number generator from the hardware random number generator. Without a good source of entropy, Linux's random number generator will start up in a very predictable state which is undesirable for the security of many cryptography protocols.
This board does not bring out any CPU DIO directly, so to access any IRQs you would require an FPGA customization. There are 2 IRQs connected to the FPGA which are typically used for CAN or the XUART core. The XUARTs by default will poll at 100hz which will be acceptable for most applications accessing the UARTs so this IRQ may not be required. See the #FPGA Programming section for more details.
The I2C_SCL and I2C_SDA pins bring out the I2C bus from the CNS2132 CPU. We do have an example for connecting to the I2C bus that uses the temperature sensor used on some of this series. You can find the C example here.
Please refer to the CNS2132 user's guide, page 55, 144, and 312 for more information on this I2C bus.
This core is for high speed SPI with auto-CS#. Starts at offset 0x40 on the this series. Chip select #0 is typically used for onboard spiflash. Chip select #1 is used for offboard spiflash. The last 2 chip selects are always available on the Cavium series boards.
Technologic Systems SPI controller manipulation.
The data stream packet to a spictl server consists of opcodes and operands. Each opcode is one byte long and may encode part or all of the operand. Some opcodes specify that additional bytes of data follow to contain the remainder of the operands.
The chip number is encoded in the two LSB.
If Bit 5 is set, OPCODE = ASSERT CHIP SELECT.
The number of bytes to write is encoded in the same manner as for a READ opcode. After the opcode byte, the number of bytes to write follows as the operands.
This opcode encodes identically as the WRITE opcode. However it specifies that bytes are to be READ as well as written.
You can also use the spictl --server=<port> and run a second invokation of spictl with --port=<port> to have the second instance act as a client to the server. You can then use tcpdump to see the exact tcp packets being sent back and forth for various operations.
The SPI clk state register should be set when CS# is deasserted. Value 0 makes SPI rising edge (CPOL=0), 1 is falling edge (CPOL=1). This only applies to speed >= 1. For speed == 0, SPI clock polarity/skew must be set from the PLL phase adjust registers in the syscon block.
Bits 10-15 were not present on TS-75XX FPGA prior to rev 4. On those TS-75XX's, SPI speed was hardcoded to 75Mhz and 75Mhz only.
The pipelined read register is for read bursts and will automatically start a subsequent SPI read upon completion of the requested SPI read. Reading from this register infers that another read will shortly follow and allows this SPI controller "a head start" on the next read for optimum read performance. This register should be accessed as long as there will be at least one more SPI read with CS# asserted to take place. This register is an appropriate target address for SBUS burst reads.
The CNS2132 features a 10/100 Ethernet port. The str8100 ethernet driver provides abstraction to the hardware as a standard linux ethernet interface. You can find instructions on using this in Linux here.
This board features a 50mm MiniPCI express header. The only connected pins on this header are the ground pins, the 3.3V rail, and the USB data positive (36) and negative (38) pins. The CNS2132 processor does not have have any PCI-E lanes, but it does have USB which is used by many devices. This allows you to use devices internal to the board such as the WIFI-G-MINIPCI which only make use of USB for communication on this header.
The barrel connector supports 2.1mm barrel plugs. The power supply must be center pin positive, and supply between 8-28V.
This is a 5mm terminal block connector that can support 8-28V to power the board. The mating connetor is an OSTTH020160.
The Cavium CPU supplies standard USB 2.0 ports. The power to the USB can also be toggled by setting a DIO.
# from Debian you will need to source the subroutine file.
The TS-7552 features 4 USB type A hosts. There is also a USB host on the #Mini PCI-E Header for supported devices.
Keep in mind that you can only use the 5 pin header, or the USB3 header, but not both at the same time.
This board contain both USB Host and USB Device ports. This section will discuss the configuration and use of the Linux USB device gadgets (http://www.linux-usb.org/). The two supported gadgets are 1) USB Mass Storage Device and 2) IP over USB (A.K.A. USB Ethernet).
The USB Mass Storage Device Linux USB gadget will allow you to use your SBC as a storage device, like a USB thumb drive, when connected to a host PC. Subsequently, the SBC can access the saved data through the storage element named usb_storage_file.
The IP over USB (A.K.A. USB Ethernet) Linux USB gadget will allow you to connect to your SBC with a USB cable from a PC like you would with a CAT5 Ethernet cable. You will have access to the SBC via the TCP/IP connection allowing you to use any networking utility (e.g. ping, ssh, ftp, http, etc).
All software modules required for Linux are contained on recent SBCs (those released with the May 18, 2010 or later software load). For Windows, a driver interface configuration file (linux.inf) will need to be downloaded and installed on the host PC. This procedure is described in detail below. The linux.inf file can be downloaded here.
The USB Gadget file storage device will allow you to allow access to a block device (file or otherwise) over USB. To use this functionality, you must first have a block device to give to the driver. In this example I will use a 100MB file on the Debian filesystem.
Now on your workstation you can use this device as any other usb storage. As this file contains all zeros, you will need to format it and create a partition/filesystem to be able to store data on it. See the documentation for your workstation for more details. Keep in mind you cannot mount the same block device or file twice so this will not allow you to share your live filesystem over USB.
The board must be setup prior to connection to a host PC. These steps are outline below.
The IP address in the above example may be any valid IP address, but should typically not be on the same subnet as the Ethernet network on the the board (if connected), or the host computer to which the SBC will be connected.
Most modern Linux distributions already have all of the required modules (such as usbnet.ko) and utilities installed, so the setup steps are minimal. Simply plug in the board after it has been prepared for IP over USB (see above) and observe that a new interface has been added named usb0 or similar (use dmesg | tail to verify). You can now assign an IP address to that interface with ifconfig (e.g. ifconfig usb0 192.168.42.21) and begin using the TCP/IP connection. To test your connection, use ping 192.168.42.20. You should also be able to login to the SBC using ssh ie. ssh root@192.168.42.40.
Select Include this location in the search and choose the location of the driver you downloaded. Finish running the wizard.
Go to the Control Panel and open "Network Connections". Right-click the new connection (labeled "Linux USB Ethernet/RNDIS Gadget") and click "Rename". Rename it to something useful such as "USB Network".
Right-click on the newly labeled icon, and select properties.
Select Use the following IP Address, and enter 192.168.42.21.
You may now access the board via the TCP/IP connection. Use ping in the Command Prompt window to verify connectivity (e.g. ping 192.168.42.20).
Note: The IP address above may be any valid IP address, but must be in the same subnet as the IP address assigned to the board IP over USB connection above. The subnet used should also be different from any other interfaces on the SBC or PC, otherwise strange results may occur.
TS-7552 also includes a .1" pin spacing external header for board to board interfacing.
16 WD_RESET# 0-3.3V 1 Ground to reset the board.
None of the DIO pins are 5V tolerant. The FPGA DIO all support up to 3.3V with 12mA drive capability.
Note: Use of the JTAG pins for programming the board is not supported or recommended.
The CAN bus has optional termination resistor enabled by JP2 jumper. The termination resistor is 124 ohms across the CAN_H and CAN_L pins.
Disk corruption is a common issue in embedded development and considerations must be made for a robust system. When used correctly, the Sandisk SD cards we include should provide a total write lifetime of around 8TB.
It's been quoted from a Sandisk engineer that a third of the Sandisk branded flash cards on the planet are fake. We recommend Sandisk SD cards as that is what we use for our testing, but make sure you use a reputable source for acquiring any flash media.
We recommend avoiding ATP flash media as well as "Industrial SD cards". We have experienced corruption with Industrial Cards, though they seem to work if multiwrite is disabled but this makes the card extremely slow to write.
Most issues are caused by interrupting a write to the storage media by disconnecting power. In a normal Linux environment for a server or desktop the start up and shutdown sequences should be very predictable, but on an embedded system a safe shutdown cannot always be guaranteed.
The most common issue is when powering off SD cards in the middle of a write. SD cards usually use MLC NAND flash for storage coupled with a manufacturer and model specific firmware. The NAND flash has a limitation where in order to perform a single byte write it must first read about 128KB to 256KB (or more) containing that byte into memory and erase that sector on the NAND chip. This is the erase block size and can vary based on the card. It takes the block in memory, changes the single byte in that copy, erases the intended location on the flash and then commits it back to the disk.
Most SD card firmwares also contain a wear leveling mechanism where they maintain a logical to physical mapping. This means that writing a contiguous file may actually end up in different areas in the NAND chip. If you interrupt a write cycle where it has erased a block, but not yet committed changes to the disk it will have lost data seemingly randomly across the card. There are several strategies you can adopt to avoid or limit your chance of corruption.
The most safe method is possible if you do not need to perform any writes that need to persist across reboots. If you are designing a data logger this is certainly not a good option, but if you're only responding to outside I/O this is your best choice. Once you get your application developed and ready for deployment you should try running from the initrd. This is already a read only filesystem which will never write to the disk. Powering off in the middle of a read is still safe. You can still write data to /tmp/ which will go to memory, but it will be lost on a poweroff. If you require the full Debian filesystem you could use the linuxrc-sdroot-readonly startup script. This will mount the Debian filesystem on the SD card as read only, but will commit any attempted writes to a ramdisk using unionFS. The downside to this configuration while booting to Debian is that you have to manage all writes to the system or risk filling up your memory and causing a crash.
The next best method is to use a battery backup. Most UPS backup solutions, or one you build yourself should contain a method to see the battery level. Once you reach lower levels you can simply run a "shutdown -h now". When power is available the board will boot back up, but you may want to check in the initrd while it is read only if the battery is back to an acceptable level before making the SD card read/write.
The last option is to limit your writes to reduce the chance of corruption. Make all of your writes to a ramdisk like /tmp/ and copy them to the physical media periodically or when you know power will be safe. This is the option many consumer electronics choose. You can make writes more predictable by mounting with the options "sync" which will stop linux from buffering writes in RAM, and "noatime" which will prevent linux from writing access times when reading a file.
The usleep allows the user time to react to a new write. Most people should be able to react to an LED in about 215ms, but to be safe I would use a higher number.
You may also want to consider using the XNAND which from our testing has proven to be much more reliable with sudden power loss.
To prepare the USB drive, erase any existing partitions and replace them with a single FAT32 or EXT2/EXT3 partition. The script will attempt to mount /dev/sda1. The linuxrc script will execute a file on the drive named "tsinit". Make sure the script is marked as executable.
This example expects an xnand-image.dd and/or an sd-image.dd in the root of the flash drive. If you exclude either, it will still run while only programming one. Normally, it will begin programming both and wait for them both to finish executing. When the script exits, the red LED will turn off automatically.
# files you access must use that path.
You could also mount a network drive and write the image from NFS rather than keeping the image on the USB drive.
The issue appears to correspond to the length of cable used as well as the network device connected to the board.
You can force the cavium PHY to 10MB/s which drastically improves reliability, and in most cases eliminates the issue. This needs to be run each time the interface is brought back up. If link is lost you would need to reset the interface (ifconfig eth0 up && ifconfig eth0 down) and run the devmem command again.
This will disable the link speed auto-negotiation and force the PHY to communicate at 10Mb/s.
The TS-75XX image was updated as of Feb 11 includes extra version information that is printed by the linuxrc. This behavior has exacerbated a bug in nandctl that can cause the SBUS to get in a hung state. Using nandctl for access via NBD is and has always been safe, however using the -k or --setmbr options are potentially unsafe. The tsversions application used in the Feb 11th release uses the -k option and can get in to a hung up state. Please note that under rare circumstances this issue can cause NAND flash corruption and it is highly recommended to update to the latest nandctl.
TS-755X/TS-4500 products and images shipped on or after March 11th 2011 are not affected by this bug.
1) Simply disable the execution of tsversions and bootmsg in the linuxrc. Any linuxrc other than linuxrc-fastboot already have this disabled.
2) Download the new nandctl binary from our FTP site to /sbin/nandctl in the fastboot shell. If booted to the fastboot shell, remember to type `save` to save the initrd back to disk.
Affected All TS-755X/TS-4500 SBCs with a NAND chip marked with "SAMSUNG"
Will put the correct timing value in the timing register, however, this leaves the SBC vulnerable to this corruption until the command is issued.
The Cavium STR8100 NIC driver was programmed with 160ms delays when Ethernet is physically disconnected (see function static void internal_phy_patch_check(int init) of .../drivers/net/str8100/star_nic.c). This causes delayed responses in real-time applications such as canctl. When Ethernet is physically connected, the issue is nonexistent.