[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
and use GOT relative reference.
---
 cpu/mpc83xx/start.S |   11 +++++++----
 lib_ppc/board.c     |    3 ++-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S
index 1dfbf62..56fd7ec 100644
--- a/cpu/mpc83xx/start.S
+++ b/cpu/mpc83xx/start.S
@@ -172,8 +172,11 @@ boot_warm: /* time t 5 */
 	/* there and deflate the flash size back to minimal size      */
 	/*------------------------------------------------------------*/
 	bl map_flash_by_law1
-	lis r4, (CFG_MONITOR_BASE)@h
-	ori r4, r4, (CFG_MONITOR_BASE)@l
+
+	GET_GOT			/* initialize GOT access	*/
+	lwz r4, GOT(_start)	
+	addi r4, r4, -EXC_OFF_SYS_RESET
+
 	addi r5, r4, in_flash - _start + EXC_OFF_SYS_RESET
 	mtlr r5
 	blr
@@ -906,8 +909,8 @@ relocate_code:
 	mr	r10, r5		/* Save copy of Destination Address */
 
 	mr	r3,  r5				/* Destination Address */
-	lis	r4, CFG_MONITOR_BASE at h		/* Source      Address */
-	ori	r4, r4, CFG_MONITOR_BASE at l
+	lwz	r4, GOT(_start)
+	addi	r4, r4, -EXC_OFF_SYS_RESET	
 	lwz	r5, GOT(__init_end)
 	sub	r5, r5, r4
 	li	r6, CFG_CACHELINE_SIZE		/* Cache Line Size */
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 45d1328..8a18350 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -117,6 +117,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define	TOTAL_MALLOC_LEN	CFG_MALLOC_LEN
 #endif
 
+extern ulong _start;
 extern ulong __init_end;
 extern ulong _end;
 ulong monitor_flash_len;
@@ -417,7 +418,7 @@ void board_init_f (ulong bootflag)
 	 *  - monitor code
 	 *  - board info struct
 	 */
-	len = (ulong)&_end - CFG_MONITOR_BASE;
+	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;
 
 #ifndef	CONFIG_VERY_BIG_RAM
 	addr = CFG_SDRAM_BASE + gd->ram_size;
-- 
1.5.3.8

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Kim Phillips]

On Fri, 28 Mar 2008 15:41:25 +0100
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote:

> Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> and use GOT relative reference.
> ---
>  cpu/mpc83xx/start.S |   11 +++++++----
>  lib_ppc/board.c     |    3 ++-
>  2 files changed, 9 insertions(+), 5 deletions(-)

Joakim,

this patch is missing your signoff, and doesn't apply cleanly (even
adds whitespace).

btw, shouldn't it fix up the other ppc start.S files?

Kim

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

> -----Original Message-----
> From: Kim Phillips [mailto:kim.phillips at freescale.com]
> Sent: den 29 mars 2008 00:33
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [PATCH] Make MPC83xx one step closer to full relocation.
> 
> On Fri, 28 Mar 2008 15:41:25 +0100
> Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote:
> 
> > Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> > and use GOT relative reference.
> > ---
> >  cpu/mpc83xx/start.S |   11 +++++++----
> >  lib_ppc/board.c     |    3 ++-
> >  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> Joakim,
> 
> this patch is missing your signoff, and doesn't apply cleanly (even
> adds whitespace).

It doesn't apply because you have been sitting on it for too long :)
I sent long ago and you said would apply it in the next merge window,
but seems to have forgotten about it. Sorry for the whitespace. I am still
on the last u-boot release so I am afraid I can't do much about it ATM.
I hope you can clean up the WS.

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

> 
> btw, shouldn't it fix up the other ppc start.S files?

The other ppc's won't break and I only got a 83xx, hence I only did
it for 83xx, hoping it would serve as a guide for the rest.

    Jocke

> 
> Kim
> 

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Kim Phillips]

On Sat, 29 Mar 2008 00:47:01 +0100
"Joakim Tjernlund" <Joakim.Tjernlund@transmode.se> wrote:

