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