[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

NULL is an absolute value and should not be relocated.
After this correction code like:
 void weak_fun(void) __attribute__((weak));
 printf("weak_fun:%p\n", weak_fun);
will still print null after relocation.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---

I have only tested this on 83xx and on a somewhat older u-boot.
The change is exactly the same on all PowerPC platforms though.

 cpu/mpc512x/start.S |    6 ++++--
 cpu/mpc5xx/start.S  |    6 ++++--
 cpu/mpc5xxx/start.S |    6 ++++--
 cpu/mpc8220/start.S |    6 ++++--
 cpu/mpc824x/start.S |    6 ++++--
 cpu/mpc8260/start.S |    6 ++++--
 cpu/mpc83xx/start.S |    6 ++++--
 cpu/mpc85xx/start.S |    6 ++++--
 cpu/mpc86xx/start.S |    6 ++++--
 cpu/mpc8xx/start.S  |    6 ++++--
 10 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/cpu/mpc512x/start.S b/cpu/mpc512x/start.S
index 360682d..a00e045 100644
--- a/cpu/mpc512x/start.S
+++ b/cpu/mpc512x/start.S
@@ -609,15 +609,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc5xx/start.S b/cpu/mpc5xx/start.S
index 106935c..85ea7a8 100644
--- a/cpu/mpc5xx/start.S
+++ b/cpu/mpc5xx/start.S
@@ -458,15 +458,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc5xxx/start.S b/cpu/mpc5xxx/start.S
index 6b1162a..eb42939 100644
--- a/cpu/mpc5xxx/start.S
+++ b/cpu/mpc5xxx/start.S
@@ -684,15 +684,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8220/start.S b/cpu/mpc8220/start.S
index 3abc619..af9472d 100644
--- a/cpu/mpc8220/start.S
+++ b/cpu/mpc8220/start.S
@@ -649,15 +649,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc824x/start.S b/cpu/mpc824x/start.S
index 39325cd..750457b 100644
--- a/cpu/mpc824x/start.S
+++ b/cpu/mpc824x/start.S
@@ -589,15 +589,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8260/start.S b/cpu/mpc8260/start.S
index 379f2fb..edb95e6 100644
--- a/cpu/mpc8260/start.S
+++ b/cpu/mpc8260/start.S
@@ -909,15 +909,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S
index 26e3106..ee4b862 100644
--- a/cpu/mpc83xx/start.S
+++ b/cpu/mpc83xx/start.S
@@ -957,16 +957,18 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 #ifndef CONFIG_NAND_SPL
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S
index 4f7236f..d56003b 100644
--- a/cpu/mpc85xx/start.S
+++ b/cpu/mpc85xx/start.S
@@ -932,15 +932,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc86xx/start.S b/cpu/mpc86xx/start.S
index 63cc8db..e65f1c0 100644
--- a/cpu/mpc86xx/start.S
+++ b/cpu/mpc86xx/start.S
@@ -733,15 +733,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8xx/start.S b/cpu/mpc8xx/start.S
index 8864c37..e84326e 100644
--- a/cpu/mpc8xx/start.S
+++ b/cpu/mpc8xx/start.S
@@ -589,15 +589,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
-- 
1.6.4.4

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
> NULL is an absolute value and should not be relocated.
> After this correction code like:
>  void weak_fun(void) __attribute__((weak));
>  printf("weak_fun:%p\n", weak_fun);
> will still print null after relocation.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> 
> I have only tested this on 83xx and on a somewhat older u-boot.
> The change is exactly the same on all PowerPC platforms though.

Hi Jocke,
I made the same changes recently, but ran into an "issue" that prevented
me from sending the change upstream.  Some boards/arches have the bss at
address 0 and later relocate it, unlike every other NULL pointer.  If
you don't fix up the bss address, the board will not function.   If you
run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be
more clear what's going on.  I was doing my testing on the XPedite5370
fwiw.

In any case, the change as is would break some other arches.  Seems like
the proper workaround would be to "fix" the 85xx (and other arches) link
script to locate the bss similar to the 83xx boards.

It might be nice to consolidate all the ppc relocate code into 1
function while we were at it.

Best,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Stefan Roese]

On Wednesday 23 September 2009 13:51:46 Joakim Tjernlund wrote:
> NULL is an absolute value and should not be relocated.
> After this correction code like:
>  void weak_fun(void) __attribute__((weak));
>  printf("weak_fun:%p\n", weak_fun);
> will still print null after relocation.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> 
> I have only tested this on 83xx and on a somewhat older u-boot.
> The change is exactly the same on all PowerPC platforms though.
> 
>  cpu/mpc512x/start.S |    6 ++++--
>  cpu/mpc5xx/start.S  |    6 ++++--
>  cpu/mpc5xxx/start.S |    6 ++++--
>  cpu/mpc8220/start.S |    6 ++++--
>  cpu/mpc824x/start.S |    6 ++++--
>  cpu/mpc8260/start.S |    6 ++++--
>  cpu/mpc83xx/start.S |    6 ++++--
>  cpu/mpc85xx/start.S |    6 ++++--
>  cpu/mpc86xx/start.S |    6 ++++--
>  cpu/mpc8xx/start.S  |    6 ++++--

Thanks. But I think you missed ppc4xx here:

cpu/ppc4xx/start.S

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Stefan Roese]

On Wednesday 23 September 2009 14:17:51 Peter Tyser wrote:
> On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
> > NULL is an absolute value and should not be relocated.
> > After this correction code like:
> >  void weak_fun(void) __attribute__((weak));
> >  printf("weak_fun:%p\n", weak_fun);
> > will still print null after relocation.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> >
> > I have only tested this on 83xx and on a somewhat older u-boot.
> > The change is exactly the same on all PowerPC platforms though.
> 
> Hi Jocke,
> I made the same changes recently, but ran into an "issue" that prevented
> me from sending the change upstream.  Some boards/arches have the bss at
> address 0 and later relocate it, unlike every other NULL pointer.  If
> you don't fix up the bss address, the board will not function.   If you
> run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be
> more clear what's going on.  I was doing my testing on the XPedite5370
> fwiw.
> 
> In any case, the change as is would break some other arches.  Seems like
> the proper workaround would be to "fix" the 85xx (and other arches) link
> script to locate the bss similar to the 83xx boards.
> 
> It might be nice to consolidate all the ppc relocate code into 1
> function while we were at it.

Yes, please!
 
Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 23/09/2009 14:17:51:
>
> On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
> > NULL is an absolute value and should not be relocated.
> > After this correction code like:
> >  void weak_fun(void) __attribute__((weak));
> >  printf("weak_fun:%p\n", weak_fun);
> > will still print null after relocation.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> >
> > I have only tested this on 83xx and on a somewhat older u-boot.
> > The change is exactly the same on all PowerPC platforms though.
>
> Hi Jocke,
> I made the same changes recently, but ran into an "issue" that prevented
> me from sending the change upstream.  Some boards/arches have the bss at
> address 0 and later relocate it, unlike every other NULL pointer.  If
> you don't fix up the bss address, the board will not function.   If you
> run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be
> more clear what's going on.  I was doing my testing on the XPedite5370
> fwiw.

Ouch, the horror continues :(

>
> In any case, the change as is would break some other arches.  Seems like
> the proper workaround would be to "fix" the 85xx (and other arches) link
> script to locate the bss similar to the 83xx boards.

Yes, something should be done. Does it work for you with a "fixed" linker script?

>
> It might be nice to consolidate all the ppc relocate code into 1
> function while we were at it.

Played around a little and this is what I got sofar, possibly
WS damged and fixups untested:

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Stefan Roese <sr@denx.de> wrote on 23/09/2009 14:24:34:
>
> On Wednesday 23 September 2009 13:51:46 Joakim Tjernlund wrote:
> > NULL is an absolute value and should not be relocated.
> > After this correction code like:
> >  void weak_fun(void) __attribute__((weak));
> >  printf("weak_fun:%p\n", weak_fun);
> > will still print null after relocation.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> >
> > I have only tested this on 83xx and on a somewhat older u-boot.
> > The change is exactly the same on all PowerPC platforms though.
> >
> >  cpu/mpc512x/start.S |    6 ++++--
> >  cpu/mpc5xx/start.S  |    6 ++++--
> >  cpu/mpc5xxx/start.S |    6 ++++--
> >  cpu/mpc8220/start.S |    6 ++++--
> >  cpu/mpc824x/start.S |    6 ++++--
> >  cpu/mpc8260/start.S |    6 ++++--
> >  cpu/mpc83xx/start.S |    6 ++++--
> >  cpu/mpc85xx/start.S |    6 ++++--
> >  cpu/mpc86xx/start.S |    6 ++++--
> >  cpu/mpc8xx/start.S  |    6 ++++--
>
> Thanks. But I think you missed ppc4xx here:
>
> cpu/ppc4xx/start.S

oops, if you rename ppc4xx to mpc4xx such mistakes can be avoided.

     Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

> > I made the same changes recently, but ran into an "issue" that prevented
> > me from sending the change upstream.  Some boards/arches have the bss at
> > address 0 and later relocate it, unlike every other NULL pointer.  If
> > you don't fix up the bss address, the board will not function.   If you
> > run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be
> > more clear what's going on.  I was doing my testing on the XPedite5370
> > fwiw.
> 
> Ouch, the horror continues :(

Yeah...  Its seemingly never ending:)

> > In any case, the change as is would break some other arches.  Seems like
> > the proper workaround would be to "fix" the 85xx (and other arches) link
> > script to locate the bss similar to the 83xx boards.
> 
> Yes, something should be done. Does it work for you with a "fixed" linker script?

My "fix" to the linker script was to change:
__bss_start = .;
into:
__bss_start = . | 4;

ie, a big hack, but it did work:)  I'll take a peek at a more proper
link script workaround.