> > -----Original Message-----
> > From: Kim Phillips [mailto:kim.phillips at freescale.com]
> > Sent: den 29 mars 2008 00:33
> > To: Joakim Tjernlund
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: Re: [PATCH] Make MPC83xx one step closer to full relocation.
> > 
> > On Fri, 28 Mar 2008 15:41:25 +0100
> > Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote:
> > 
> > > Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> > > and use GOT relative reference.
> > > ---
> > >  cpu/mpc83xx/start.S |   11 +++++++----
> > >  lib_ppc/board.c     |    3 ++-
> > >  2 files changed, 9 insertions(+), 5 deletions(-)
> > 
> > Joakim,
> > 
> > this patch is missing your signoff, and doesn't apply cleanly (even
> > adds whitespace).
> 
> It doesn't apply because you have been sitting on it for too long :)
> I sent long ago and you said would apply it in the next merge window,
> but seems to have forgotten about it. Sorry for the whitespace. I am still
> on the last u-boot release so I am afraid I can't do much about it ATM.
> I hope you can clean up the WS.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>

ok, I can add it now.

Kim

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

> -----Original Message-----
> From: Kim Phillips [mailto:kim.phillips at freescale.com]
> Sent: den 29 mars 2008 01:01
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [PATCH] Make MPC83xx one step closer to full relocation.
> 
> On Sat, 29 Mar 2008 00:47:01 +0100
> "Joakim Tjernlund" <Joakim.Tjernlund@transmode.se> wrote:
> 
> > > -----Original Message-----
> > > From: Kim Phillips [mailto:kim.phillips at freescale.com]
> > > Sent: den 29 mars 2008 00:33
> > > To: Joakim Tjernlund
> > > Cc: u-boot-users at lists.sourceforge.net
> > > Subject: Re: [PATCH] Make MPC83xx one step closer to full relocation.
> > >
> > > On Fri, 28 Mar 2008 15:41:25 +0100
> > > Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote:
> > >
> > > > Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> > > > and use GOT relative reference.
> > > > ---
> > > >  cpu/mpc83xx/start.S |   11 +++++++----
> > > >  lib_ppc/board.c     |    3 ++-
> > > >  2 files changed, 9 insertions(+), 5 deletions(-)
> > >
> > > Joakim,
> > >
> > > this patch is missing your signoff, and doesn't apply cleanly (even
> > > adds whitespace).
> >
> > It doesn't apply because you have been sitting on it for too long :)
> > I sent long ago and you said would apply it in the next merge window,
> > but seems to have forgotten about it. Sorry for the whitespace. I am still
> > on the last u-boot release so I am afraid I can't do much about it ATM.
> > I hope you can clean up the WS.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> 
> ok, I can add it now.
> 
> Kim

Thanks, again sorry for the WS. Is there a git config
option that implies -s to git format-patch ?:)

     Jcoke

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Stefan Roese]

Hi Joakim,

On Saturday 29 March 2008, Joakim Tjernlund wrote:
> > Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote:
> > > Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> > > and use GOT relative reference.
> > > ---
> > >  cpu/mpc83xx/start.S |   11 +++++++----
> > >  lib_ppc/board.c     |    3 ++-
> > >  2 files changed, 9 insertions(+), 5 deletions(-)

<snip>

> > btw, shouldn't it fix up the other ppc start.S files?
>
> The other ppc's won't break and I only got a 83xx, hence I only did
> it for 83xx, hoping it would serve as a guide for the rest.

I'm afraid, but the "other ppc's" did break with this patch. At least 4xx 
does. With your patch applied relocation to SDRAM does not work anymore. 
Here's what I get:

