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