> > It might be nice to consolidate all the ppc relocate code into 1
> > function while we were at it.
> 
> Played around a little and this is what I got sofar, possibly
> WS damged and fixups untested:

Nice!  It'd be great to have the magical 20 lines of assembly put into
some semi-understandable c.

Best,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 23/09/2009 14:57:19:
>
>
> > > I made the same changes recently, but ran into an "issue" that prevented
> > > me from sending the change upstream.  Some boards/arches have the bss at
> > > address 0 and later relocate it, unlike every other NULL pointer.  If
> > > you don't fix up the bss address, the board will not function.   If you
> > > run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be
> > > more clear what's going on.  I was doing my testing on the XPedite5370
> > > fwiw.
> >
> > Ouch, the horror continues :(
>
> Yeah...  Its seemingly never ending:)
>
> > > In any case, the change as is would break some other arches.  Seems like
> > > the proper workaround would be to "fix" the 85xx (and other arches) link
> > > script to locate the bss similar to the 83xx boards.
> >
> > Yes, something should be done. Does it work for you with a "fixed" linker script?
>
> My "fix" to the linker script was to change:
> __bss_start = .;
> into:
> __bss_start = . | 4;
>
> ie, a big hack, but it did work:)  I'll take a peek at a more proper
> link script workaround.
>
> > > It might be nice to consolidate all the ppc relocate code into 1
> > > function while we were at it.
> >
> > Played around a little and this is what I got sofar, possibly
> > WS damged and fixups untested:
>
> Nice!  It'd be great to have the magical 20 lines of assembly put into
> some semi-understandable c.

Played some more and got this, running out of time now so
I figured I should post as is in case you (or someone else)
wants to play some more. I will answer questions though.

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Peter Tyser,

In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> 
> My "fix" to the linker script was to change:
> __bss_start = .;
> into:
> __bss_start = . | 4;
> 
> ie, a big hack, but it did work:)  I'll take a peek at a more proper
> link script workaround.

32 bit alignment of the BSS segment might not be sufficient. Be
careful!

> Nice!  It'd be great to have the magical 20 lines of assembly put into
> some semi-understandable c.

:-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
>
> Dear Peter Tyser,
>
> In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> >
> > My "fix" to the linker script was to change:
> > __bss_start = .;
> > into:
> > __bss_start = . | 4;
> >
> > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > link script workaround.
>
> 32 bit alignment of the BSS segment might not be sufficient. Be
> careful!

Any progress on this ?

>
> > Nice!  It'd be great to have the magical 20 lines of assembly put into
> > some semi-understandable c.
>
> :-)

I have worked some more on this but all boards need to be converted to use
the new C-variants.

Anyhow, I have also been thinking/working on making U-boot
fully PIC and reached a important conclusion. The GOT holds absolute
ptr values and there is not much one can do about it sans modifying gcc.
So before u-boot is relocated to RAM one must manually add any offset to
all global/static data and string literals. The majority of strings
are passed directly to printf and friends so the offset can be added inside
printf. The remaining few data accesses needs to be dealt with directly, example:
-       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
+       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {

Only code called before relocation to RAM needs this, mostly the _f() functions.
Would this be an acceptable change?

 Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Graeme Russ]

On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
> Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
>>
>> Dear Peter Tyser,
>>
>> In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
>> >

>>
>> > Nice!  It'd be great to have the magical 20 lines of assembly put into
>> > some semi-understandable c.
>>
>> :-)
>
> I have worked some more on this but all boards need to be converted to use
> the new C-variants.
>
> Anyhow, I have also been thinking/working on making U-boot
> fully PIC and reached a important conclusion. The GOT holds absolute
> ptr values and there is not much one can do about it sans modifying gcc.
> So before u-boot is relocated to RAM one must manually add any offset to
> all global/static data and string literals. The majority of strings
> are passed directly to printf and friends so the offset can be added inside
> printf. The remaining few data accesses needs to be dealt with directly, example:
> -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
>
> Only code called before relocation to RAM needs this, mostly the _f() functions.
> Would this be an acceptable change?
>

I think you might want to look at the x86 relocation work I have just
submitted for comment. It processes all relocation sections generated by
gcc/ld using the ELF data structures defined in elf.h - I generate code at
a text base equal to the boot flash (0x38004000) so I can easily check if
the relocation entry is with the executable. After the elf relocation
processing, there is ZERO need for any offset compensation once I've jumped
into the relocated code

And its all in C ;)

>  Jocke
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Graeme Russ <graeme.russ@gmail.com> wrote on 27/09/2009 15:52:38:
>
> On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> >>
> >> Dear Peter Tyser,
> >>
> >> In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> >> >
>
> >>
> >> > Nice!  It'd be great to have the magical 20 lines of assembly put into
> >> > some semi-understandable c.
> >>
> >> :-)
> >
> > I have worked some more on this but all boards need to be converted to use
> > the new C-variants.
> >
> > Anyhow, I have also been thinking/working on making U-boot
> > fully PIC and reached a important conclusion. The GOT holds absolute
> > ptr values and there is not much one can do about it sans modifying gcc.
> > So before u-boot is relocated to RAM one must manually add any offset to
> > all global/static data and string literals. The majority of strings
> > are passed directly to printf and friends so the offset can be added inside
> > printf. The remaining few data accesses needs to be dealt with directly, example:
> > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
> >
> > Only code called before relocation to RAM needs this, mostly the _f() functions.
> > Would this be an acceptable change?
> >
>
> I think you might want to look at the x86 relocation work I have just
> submitted for comment. It processes all relocation sections generated by
> gcc/ld using the ELF data structures defined in elf.h - I generate code at
> a text base equal to the boot flash (0x38004000) so I can easily check if
> the relocation entry is with the executable. After the elf relocation
> processing, there is ZERO need for any offset compensation once I've jumped
> into the relocated code
>
> And its all in C ;)

hmm, I don't know x86 that well, but I did look at your
  [RFC][PATCH 8/8] Final i386 Relocation
and I don't understand it fully. To make sure, is it possible for you
to link at address X and run from address Y directly from flash?

   Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Graeme Russ]

On Mon, Sep 28, 2009 at 2:18 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
> Graeme Russ <graeme.russ@gmail.com> wrote on 27/09/2009 15:52:38:
>>
>> On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund
>> <joakim.tjernlund@transmode.se> wrote:
>> > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
>> >>
>> >> Dear Peter Tyser,
>> >>
>> >> In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
>> >> >
>>
>> >>
>> >> > Nice!  It'd be great to have the magical 20 lines of assembly put into
>> >> > some semi-understandable c.
>> >>
>> >> :-)
>
> hmm, I don't know x86 that well, but I did look at your
>  [RFC][PATCH 8/8] Final i386 Relocation
> and I don't understand it fully. To make sure, is it possible for you
> to link at address X and run from address Y directly from flash?
>
>   Jocke
>
>

Ah, I know understand what you are trying to achieve - No, my code does
not allow for in-flash relocation.

My code processes the ELF relocation structures rel.got (which has pointers
into .got), got.plt (which is where the location of .got is retrieved at
run-time), rel.dyn (pointers into other sections other than .got), .dynamic
and .dynsym

I must admit, I do not know why there are so many sections which need to
be patched - I originally thought that only .got would need modifying, but
the rabbit-hole is much deeper

Regards,

G

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> >
> > Dear Peter Tyser,
> >
> > In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> > >
> > > My "fix" to the linker script was to change:
> > > __bss_start = .;
> > > into:
> > > __bss_start = . | 4;
> > >
> > > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > > link script workaround.
> >
> > 32 bit alignment of the BSS segment might not be sufficient. Be
> > careful!
> 
> Any progress on this ?

I've been swamped the last few days, but think I have a workaround.  I
hope to test it tomorrow or tues.  I'll send an email when I have a more
definitive answer.

> > > Nice!  It'd be great to have the magical 20 lines of assembly put into
> > > some semi-understandable c.
> >
> > :-)
> 
> I have worked some more on this but all boards need to be converted to use
> the new C-variants.

Great!

> Anyhow, I have also been thinking/working on making U-boot
> fully PIC and reached a important conclusion. The GOT holds absolute
> ptr values and there is not much one can do about it sans modifying gcc.
> So before u-boot is relocated to RAM one must manually add any offset to
> all global/static data and string literals. The majority of strings
> are passed directly to printf and friends so the offset can be added inside
> printf. The remaining few data accesses needs to be dealt with directly, example:
> -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
> 
> Only code called before relocation to RAM needs this, mostly the _f() functions.
> Would this be an acceptable change?

Could you describe the advantages of generating a fully PIC U-Boot
image?  I understand you could execute the image from different places
in flash, but on the boards I've worked with this isn't a huge concern.
For example, its possible to have a preliminary flash mapping that
U-Boot executes from, then after relocation to RAM that flash mapping
can be modified.  So where U-Boot initially executes from isn't all that
important for me.  Is there some killer feature that a fully PIC U-Boot
provides to make adding the got_off() workarounds you mention
worthwhile?