CFG_MONITOR_BASE=fffa0000
(ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
EXC_OFF_SYS_RESET=100

I haven't looked into it closer yet. Any idea on how to fix this? 

Thanks.

Best regards,
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-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

On Tue, 2008-04-08 at 10:58 +0200, Stefan Roese wrote:
> Hi Joakim,
> 
> On Saturday 29 March 2008, Joakim Tjernlund wrote:
> > > Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote:
> > > > Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> > > > and use GOT relative reference.
> > > > ---
> > > >  cpu/mpc83xx/start.S |   11 +++++++----
> > > >  lib_ppc/board.c     |    3 ++-
> > > >  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> <snip>
> 
> > > btw, shouldn't it fix up the other ppc start.S files?
> >
> > The other ppc's won't break and I only got a 83xx, hence I only did
> > it for 83xx, hoping it would serve as a guide for the rest.
> 
> I'm afraid, but the "other ppc's" did break with this patch. At least 4xx 
> does. With your patch applied relocation to SDRAM does not work anymore. 
> Here's what I get:
> 
> CFG_MONITOR_BASE=fffa0000
> (ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
> EXC_OFF_SYS_RESET=100
> 
> I haven't looked into it closer yet. Any idea on how to fix this? 
> 
> Thanks.
> 
> Best regards,
> Stefan

Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
pointing to your real start of execution. Seems like _start_440 is your
real start but I can't be sure. There are some strange code in there
that I don't understand.

 Jocke

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Stefan Roese]

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > I'm afraid, but the "other ppc's" did break with this patch. At least 4xx
> > does. With your patch applied relocation to SDRAM does not work anymore.
> > Here's what I get:
> >
> > CFG_MONITOR_BASE=fffa0000
> > (ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
> > EXC_OFF_SYS_RESET=100
> >
> > I haven't looked into it closer yet. Any idea on how to fix this?
> >
> > Thanks.
> >
> > Best regards,
> > Stefan
>
> Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
> pointing to your real start of execution. Seems like _start_440 is your
> real start but I can't be sure.

No, unfortunately it's not. _start_440 is loaded into the last 4k of bootrom 
(via linker script), since 440 has a shadow TLB upon startup to only map 4k 
of address space. After looking at System.map it seems that _start_of_vectors 
seems to be the way to go for 4xx:

fffa0004 T version_string
fffa0100 t CritcalInput
fffa0100 T _start_of_vectors

But I don't want to introduce some #ifdef here. Perhaps it would be better to 
introduce a common (PPC) label that points to the beginning of the U-Boot 
image here.

BTW: I think this version:

	len = (ulong)&_end - ((ulong)&_start - EXC_OFF_SYS_RESET);

instead of:

	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;

is better. Makes the transition from CFG_MONITOR_BASE clearer, don't you think 
so?

> There are some strange code in there 
> that I don't understand.

Yes, it's quite complex because it supports all 4xx variants.

Best regards,
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-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

On Tue, 2008-04-08 at 12:06 +0200, Stefan Roese wrote:
> On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > I'm afraid, but the "other ppc's" did break with this patch. At least 4xx
> > > does. With your patch applied relocation to SDRAM does not work anymore.
> > > Here's what I get:
> > >
> > > CFG_MONITOR_BASE=fffa0000
> > > (ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
> > > EXC_OFF_SYS_RESET=100
> > >
> > > I haven't looked into it closer yet. Any idea on how to fix this?
> > >
> > > Thanks.
> > >
> > > Best regards,
> > > Stefan
> >
> > Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
> > pointing to your real start of execution. Seems like _start_440 is your
> > real start but I can't be sure.
> 
> No, unfortunately it's not. _start_440 is loaded into the last 4k of bootrom 
> (via linker script), since 440 has a shadow TLB upon startup to only map 4k 
> of address space. After looking at System.map it seems that _start_of_vectors 
> seems to be the way to go for 4xx:
> 
> fffa0004 T version_string
> fffa0100 t CritcalInput
> fffa0100 T _start_of_vectors
> 
> But I don't want to introduce some #ifdef here. Perhaps it would be better to 
> introduce a common (PPC) label that points to the beginning of the U-Boot 
> image here.

I first did a new symbol for this but changed it to use _start as  I
didn't want to introduce yet another symbol. I would hope it is
possible to rework 4xx to move the _start symbol to were it belongs?
Not having the _start symbol where it should be could bite you some
other day too.

> 
> BTW: I think this version:
> 
> 	len = (ulong)&_end - ((ulong)&_start - EXC_OFF_SYS_RESET);
> 
> instead of:
> 
> 	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;
> 
> is better. Makes the transition from CFG_MONITOR_BASE clearer, don't you think 
> so?

Sure, but I don't feel that strongly about it.

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Wolfgang Denk]

In message <1207651833.5826.21.camel@gentoo-jocke.transmode.se> you wrote:
> 
> > > > CFG_MONITOR_BASE=fffa0000
...
> I first did a new symbol for this but changed it to use _start as  I
> didn't want to introduce yet another symbol. I would hope it is
> possible to rework 4xx to move the _start symbol to were it belongs?
> Not having the _start symbol where it should be could bite you some
> other day too.

I think you got this wrong. _start *is* where it should be, where the
execution of the code begins. Where you set the breakpoint in gdb.

The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
that it has no fixed address as it depends where you place your image
in flash.

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
Just about every computer on the market today runs Unix,  except  the
Mac (and nobody cares about it).                   - Bill Joy 6/21/85

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

On Tue, 2008-04-08 at 13:58 +0200, Wolfgang Denk wrote:
> In message <1207651833.5826.21.camel@gentoo-jocke.transmode.se> you wrote:
> > 
> > > > > CFG_MONITOR_BASE=fffa0000
> ...
> > I first did a new symbol for this but changed it to use _start as  I
> > didn't want to introduce yet another symbol. I would hope it is
> > possible to rework 4xx to move the _start symbol to were it belongs?
> > Not having the _start symbol where it should be could bite you some
> > other day too.
> 
> I think you got this wrong. _start *is* where it should be, where the
> execution of the code begins. Where you set the breakpoint in gdb.

Ah, right. I *assumed* that _start was always the first symbol in the
text segment too. On 4xx it isn't for some reason, but it should be
possible to move it first.

Sidnote: Does execution really begin at _start for 4xx? I still looks
like it begin at _start_440 and eventually end up at _start

> 
> The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
> that it has no fixed address as it depends where you place your image
> in flash.

Yes, but the address is not important here, it is the difference
_end - _start. I guess we could define a linker symbol too
that calculates _end - _start for us and then just do
  len = _uboot_reloc_size + EXC_OFF_SYS_RESET;

or define a new symbol that is initialised to CFG_MONITOR_BASE or let
the linker place it at the beginning of .text, hopefully there is
already a name reserved for the symbol although I don't know of such a
name. I either case I think one needs to add that symbol to the GOT list
in start.S

 Jocke

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Stefan Roese]

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > I first did a new symbol for this but changed it to use _start as  I
> > > didn't want to introduce yet another symbol. I would hope it is
> > > possible to rework 4xx to move the _start symbol to were it belongs?
> > > Not having the _start symbol where it should be could bite you some
> > > other day too.
> >
> > I think you got this wrong. _start *is* where it should be, where the
> > execution of the code begins. Where you set the breakpoint in gdb.
>
> Ah, right. I *assumed* that _start was always the first symbol in the
> text segment too. On 4xx it isn't for some reason, but it should be
> possible to move it first.
>
> Sidnote: Does execution really begin at _start for 4xx? I still looks
> like it begin at _start_440 and eventually end up at _start

On 4xx execution always starts at 0xfffffffc (last lword in 32bit address 
space). This location holds a jump to _start for 405 PPC's and to _start_440 
for 440 PPC's. 440 PPC's need some extended initialization (TLB setup etc) 
and later jump to the 4xx common _start.

> > The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
> > that it has no fixed address as it depends where you place your image
> > in flash.
>
> Yes, but the address is not important here, it is the difference
> _end - _start. I guess we could define a linker symbol too
> that calculates _end - _start for us and then just do
>   len = _uboot_reloc_size + EXC_OFF_SYS_RESET;
>
> or define a new symbol that is initialised to CFG_MONITOR_BASE or let
> the linker place it at the beginning of .text, hopefully there is
> already a name reserved for the symbol although I don't know of such a
> name. I either case I think one needs to add that symbol to the GOT list
> in start.S

I'm an linker script dyslexic. So no idea if we can handle this solely in the 
linker script or if we need a new common symbol in the PPC start.S's.

Best regards,
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-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

On Tue, 2008-04-08 at 15:25 +0200, Stefan Roese wrote:
> On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > > I first did a new symbol for this but changed it to use _start as  I
> > > > didn't want to introduce yet another symbol. I would hope it is
> > > > possible to rework 4xx to move the _start symbol to were it belongs?
> > > > Not having the _start symbol where it should be could bite you some
> > > > other day too.
> > >
> > > I think you got this wrong. _start *is* where it should be, where the
> > > execution of the code begins. Where you set the breakpoint in gdb.
> >
> > Ah, right. I *assumed* that _start was always the first symbol in the
> > text segment too. On 4xx it isn't for some reason, but it should be
> > possible to move it first.
> >
> > Sidnote: Does execution really begin at _start for 4xx? I still looks
> > like it begin at _start_440 and eventually end up at _start
> 
> On 4xx execution always starts at 0xfffffffc (last lword in 32bit address 
> space). This location holds a jump to _start for 405 PPC's and to _start_440 
> for 440 PPC's. 440 PPC's need some extended initialization (TLB setup etc) 
> and later jump to the 4xx common _start.

OK, then it is like I suspected. What if you rename _start to
_common_start. Make _start equal _common_start for 405 and rename
_start_440 to _start, i.e make sure that _start is defined where you
start executing after the jump.

> 
> > > The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
> > > that it has no fixed address as it depends where you place your image
> > > in flash.
> >
> > Yes, but the address is not important here, it is the difference
> > _end - _start. I guess we could define a linker symbol too
> > that calculates _end - _start for us and then just do
> >   len = _uboot_reloc_size + EXC_OFF_SYS_RESET;
> >
> > or define a new symbol that is initialised to CFG_MONITOR_BASE or let
> > the linker place it at the beginning of .text, hopefully there is
> > already a name reserved for the symbol although I don't know of such a
> > name. I either case I think one needs to add that symbol to the GOT list
> > in start.S
> 
> I'm an linker script dyslexic. So no idea if we can handle this solely in the 
> linker script or if we need a new common symbol in the PPC start.S's.

Both ways should be doable I think. A linker script would probably look
something like(pseudo diff below):
 .text      :
  {
+    _monitor_base = . ;
+    PROVIDE (_monitor_base = .);
    cpu/mpc83xx/start.o	(.text)

And then add a
	GOT_ENTRY(_monitor_base)
in start.S

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Stefan Roese]

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > On 4xx execution always starts at 0xfffffffc (last lword in 32bit address
> > space). This location holds a jump to _start for 405 PPC's and to
> > _start_440 for 440 PPC's. 440 PPC's need some extended initialization
> > (TLB setup etc) and later jump to the 4xx common _start.
>
> OK, then it is like I suspected. What if you rename _start to
> _common_start. Make _start equal _common_start for 405 and rename
> _start_440 to _start, i.e make sure that _start is defined where you
> start executing after the jump.

As I mentioned earlier, _start_440 is mapped to 0xfffff000 via the linker 
script since the jump from 0xfffffffc can't be too long (because of the 4k 
shadow TLB entry). So renaming _start_440 to _start won't help here. It can 
be done, but frankly I don't have the time for it currently.

