1 Can I emulate the software image?
If you want to emulate just the Debian environment you can do that quite easily using QEMU's userland emulation. On your Linux workstation you will need to install qemu-arm-static. If your workstation runs Debian you can find this as qemu-user-static. The qemu-arm-static application will emulate an ARM kernel.Refer to QEMU or your distribution's documentation for more details on setting this up. Once it is installed it will register with binfmt.
$ cat /proc/sys/fs/binfmt_misc/qemu-arm enabled interpreter /usr/bin/qemu-arm-static flags: OC offset 0 magic 7f454c4601010100000000000000000002002800 mask ffffffffffffff00fffffffffffffffffeffffff
What this means is that anytime your system tries to run an ELF binary that is detected to be ARM it will use /usr/bin/qemu-arm-static. For example, lets say you want to use the TS-4800 Debian distribution. You can download the distribution here.
wget ftp://ftp.embeddedarm.com/ts-socket-macrocontrollers/ts-4800-linux/distributions/debian-squeeze-latest.tar.gz # These next commands should all be run as root. mkdir fs cd fs tar -xf ../debian-squeeze-latest.tar.gz # Make sure this path matches the path used # by the interpreter. qemu-arm-static in my case must # be in /usr/bin/qemu-arm-static or it will not call the interpreter correctly. cp /usr/bin/qemu-arm-static ./usr/bin/ chroot .
This resulting shell will be in the TS-4800's debian environment, though keep in mind it will retain your hostname from the $PS1 variable. You can also mount the 4th partition of the SD card instead of extracting the root if you want to run your copy of the Debian FS instead of extracting this copy. You will still need to copy qemu-arm-static to the same path.
This will let you test ARM binaries, but this is not capable of emulating the hardware. If you need to test code that is talking to DIO, I2C, UARTs, SPI, etc then you will need to execute your code directly on the board. There are technical limitations such as emulating an FPGA in realtime, and legal restrictions such as emulating other companies intellectual property from various CPUs or other chips that make complete emulation impossible.
2 Where are the regulatory compliance documents?
2.1 Regulation and Certification
Technologic Systems believes it is in our customers' best interest that this testing be performed as few times as possible to minimize the extremely high cost of regulatory compliance. As most of our products are components of a larger whole, any testing and certification would of necessity be redone in a final product, negating some or most value gained by previous testing costs. To that end, Technologic Systems does not normally perform UL, CE, or other testing for regulatory compliance and consumer listing beyond such testing as required by US law. The result is a significantly lower per-unit cost to everyone involved. If your product requires such certification, please contact Technologic Systems' support engineers. We will help as much as we can to provide the information necessary to obtain the certifications you require.
2.2 UL 94v-0 Flammability Compliance
All PCB used in Technologic Systems hardware are UL 94v-0 compliant, and bear the applicable stamp. For documentation of this, please refer to the UL database. The document for the most common PCB printing house we use is located here: http://database.ul.com/cgi-bin/XYV/template/LISEXT/1FRAME/showpage.html?name=ZPMV2.E207844&ccnshorttitle=Wiring,+Printed+-+Component&objid=1074986192&cfgid=1073741824&version=versionless&parent_id=1073814637&sequence=1
3 What is the difference between Kernel Image and zImage?
Question: What is the difference between Image and zImage kernel images?
Answer: The only difference is that Image is uncompressed while zImage is compressed. You'd want to use the zImage file if you need to include many additional kernel features that could otherwise not fit on the kernel partition of a Technologic Systems SD card. Keep in mind that it will take the system a little longer to boot since it requires an uncompression first. For this reason, we recommend using Image when possible.
4 Can I install a different Linux distribution on a TS board?
Question: Can I run Ubuntu, Fedora, Suse, Red Hat, or Other Linux Distribution on a TS product?
Answer: You're absolutely welcome to download and compile whichever distribution you choose to on any of Technologic Systems Single Board Computers (SBCs). However, the effort to go through this process generally outweighs the benefits and is discouraged. Unless there is a specific reason to do so, we recommend sticking with the supplied distribution.
On a typical desktop Linux environment, the latest version of a distribution would provide not only updated binaries in the filesystem, but also an updated initrd and kernel. In the embedded Linux environment, you would simply be replacing the pre-loaded filesystem binaries and files with that of your favorite distribution. Locations of system files or folders might change, but the same kernel and initrd versions as before exist.
If you'd still like to pursue loading your preferred Linux distribution, you'll need to seek support through the Linux community. Debian is excellently simple to download and compile for use on our boards by way of debootstrap (http://wiki.debian.org/Debootstrap). We would recommend you start your journey by finding out if this utility (or one like it) is available for your distribution.
5 How do I install or update the XNAND Flash image?
Question: How do I update or install the XNAND image onto my XNAND-enabled SBC?
Note: This is a legacy answer kept for archival purposes. For current information on the XNAND implementation specific to your TS board, please see the wiki page associated with the product you have.
This section provides the necessary steps for updating the XNAND Drive of an XNAND enabled single board computer. Keep in mind that this section will refer to a generic xnandimg.dd.gz file. Use the appropriate image name for your update by referring to the images available on the FTP server. For example, the June 1st, 2010 image for the TS-75XX/TS-4500 is specifically named "xnandimg-jun012010.dd.gz" and can be found on the FTP server here: ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7500-linux/binaries/ts-images/xnandimg-jun012010.dd.gz
First, the appropriate xnandimg.dd.gz file must be downloaded and copied to an accessible location that the SBC can access while booted to the initial ramdisk (initrd/fastboot) off the offboard SPI flash, XNAND drive, or USB drive.* Possible locations are USB thumb drive, microSD card, or network server (NFS, FTP, TFTP, SSH). Whichever the case may be, use the following command to write the appropriate xnandimg.dd.gz file to the XNAND drive:
gunzip -c /path/to/xnandimg.dd.gz | nandctl -z 131072 -XW 2048 -i -
- If you do not have an accessible location for the image readily available, you can use a cute series of pipes to write the image to the XNAND drive directly from Technologic Systems FTP server to the XNAND drive without using USB flash drive or other storage medium with the following commands. Keep in mind that if your network connection should drop or there are any download problems, you risk being left with a corrupted XNAND image. Don't restart the SBC unless you feel confident that it copied okay!
1.) Get IP Address: * udhcpc
2.) Specify FTP_URL variable with actual path and name of the xnandimg file: * FTP_URL=ftp://ftp.embeddedarm.com/path/to/xnandimg.dd.gz -- NOTE: For example, for the June 1st, 2010 XNAND image release use the following command: * FTP_URL=ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7500-linux/binaries/ts-images/xnandimg-jun012010.dd.gz 3.) Download file from ftp, pipe to gunzip, pipe to nandctl (single, one-liner command): * wget $FTP_URL -O - | gunzip - | nandctl -z 131072 -XW 2048 -i -
6 How are the SD card images organized?
Question: Can you provide a breakdown of the partitioning scheme and filesystem of a typical SD Card Image
This question is better answered in the individual product pages. The answer provided here is for overview purposes only and may contain outdated information. Refer to your product's specific wiki page for up to date information.
There are two main types of images from which most SD card images can be derived: 1) with the development partition and 2) without it. Generally, the image with a development partition is 2GB and the other is 512MB. Each has the same number of partitions, which is important because the bootloader looks for partition 2, jumps in, and starts executing the kernel. The kernel looks for the initial ramdisk (initrd) on partition 3. The initrd looks for drivers/Debian on partition 4. Shown below are two graphics that give an overall look at the partition scheme for each.
Within the 2GB image, there is a 1.25GB partition which contains all sources and programs for development, including Eclipse IDE, kernel sources, utility sources, etc. specific to your board. In contrast, the 512MB image only contains a 'dummy' partition. This is to keep the four partition layout that is important to the bootloader as mentioned above. This partition has been formatted FAT32 and is first so that you may access these files on a Windows box.
The kernel, initrd, and Debian filesystem partitions between the two cards are practically identical. The first difference you might notice are the difference in partition size (512MB vs 473MB). This is the partition space, not the amount of space taken up by the Debian filesystem, which takes up about 344.75MB. You can take a 512MB image, write it to a 2GB+ image without any modifications, and boot successfully from it.
When plugged into a Linux box and issuing the 'fdisk -l' command within the terminal (or by opening gparted), you will be able to recognize the entire SD card most likely as /dev/sdb. The partitions can be recognized as:
/dev/sdb1 -- FAT32 Development/Dummy Partition
/dev/sdb2 -- NonFS Kernel Partition
/dev/sdb3 -- NonFS Initrd/Busybox Filesystem
/dev/sdb4 -- JFS/EXT3 Debian Filesystem
The kernel is of Non Filesystem type since it only holds a binary executable called "Image" (capital "I"). The kernel will start executing code and then reach for an initial ramdisk image. It finds this on partition 3 along with the linuxrc init script. The initial ramdisk first loads essential drivers and then provides the user with a command prompt. All of this happens within 3 seconds or so.
The command prompt is provided by the busybox program which resides in '/bin'. This single busybox binary is a swiss army knife containing many of the unix-type commands you're used to: ls, cd, mkdir, mount, etc... Use 'busybox --help' for a list of commands which were configured and included within the busybox binary. All commands run within the initrd are symbolic links to the busybox binary. Use 'ls -la /bin' to see these links. You may also notice by running 'ls -la /' that many of the directories such as /lib, /etc, /usr, etc are also symbolic links. These point to partition 4 which contains the Debian filesystem.
From the initrd, you may 'exit' to the Debian filesystem by using the command 'exit'. This will exit the busybox shell and begin the initialization and booting of Debian. You can then use all of the commands that you would normally use on a full-fledged Linux PC, like 'apt-get install'.