Cross Compiling for the OMAP3 series (TAM-3517, THB-3517, TAO-3530, TDM-3730)

Difficulty Levels: Advanced
Date added: June 26, 2018
Affected Products: TAM-3517 , TAO-3530 , TDM-3730 , THB-3517

Summary

This guide teaches how to cross compile the essential boot files for the TI OMAP3 product family.

Introduction: Cross Compilers for ARM

For a long time, many cross compilers for the ARM platform have been known for not producing correct expected output.
For this reason it is important to use a cross compiler that has been tested to produce code that works as expected.

For the TechNexion Texas Instruments OMAP3 product line, the recommended compiler is the CodeSourcery GCC 4.5.1 build 50 (October 2010). It can be downloaded here.

See Appendix at the end for more background about compiler troubles.

Setup

These instructions have been tested with both a Ubuntu 16.04 native install, and with TechNexion Ubuntu 12.04 virtual machine.

Uncompress the compiler tarball somewhere, here assumed to be in the /opt/arm-2010.09 folder.

To be able to use this compiler, it has to be added to the PATH variable. This can be done with (in bash) by
% export PATH=$PATH:/opt/arm-2010.09/bin

Other variables that might need to be set (depending on target application/build process) are:
export ARCH=arm
export CROSS_COMPILE=arm-none-linux-gnueabi-
export TOOLCHAIN_PATH=/opt/arm-2010.09/

Downloading OMAP3-series Software

The latest available source code package for the OMAP3-series can be found in TechNexion FTP. The latest package at the time of this guide is the 2015-10-16 xukr.

The XUKR stands for X-loader, U-boot, Kernel and Root filesystem.

The X-loader is equivalent to the more modern SPL bootloaders, responsible to set up memory and to launch the main u-boot.

U-boot is the main bootloader, responsible to do additional initialization and to launch the kernel.

The Kernel is the typically the Linux kernel (v2.6.37).

And the Root filesystem is a sample root filesystem.

Compiling X-loader

The first step in compiling X-loader is to configure it for your target product. For TAM-3517 or THB-3517 use
% make tam3517_config,
for TAO-3530, use
% make tao3530_config,
and for TDM-3730, use
% make tdm3730_config.

The second step is the compile itself, which is just a straightforward
% make.

Compiling U-boot

To compile a u-boot use the appropriate make command:
% make tam3517
% make tao3530
% make tdm3730
the THB-3517 should use the TAM-3517 make rule.

Compiling the Linux Kernel

To compile the kernel, first contigure it with
% make tam3517_defconfig
for TAM-3517 or THB-3517 based products, or
% make taotdm_defconfig
for TAO-3530 or TDM-3730.

Then build the kernel and modules with the usual
% make modules uImage

Installing the XUKR

A bootable SD card for the OMAP3 series contains two partitions.
The first partition is a FAT partition with X-loader, u-boot and uImage. The second partition is typically the root filesystem, like a linux ext partition.

Texas Instrument’s boot ROM code does not contain full support for FAT filesystems, instead only some special cases can be used.
The partition beginning / end cannot be arbitrary, only certain (quite many) sizes can work. To be sure, one working partition is:
Device Boot Start End Sectors Size Id Type
sdd1 * 63 144584 144522 70.6M c W95 FAT32
where the units are in 512 byte sectors.

To make the card bootable copy the X-loader binary (“MLO”) as the first file on a freshly formatted FAT partition.
Thereafter copy u-boot.bin and uImage to the FAT partition. This should be enough to boot the kernel.

Appendix: What’s Up With “Buggy” ARM Compilers?

The ARM cross compiler “problems” are seldom problems with compilers producing incorrect code. They are rather stemming from programmers assuming undefined behaviour will be the same in all compilers, which is not true. One simple example of such undefined behaviour is adding a signed and an unsigned integer in C. Will the result be a signed or an unsigned int?
The answer is that it is up to the compiler. Different compilers do different choices. But, when dealing with numbers (like RAM sizes) around the maximum signed value (2G for 32-bit), the choice of the compiler is significant. For instance, the u-boot bootloader, is known to contain such problematic code segments.

Stay up to date with all the latest TechNexion news...

Sign-up for our Newsletter