> > I'm an linker script dyslexic. So no idea if we can handle this solely in
> > the linker script or if we need a new common symbol in the PPC start.S's.
>
> Both ways should be doable I think. A linker script would probably look
> something like(pseudo diff below):
>  .text      :
>   {
> +    _monitor_base = . ;
> +    PROVIDE (_monitor_base = .);
>     cpu/mpc83xx/start.o	(.text)
>
> And then add a
> 	GOT_ENTRY(_monitor_base)
> in start.S

The disadvantage I see is that I need to change the linker scripts for all 
boards for such a solution. Doesn't sound like fun.

So for now, I would really like to see the old version with the ugly 
CFG_MONITOR_BASE back so that 4xx board can be used again.

Best regards,
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-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net]
> On Behalf Of Stefan Roese
> Sent: den 8 april 2008 21:53
> To: joakim.tjernlund at transmode.se
> Cc: u-boot-users at lists.sourceforge.net; 'Kim Phillips'; Wolfgang Denk
> Subject: Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
> 
> On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > On 4xx execution always starts at 0xfffffffc (last lword in 32bit address
> > > space). This location holds a jump to _start for 405 PPC's and to
> > > _start_440 for 440 PPC's. 440 PPC's need some extended initialization
> > > (TLB setup etc) and later jump to the 4xx common _start.
> >
> > OK, then it is like I suspected. What if you rename _start to
> > _common_start. Make _start equal _common_start for 405 and rename
> > _start_440 to _start, i.e make sure that _start is defined where you
> > start executing after the jump.
> 
> As I mentioned earlier, _start_440 is mapped to 0xfffff000 via the linker
> script since the jump from 0xfffffffc can't be too long (because of the 4k
> shadow TLB entry). So renaming _start_440 to _start won't help here. It can
> be done, but frankly I don't have the time for it currently.

