Page History

NuttX FLAT Binary Format (NXFLAT)

Overview

NuttX supports a configurable binary loader.
This binary loader supports loading and executing binary objects from the file system.
The NuttX binary loader is capable of supporting multiple binary formats.
One of of those binary formats is NXFLAT, the top of this Wiki page.

...

• A linker to bind ELF binaries to produce the NXFLAT binary format (See SVN).

Toolchain Compatibility Problem

Description

NXFLAT flat requires a specific kind of position independence. The ARM family of GCC toolchains has historically supported this method of position independence: All code addresses are accessed relative to the Program Counter (PC) and a special, PIC register (usually r10) is used to access all data. To load or store a data value, the contents of r10, the PIC base, is added to a constant, position-independent offset to produce the absolute address of the data.

http://nuttx.org/Images/nxflat-addressing.pngImage RemovedImage Added

The Global Offset Table (GOT) is a special data structure that resides in D-Space. So PIC-base relative addressing may also be specified as GOT-Relative addressing (or GOTOFF). The older GCC 4.3.3 GCC compiler, for example, generates GOTOFF relocations to the constant strings, like:

...

Where .LC0, .LC1, .LC2, .LC3, and .LC4 are the labels correponding to strings in the .rodata.str1.1 section. One consequence of this is that .rodata must reside in D-Space since it will addressed relative to the GOT (see the section entitled "Read-Only Data in RAM" at http://nuttx.org/Documentation/NuttXNxFlat.html#limitations^{Image Removed} here).

The newer 4.6.3 GCC compiler, however, generated PC relative relocations to these same strings:

...

The workaround for now is to use the older, 4.3.3 OABI compiler. In the long run, this might spell the end to NXFLAT.

Update: Restored GCC Support

This post was pointed out by Michael Jung:

  MCU: STM32F4 (ARM Cortex M4)
  Build environment: arm-none-eabi-gcc 4.8.4 20140725

  My goal is to build an image that can be run from any properly-aligned
  offset in internal flash (i.e., position-independent).  I found the
  following set of gcc flags that achieves this goal:

    # Generate position independent code.

1. fPIC

    -fPIC

  # Access bss via the GOT.
  -mno-pic-data-is-text-relative

...

    # GOT is not PC-relative; store GOT location in a register.
  -msingle-pic-base

...

    # Store GOT location in r9.
  -mpic-register=r9

Reference: https://gcc.gnu.org/ml/gcc-help/2015-07/msg00027.html^{Image RemovedImage Added}

Michael has verified that -mno-pic-data-is-text-relative is, indeed, a solution to the above NXFLAT problem in newer compilers. You simply need to modify the board Make.defs file like:

...

NOTE the minor difference from the post: NuttX uses r10 as the PIC base register by default in all configurations.
See this thread for additional information.

References

• NXFLAT : http : //nuttx.org/Documentation/NuttXNxFlat.html^{Image Removed}|NXFLAT Documenation

• XFLAT : XFLAT AT Sourceforge

...