[U-Boot-Users] Does u-boot relocate absolute symbols?

Andreas Block andreas.block at esd-electronics.com
Tue Jun 14 11:47:57 CEST 2005


Hi,

I'm not quite sure, if this is a bug or a feature, but I tried to do the following and 
it didn't work:

Here at esd, we've some code common for all our boards (used to program FPGAs or CPLDs 
in u-boot). Up to now, the respective CPLD/FPGA-image was included into u-boot as an 
array, declared as follows in a board-dependent file (e.g. pf5200.c):

const unsigned char fpgadata[] = {
  #include "fpgadata.c"
};

The common code (located in micro.c or ports.c in esd/common/) accesses the image via 
fpgadata using the following extern-declaration:

extern const unsigned char fpgadata[];

This far everything's fine. With a new hardware, we've the following problem:
The CPLD image is too large to fit within u-boot and I'd like to retrieve the CPLD 
image at runtime via TFTP. And I'd like to do this without the need to change any of 
the common code (like the above mentioned extern-declaration), which of course would 
mean to test all other hardware using the common-code again.

It does not work (because it's simply wrong) to declare fpgadata as follows in pf5200.c 
(although looking good in the first place, if you think about it, the compiler needs to 
handle both declarations differently):

const unsigned char *fpgadata = 0x400000; /* (with 0x400000 being the address to store 
the image with TFTP at) */

So I tried a different approach (since all I need is to get access to the array at a 
certain memory location). I didn't declare fpgadata in pf5200.c at all, but instead 
wrote a small fpgadata.S containing the following:

.globl fpgadata
.data
.set fpgadata, 0x400000

It's supposed to generate the symbol fpgadata.c and locate it at the right absolute 
address in memory. One can try this with some small test-code under Linux and it works 
as it's supposed to. Also the output of nm "fpgadata.o" looks beautiful:

00400000 A fpgadata

But when used in u-boot the address of fpgadata is not 0x400000, but something 
different. I assume this is related to u-boot booting from flash and relocating itself 
into RAM. And this is the point, I'm not sure about. Is this the way one wants it work. 
Does one want u-boot to relocate absolute addresses, or is this behaviour even needed 
for u-boot to work at all? Or is it a bug and u-boot doesn't pay attention to the 
absolute flag as it's supposed to? Wouldn't it be nice in a boot-loader to be able to 
locate something at certain memory locations at link time?

Best regards,
Andreas Block






More information about the U-Boot mailing list