I see, suspected that we would not get away that easy :(

> 
> > > I'm an linker script dyslexic. So no idea if we can handle this solely in
> > > the linker script or if we need a new common symbol in the PPC start.S's.
> >
> > Both ways should be doable I think. A linker script would probably look
> > something like(pseudo diff below):
> >  .text      :
> >   {
> > +    _monitor_base = . ;
> > +    PROVIDE (_monitor_base = .);
> >     cpu/mpc83xx/start.o	(.text)
> >
> > And then add a
> > 	GOT_ENTRY(_monitor_base)
> > in start.S
> 
> The disadvantage I see is that I need to change the linker scripts for all
> boards for such a solution. Doesn't sound like fun.

Yeah, probably easier to define the symbol in start.S and skip the linker
version. 

> 
> So for now, I would really like to see the old version with the ugly
> CFG_MONITOR_BASE back so that 4xx board can be used again.

Then I would ask you to do an #ifdef for ppc440(or similar). If the
long term solution should be to move _start to its true start vector, you
could just go back to the old way for ppc4xx. If the long term solution should
be a new symbol you could just impl. that for ppc4xx and just use it for
ppc4xx only, then the other archs can follow when the next merge window opens.

    Jocke
> 
> Best regards,
> Stefan

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Wolfgang Denk]

In message <1207663498.5826.56.camel@gentoo-jocke.transmode.se> you wrote:
> 
> Both ways should be doable I think. A linker script would probably look
> something like(pseudo diff below):
>  .text      :
>   {
> +    _monitor_base = . ;

There is no guarantee that this is the same as the start address of
.text


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
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
	-- Kirk, "The Ultimate Computer", stardate 4731.3

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: den 8 april 2008 22:42
> To: joakim.tjernlund at transmode.se
> Cc: Stefan Roese; u-boot-users at lists.sourceforge.net; 'Kim Phillips'
> Subject: Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
> 
> In message <1207663498.5826.56.camel@gentoo-jocke.transmode.se> you wrote:
> >
> > Both ways should be doable I think. A linker script would probably look
> > something like(pseudo diff below):
> >  .text      :
> >   {
> > +    _monitor_base = . ;
> 
> There is no guarantee that this is the same as the start address of
> .text
> 

I am no link script expert, but I cannot see why that would not be the start
of the .text segment?

Anyhow, we can go with the other solution instead, define the symbol in start.S
instead, if one is needed.

 Jocke

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Wolfgang Denk]

In message <044901c899ba$83532450$89f96cf0$@Tjernlund@transmode.se> you wrote:
>
> > >  .text      :
> > >   {
> > > +    _monitor_base = . ;
> > 
> > There is no guarantee that this is the same as the start address of
> > .text
> > 
> 
> I am no link script expert, but I cannot see why that would not be the start
> of the .text segment?

There might be other segments at the start of the image...

See for example cpu/mpc8xx/start.S - while at the  moment  we  really
start with .text, it would technically be more approrpriate to change
the  first  256  bytes  (from monitor base to EXC_OFF_SYS_RESET) into
.rodata or something like this.

> Anyhow, we can go with the other solution instead, define the symbol in start.S
> instead, if one is needed.

If it cannot be avoided ;-)

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
Thought for the day: What if there were no hypothetical situations?

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: den 8 april 2008 23:09
> To: Joakim Tjernlund
> Cc: 'Stefan Roese'; u-boot-users at lists.sourceforge.net; 'Kim Phillips'
> Subject: Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
> 
> In message <044901c899ba$83532450$89f96cf0$@Tjernlund@transmode.se> you wrote:
> >
> > > >  .text      :
> > > >   {
> > > > +    _monitor_base = . ;
> > >
> > > There is no guarantee that this is the same as the start address of
> > > .text
> > >
> >
> > I am no link script expert, but I cannot see why that would not be the start
> > of the .text segment?
> 
> There might be other segments at the start of the image...
> 
> See for example cpu/mpc8xx/start.S - while at the  moment  we  really
> start with .text, it would technically be more approrpriate to change
> the  first  256  bytes  (from monitor base to EXC_OFF_SYS_RESET) into
> .rodata or something like this.

Ahh, now I see what you mean and it gave me an idea ...

> 
> > Anyhow, we can go with the other solution instead, define the symbol in start.S
> > instead, if one is needed.
> 
> If it cannot be avoided ;-)

... Stefan, maybe you can #define EXC_OFF_SYS_RESET for 405 to something that
fits with my relocation patch?

  Jocke

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[David Hawkins]

Hi Joakim,

>> See for example cpu/mpc8xx/start.S - while at the  moment we really
>> start with .text, it would technically be more approrpriate to change
>> the  first  256  bytes  (from monitor base to EXC_OFF_SYS_RESET) into
>> .rodata or something like this.
> 
> Ahh, now I see what you mean and it gave me an idea ...

While you're chewing on ideas, here's a couple of points about
mpc83xx/start.S

The reset configuration words that start at the beginning of
Flash are *optional*, and depend on the reset configurations
words source pin strapping (CFG_RS[0:2]).

If CFG_RS[0:2] = 000b, then the RCWs are read from the local
bus chip-select 0. Nominally this means read from flash, but
hardware can subvert the bus to the flash and supply the RCWs
from an alternative source, eg. on the MPC8349EA-MDS-PB, the
RCWs can be driven onto the local bus by an on-board CPLD
(which in turn gets the RCWs from dip switches).

On my custom MPC8349EA board, I can deliver the RCWs from the
Flash, or if flash is blank, from the FPGA, or I can change the
CFG_RS[0:2] source so that the processor uses hard-coded
RCWs, or an I2C boot EEPROM.

If the RCWs were placed in their own section, then that section
could be made optional. In the case of it being used, and boot-low
being used (RCWH[BMS] = 0), then the RCW+U-Boot magic+string section
would need be 100h bytes in size, and be concatenated with the
U-Boot image. Otherwise the RCW area could be left as a separate
binary image, that the user has to burn to Flash. (Eg. for a user
that for some bizarre reason wants to put RCWH[BMS] = 1 :) ).

How about a 100-byte section called .rcw, or .rcwdata?

I'm not sure if these comments will make life easier or worse ...

Cheers,
Dave

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Stefan Roese]

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > Anyhow, we can go with the other solution instead, define the symbol in
> > > start.S instead, if one is needed.
> >
> > If it cannot be avoided ;-)
>
> ... Stefan, maybe you can #define EXC_OFF_SYS_RESET for 405 to something
> that fits with my relocation patch?