Thanks,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Graeme Russ <graeme.russ@gmail.com> wrote on 28/09/2009 01:23:36:
>
> On Mon, Sep 28, 2009 at 2:18 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > Graeme Russ <graeme.russ@gmail.com> wrote on 27/09/2009 15:52:38:
> >>
> >> On Sun, Sep 27, 2009 at 11:15 PM, Joakim Tjernlund
> >> <joakim.tjernlund@transmode.se> wrote:
> >> > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> >> >>
> >> >> Dear Peter Tyser,
> >> >>
> >> >> In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> >> >> >
> >>
> >> >>
> >> >> > Nice!  It'd be great to have the magical 20 lines of assembly put into
> >> >> > some semi-understandable c.
> >> >>
> >> >> :-)
> >
> > hmm, I don't know x86 that well, but I did look at your
> >  [RFC][PATCH 8/8] Final i386 Relocation
> > and I don't understand it fully. To make sure, is it possible for you
> > to link at address X and run from address Y directly from flash?
> >
> >   Jocke
> >
> >
>
> Ah, I know understand what you are trying to achieve - No, my code does
> not allow for in-flash relocation.
>
> My code processes the ELF relocation structures rel.got (which has pointers
> into .got), got.plt (which is where the location of .got is retrieved at
> run-time), rel.dyn (pointers into other sections other than .got), .dynamic
> and .dynsym
>
> I must admit, I do not know why there are so many sections which need to
> be patched - I originally thought that only .got would need modifying, but
> the rabbit-hole is much deeper

Sounds a bit much. I did a lot of LDSO work for uClibc some years ago but
I forgot the details now :(
But I I do remember one thing, try using -Bsymbolic when linking.

      Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 06:31:28:
>
> On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> > >
> > > Dear Peter Tyser,
> > >
> > > In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> > > >
> > > > My "fix" to the linker script was to change:
> > > > __bss_start = .;
> > > > into:
> > > > __bss_start = . | 4;
> > > >
> > > > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > > > link script workaround.
> > >
> > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > careful!
> >
> > Any progress on this ?
>
> I've been swamped the last few days, but think I have a workaround.  I
> hope to test it tomorrow or tues.  I'll send an email when I have a more
> definitive answer.
>
> > > > Nice!  It'd be great to have the magical 20 lines of assembly put into
> > > > some semi-understandable c.
> > >
> > > :-)
> >
> > I have worked some more on this but all boards need to be converted to use
> > the new C-variants.
>
> Great!
>
> > Anyhow, I have also been thinking/working on making U-boot
> > fully PIC and reached a important conclusion. The GOT holds absolute
> > ptr values and there is not much one can do about it sans modifying gcc.
> > So before u-boot is relocated to RAM one must manually add any offset to
> > all global/static data and string literals. The majority of strings
> > are passed directly to printf and friends so the offset can be added inside
> > printf. The remaining few data accesses needs to be dealt with directly, example:
> > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
> >
> > Only code called before relocation to RAM needs this, mostly the _f() functions.
> > Would this be an acceptable change?
>
> Could you describe the advantages of generating a fully PIC U-Boot
> image?  I understand you could execute the image from different places
> in flash, but on the boards I've worked with this isn't a huge concern.
> For example, its possible to have a preliminary flash mapping that
> U-Boot executes from, then after relocation to RAM that flash mapping
> can be modified.  So where U-Boot initially executes from isn't all that
> important for me.  Is there some killer feature that a fully PIC U-Boot
> provides to make adding the got_off() workarounds you mention
> worthwhile?

For me, it is mainly to be to have two u-boot partitions and
be able to select one to boot from. This makes it safer to
update u-boot in the field.

  Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
> Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 06:31:28:
> >
> > On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> > > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> > > >
> > > > Dear Peter Tyser,
> > > >
> > > > In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> > > > >
> > > > > My "fix" to the linker script was to change:
> > > > > __bss_start = .;
> > > > > into:
> > > > > __bss_start = . | 4;
> > > > >
> > > > > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > > > > link script workaround.
> > > >
> > > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > > careful!
> > >
> > > Any progress on this ?
> >
> > I've been swamped the last few days, but think I have a workaround.  I
> > hope to test it tomorrow or tues.  I'll send an email when I have a more
> > definitive answer.
> >
> > > > > Nice!  It'd be great to have the magical 20 lines of assembly put into
> > > > > some semi-understandable c.
> > > >
> > > > :-)
> > >
> > > I have worked some more on this but all boards need to be converted to use
> > > the new C-variants.
> >
> > Great!
> >
> > > Anyhow, I have also been thinking/working on making U-boot
> > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > ptr values and there is not much one can do about it sans modifying gcc.
> > > So before u-boot is relocated to RAM one must manually add any offset to
> > > all global/static data and string literals. The majority of strings
> > > are passed directly to printf and friends so the offset can be added inside
> > > printf. The remaining few data accesses needs to be dealt with directly, example:
> > > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
> > >
> > > Only code called before relocation to RAM needs this, mostly the _f() functions.
> > > Would this be an acceptable change?
> >
> > Could you describe the advantages of generating a fully PIC U-Boot
> > image?  I understand you could execute the image from different places
> > in flash, but on the boards I've worked with this isn't a huge concern.
> > For example, its possible to have a preliminary flash mapping that
> > U-Boot executes from, then after relocation to RAM that flash mapping
> > can be modified.  So where U-Boot initially executes from isn't all that
> > important for me.  Is there some killer feature that a fully PIC U-Boot
> > provides to make adding the got_off() workarounds you mention
> > worthwhile?
> 
> For me, it is mainly to be to have two u-boot partitions and
> be able to select one to boot from. This makes it safer to
> update u-boot in the field.

