All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot-Users] GOT pointer in U-boot
@ 2004-11-05 13:39 calvin
  2004-11-05 14:22 ` Wolfgang Denk
  0 siblings, 1 reply; 4+ messages in thread
From: calvin @ 2004-11-05 13:39 UTC (permalink / raw)
  To: 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot-Users] GOT pointer in U-boot
  2004-11-05 13:39 [U-Boot-Users] GOT pointer in U-boot calvin
@ 2004-11-05 14:22 ` Wolfgang Denk
  2004-11-06 12:10   ` [U-Boot-Users] " calvin
  0 siblings, 1 reply; 4+ messages in thread
From: Wolfgang Denk @ 2004-11-05 14:22 UTC (permalink / raw)
  To: u-boot

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

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The more sins you confess, the more books you will sell.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot-Users] Re: GOT pointer in U-boot
  2004-11-05 14:22 ` Wolfgang Denk
@ 2004-11-06 12:10   ` calvin
  2004-11-06 13:30     ` Wolfgang Denk
  0 siblings, 1 reply; 4+ messages in thread
From: calvin @ 2004-11-06 12:10 UTC (permalink / raw)
  To: u-boot

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
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot-Users] Re: GOT pointer in U-boot
  2004-11-06 12:10   ` [U-Boot-Users] " calvin
@ 2004-11-06 13:30     ` Wolfgang Denk
  0 siblings, 0 replies; 4+ messages in thread
From: Wolfgang Denk @ 2004-11-06 13:30 UTC (permalink / raw)
  To: u-boot

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

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q:  What's a light-year?
A:  One-third less calories than a regular year.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-11-06 13:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-05 13:39 [U-Boot-Users] GOT pointer in U-boot calvin
2004-11-05 14:22 ` Wolfgang Denk
2004-11-06 12:10   ` [U-Boot-Users] " calvin
2004-11-06 13:30     ` Wolfgang Denk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.