Not sure if this could be done, since EXC_OFF_SYS_RESET is used for other 
things as well, and changing its value might bring other problems. And this 
really sounds like a bad hack, to change EXC_OFF_SYS_RESET to 
something "strange". So, no I don't want to fix this problem this way.

Since I'm really short in time currently, and I need U-Boot running on 4xx 
again, I vote for reverting this patch now. I'll try to come up with 
a "generic" solution for the next merge window.

Wolfgang? What do you think?

Best regards,
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-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Wolfgang Denk]

In message <200804091140.45661.sr@denx.de> you wrote:
>
> Since I'm really short in time currently, and I need U-Boot running on 4xx 
> again, I vote for reverting this patch now. I'll try to come up with 
> a "generic" solution for the next merge window.
> 
> Wolfgang? What do you think?

I agree. This patch is too invasive at this point of the  development
cycle.  Please  revert  it.  We  will  handle  this in the next merge
window, then.

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
An Elephant is a mouse with an Operating System.              - Knuth

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

On Wed, 2008-04-09 at 12:44 +0200, Wolfgang Denk wrote:
> In message <200804091140.45661.sr@denx.de> you wrote:
> >
> > Since I'm really short in time currently, and I need U-Boot running on 4xx 
> > again, I vote for reverting this patch now. I'll try to come up with 
> > a "generic" solution for the next merge window.
> > 
> > Wolfgang? What do you think?
> 
> I agree. This patch is too invasive at this point of the  development
> cycle.  Please  revert  it.  We  will  handle  this in the next merge
> window, then.