X-ES requires this same functionality of dual booting.  We generally
have a jumper on each card that swaps 2 chip select 0 and 1 so that
either can be booted from (assuming CS 0 is always used to load U-Boot).
The same U-Boot image can be programmed to both flashes.  After U-Boot
relocates to RAM, we remap the flashes (in
board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a
common flash layout regardless of which flash we booted from.  Would it
be possible to do something similar in your hardware setup so that the
same U-Boot image could be loaded from either flash partition without
the got_off() fixups you mention above?

Best,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 14:45:46:
>
> On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
> > Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 06:31:28:
> > >
> > > On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> > > > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> > > > >
> > > > > Dear Peter Tyser,
> > > > >
> > > > > In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> > > > > >
> > > > > > My "fix" to the linker script was to change:
> > > > > > __bss_start = .;
> > > > > > into:
> > > > > > __bss_start = . | 4;
> > > > > >
> > > > > > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > > > > > link script workaround.
> > > > >
> > > > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > > > careful!
> > > >
> > > > Any progress on this ?
> > >
> > > I've been swamped the last few days, but think I have a workaround.  I
> > > hope to test it tomorrow or tues.  I'll send an email when I have a more
> > > definitive answer.
> > >
> > > > > > Nice!  It'd be great to have the magical 20 lines of assembly put into
> > > > > > some semi-understandable c.
> > > > >
> > > > > :-)
> > > >
> > > > I have worked some more on this but all boards need to be converted to use
> > > > the new C-variants.
> > >
> > > Great!
> > >
> > > > Anyhow, I have also been thinking/working on making U-boot
> > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > ptr values and there is not much one can do about it sans modifying gcc.
> > > > So before u-boot is relocated to RAM one must manually add any offset to
> > > > all global/static data and string literals. The majority of strings
> > > > are passed directly to printf and friends so the offset can be added inside
> > > > printf. The remaining few data accesses needs to be dealt with directly, example:
> > > > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > > > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> +init_fnc_ptr) {
> > > >
> > > > Only code called before relocation to RAM needs this, mostly the _f() functions.
> > > > Would this be an acceptable change?
> > >
> > > Could you describe the advantages of generating a fully PIC U-Boot
> > > image?  I understand you could execute the image from different places
> > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > For example, its possible to have a preliminary flash mapping that
> > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > can be modified.  So where U-Boot initially executes from isn't all that
> > > important for me.  Is there some killer feature that a fully PIC U-Boot
> > > provides to make adding the got_off() workarounds you mention
> > > worthwhile?
> >
> > For me, it is mainly to be to have two u-boot partitions and
> > be able to select one to boot from. This makes it safer to
> > update u-boot in the field.
>
> X-ES requires this same functionality of dual booting.  We generally
> have a jumper on each card that swaps 2 chip select 0 and 1 so that
> either can be booted from (assuming CS 0 is always used to load U-Boot).
> The same U-Boot image can be programmed to both flashes.  After U-Boot
> relocates to RAM, we remap the flashes (in
> board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a
> common flash layout regardless of which flash we booted from.  Would it
> be possible to do something similar in your hardware setup so that the
> same U-Boot image could be loaded from either flash partition without
> the got_off() fixups you mention above?

Nope, we don't have that extra HW support and won't have in the future
either. This type of extra HW logic should not be needed and even if you
do have it, how do you flip a jumper remotely? Can be done I am sure, but
all this extra HW logic should not be needed at all.

     Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

<snip>

> > > >
> > > > > Anyhow, I have also been thinking/working on making U-boot
> > > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > > ptr values and there is not much one can do about it sans modifying gcc.
> > > > > So before u-boot is relocated to RAM one must manually add any offset to
> > > > > all global/static data and string literals. The majority of strings
> > > > > are passed directly to printf and friends so the offset can be added inside
> > > > > printf. The remaining few data accesses needs to be dealt with directly, example:
> > > > > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > > > > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> > +init_fnc_ptr) {
> > > > >
> > > > > Only code called before relocation to RAM needs this, mostly the _f() functions.
> > > > > Would this be an acceptable change?
> > > >
> > > > Could you describe the advantages of generating a fully PIC U-Boot
> > > > image?  I understand you could execute the image from different places
> > > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > > For example, its possible to have a preliminary flash mapping that
> > > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > > can be modified.  So where U-Boot initially executes from isn't all that
> > > > important for me.  Is there some killer feature that a fully PIC U-Boot
> > > > provides to make adding the got_off() workarounds you mention
> > > > worthwhile?
> > >
> > > For me, it is mainly to be to have two u-boot partitions and
> > > be able to select one to boot from. This makes it safer to
> > > update u-boot in the field.
> >
> > X-ES requires this same functionality of dual booting.  We generally
> > have a jumper on each card that swaps 2 chip select 0 and 1 so that
> > either can be booted from (assuming CS 0 is always used to load U-Boot).
> > The same U-Boot image can be programmed to both flashes.  After U-Boot
> > relocates to RAM, we remap the flashes (in
> > board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a
> > common flash layout regardless of which flash we booted from.  Would it
> > be possible to do something similar in your hardware setup so that the
> > same U-Boot image could be loaded from either flash partition without
> > the got_off() fixups you mention above?
> 
> Nope, we don't have that extra HW support and won't have in the future
> either. This type of extra HW logic should not be needed and even if you
> do have it, how do you flip a jumper remotely? Can be done I am sure, but
> all this extra HW logic should not be needed at all.

How do you provide true redundancy without some means of changing a chip
select, hardware strapping pin, etc?  Without hardware support you only
have 1 code entry point, correct?  If that fails, the board is toast,
regardless if you have redundant U-Boot images.  The "jumper" I was
refering to could be a physical jumper, a non-volatile gpio device,
FPGA, IPMI controller, etc.

Best,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 14:45:46:
>
> On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
> > Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 06:31:28:
> > >
> > > On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> > > > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> > > > >
> > > > > Dear Peter Tyser,
> > > > >
> > > > > In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> > > > > >
> > > > > > My "fix" to the linker script was to change:
> > > > > > __bss_start = .;
> > > > > > into:
> > > > > > __bss_start = . | 4;
> > > > > >
> > > > > > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > > > > > link script workaround.
> > > > >
> > > > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > > > careful!
> > > >
> > > > Any progress on this ?
> > >
> > > I've been swamped the last few days, but think I have a workaround.  I
> > > hope to test it tomorrow or tues.  I'll send an email when I have a more
> > > definitive answer.
> > >
> > > > > > Nice!  It'd be great to have the magical 20 lines of assembly put into
> > > > > > some semi-understandable c.
> > > > >
> > > > > :-)
> > > >
> > > > I have worked some more on this but all boards need to be converted to use
> > > > the new C-variants.
> > >
> > > Great!
> > >
> > > > Anyhow, I have also been thinking/working on making U-boot
> > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > ptr values and there is not much one can do about it sans modifying gcc.
> > > > So before u-boot is relocated to RAM one must manually add any offset to
> > > > all global/static data and string literals. The majority of strings
> > > > are passed directly to printf and friends so the offset can be added inside
> > > > printf. The remaining few data accesses needs to be dealt with directly, example:
> > > > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > > > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> +init_fnc_ptr) {
> > > >
> > > > Only code called before relocation to RAM needs this, mostly the _f() functions.
> > > > Would this be an acceptable change?
> > >
> > > Could you describe the advantages of generating a fully PIC U-Boot
> > > image?  I understand you could execute the image from different places
> > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > For example, its possible to have a preliminary flash mapping that
> > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > can be modified.  So where U-Boot initially executes from isn't all that
> > > important for me.  Is there some killer feature that a fully PIC U-Boot
> > > provides to make adding the got_off() workarounds you mention
> > > worthwhile?
> >
> > For me, it is mainly to be to have two u-boot partitions and
> > be able to select one to boot from. This makes it safer to
> > update u-boot in the field.

Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie
-fpie is about the same as -fpic and -fPIE is similar to -fPIC
-fpie generates smaller code so one could consider using -fpie and -mrelocatable
However -fpic/-fpie needs some fixes to the relocation code, but a quick hack
by me works on my board.

Does -fpie and -mrelocatable compile for you and do you have a non zero fixup section?

       Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 16:29:15:
>
> > > > >
> > > > > > Anyhow, I have also been thinking/working on making U-boot
> > > > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > > > ptr values and there is not much one can do about it sans modifying gcc.
> > > > > > So before u-boot is relocated to RAM one must manually add any offset to
> > > > > > all global/static data and string literals. The majority of strings
> > > > > > are passed directly to printf and friends so the offset can be added inside
> > > > > > printf. The remaining few data accesses needs to be dealt with
> directly, example:
> > > > > > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > > > > > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> > > +init_fnc_ptr) {
> > > > > >
> > > > > > Only code called before relocation to RAM needs this, mostly the _f
> () functions.
> > > > > > Would this be an acceptable change?
> > > > >
> > > > > Could you describe the advantages of generating a fully PIC U-Boot
> > > > > image?  I understand you could execute the image from different places
> > > > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > > > For example, its possible to have a preliminary flash mapping that
> > > > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > > > can be modified.  So where U-Boot initially executes from isn't all that
> > > > > important for me.  Is there some killer feature that a fully PIC U-Boot
> > > > > provides to make adding the got_off() workarounds you mention
> > > > > worthwhile?
> > > >
> > > > For me, it is mainly to be to have two u-boot partitions and
> > > > be able to select one to boot from. This makes it safer to
> > > > update u-boot in the field.
> > >
> > > X-ES requires this same functionality of dual booting.  We generally
> > > have a jumper on each card that swaps 2 chip select 0 and 1 so that
> > > either can be booted from (assuming CS 0 is always used to load U-Boot).
> > > The same U-Boot image can be programmed to both flashes.  After U-Boot
> > > relocates to RAM, we remap the flashes (in
> > > board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a
> > > common flash layout regardless of which flash we booted from.  Would it
> > > be possible to do something similar in your hardware setup so that the
> > > same U-Boot image could be loaded from either flash partition without
> > > the got_off() fixups you mention above?
> >
> > Nope, we don't have that extra HW support and won't have in the future
> > either. This type of extra HW logic should not be needed and even if you
> > do have it, how do you flip a jumper remotely? Can be done I am sure, but
> > all this extra HW logic should not be needed at all.
>
> How do you provide true redundancy without some means of changing a chip
> select, hardware strapping pin, etc?  Without hardware support you only
> have 1 code entry point, correct?  If that fails, the board is toast,
> regardless if you have redundant U-Boot images.  The "jumper" I was
> refering to could be a physical jumper, a non-volatile gpio device,
> FPGA, IPMI controller, etc.

I have a small flash block at the reset vector(which is never updated). This
block should choose which boot to branch to. This small boot block only looks
at the two boot images without any HW initialization. The exact method how
to choose boot isn't ready yet, but I figure one could embed a simple crc sum
in u-boot which will validate the boot images.

       Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

On Mon, 2009-09-28 at 16:41 +0200, Joakim Tjernlund wrote:
> Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 14:45:46:
> >
> > On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
> > > Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 06:31:28:
> > > >
> > > > On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> > > > > Wolfgang Denk <wd@denx.de> wrote on 23/09/2009 20:23:14:
> > > > > >
> > > > > > Dear Peter Tyser,
> > > > > >
> > > > > > In message <1253710639.3968.19.camel@ptyser-laptop> you wrote:
> > > > > > >
> > > > > > > My "fix" to the linker script was to change:
> > > > > > > __bss_start = .;
> > > > > > > into:
> > > > > > > __bss_start = . | 4;
> > > > > > >
> > > > > > > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > > > > > > link script workaround.
> > > > > >
> > > > > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > > > > careful!
> > > > >
> > > > > Any progress on this ?
> > > >
> > > > I've been swamped the last few days, but think I have a workaround.  I
> > > > hope to test it tomorrow or tues.  I'll send an email when I have a more
> > > > definitive answer.
> > > >
> > > > > > > Nice!  It'd be great to have the magical 20 lines of assembly put into
> > > > > > > some semi-understandable c.
> > > > > >
> > > > > > :-)
> > > > >
> > > > > I have worked some more on this but all boards need to be converted to use
> > > > > the new C-variants.
> > > >
> > > > Great!
> > > >
> > > > > Anyhow, I have also been thinking/working on making U-boot
> > > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > > ptr values and there is not much one can do about it sans modifying gcc.
> > > > > So before u-boot is relocated to RAM one must manually add any offset to
> > > > > all global/static data and string literals. The majority of strings
> > > > > are passed directly to printf and friends so the offset can be added inside
> > > > > printf. The remaining few data accesses needs to be dealt with directly, example:
> > > > > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > > > > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> > +init_fnc_ptr) {
> > > > >
> > > > > Only code called before relocation to RAM needs this, mostly the _f() functions.
> > > > > Would this be an acceptable change?
> > > >
> > > > Could you describe the advantages of generating a fully PIC U-Boot
> > > > image?  I understand you could execute the image from different places
> > > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > > For example, its possible to have a preliminary flash mapping that
> > > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > > can be modified.  So where U-Boot initially executes from isn't all that
> > > > important for me.  Is there some killer feature that a fully PIC U-Boot
> > > > provides to make adding the got_off() workarounds you mention
> > > > worthwhile?
> > >
> > > For me, it is mainly to be to have two u-boot partitions and
> > > be able to select one to boot from. This makes it safer to
> > > update u-boot in the field.
> 
> Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie
> -fpie is about the same as -fpic and -fPIE is similar to -fPIC
> -fpie generates smaller code so one could consider using -fpie and -mrelocatable
> However -fpic/-fpie needs some fixes to the relocation code, but a quick hack
> by me works on my board.
> 
> Does -fpie and -mrelocatable compile for you and do you have a non zero fixup section?

-fpie and -mrelocatable does compile for me (tested on the XPedite5370
with gcc 4.2.2) and has a non-zero fixup section.  However, the -fpie
U-Boot image is slightly larger:

ptyser at petert u-boot $ size u-boot.PIC
   text	   data	    bss	    dec	    hex	filename
 304300	  28644	  33156	 366100	  59614	u-boot.PIC

ptyser at petert u-boot $ size u-boot.pie
   text	   data	    bss	    dec	    hex	filename
 304508	  28624	  33156	 366288	  596d0	u-boot.pie

Let me know if I can provide any additional detail.

Best,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 17:08:58:
> >
> > Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie
> > -fpie is about the same as -fpic and -fPIE is similar to -fPIC
> > -fpie generates smaller code so one could consider using -fpie and -mrelocatable
> > However -fpic/-fpie needs some fixes to the relocation code, but a quick hack
> > by me works on my board.
> >
> > Does -fpie and -mrelocatable compile for you and do you have a non zero fixup section?
>
> -fpie and -mrelocatable does compile for me (tested on the XPedite5370
> with gcc 4.2.2) and has a non-zero fixup section.  However, the -fpie
> U-Boot image is slightly larger:
>
> ptyser at petert u-boot $ size u-boot.PIC
>    text      data       bss       dec       hex   filename
>  304300     28644     33156    366100     59614   u-boot.PIC
>
> ptyser at petert u-boot $ size u-boot.pie
>    text      data       bss       dec       hex   filename
>  304508     28624     33156    366288     596d0   u-boot.pie
>
> Let me know if I can provide any additional detail.

ehh, that is strange. Did you run a make clean in between?
Do you see any "bl _GLOBAL_OFFSET_TABLE_ at local-4" if you generate
assembler(-S)?
Maybe you had both -fPIC and -fpie defined?

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

>
> Peter Tyser <ptyser@xes-inc.com> wrote on 28/09/2009 17:08:58:
> > >
> > > Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie
> > > -fpie is about the same as -fpic and -fPIE is similar to -fPIC
> > > -fpie generates smaller code so one could consider using -fpie and -mrelocatable
> > > However -fpic/-fpie needs some fixes to the relocation code, but a quick hack
> > > by me works on my board.
> > >
> > > Does -fpie and -mrelocatable compile for you and do you have a non zero
> fixup section?
> >
> > -fpie and -mrelocatable does compile for me (tested on the XPedite5370
> > with gcc 4.2.2) and has a non-zero fixup section.  However, the -fpie
> > U-Boot image is slightly larger:
> >
> > ptyser at petert u-boot $ size u-boot.PIC
> >    text      data       bss       dec       hex   filename
> >  304300     28644     33156    366100     59614   u-boot.PIC
> >
> > ptyser at petert u-boot $ size u-boot.pie
> >    text      data       bss       dec       hex   filename
> >  304508     28624     33156    366288     596d0   u-boot.pie
> >
> > Let me know if I can provide any additional detail.
>
> ehh, that is strange. Did you run a make clean in between?
> Do you see any "bl _GLOBAL_OFFSET_TABLE_ at local-4" if you generate
> assembler(-S)?
> Maybe you had both -fPIC and -fpie defined?

Seems like I was in a hurry, -fpie and -mrelocatable appears to silently
transform into -fPIE -mrelocatable so no gain there.

     Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Jocke & Peter,

In message <OF1F14A150.6DF103F0-ONC125763F.00559936-C125763F.0055D143@transmode.se> you wrote:
>
> > ehh, that is strange. Did you run a make clean in between?
> > Do you see any "bl _GLOBAL_OFFSET_TABLE_ at local-4" if you generate
> > assembler(-S)?
> > Maybe you had both -fPIC and -fpie defined?
> 
> Seems like I was in a hurry, -fpie and -mrelocatable appears to silently
> transform into -fPIE -mrelocatable so no gain there.

Sorry, but I lost thread on this.

It seems discussion stopped here. Is it correct forme to assume that
there is no patch available yet that is considered ripe to be added
(to the "reloc" branch) ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When dreams become more important than reality, you give  up  travel,
building,  creating;  you even forget how to repair the machines left
behind by your ancestors. You just  sit  living  and  reliving  other
lives left behind in the thought records.
	-- Vina, "The Menagerie" ("The Cage"), stardate unknown

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 03/10/2009 10:13:45:
>
> Dear Jocke & Peter,
>
> In message <OF1F14A150.6DF103F0-ONC125763F.00559936-C125763F.
> 0055D143 at transmode.se> you wrote:
> >
> > > ehh, that is strange. Did you run a make clean in between?
> > > Do you see any "bl _GLOBAL_OFFSET_TABLE_ at local-4" if you generate
> > > assembler(-S)?
> > > Maybe you had both -fPIC and -fpie defined?
> >
> > Seems like I was in a hurry, -fpie and -mrelocatable appears to silently
> > transform into -fPIE -mrelocatable so no gain there.
>
> Sorry, but I lost thread on this.
>
> It seems discussion stopped here. Is it correct forme to assume that
> there is no patch available yet that is considered ripe to be added
> (to the "reloc" branch) ?

That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes
and that won't play nice with this patch. Peter was looking into this but
seems like he isn't finished yet.

Also, I have been looking at moving this relocation to C-code and it isn't
quite ready yet. What is left is to modify all ppc boards to use this new C-code

 Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <OF3474ED49.C18DA041-ONC1257644.0033ADEB-C1257644.0034147E@transmode.se> you wrote:
> 
> > It seems discussion stopped here. Is it correct forme to assume that
> > there is no patch available yet that is considered ripe to be added
> > (to the "reloc" branch) ?
> 
> That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes
> and that won't play nice with this patch. Peter was looking into this but
> seems like he isn't finished yet.
> 
> Also, I have been looking at moving this relocation to C-code and it isn't
> quite ready yet. What is left is to modify all ppc boards to use this new C-code

So how should we proceed? My plan was to merge the "reloc" branch by
the end of next week. Is this still realistic?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of all possible committee reactions to any  given  agenda  item,  the
reaction  that will occur is the one which will liberate the greatest
amount of hot air.                                -- Thomas L. Martin

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 03/10/2009 14:13:57:
>
> Dear Joakim Tjernlund,
>
> In message <OF3474ED49.C18DA041-ONC1257644.0033ADEB-C1257644.
> 0034147E at transmode.se> you wrote:
> >
> > > It seems discussion stopped here. Is it correct forme to assume that
> > > there is no patch available yet that is considered ripe to be added
> > > (to the "reloc" branch) ?
> >
> > That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes
> > and that won't play nice with this patch. Peter was looking into this but
> > seems like he isn't finished yet.
> >
> > Also, I have been looking at moving this relocation to C-code and it isn't
> > quite ready yet. What is left is to modify all ppc boards to use this new C-code
>
> So how should we proceed? My plan was to merge the "reloc" branch by
> the end of next week. Is this still realistic?

Yes, my work is not required. Actually the current u-boot also suffers from this
defect. I am only trying to future prof the relocation.
Some day we might want to do:
 if (weak_fun)
    weak_fun();
but today nobody is using this in u-boot.

 Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

On Sat, 2009-10-03 at 14:13 +0200, Wolfgang Denk wrote:
> Dear Joakim Tjernlund,
> 
> In message <OF3474ED49.C18DA041-ONC1257644.0033ADEB-C1257644.0034147E@transmode.se> you wrote:
> > 
> > > It seems discussion stopped here. Is it correct forme to assume that
> > > there is no patch available yet that is considered ripe to be added
> > > (to the "reloc" branch) ?
> > 
> > That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes
> > and that won't play nice with this patch. Peter was looking into this but
> > seems like he isn't finished yet.
> > 
> > Also, I have been looking at moving this relocation to C-code and it isn't
> > quite ready yet. What is left is to modify all ppc boards to use this new C-code
> 
> So how should we proceed? My plan was to merge the "reloc" branch by
> the end of next week. Is this still realistic?

That plan is realistic.  The executive summary is:
The current "reloc" branch works, and is an improvement on U-Boot's
previous "semi-reolcation", so we should merge it for this release.

There are a few change which would further improve relocation that Jocke
and I want to get merged.  Whether these improvements occur in this
release or the next is not a big deal to me.
1. Fix relocation of NULL pointers.
eg the following code would print the relocation fixup offset instead of
the expected NULL.
   void weak_fun(void) __attribute__((weak));
   printf("weak_fun:%p\n", weak_fun);
This was already an issue, so we're not breaking anything in the "reloc"
branch

2. Move relocation fixup code to C-code

3. Possibly get true relocation working so that U-Boot could be located
anywhere and still execute.

Jocke has 1 and 2 mostly figured out, I just need some time to play with
the linker scripts a bit more to ensure nothing breaks.  (Sorry Jocke,
its been a busy week).

Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Peter,

In message <1254577553.23101.14.camel@ptyser-laptop> you wrote:
>
> > So how should we proceed? My plan was to merge the "reloc" branch by
> > the end of next week. Is this still realistic?
> 
> That plan is realistic.  The executive summary is:
> The current "reloc" branch works, and is an improvement on U-Boot's
> previous "semi-reolcation", so we should merge it for this release.

OK, so let's do that.

> There are a few change which would further improve relocation that Jocke
> and I want to get merged.  Whether these improvements occur in this
> release or the next is not a big deal to me.
> 1. Fix relocation of NULL pointers.
> eg the following code would print the relocation fixup offset instead of
> the expected NULL.
>    void weak_fun(void) __attribute__((weak));
>    printf("weak_fun:%p\n", weak_fun);
> This was already an issue, so we're not breaking anything in the "reloc"
> branch
> 
> 2. Move relocation fixup code to C-code
> 
> 3. Possibly get true relocation working so that U-Boot could be located
> anywhere and still execute.

I tend to get all of this (as far as it's available and considered to
be ready) into this release, so we have it all in one big block.

> Jocke has 1 and 2 mostly figured out, I just need some time to play with
> the linker scripts a bit more to ensure nothing breaks.  (Sorry Jocke,
> its been a busy week).

You don't have to apologize. We've all been in similar situations
before. And we really appreciate your efforts (and Jocke's, of
course).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q:  Why do mountain climbers rope themselves together?
A:  To prevent the sensible ones from going home.

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 03/10/2009 16:28:23:
>
> Dear Peter,
>
> In message <1254577553.23101.14.camel@ptyser-laptop> you wrote:
> >
> > > So how should we proceed? My plan was to merge the "reloc" branch by
> > > the end of next week. Is this still realistic?
> >
> > That plan is realistic.  The executive summary is:
> > The current "reloc" branch works, and is an improvement on U-Boot's
> > previous "semi-reolcation", so we should merge it for this release.
>
> OK, so let's do that.
>
> > There are a few change which would further improve relocation that Jocke
> > and I want to get merged.  Whether these improvements occur in this
> > release or the next is not a big deal to me.
> > 1. Fix relocation of NULL pointers.
> > eg the following code would print the relocation fixup offset instead of
> > the expected NULL.
> >    void weak_fun(void) __attribute__((weak));
> >    printf("weak_fun:%p\n", weak_fun);
> > This was already an issue, so we're not breaking anything in the "reloc"
> > branch
> >
> > 2. Move relocation fixup code to C-code
> >
> > 3. Possibly get true relocation working so that U-Boot could be located
> > anywhere and still execute.
>
> I tend to get all of this (as far as it's available and considered to
> be ready) into this release, so we have it all in one big block.

3. isn't ready and won't be for a while more

1. is just a small fix the the existing asm reloc functions. Pretty much
   ready but needs some linker tweeks it seems. No idea if other
   boards than 85xx also needs a linker tweak or not.

2. is 1 in C and some common supporting asm for ppc. Any idea were
   to put common asm files for ppc? I was hoping I could get away with
   just 83xx and the rest could be done later by interested parties?

I have also done some work to fully relocate the IRQ code so
one can remove the --fixed-r14 flag to gcc for 83xx.

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Jocke,

In message <OFC719203E.B96F8807-ONC1257644.00522490-C1257644.005349B9@transmode.se> you wrote:
>
> > I tend to get all of this (as far as it's available and considered to
> > be ready) into this release, so we have it all in one big block.
> 
> 3. isn't ready and won't be for a while more

OK...

> 1. is just a small fix the the existing asm reloc functions. Pretty much
>    ready but needs some linker tweeks it seems. No idea if other
>    boards than 85xx also needs a linker tweak or not.
> 
> 2. is 1 in C and some common supporting asm for ppc. Any idea were
>    to put common asm files for ppc? I was hoping I could get away with
>    just 83xx and the rest could be done later by interested parties?

What about lib_ppc/*.S ?

> I have also done some work to fully relocate the IRQ code so
> one can remove the --fixed-r14 flag to gcc for 83xx.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
ATTENTION: Despite Any Other Listing of Product Contents Found  Here-
on, the Consumer is Advised That, in Actuality, This Product Consists
Of 99.9999999999% Empty Space.

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

Hi Wolfgang,

> > My "fix" to the linker script was to change:
> > __bss_start = .;
> > into:
> > __bss_start = . | 4;
> > 
> > ie, a big hack, but it did work:)  I'll take a peek at a more proper
> > link script workaround.
> 
> 32 bit alignment of the BSS segment might not be sufficient. Be
> careful!

I've tried a few ways to ensure the BSS isn't at address 0x0, and they
all seem to have their shortcomings.  I'm currently leaning towards
doing something along the lines of the above, ie ORing 0x10 into the BSS
address.

I had assumed 8 or 16 bit alignment of the BSS would be sufficient.
Could you give a little background on your warning above about 32 bit
alignment being insufficient?

Thanks,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Peter Tyser,

In message <1254773254.24664.657.camel@localhost.localdomain> you wrote:
> 
> > 32 bit alignment of the BSS segment might not be sufficient. Be
> > careful!
> 
> I've tried a few ways to ensure the BSS isn't at address 0x0, and they
> all seem to have their shortcomings.  I'm currently leaning towards
> doing something along the lines of the above, ie ORing 0x10 into the BSS
> address.
> 
> I had assumed 8 or 16 bit alignment of the BSS would be sufficient.
> Could you give a little background on your warning above about 32 bit
> alignment being insufficient?

I don't know all flavours of Power machines, but gcc seems to align
"double" on 64 bit boundaries. This makes me think it might be needed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"355/113 -- Not the famous irrational number PI,  but  an  incredible
simulation!"

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

Hi Jocke,

> > > There are a few change which would further improve relocation that Jocke
> > > and I want to get merged.  Whether these improvements occur in this
> > > release or the next is not a big deal to me.
> > > 1. Fix relocation of NULL pointers.
> > > eg the following code would print the relocation fixup offset instead of
> > > the expected NULL.
> > >    void weak_fun(void) __attribute__((weak));
> > >    printf("weak_fun:%p\n", weak_fun);
> > > This was already an issue, so we're not breaking anything in the "reloc"
> > > branch
> > >
> > > 2. Move relocation fixup code to C-code
> > >
> > > 3. Possibly get true relocation working so that U-Boot could be located
> > > anywhere and still execute.
> >
> > I tend to get all of this (as far as it's available and considered to
> > be ready) into this release, so we have it all in one big block.
> 
> 3. isn't ready and won't be for a while more
> 
> 1. is just a small fix the the existing asm reloc functions. Pretty much
>    ready but needs some linker tweeks it seems. No idea if other
>    boards than 85xx also needs a linker tweak or not.

It looks like 85xx is the only arch that needed linker script tweaks.  I
just submitted some patches a bit ago.

> 2. is 1 in C and some common supporting asm for ppc. Any idea were
>    to put common asm files for ppc? I was hoping I could get away with
>    just 83xx and the rest could be done later by interested parties?

Assuming the 85xx link script changes are accepted, what's the gameplan
now?  #1 is pretty trivial (the original patch that spawned this thread
with slight tweaks) and should be easy to get in this merge window.
That would get us to the point that relocation is fully functional,
including non-relocation of NULL pointers.

#2 looks more involved and prone to errors as it requires some shuffling
of registers in assembly for all architectures.  Are we aiming for
getting #2 across all architectures in this window?  I should be able to
implement and test it on 85xx, 86xx, and 44x, and Jocke's tested on
83xx.  I don't think I could do the rest of the arches by the end of
this week though.  Any other takers?  Save it for the next merge window?

Best,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Peter Tyser,

In message <1254784811.24664.968.camel@localhost.localdomain> you wrote:
> 
> > 1. is just a small fix the the existing asm reloc functions. Pretty much
> >    ready but needs some linker tweeks it seems. No idea if other
> >    boards than 85xx also needs a linker tweak or not.
> 
> It looks like 85xx is the only arch that needed linker script tweaks.  I
> just submitted some patches a bit ago.

I think this code is too complex. Eventually we could hard-wire
something like ". = 0x40000" or similar for a fixed location of the
(pre-relocation) bss on all 85xx/86xx systems.

> > 2. is 1 in C and some common supporting asm for ppc. Any idea were
> >    to put common asm files for ppc? I was hoping I could get away with
> >    just 83xx and the rest could be done later by interested parties?
> 
> Assuming the 85xx link script changes are accepted, what's the gameplan
> now?  #1 is pretty trivial (the original patch that spawned this thread
> with slight tweaks) and should be easy to get in this merge window.
> That would get us to the point that relocation is fully functional,
> including non-relocation of NULL pointers.

I think this is a nice and realistic goal for the current release.

> #2 looks more involved and prone to errors as it requires some shuffling
> of registers in assembly for all architectures.  Are we aiming for
> getting #2 across all architectures in this window?  I should be able to
> implement and test it on 85xx, 86xx, and 44x, and Jocke's tested on
> 83xx.  I don't think I could do the rest of the arches by the end of
> this week though.  Any other takers?  Save it for the next merge window?

I guess this is for next version.


Um... jut to be sure - I understand that by "all architectures" above
you actually mean "all Power architecture CPU families",  i.  e.  you
don't include the needed cleanup for ARM, MIPs, etc. here (yet) ?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
365 Days of drinking Lo-Cal beer.                       1 Lite-year

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 06/10/2009 10:58:53:
>
> Dear Peter Tyser,
>
> In message <1254784811.24664.968.camel@localhost.localdomain> you wrote:
> >
> > > 1. is just a small fix the the existing asm reloc functions. Pretty much
> > >    ready but needs some linker tweeks it seems. No idea if other
> > >    boards than 85xx also needs a linker tweak or not.
> >
> > It looks like 85xx is the only arch that needed linker script tweaks.  I
> > just submitted some patches a bit ago.
>
> I think this code is too complex. Eventually we could hard-wire
> something like ". = 0x40000" or similar for a fixed location of the
> (pre-relocation) bss on all 85xx/86xx systems.
>
> > > 2. is 1 in C and some common supporting asm for ppc. Any idea were
> > >    to put common asm files for ppc? I was hoping I could get away with
> > >    just 83xx and the rest could be done later by interested parties?
> >
> > Assuming the 85xx link script changes are accepted, what's the gameplan
> > now?  #1 is pretty trivial (the original patch that spawned this thread
> > with slight tweaks) and should be easy to get in this merge window.
> > That would get us to the point that relocation is fully functional,
> > including non-relocation of NULL pointers.
>
> I think this is a nice and realistic goal for the current release.

Yes, then it works and the C-version can come on top.

>
> > #2 looks more involved and prone to errors as it requires some shuffling
> > of registers in assembly for all architectures.  Are we aiming for
> > getting #2 across all architectures in this window?  I should be able to
> > implement and test it on 85xx, 86xx, and 44x, and Jocke's tested on
> > 83xx.  I don't think I could do the rest of the arches by the end of
> > this week though.  Any other takers?  Save it for the next merge window?
>
> I guess this is for next version.

Yes, I am getting behind due to some 8xx MMU problems. If I am really lucky I
may be able to do 83xx only, but my code base is a mess ATM :(

>
>
> Um... jut to be sure - I understand that by "all architectures" above
> you actually mean "all Power architecture CPU families",  i.  e.  you
> don't include the needed cleanup for ARM, MIPs, etc. here (yet) ?

I sure hope so :)

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Scott Wood]

On Mon, Oct 05, 2009 at 11:18:11PM +0200, Wolfgang Denk wrote:
> Dear Peter Tyser,
> 
> In message <1254773254.24664.657.camel@localhost.localdomain> you wrote:
> > 
> > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > careful!
> > 
> > I've tried a few ways to ensure the BSS isn't at address 0x0, and they
> > all seem to have their shortcomings.  I'm currently leaning towards
> > doing something along the lines of the above, ie ORing 0x10 into the BSS
> > address.
> > 
> > I had assumed 8 or 16 bit alignment of the BSS would be sufficient.
> > Could you give a little background on your warning above about 32 bit
> > alignment being insufficient?
> 
> I don't know all flavours of Power machines, but gcc seems to align
> "double" on 64 bit boundaries. This makes me think it might be needed.

Plus, explicit alignment (cacheline, page, some DMA alignment
restriction, etc) could have been requested on something in the BSS.  I'd
keep it at least page-aligned if possible.

-Scott

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Scott Wood,

In message <20091006171203.GA10244@b07421-ec1.am.freescale.net> you wrote:
>
> > I don't know all flavours of Power machines, but gcc seems to align
> > "double" on 64 bit boundaries. This makes me think it might be needed.
> 
> Plus, explicit alignment (cacheline, page, some DMA alignment
> restriction, etc) could have been requested on something in the BSS.  I'd
> keep it at least page-aligned if possible.

We have no notation of "pages" in U-Boot. Linker scripts typically use
256 byte alignment as the most strict requriement, and this is
randomly chosen, either. I guess cache line size would do just fine
(and even this is probably overkill).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
They say, well, meybe it _is_ smelly, maybe it _is_ overcrowded, may-
be it _is_ a bit like Hell would be if they shut the  fires  off  and
stabled  a  herd  of  incontinent cows there for a year, but you must
admit that it is full of sheer, vibrant, dynamic _life_.
                                 - Terry Pratchett, _Moving Pictures_

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Peter Tyser,

In message <1255009252.9100.1019.camel@localhost.localdomain> you wrote:
> 
> > > Jocke, Peter: am I understanding correctly that we now have everything
> > > in the "reloc" branch that we want to include with this upcoming
> > > release, i. e. that we can do the "final" testing now before I merge
> > > that branch into master?
> > 
> > Yes, I have nothing more ready and I believe everything is in place.
> 
> Same here, should be good to go.

I tested the "reloc" branch on a few boards, and didn't see any
problems.  So I decided to go ahead and merged it into "master".

It's in mainline now :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
On my planet, to rest is to rest -- to cease using energy. To me,  it
is  quite  illogical to run up and down on green grass, using energy,
instead of saving it.
	-- Spock, "Shore Leave", stardate 3025.2

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

> > Jocke, Peter: am I understanding correctly that we now have everything
> > in the "reloc" branch that we want to include with this upcoming
> > release, i. e. that we can do the "final" testing now before I merge
> > that branch into master?
> 
> Yes, I have nothing more ready and I believe everything is in place.

Same here, should be good to go.

Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 08/10/2009 14:44:07:
>
> Dear Joakim Tjernlund,
>
> In message <OF5F1602B1.C165074D-ONC1257649.0030F813-C1257649.
> 00311F2C at transmode.se> you wrote:
> >
> > > Could you next time _please_ add this "v3" information to the
> > > Subject:, say as "[PATCH v3] relocation: ..." ?
> >
> > You sure are hard to please :)
>
> Not really. I consider this a basic requirement to patch submission.
> In your case, I received two patches with identical subjets within a
> very short interval. In such cases it is impossible to say which was
> sent first, i.e. I have to rely on (often non-working) threading
> and/or to open the messages and try to figure out from content which
> is what. This is just a waste of time.

That was not seriously meant, hence the :)
Sorry for the confusion.

      Jocke

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <OF5F1602B1.C165074D-ONC1257649.0030F813-C1257649.00311F2C@transmode.se> you wrote:
> 
> > Could you next time _please_ add this "v3" information to the
> > Subject:, say as "[PATCH v3] relocation: ..." ?
> 
> You sure are hard to please :)

Not really. I consider this a basic requirement to patch submission.
In your case, I received two patches with identical subjets within a
very short interval. In such cases it is impossible to say which was
sent first, i.e. I have to rely on (often non-working) threading
and/or to open the messages and try to figure out from content which
is what. This is just a waste of time.

> > Jocke, Peter: am I understanding correctly that we now have everything
> > in the "reloc" branch that we want to include with this upcoming
> > release, i. e. that we can do the "final" testing now before I merge
> > that branch into master?
> 
> Yes, I have nothing more ready and I believe everything is in place.

Good.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are three ways to get something done:
        (1) Do it yourself.
        (2) Hire someone to do it for you.
        (3) Forbid your kids to do it.

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

>
> Dear Joakim Tjernlund,
>
> In message <1254960231-11441-1-git-send-email-Joakim.Tjernlund@transmode.se> you wrote:
> > NULL is an absolute value and should not be relocated.
> > After this correction code like:
> >  void weak_fun(void) __attribute__((weak));
> >  printf("weak_fun:%p\n", weak_fun);
> > will still print null after relocation.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> >
> >  v2 - add ppc4xx
> >  v3 - add 74xx_7xx
>
> Could you next time _please_ add this "v3" information to the
> Subject:, say as "[PATCH v3] relocation: ..." ?

You sure are hard to please :)

>
> Thanks!
>
>
> >  cpu/74xx_7xx/start.S |    6 ++++--
> >  cpu/mpc512x/start.S  |    6 ++++--
> >  cpu/mpc5xx/start.S   |    6 ++++--
> >  cpu/mpc5xxx/start.S  |    6 ++++--
> >  cpu/mpc8220/start.S  |    6 ++++--
> >  cpu/mpc824x/start.S  |    6 ++++--
> >  cpu/mpc8260/start.S  |    6 ++++--
> >  cpu/mpc83xx/start.S  |    6 ++++--
> >  cpu/mpc85xx/start.S  |    6 ++++--
> >  cpu/mpc86xx/start.S  |    6 ++++--
> >  cpu/mpc8xx/start.S   |    6 ++++--
> >  cpu/ppc4xx/start.S   |    6 ++++--
> >  12 files changed, 48 insertions(+), 24 deletions(-)
>
> I really wonder why we have that many copis of that code :-(
>
>
> Applied to reloc branch.
>
>
> Jocke, Peter: am I understanding correctly that we now have everything
> in the "reloc" branch that we want to include with this upcoming
> release, i. e. that we can do the "final" testing now before I merge
> that branch into master?

Yes, I have nothing more ready and I believe everything is in place.

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <1254960231-11441-1-git-send-email-Joakim.Tjernlund@transmode.se> you wrote:
> NULL is an absolute value and should not be relocated.
> After this correction code like:
>  void weak_fun(void) __attribute__((weak));
>  printf("weak_fun:%p\n", weak_fun);
> will still print null after relocation.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> 
>  v2 - add ppc4xx
>  v3 - add 74xx_7xx

Could you next time _please_ add this "v3" information to the
Subject:, say as "[PATCH v3] relocation: ..." ?

Thanks!


>  cpu/74xx_7xx/start.S |    6 ++++--
>  cpu/mpc512x/start.S  |    6 ++++--
>  cpu/mpc5xx/start.S   |    6 ++++--
>  cpu/mpc5xxx/start.S  |    6 ++++--
>  cpu/mpc8220/start.S  |    6 ++++--
>  cpu/mpc824x/start.S  |    6 ++++--
>  cpu/mpc8260/start.S  |    6 ++++--
>  cpu/mpc83xx/start.S  |    6 ++++--
>  cpu/mpc85xx/start.S  |    6 ++++--
>  cpu/mpc86xx/start.S  |    6 ++++--
>  cpu/mpc8xx/start.S   |    6 ++++--
>  cpu/ppc4xx/start.S   |    6 ++++--
>  12 files changed, 48 insertions(+), 24 deletions(-)

I really wonder why we have that many copis of that code :-(


Applied to reloc branch.


Jocke, Peter: am I understanding correctly that we now have everything
in the "reloc" branch that we want to include with this upcoming
release, i. e. that we can do the "final" testing now before I merge
that branch into master?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I go on working for the same reason a hen goes on laying eggs."
- H. L. Mencken

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

NULL is an absolute value and should not be relocated.
After this correction code like:
 void weak_fun(void) __attribute__((weak));
 printf("weak_fun:%p\n", weak_fun);
will still print null after relocation.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---

 v2 - add ppc4xx
 v3 - add 74xx_7xx

 cpu/74xx_7xx/start.S |    6 ++++--
 cpu/mpc512x/start.S  |    6 ++++--
 cpu/mpc5xx/start.S   |    6 ++++--
 cpu/mpc5xxx/start.S  |    6 ++++--
 cpu/mpc8220/start.S  |    6 ++++--
 cpu/mpc824x/start.S  |    6 ++++--
 cpu/mpc8260/start.S  |    6 ++++--
 cpu/mpc83xx/start.S  |    6 ++++--
 cpu/mpc85xx/start.S  |    6 ++++--
 cpu/mpc86xx/start.S  |    6 ++++--
 cpu/mpc8xx/start.S   |    6 ++++--
 cpu/ppc4xx/start.S   |    6 ++++--
 12 files changed, 48 insertions(+), 24 deletions(-)

diff --git a/cpu/74xx_7xx/start.S b/cpu/74xx_7xx/start.S
index 792cd30..23381a3 100644
--- a/cpu/74xx_7xx/start.S
+++ b/cpu/74xx_7xx/start.S
@@ -716,15 +716,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc512x/start.S b/cpu/mpc512x/start.S
index 360682d..a00e045 100644
--- a/cpu/mpc512x/start.S
+++ b/cpu/mpc512x/start.S
@@ -609,15 +609,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc5xx/start.S b/cpu/mpc5xx/start.S
index 106935c..85ea7a8 100644
--- a/cpu/mpc5xx/start.S
+++ b/cpu/mpc5xx/start.S
@@ -458,15 +458,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc5xxx/start.S b/cpu/mpc5xxx/start.S
index 6b1162a..eb42939 100644
--- a/cpu/mpc5xxx/start.S
+++ b/cpu/mpc5xxx/start.S
@@ -684,15 +684,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8220/start.S b/cpu/mpc8220/start.S
index 3abc619..af9472d 100644
--- a/cpu/mpc8220/start.S
+++ b/cpu/mpc8220/start.S
@@ -649,15 +649,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc824x/start.S b/cpu/mpc824x/start.S
index 39325cd..750457b 100644
--- a/cpu/mpc824x/start.S
+++ b/cpu/mpc824x/start.S
@@ -589,15 +589,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8260/start.S b/cpu/mpc8260/start.S
index 379f2fb..edb95e6 100644
--- a/cpu/mpc8260/start.S
+++ b/cpu/mpc8260/start.S
@@ -909,15 +909,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S
index 26e3106..ee4b862 100644
--- a/cpu/mpc83xx/start.S
+++ b/cpu/mpc83xx/start.S
@@ -957,16 +957,18 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 #ifndef CONFIG_NAND_SPL
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S
index 4f7236f..d56003b 100644
--- a/cpu/mpc85xx/start.S
+++ b/cpu/mpc85xx/start.S
@@ -932,15 +932,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc86xx/start.S b/cpu/mpc86xx/start.S
index 63cc8db..e65f1c0 100644
--- a/cpu/mpc86xx/start.S
+++ b/cpu/mpc86xx/start.S
@@ -733,15 +733,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8xx/start.S b/cpu/mpc8xx/start.S
index 8864c37..e84326e 100644
--- a/cpu/mpc8xx/start.S
+++ b/cpu/mpc8xx/start.S
@@ -589,15 +589,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
index f2b8908..c3cf2ba 100644
--- a/cpu/ppc4xx/start.S
+++ b/cpu/ppc4xx/start.S
@@ -1568,15 +1568,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
-- 
1.6.4.4

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser@xes-inc.com> wrote on 08/10/2009 01:49:40:
>
> Hi Jocke,
>
> > v2: included ppc4xx too.
>
> Looks like cpu/74xx_7xx is missing too:(

Yeah, the cpu directory is a mess. Sending
a new version.

>
> >  cpu/mpc512x/start.S |    6 ++++--
> >  cpu/mpc5xx/start.S  |    6 ++++--
> >  cpu/mpc5xxx/start.S |    6 ++++--
> >  cpu/mpc8220/start.S |    6 ++++--
> >  cpu/mpc824x/start.S |    6 ++++--
> >  cpu/mpc8260/start.S |    6 ++++--
> >  cpu/mpc83xx/start.S |    6 ++++--
> >  cpu/mpc85xx/start.S |    6 ++++--
> >  cpu/mpc86xx/start.S |    6 ++++--
> >  cpu/mpc8xx/start.S  |    6 ++++--
> >  cpu/ppc4xx/start.S  |    6 ++++--
> >  11 files changed, 44 insertions(+), 22 deletions(-)
>
> Best,
> Peter
>
>
>

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Peter Tyser]

Hi Jocke,

> v2: included ppc4xx too.

Looks like cpu/74xx_7xx is missing too:(

>  cpu/mpc512x/start.S |    6 ++++--
>  cpu/mpc5xx/start.S  |    6 ++++--
>  cpu/mpc5xxx/start.S |    6 ++++--
>  cpu/mpc8220/start.S |    6 ++++--
>  cpu/mpc824x/start.S |    6 ++++--
>  cpu/mpc8260/start.S |    6 ++++--
>  cpu/mpc83xx/start.S |    6 ++++--
>  cpu/mpc85xx/start.S |    6 ++++--
>  cpu/mpc86xx/start.S |    6 ++++--
>  cpu/mpc8xx/start.S  |    6 ++++--
>  cpu/ppc4xx/start.S  |    6 ++++--
>  11 files changed, 44 insertions(+), 22 deletions(-)

Best,
Peter

[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

NULL is an absolute value and should not be relocated.
After this correction code like:
 void weak_fun(void) __attribute__((weak));
 printf("weak_fun:%p\n", weak_fun);
will still print null after relocation.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---

So here is the latest version of the patch.

v2: included ppc4xx too.
 cpu/mpc512x/start.S |    6 ++++--
 cpu/mpc5xx/start.S  |    6 ++++--
 cpu/mpc5xxx/start.S |    6 ++++--
 cpu/mpc8220/start.S |    6 ++++--
 cpu/mpc824x/start.S |    6 ++++--
 cpu/mpc8260/start.S |    6 ++++--
 cpu/mpc83xx/start.S |    6 ++++--
 cpu/mpc85xx/start.S |    6 ++++--
 cpu/mpc86xx/start.S |    6 ++++--
 cpu/mpc8xx/start.S  |    6 ++++--
 cpu/ppc4xx/start.S  |    6 ++++--
 11 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/cpu/mpc512x/start.S b/cpu/mpc512x/start.S
index 360682d..a00e045 100644
--- a/cpu/mpc512x/start.S
+++ b/cpu/mpc512x/start.S
@@ -609,15 +609,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc5xx/start.S b/cpu/mpc5xx/start.S
index 106935c..85ea7a8 100644
--- a/cpu/mpc5xx/start.S
+++ b/cpu/mpc5xx/start.S
@@ -458,15 +458,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc5xxx/start.S b/cpu/mpc5xxx/start.S
index 6b1162a..eb42939 100644
--- a/cpu/mpc5xxx/start.S
+++ b/cpu/mpc5xxx/start.S
@@ -684,15 +684,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8220/start.S b/cpu/mpc8220/start.S
index 3abc619..af9472d 100644
--- a/cpu/mpc8220/start.S
+++ b/cpu/mpc8220/start.S
@@ -649,15 +649,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc824x/start.S b/cpu/mpc824x/start.S
index 39325cd..750457b 100644
--- a/cpu/mpc824x/start.S
+++ b/cpu/mpc824x/start.S
@@ -589,15 +589,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8260/start.S b/cpu/mpc8260/start.S
index 379f2fb..edb95e6 100644
--- a/cpu/mpc8260/start.S
+++ b/cpu/mpc8260/start.S
@@ -909,15 +909,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S
index 26e3106..ee4b862 100644
--- a/cpu/mpc83xx/start.S
+++ b/cpu/mpc83xx/start.S
@@ -957,16 +957,18 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 #ifndef CONFIG_NAND_SPL
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S
index 4f7236f..d56003b 100644
--- a/cpu/mpc85xx/start.S
+++ b/cpu/mpc85xx/start.S
@@ -932,15 +932,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc86xx/start.S b/cpu/mpc86xx/start.S
index 63cc8db..e65f1c0 100644
--- a/cpu/mpc86xx/start.S
+++ b/cpu/mpc86xx/start.S
@@ -733,15 +733,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/mpc8xx/start.S b/cpu/mpc8xx/start.S
index 8864c37..e84326e 100644
--- a/cpu/mpc8xx/start.S
+++ b/cpu/mpc8xx/start.S
@@ -589,15 +589,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
index f2b8908..c3cf2ba 100644
--- a/cpu/ppc4xx/start.S
+++ b/cpu/ppc4xx/start.S
@@ -1568,15 +1568,17 @@ in_ram:
 	sub	r11,r3,r11
 	addi	r3,r3,-4
 1:	lwzu	r0,4(r3)
+	cmpwi	r0,0
+	beq-	2f
 	add	r0,r0,r11
 	stw	r0,0(r3)
-	bdnz	1b
+2:	bdnz	1b
 
 	/*
 	 * Now adjust the fixups and the pointers to the fixups
 	 * in case we need to move ourselves again.
 	 */
-2:	li	r0,__fixup_entries at sectoff@l
+	li	r0,__fixup_entries at sectoff@l
 	lwz	r3,GOT(_FIXUP_TABLE_)
 	cmpwi	r0,0
 	mtctr	r0
-- 
1.6.4.4