Copy tables is the term for a general capability in the TI Toolchain to facilitate moving data from offline storage to online storage. Offline storage generally refers to where the program is loaded; it could be ROM, slower memory, and so on. Online storage generally refers to where the data resides when the program runs. The data being copied can be either code or variables. The term copy table refers to a table of source and destination addresses in which objects to be copied are registered. There is also a runtime component in the form of library functions that read the table and perform the copying in response to calls in the program.

There are numerous applications for copy tables, but the two most common are:

• Initialization—In a ROM-based bare-metal system, initialized read-write variables must be copied from ROM to RAM at program startup time.
• Overlays—As the program runs, different code and data components are swapped in and out of a region of memory.

The copy table mechanism is not part of the ABI. The means by which initialized variables get their initial values is by contract between the linker and the run-time library, which are required to be from the same toolchain. However, there may be advantages for other toolchains to follow the TI mechanism, or there may be a need for downstream tools to recognize the format, so we document it here.

The following figure illustrations the general mechanism. An object file contains an initialized section, .mydata in the example. At link time, the user specifies that .mydata is to have separate load and run addresses, and specifies that a copy table entry be created for it. The linker removes the data from .mysect, making it an uninitialized section, and assigns its address as its run location. It creates a new initialized section called .mydata.load1 which contains .mydata‟s data in encoded form, and places it at the load location. It links in a function called copy_in from the run-time library to decode and copy the data at run time, as well as additional format-specific helper functions. Finally, it creates a section (.ovly1 in the example) that contains a copy table, which is a sequence of copy records that point to the source data and the destination address, and a handler table (not shown) that the copy function uses to choose the right decode helper function.

At run time, the application invokes copy_in to decompress and copy the data. The argument to copy_in is the address of the copy table associated with the section. The function parses the table and executes the specified copy operations.

Multiple objects can be encoded and registered for copy-in. Each generates its own copy table in the .ovly ⁽¹⁾section.

A few variations are possible:

• Multiple objects. Multiple sections can be registered into a single copy table. This is so that all the code and data associated with an overlay can be copied in with a single invocation, without the application having to be aware of the number of separate components that comprise the overlay. A copy table can contain multiple copy records. Each copy record controls the copy-in of a contiguous chunk of code or data.
• No compression. The compression is optional. If compression is not enabled, there is no need for a separate load version of the section. The linker simply assigns separate load and run addresses to the initialized section.
• Initialization. Initialization of variables is a special case of the general mechanism. Copy records for initialization have a slightly different format, are stored in a different section called .cinit, and support zero-initialization as well as copy-in. These details are covered in Section 14.4.
• Boot-Time Copy-In. A special section called .binit contains copy tables that are automatically invoked at application startup time. This is similar to the initialization case, but whereas initialization is part of the language implementation and is therefore built-in to the toolchain, boot-time copy-in is strictly an application level operation.