I rather see a #ifdef for ppc4xx instead.

  Jocke

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Stefan Roese]

On Wednesday 09 April 2008, Joakim Tjernlund wrote:
> On Wed, 2008-04-09 at 12:44 +0200, Wolfgang Denk wrote:
> > In message <200804091140.45661.sr@denx.de> you wrote:
> > > Since I'm really short in time currently, and I need U-Boot running on
> > > 4xx again, I vote for reverting this patch now. I'll try to come up
> > > with a "generic" solution for the next merge window.
> > >
> > > Wolfgang? What do you think?
> >
> > I agree. This patch is too invasive at this point of the  development
> > cycle.  Please  revert  it.  We  will  handle  this in the next merge
> > window, then.
>
> I rather see a #ifdef for ppc4xx instead.

I disagree. As we would need different symbols for 405 and 440, this would 
look really ugly. So let's fix it correctly in the next merge window.

Best regards,
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-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Wolfgang Denk]

In message <1207739685.5826.63.camel@gentoo-jocke.transmode.se> you wrote:
> 
> > I agree. This patch is too invasive at this point of the  development
> > cycle.  Please  revert  it.  We  will  handle  this in the next merge
> > window, then.
> 
> I rather see a #ifdef for ppc4xx instead.

Yes - in the next window, please.

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
Defaults are wonderful, just like fire.
                  - Larry Wall in <1996Mar6.004121.27890@netlabs.com>

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Wolfgang Denk]

