Specifications

99% or more of all errors are located when you port U-Boot to a new hardware. In the result, your
RAM image may work, but in the end you will need a full image to program the flash memory with it,
and then you will have to enable all this highly critical and completely untested code.
You see? You cannot use a RAM version of U-Boot to avoid testing a flash version, so you can save
all this effort and just burn your image to flash.
Question:
So how can I test an U-Boot image and recover my system if it doesn't work?
Answer:
Attach a BDI2000 (or any appropriate JTAG ICE) to your board, burn the image to flash, and debug it
in its natural environment, i.e. U-Boot being the boot loader of the system and taking control over the
CPU right as it comes out of reset. If something goes wrong, erase the flash and program a new
image. This is a routine job using a BDI2000.
14.2.2. Relocation cannot be done when using
-mrelocatable
Question:
I use ELDK version 3.0. When I build U-Boot I get error messages like this:
{standard input}: Assembler messages:
{standard input}:4998: Error: Relocation cannot be done when using -mrelocatable
...
Answer:
ELDK 3.0 uses GCC-3.2.2; your U-Boot sources are too old for this compiler. GCC-3.x requires a
few adaptions which were added in later versions of U-Boot. Use for example the source tree (1.0.2)
which is included with the ELDK, or download the latest version from CVS.
14.2.3. Source object has EABI version 4, but
target has EABI version 0
Question:
When trying to build U-Boot with an EABI compliant tool chain, I get such error messages:
arm-ld: ERROR: Source object ... has EABI version 4, but target ... has EABI version 0
What does that mean, and how can I fix that?
Answer:
"EABI version 0" means the "apcs-gnu" ABI, while "EABI version 4" is the "aapcs-linux"
ABI, aka "gnueabi".
All U-Boot ARM sources are built with "-mapcs-gnu" option set in "cpu/arm/config.mk",
while libgcc.a modules are built in "gnueabi" format, which is for example the ARM GCC default
in ELDK Release 4.2.
So the real problem is compatibility between toolchain ABI and U-Boot ARM ABI. In the Linux
kernel there is a special kernel config option for EABI-enabled tool chains (CONFIG_AEABI), which
enables special pieces of code in ARM assembler modules. We could follow this approach, reworking
existing assembler sources and respective config.mk files in U-Boot.
14.2.3. Source object has EABI version 4, but target has EABI version 0 160