[U-Boot-Users] GOT pointer in U-boot

Hi,
I understand that global pointer is adjusted with respect to end of u-boot data. But there is a reference to GLOBAL_OFFSET_TABLE in cpu/mips/start.S whose contents are assigned to "gp" in the code. My code does not have the memory location which gp points to ? How should I find out what should be the contents of gp ? README file does mention the use of global pointers but it does not have a reference to GOT pointer.
Thanks and regards, Pooja

In message cmfvr3$61o$1@sea.gmane.org you wrote:
I understand that global pointer is adjusted with respect to end of u-boot data. But there is a reference to GLOBAL_OFFSET_TABLE in cpu/mips/start.S whose contents are assigned to "gp" in the code. My code does not have the memory location which gp points to ? How should I find out what should be the contents of gp ? README file does mention the use of global pointers but it does not have a reference to GOT pointer.
These are compiler / linker internals. In short: for position independent or relocatable code, GCC will generate accesses to all constant addresses through a global offset table (GOT). The loader resolves the GOT entries when the program starts, or - in case of U-boot - we manually adjustt he GOT when relocating the image to RAM.
You will need to dig into the GCC / ld documentation if you really want to understand what's going on there. [On the other hand it's usually safe to ignore this; the relevant problems have already been solved for MIPS and the other supported architectures.]
Best regards,
Wolfgang Denk

Wolfgang Denk wrote:
In message cmfvr3$61o$1@sea.gmane.org you wrote:
You will need to dig into the GCC / ld documentation if you really want to understand what's going on there. [On the other hand it's usually safe to ignore this; the relevant problems have already been solved for MIPS and the other supported architectures.]
Thanks for your time Wolfgang.
But Even if I ignore GOT pointer my problem still persists. The problem of bootloader trying to jump to an address which does not exist.
I compile for ROM version(config.mk) the code downloads in flash but when it relocates itself to SDRAM, the address it tries to jump is a "valid" SDRAM address but I don't see that address anywhere in u-boot.dis. All the addresses in u-boot.dis are relative to the TEXT_BASE I have given in ROM version.
Do I need to make some changes in linker file ? For the same board and YAMON bootloader the disassembled file has initial flash addresses and then SDRAM addresses for opcodes after the code is relocated. I am not expecting the same from u-boot but I am unable to understand u-boot policy regarding this.
Thanks and regards, Pooja
Best regards,
Wolfgang Denk

In message cmif0k$kq6$1@sea.gmane.org you wrote:
But Even if I ignore GOT pointer my problem still persists. The problem
Ignorance has never been a solution to problems.
You should try to understand what's going on.
of bootloader trying to jump to an address which does not exist.
How do you know that the address is bad?
I compile for ROM version(config.mk) the code downloads in flash but
I have no idea what you mean by "ROM version".
when it relocates itself to SDRAM, the address it tries to jump is a "valid" SDRAM address but I don't see that address anywhere in u-boot.dis. All the addresses in u-boot.dis are relative to the TEXT_BASE I have given in ROM version.
Yes, of course. What did you expect? The image that you build uses the addresses as set up by the TEXT_BASE definition and the linker script. The code then relocates itself into RAM, i. e. ij adjusts the addresses of the in-RAM copy of itself. So far, I don't know of any magic way to make it change the image files on ypur host system while doing this.
Do I need to make some changes in linker file ? For the same board and
No.
YAMON bootloader the disassembled file has initial flash addresses and then SDRAM addresses for opcodes after the code is relocated. I am not
YAMON is something different. I have no idea how it is implement. (Well, I do, but for this discussion it does not matter.) Ignore what you know about YAMON. This is U-Boot, and U-Boot does it as documented in the README, and as I explained to you.
expecting the same from u-boot but I am unable to understand u-boot policy regarding this.
The README says: "After booting and sizing and initializing DRAM, the code relocates itself to the upper end of DRAM." what exactly is not clear with this statement?
Don't you know what "relocate" means? Sorry, but this list is not the right place to discuss basics like this.
Best regards,
Wolfgang Denk
participants (2)
-
calvin
-
Wolfgang Denk