In message <1207647084.5826.14.camel@gentoo-jocke.transmode.se> you wrote:
> 
> Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
> pointing to your real start of execution. Seems like _start_440 is your
> real start but I can't be sure. There are some strange code in there
> that I don't understand.

Of course. _start is where the execution of the code starts, i. e. the
entry point for U-Boot. There is no reason to expect that this might
be at the begin of any specific section.

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
GUIs  are  virtually  useless.  Learn  tools.  They're  configurable,
scriptable, automatable, cron-able, interoperable, etc. We don't need
no brain-dead winslurping monolithic claptrap.
                               -- Tom Christiansen in 371140df at csnews

[U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.

[Joakim Tjernlund]

Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
and use GOT relative reference.
---
 cpu/mpc83xx/start.S |   11 +++++++----
 lib_ppc/board.c     |    3 ++-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S
index 1dfbf62..56fd7ec 100644
--- a/cpu/mpc83xx/start.S
+++ b/cpu/mpc83xx/start.S
@@ -172,8 +172,11 @@ boot_warm: /* time t 5 */
 	/* there and deflate the flash size back to minimal size      */
 	/*------------------------------------------------------------*/
 	bl map_flash_by_law1
-	lis r4, (CFG_MONITOR_BASE)@h
-	ori r4, r4, (CFG_MONITOR_BASE)@l
+
+	GET_GOT			/* initialize GOT access	*/
+	lwz r4, GOT(_start)	
+	addi r4, r4, -EXC_OFF_SYS_RESET
+
 	addi r5, r4, in_flash - _start + EXC_OFF_SYS_RESET
 	mtlr r5
 	blr
@@ -906,8 +909,8 @@ relocate_code:
 	mr	r10, r5		/* Save copy of Destination Address */
 
 	mr	r3,  r5				/* Destination Address */
-	lis	r4, CFG_MONITOR_BASE at h		/* Source      Address */
-	ori	r4, r4, CFG_MONITOR_BASE at l
+	lwz	r4, GOT(_start)
+	addi	r4, r4, -EXC_OFF_SYS_RESET	
 	lwz	r5, GOT(__init_end)
 	sub	r5, r5, r4
 	li	r6, CFG_CACHELINE_SIZE		/* Cache Line Size */
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 45d1328..8a18350 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -117,6 +117,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define	TOTAL_MALLOC_LEN	CFG_MALLOC_LEN
 #endif
 
+extern ulong _start;
 extern ulong __init_end;
 extern ulong _end;
 ulong monitor_flash_len;
@@ -417,7 +418,7 @@ void board_init_f (ulong bootflag)
 	 *  - monitor code
 	 *  - board info struct
 	 */
-	len = (ulong)&_end - CFG_MONITOR_BASE;
+	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;
 
 #ifndef	CONFIG_VERY_BIG_RAM
 	addr = CFG_SDRAM_BASE + gd->ram_size;
-- 
1.5.3.8