[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

The fixup routine must not fixup NULL pointers.
Problem can be seen by
 char *testfun(void) __attribute__((weak));
 char *(*myfun)(void) = testfun;

Then add
  printf("myfun:%p, &myfun:%p\n", myfun, &myfun);
before relocation and after relocation.
myfun should be NULL in both cases but it is not.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/powerpc/cpu/74xx_7xx/start.S |    4 +++-
 arch/powerpc/cpu/mpc512x/start.S  |    4 +++-
 arch/powerpc/cpu/mpc5xx/start.S   |    4 +++-
 arch/powerpc/cpu/mpc5xxx/start.S  |    4 +++-
 arch/powerpc/cpu/mpc8220/start.S  |    4 +++-
 arch/powerpc/cpu/mpc824x/start.S  |    4 +++-
 arch/powerpc/cpu/mpc8260/start.S  |    4 +++-
 arch/powerpc/cpu/mpc83xx/start.S  |    4 +++-
 arch/powerpc/cpu/mpc85xx/start.S  |    4 +++-
 arch/powerpc/cpu/mpc86xx/start.S  |    4 +++-
 arch/powerpc/cpu/mpc8xx/start.S   |    4 +++-
 arch/powerpc/cpu/ppc4xx/start.S   |    4 +++-
 12 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/cpu/74xx_7xx/start.S b/arch/powerpc/cpu/74xx_7xx/start.S
index 88fdf88..ce0fa3d 100644
--- a/arch/powerpc/cpu/74xx_7xx/start.S
+++ b/arch/powerpc/cpu/74xx_7xx/start.S
@@ -722,10 +722,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 /* clear_bss: */
 	/*
diff --git a/arch/powerpc/cpu/mpc512x/start.S b/arch/powerpc/cpu/mpc512x/start.S
index d26b617..64eb657 100644
--- a/arch/powerpc/cpu/mpc512x/start.S
+++ b/arch/powerpc/cpu/mpc512x/start.S
@@ -615,10 +615,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/mpc5xx/start.S b/arch/powerpc/cpu/mpc5xx/start.S
index 0af879e..560c706 100644
--- a/arch/powerpc/cpu/mpc5xx/start.S
+++ b/arch/powerpc/cpu/mpc5xx/start.S
@@ -464,10 +464,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/mpc5xxx/start.S b/arch/powerpc/cpu/mpc5xxx/start.S
index 8b9f09b..b8c1cb5 100644
--- a/arch/powerpc/cpu/mpc5xxx/start.S
+++ b/arch/powerpc/cpu/mpc5xxx/start.S
@@ -680,10 +680,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/mpc8220/start.S b/arch/powerpc/cpu/mpc8220/start.S
index 3d79d8e..6b63821 100644
--- a/arch/powerpc/cpu/mpc8220/start.S
+++ b/arch/powerpc/cpu/mpc8220/start.S
@@ -653,10 +653,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/mpc824x/start.S b/arch/powerpc/cpu/mpc824x/start.S
index f3f595a..a32e68b 100644
--- a/arch/powerpc/cpu/mpc824x/start.S
+++ b/arch/powerpc/cpu/mpc824x/start.S
@@ -595,10 +595,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/mpc8260/start.S b/arch/powerpc/cpu/mpc8260/start.S
index a435042..5c2e251 100644
--- a/arch/powerpc/cpu/mpc8260/start.S
+++ b/arch/powerpc/cpu/mpc8260/start.S
@@ -915,10 +915,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index c9bb0ea..e8b1ebc 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -986,10 +986,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 #endif
 
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index b3cb56a..19e9735 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1025,10 +1025,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/mpc86xx/start.S b/arch/powerpc/cpu/mpc86xx/start.S
index ed1e4ca..3f05e53 100644
--- a/arch/powerpc/cpu/mpc86xx/start.S
+++ b/arch/powerpc/cpu/mpc86xx/start.S
@@ -739,10 +739,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 /* clear_bss: */
 	/*
diff --git a/arch/powerpc/cpu/mpc8xx/start.S b/arch/powerpc/cpu/mpc8xx/start.S
index 7cf602f..1b729eb 100644
--- a/arch/powerpc/cpu/mpc8xx/start.S
+++ b/arch/powerpc/cpu/mpc8xx/start.S
@@ -595,10 +595,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S
index c739deb..27709c4 100644
--- a/arch/powerpc/cpu/ppc4xx/start.S
+++ b/arch/powerpc/cpu/ppc4xx/start.S
@@ -1602,10 +1602,12 @@ in_ram:
 	beq	4f
 3:	lwzu	r4,4(r3)
 	lwzux	r0,r4,r11
+	cmpwi	r0,0
 	add	r0,r0,r11
 	stw	r10,0(r3)
+	beq-	5f
 	stw	r0,0(r4)
-	bdnz	3b
+5:	bdnz	3b
 4:
 clear_bss:
 	/*
-- 
1.7.2.2

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <1287049904-18917-1-git-send-email-Joakim.Tjernlund@transmode.se> you wrote:
> The fixup routine must not fixup NULL pointers.
> Problem can be seen by
>  char *testfun(void) __attribute__((weak));
>  char *(*myfun)(void) = testfun;
> 
> Then add
>   printf("myfun:%p, &myfun:%p\n", myfun, &myfun);
> before relocation and after relocation.
> myfun should be NULL in both cases but it is not.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
>  arch/powerpc/cpu/74xx_7xx/start.S |    4 +++-
>  arch/powerpc/cpu/mpc512x/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc5xx/start.S   |    4 +++-
>  arch/powerpc/cpu/mpc5xxx/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc8220/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc824x/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc8260/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc83xx/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc85xx/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc86xx/start.S  |    4 +++-
>  arch/powerpc/cpu/mpc8xx/start.S   |    4 +++-
>  arch/powerpc/cpu/ppc4xx/start.S   |    4 +++-
>  12 files changed, 36 insertions(+), 12 deletions(-)

Applied, 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 is an order of things in this universe.
	-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Schwarz, Andre]

All,



Wolfgang Denk <wd@denx.de> hat am 18. Oktober 2010 um 22:39 geschrieben:

> Dear Joakim Tjernlund,
>
> In message <1287049904-18917-1-git-send-email-Joakim.Tjernlund@transmode.se>
> you wrote:
> > The fixup routine must not fixup NULL pointers.
> > Problem can be seen by
> >? char *testfun(void) __attribute__((weak));
> >? char *(*myfun)(void) = testfun;
> >
> > Then add
> >? ?printf("myfun:%p, &myfun:%p\n", myfun, &myfun);
> > before relocation and after relocation.
> > myfun should be NULL in both cases but it is not.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> >? arch/powerpc/cpu/74xx_7xx/start.S |? ? 4 +++-
> >? arch/powerpc/cpu/mpc512x/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc5xx/start.S? ?|? ? 4 +++-
> >? arch/powerpc/cpu/mpc5xxx/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc8220/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc824x/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc8260/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc83xx/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc85xx/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc86xx/start.S? |? ? 4 +++-
> >? arch/powerpc/cpu/mpc8xx/start.S? ?|? ? 4 +++-
> >? arch/powerpc/cpu/ppc4xx/start.S? ?|? ? 4 +++-
> >? 12 files changed, 36 insertions(+), 12 deletions(-)
>
> Applied, thanks.?
has anybody ever tested this ?
Although it looks obvious and correct this patch is somewhat intrusive and
breaks at least two of our (MPC83xx) boards.
?
I've asked Joakim already for some clarification :
?
http://lists.denx.de/pipermail/u-boot/2010-October/080121.html
?
Since I assume Wolfgang won't accept a board specific "add 4 nops after
_start"-patch I'd like to solve this without trial and error.
?
Of course digging into this is beyond my knowledge and any help would be
appreciated.
I simply can't think of being the only one having this issue...
?
I'm running U-Boot TOT with ELDK-4.2 toolchain.


Regards,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear "Schwarz,Andre",

In message <1702240919.111.1287950899754.JavaMail.open-xchange@proteus> you wrote:
>
> Since I assume Wolfgang won't accept a board specific "add 4 nops after
> _start"-patch I'd like to solve this without trial and error.

To the best of my knowledge no board made use f this "warmboot" entry
point. OK, I wasn't aware that Jocke obviously did something lioke
this, so there might be other boards as well - but it's unlikely.

> Of course digging into this is beyond my knowledge and any help would be
> appreciated.
> I simply can't think of being the only one having this issue...

Check how your board implements the "reset" command - I cannot see any
specific code for that in your sources, so it looks mostly harmless to
me.

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
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
                         - Fred Brooks, Jr., _The Mythical Man Month_

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Schwarz, Andre]

Wolfgang,



Wolfgang Denk <wd@denx.de> hat am 24. Oktober 2010 um 22:18 geschrieben:

> Dear "Schwarz,Andre",
>
> In message <1702240919.111.1287950899754.JavaMail.open-xchange@proteus> you
> wrote:
> >
> > Since I assume Wolfgang won't accept a board specific "add 4 nops after
> > _start"-patch I'd like to solve this without trial and error.
>
> To the best of my knowledge no board made use f this "warmboot" entry
> point. OK, I wasn't aware that Jocke obviously did something lioke
> this, so there might be other boards as well - but it's unlikely.
>
> > Of course digging into this is beyond my knowledge and any help would be
> > appreciated.
> > I simply can't think of being the only one having this issue...
>
> Check how your board implements the "reset" command - I cannot see any
> specific code for that in your sources, so it looks mostly harmless to
> me.?
this is what I don't understand :
?
The broken boards are *dead*, i.e. no single character on the serial line.
To me this means even the initial code running from flash isn't executed
properly.
IMHO this doesn't look like something like a problem after relocation ... it's
something more fundamental.
?
The boards in question are using low boot, i.e. reset vector @ 0x100.
There's normal power-on-reset sequencing and no such thing like a reboot or
"warm" reset.
?
Without that patch the boards are running fine.

I can see no obvious difference between working and broken boards.

I'd be happy to hear that the error is caused by something hidden within board
specific code.

Reards,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

"Schwarz,Andre" <andre.schwarz@matrix-vision.de> wrote on 2010/10/24 22:33:44:
>
> Wolfgang,
>
> Wolfgang Denk <wd@denx.de> hat am 24. Oktober 2010 um 22:18 geschrieben:
>
> > Dear "Schwarz,Andre",
> >
> > In message <1702240919.111.1287950899754.JavaMail.open-xchange@proteus> you wrote:
> > >
> > > Since I assume Wolfgang won't accept a board specific "add 4 nops after
> > > _start"-patch I'd like to solve this without trial and error.
> >
> > To the best of my knowledge no board made use f this "warmboot" entry
> > point. OK, I wasn't aware that Jocke obviously did something lioke
> > this, so there might be other boards as well - but it's unlikely.
> >
> > > Of course digging into this is beyond my knowledge and any help would be
> > > appreciated.
> > > I simply can't think of being the only one having this issue...
> >
> > Check how your board implements the "reset" command - I cannot see any
> > specific code for that in your sources, so it looks mostly harmless to
> > me.
>
> this is what I don't understand :
>
> The broken boards are *dead*, i.e. no single character on the serial line.
> To me this means even the initial code running from flash isn't executed properly.
> IMHO this doesn't look like something like a problem after relocation ... it's something more fundamental.

Yes, like something is wrong with the reset code.

>
> The boards in question are using low boot, i.e. reset vector @ 0x100.

Me too.

> There's normal power-on-reset sequencing and no such thing like a reboot or "warm" reset.
>
> Without that patch the boards are running fine.
>
> I can see no obvious difference between working and broken boards.
>
> I'd be happy to hear that the error is caused by something hidden within board specific code.

You still haven't reported weather the 4 nop's helped or not, yet you
seek my help. I am just going to ignore you until you do test it.

 Jocke

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Schwarz, Andre]

Jocke,



[snip]?

> > You still haven't reported weather the 4 nop's helped or not, yet you
> seek my help. I am just going to ignore you until you do test it.?
of course.
Will give it a try as soon as I'll be back to office and have a board at hand
...
?
Just wanted to collect some more feedback.
?
Cheers,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Jocke,

[snip]

> You still haven't reported weather the 4 nop's helped or not, yet you
> seek my help. I am just going to ignore you until you do test it.
>
>

finally I got both some time and hardware :

4 nops after _start does the trick, i.e. the board is up and running fine.


Diffing both System.maps and U-Boot hexdump gives only trivial results :

- "in_flash" and "_start_of_vectors" adress increment = 0x10.
- offset calculation for relative branch instruction also increases by 0x10.


Let me know if you need more information or something else tested.



Regards,
Andr?


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/10/25 15:50:19:
>
> Jocke,
>
> [snip]
>
> > You still haven't reported weather the 4 nop's helped or not, yet you
> > seek my help. I am just going to ignore you until you do test it.
> >
> >
>
> finally I got both some time and hardware :
>
> 4 nops after _start does the trick, i.e. the board is up and running fine.
>
>
> Diffing both System.maps and U-Boot hexdump gives only trivial results :
>
> - "in_flash" and "_start_of_vectors" adress increment = 0x10.
> - offset calculation for relative branch instruction also increases by 0x10.
>
>
> Let me know if you need more information or something else tested.

I am not looking at this as I am busy but I have an idea or two

- CPU bug in 83xx CPUs which uses 0x110 as cold start vector.

- Misconfig of HRCW, don't know if you can change the reset vector that way
  but I guess you need to check.

I think a Freescale guy needs to look at this unless you can find something wrong
with HRCW

   Jocke

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Jocke,

> Andre Schwarz<andre.schwarz@matrix-vision.de>  wrote on 2010/10/25 15:50:19:
>    
>> Jocke,
>>
>> [snip]
>>
>>      
>>> You still haven't reported weather the 4 nop's helped or not, yet you
>>> seek my help. I am just going to ignore you until you do test it.
>>>
>>>
>>>        
>> finally I got both some time and hardware :
>>
>> 4 nops after _start does the trick, i.e. the board is up and running fine.
>>
>>
>> Diffing both System.maps and U-Boot hexdump gives only trivial results :
>>
>> - "in_flash" and "_start_of_vectors" adress increment = 0x10.
>> - offset calculation for relative branch instruction also increases by 0x10.
>>
>>
>> Let me know if you need more information or something else tested.
>>      
> I am not looking at this as I am busy but I have an idea or two
>    
ok - thanks.
> - CPU bug in 83xx CPUs which uses 0x110 as cold start vector.
>    
This is indeed something FSL has to investigate.
But at least *some* 83xx boards are running fine ... e300c2 though.
> - Misconfig of HRCW, don't know if you can change the reset vector that way
>    but I guess you need to check.
>    
HRCW reset vector settings are high/low boot only.
> I think a Freescale guy needs to look at this unless you can find something wrong
> with HRCW
>    

Kim, Timur,
can you give any information ? What about your boards ? Is everything 
running fine using Nor-Boot ?


Regards,
Andr?


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/10/25 16:46:42:
>
> Jocke,
>
> > Andre Schwarz<andre.schwarz@matrix-vision.de>  wrote on 2010/10/25 15:50:19:
> >
> >> Jocke,
> >>
> >> [snip]
> >>
> >>
> >>> You still haven't reported weather the 4 nop's helped or not, yet you
> >>> seek my help. I am just going to ignore you until you do test it.
> >>>
> >>>
> >>>
> >> finally I got both some time and hardware :
> >>
> >> 4 nops after _start does the trick, i.e. the board is up and running fine.
> >>
> >>
> >> Diffing both System.maps and U-Boot hexdump gives only trivial results :
> >>
> >> - "in_flash" and "_start_of_vectors" adress increment = 0x10.
> >> - offset calculation for relative branch instruction also increases by 0x10.
> >>
> >>
> >> Let me know if you need more information or something else tested.
> >>
> > I am not looking at this as I am busy but I have an idea or two
> >
> ok - thanks.
> > - CPU bug in 83xx CPUs which uses 0x110 as cold start vector.
> >
> This is indeed something FSL has to investigate.
> But at least *some* 83xx boards are running fine ... e300c2 though.

I got a e300c2, mpc8321

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Andre Schwarz,

In message <4CC58B1B.8040005@matrix-vision.de> you wrote:
> 
> finally I got both some time and hardware :
> 
> 4 nops after _start does the trick, i.e. the board is up and running fine.

This is probably completely unrelated - but check your
CONFIG_SYS_GBL_DATA_SIZE setting and make sure it's still >=
sizeof(struct global_data).

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
O Staat!   Wie tief dir alle Besten fluchen!  Du bist kein Ziel.  Der
Mensch mu? weiter suchen.                     - Christian Morgenstern

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Wolfgang,
> Dear Andre Schwarz,
>
> In message<4CC58B1B.8040005@matrix-vision.de>  you wrote:
>    
>> finally I got both some time and hardware :
>>
>> 4 nops after _start does the trick, i.e. the board is up and running fine.
>>      
> This is probably completely unrelated - but check your
> CONFIG_SYS_GBL_DATA_SIZE setting and make sure it's still>=
> sizeof(struct global_data).
>    

Having a look at include/asm/global_data.h gives some 40 ulongs for my 
MPC8377 system.
Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.

Nevertheless I doubled to 0x200.

The system is still dead after removing the 4 nops after _start.



Regards,
Andr?


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Andre Schwarz,

In message <4CC5C226.8080202@matrix-vision.de> you wrote:
>
> Having a look at include/asm/global_data.h gives some 40 ulongs for my 
> MPC8377 system.
> Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.

Indeed. I was asking because I just discovered that most of the
PowerPC boards are actually broken in this respect - 89 % of them,
170 out of 191 :-(

> The system is still dead after removing the 4 nops after _start.

Sorry, but it was worth a try.

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
If you're not part of the solution, you're part of the problem.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Wolfgang,
> Dear Andre Schwarz,
>
> In message<4CC5C226.8080202@matrix-vision.de>  you wrote:
>    
>> Having a look at include/asm/global_data.h gives some 40 ulongs for my
>> MPC8377 system.
>> Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
>>      
> Indeed. I was asking because I just discovered that most of the
> PowerPC boards are actually broken in this respect - 89 % of them,
> 170 out of 191 :-(
>    

understood - this should be easy to fix.

>> The system is still dead after removing the 4 nops after _start.
>>      
> Sorry, but it was worth a try.
>    

absolutely - so don't mind.
I'm still happy to get any directions at all.

Still wondering why there's no comment from Kim etc. ...


Regards,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

All,

>
>> Having a look at include/asm/global_data.h gives some 40 ulongs for my
>> MPC8377 system.
>> Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
>>      
> Indeed. I was asking because I just discovered that most of the
> PowerPC boards are actually broken in this respect - 89 % of them,
> 170 out of 191 :-(
>
>    
>> The system is still dead after removing the 4 nops after _start.
>>      

actually I'm facing another issue and don't now whether this might be 
related to this thread or not.


Just before relocation in arch/powerpc/lib/board.c the CPU gets a "check 
stop" followed by reset during "memset()" in line 493.

[snip]
DRAM:  256 MiB
Top of RAM usable for U-Boot at: 10000000
Reserving 341k for U-Boot at: 0ffaa000
Reserving 512k for malloc() at: 0ff29f80

- reset -

U-Boot 2010.09-00488-g5edbadb-dirty (Oct 26 2010 - 14:16:00) MPC83XX

Reset Status: Check Stop, External/Internal Soft, External/Internal Hard


I know that DDR might not be 100% stable but it is basically set up 
properly.
Removing the memset yields the next debug messages before resetting 
again while setting up SP.

Is the DDR required to work 100% for a simple write operation or might 
there be another problem ?

256MiB DDR is mapped by single BAT and there should be no overlapping 
BATs either.


Any ideas ?

-- 

Regards,
Andre



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/10/26 14:34:57:
>
> All,
>
> >
> >> Having a look at include/asm/global_data.h gives some 40 ulongs for my
> >> MPC8377 system.
> >> Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
> >>
> > Indeed. I was asking because I just discovered that most of the
> > PowerPC boards are actually broken in this respect - 89 % of them,
> > 170 out of 191 :-(
> >
> >
> >> The system is still dead after removing the 4 nops after _start.
> >>
>
> actually I'm facing another issue and don't now whether this might be
> related to this thread or not.
>
>
> Just before relocation in arch/powerpc/lib/board.c the CPU gets a "check
> stop" followed by reset during "memset()" in line 493.
>
> [snip]
> DRAM:  256 MiB
> Top of RAM usable for U-Boot at: 10000000
> Reserving 341k for U-Boot at: 0ffaa000
> Reserving 512k for malloc() at: 0ff29f80
>
> - reset -
>
> U-Boot 2010.09-00488-g5edbadb-dirty (Oct 26 2010 - 14:16:00) MPC83XX
>
> Reset Status: Check Stop, External/Internal Soft, External/Internal Hard
>
>
> I know that DDR might not be 100% stable but it is basically set up
> properly.
> Removing the memset yields the next debug messages before resetting
> again while setting up SP.
>
> Is the DDR required to work 100% for a simple write operation or might
> there be another problem ?

Yes, DDR must be correct. You might get a bit further by turning off
the data cache.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/10/25 15:50:19:
>
> Jocke,
>
> [snip]
>
> > You still haven't reported weather the 4 nop's helped or not, yet you
> > seek my help. I am just going to ignore you until you do test it.
> >
> >
>
> finally I got both some time and hardware :
>
> 4 nops after _start does the trick, i.e. the board is up and running fine.
>
>
> Diffing both System.maps and U-Boot hexdump gives only trivial results :
>
> - "in_flash" and "_start_of_vectors" adress increment = 0x10.
> - offset calculation for relative branch instruction also increases by 0x10.
>
>
> Let me know if you need more information or something else tested.

How is this going? If nothing else I think you should send
a patch for 83xx, adding the 4 nop's as your(and mine) board is
broken otherwise. Freescale guys seems busy with other things so
I think this is the best thing to do.

      Jocke

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <OF5324EC0A.37C044B2-ONC12577D1.0031F002-C12577D1.00326E3D@transmode.se> you wrote:
>
> > 4 nops after _start does the trick, i.e. the board is up and running fine.
...
> How is this going? If nothing else I think you should send
> a patch for 83xx, adding the 4 nop's as your(and mine) board is
> broken otherwise. Freescale guys seems busy with other things so
> I think this is the best thing to do.

I don't like the idea of adding such code without any understanding
why it would be needed for some boards, while it is not needed for
others.

Is it really needed at _start?  Or can these NOPs be anywhere, and are
just needed to adjust some alignment?

When building for example for the MPC8315ERDB board, I see this
strange alignment here:

	-> grep _start_of_vectors System.map 
	fe0001a8 T _start_of_vectors

Adding 4 NOPs will move this nicely to the next exception vector
address at 0x200.

Eventually this is an alignment problem (but then, the
"STD_EXCEPTION(0x200, ...)" is supposed to align the respective code
to 0x200, and indeed we see

	fe0001a8 T _start_of_vectors
	fe000200 t MachineCheck
	fe000300 t DataStorage
	fe000400 t InstStorage
	...

Given the fact that _start_of_vectors is not used anywhere in the 83xx
code, all this is a pretty big mystery to me.

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
The explanation requiring the fewest assumptions is the  most  likely
to be correct.                                    -- William of Occam

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 2010/11/04 10:57:42:
>
> Dear Joakim Tjernlund,
>
> In message <OF5324EC0A.37C044B2-ONC12577D1.0031F002-C12577D1.00326E3D@transmode.se> you wrote:
> >
> > > 4 nops after _start does the trick, i.e. the board is up and running fine.
> ...
> > How is this going? If nothing else I think you should send
> > a patch for 83xx, adding the 4 nop's as your(and mine) board is
> > broken otherwise. Freescale guys seems busy with other things so
> > I think this is the best thing to do.
>
> I don't like the idea of adding such code without any understanding
> why it would be needed for some boards, while it is not needed for
> others.

Sure, but until freescale or someone else with eq. and motivation
researches it, we are stuck. I am not sure anyone else has tried
83xx based boards yet. If someone has please report. Also
include weather booted from NAND or NOR, CPU type(e300cX) and
what reset vector is used.

>
> Is it really needed at _start?  Or can these NOPs be anywhere, and are
> just needed to adjust some alignment?

no, the nops has to be directly after _start:
	. = EXC_OFF_SYS_RESET

	.globl	_start
_start: /* time t 0 */
	nop
	nop
	nop
	nop

My theory is that e300c2(no FPU) CPUs configured for low
boot vector, 0x100, really uses 0x110 instead.

>
> When building for example for the MPC8315ERDB board, I see this
> strange alignment here:
>
>    -> grep _start_of_vectors System.map
>    fe0001a8 T _start_of_vectors
>
> Adding 4 NOPs will move this nicely to the next exception vector
> address at 0x200.

ehh no. It will just move _start_of_vectors 16 bytes as
start_of_vectors doesn't have any alignment.

>
> Eventually this is an alignment problem (but then, the
> "STD_EXCEPTION(0x200, ...)" is supposed to align the respective code
> to 0x200, and indeed we see
>
>    fe0001a8 T _start_of_vectors
>    fe000200 t MachineCheck
>    fe000300 t DataStorage
>    fe000400 t InstStorage
>    ...
>
> Given the fact that _start_of_vectors is not used anywhere in the 83xx
> code, all this is a pretty big mystery to me.

It is probably some leftover. Either remove is for all ppc's. It only
seems to be used by mpc85xx and ppc4xx so the majority doesn't use it.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

>
> Wolfgang Denk <wd@denx.de> wrote on 2010/11/04 10:57:42:
> >
> > Dear Joakim Tjernlund,
> >
> > In message <OF5324EC0A.37C044B2-ONC12577D1.0031F002-C12577D1.00326E3D@transmode.se> you wrote:
> > >
> > > > 4 nops after _start does the trick, i.e. the board is up and running fine.
> > ...
> > > How is this going? If nothing else I think you should send
> > > a patch for 83xx, adding the 4 nop's as your(and mine) board is
> > > broken otherwise. Freescale guys seems busy with other things so
> > > I think this is the best thing to do.
> >
> > I don't like the idea of adding such code without any understanding
> > why it would be needed for some boards, while it is not needed for
> > others.
>
> Sure, but until freescale or someone else with eq. and motivation
> researches it, we are stuck. I am not sure anyone else has tried
> 83xx based boards yet. If someone has please report. Also
> include weather booted from NAND or NOR, CPU type(e300cX) and
> what reset vector is used.
>
> >
> > Is it really needed at _start?  Or can these NOPs be anywhere, and are
> > just needed to adjust some alignment?
>
> no, the nops has to be directly after _start:
>    . = EXC_OFF_SYS_RESET
>
>    .globl   _start
> _start: /* time t 0 */
>    nop
>    nop
>    nop
>    nop
>
> My theory is that e300c2(no FPU) CPUs configured for low
> boot vector, 0x100, really uses 0x110 instead.

hmm, what if a board decides to do a soft reset anyway, perhaps by mistake.
Would it not be a good thing if u-boot could handle that too?

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <OF4390B64D.1FBD6276-ONC12577D1.003BB658-C12577D1.003BF18A@transmode.se> you wrote:
>
> hmm, what if a board decides to do a soft reset anyway, perhaps by mistake.
> Would it not be a good thing if u-boot could handle that too?

What exactly is a "soft reset" in U-Boot?  And how would you perform
one?

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
What about WRITING it first and rationalizing it afterwords?  :-)
                       - Larry Wall in <8162@jpl-devvax.JPL.NASA.GOV>

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 2010/11/04 12:16:31:
>
> Dear Joakim Tjernlund,
>
> In message <OF4390B64D.1FBD6276-ONC12577D1.003BB658-C12577D1.003BF18A@transmode.se> you wrote:
> >
> > hmm, what if a board decides to do a soft reset anyway, perhaps by mistake.
> > Would it not be a good thing if u-boot could handle that too?
>
> What exactly is a "soft reset" in U-Boot?  And how would you perform
> one?

Not in u-boot, but Linux or a privileged linux app. could.

   Jocke

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <OF18CA6215.DC3A539B-ONC12577D1.00439A8B-C12577D1.0043BB01@transmode.se> you wrote:
>
> > What exactly is a "soft reset" in U-Boot?  And how would you perform
> > one?
> 
> Not in u-boot, but Linux or a privileged linux app. could.

Could do what?  Modify the memory map such that the Flash is mapped
as it was (eventually) when U-Boot is running, and then jump right in
the middle of nowhere?

That would be invoking undefined behaviour in it's purest form.

Anything can happen 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
Hindsight is an exact science.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 2010/11/04 13:46:17:
>
> Dear Joakim Tjernlund,
>
> In message <OF18CA6215.DC3A539B-ONC12577D1.00439A8B-C12577D1.0043BB01@transmode.se> you wrote:
> >
> > > What exactly is a "soft reset" in U-Boot?  And how would you perform
> > > one?
> >
> > Not in u-boot, but Linux or a privileged linux app. could.
>
> Could do what?  Modify the memory map such that the Flash is mapped

Issue an soft reset somehow. Don't know how but I guessing it is possible?
If so the CPU would use reset vector 0x110 instead of 0x100(still guessing here)

> as it was (eventually) when U-Boot is running, and then jump right in
> the middle of nowhere?
>
> That would be invoking undefined behaviour in it's purest form.
>
> Anything can happen then.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Joakim Tjernlund,

In message <OF51547B77.F521DBCE-ONC12577D1.0046EB0D-C12577D1.0047448E@transmode.se> you wrote:
>
> > Could do what?  Modify the memory map such that the Flash is mapped
> 
> Issue an soft reset somehow. Don't know how but I guessing it is possible?
> If so the CPU would use reset vector 0x110 instead of 0x100(still guessing here)

I wonder where this idea of a "reset vector" or any other entry point
at 0x110 might come from?

AFAICT there is no such thing, and never has been one.

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
You have the capacity to learn from  mistakes.  You'll  learn  a  lot
today.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 2010/11/04 14:07:50:
>
> Dear Joakim Tjernlund,
>
> In message <OF51547B77.F521DBCE-ONC12577D1.0046EB0D-C12577D1.0047448E@transmode.se> you wrote:
> >
> > > Could do what?  Modify the memory map such that the Flash is mapped
> >
> > Issue an soft reset somehow. Don't know how but I guessing it is possible?
> > If so the CPU would use reset vector 0x110 instead of 0x100(still guessing here)
>
> I wonder where this idea of a "reset vector" or any other entry point
> at 0x110 might come from?
>
> AFAICT there is no such thing, and never has been one.

ah, I just assumed there was one as start.S was written like there was
one. My problem appears to be something else then.

  Jocke

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andy Pont]

Joakim wrote...

> Sure, but until freescale or someone else with eq. and motivation
> researches it, we are stuck. I am not sure anyone else has tried
> 83xx based boards yet. If someone has please report. Also
> include weather booted from NAND or NOR, CPU type(e300cX) and
> what reset vector is used.

I have a couple of Freescale reference boards here (8313ERDB and
8349-MITX-GP).  I'm not a powerpc expert by any means but if there are some
(simple) tests you would like me to run on them then I will see if I can
find some time.

Andy.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

"Andy Pont" <andy.pont@sdcsystems.com> wrote on 2010/11/04 11:58:19:
>
> Joakim wrote...
>
> > Sure, but until freescale or someone else with eq. and motivation
> > researches it, we are stuck. I am not sure anyone else has tried
> > 83xx based boards yet. If someone has please report. Also
> > include weather booted from NAND or NOR, CPU type(e300cX) and
> > what reset vector is used.
>
> I have a couple of Freescale reference boards here (8313ERDB and
> 8349-MITX-GP).  I'm not a powerpc expert by any means but if there are some
> (simple) tests you would like me to run on them then I will see if I can
> find some time.

Just install latest u-boot from git and see if the boot.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Andy,
>> Sure, but until freescale or someone else with eq. and motivation
>> researches it, we are stuck. I am not sure anyone else has tried
>> 83xx based boards yet. If someone has please report. Also
>> include weather booted from NAND or NOR, CPU type(e300cX) and
>> what reset vector is used.
>>      
> I have a couple of Freescale reference boards here (8313ERDB and
> 8349-MITX-GP).  I'm not a powerpc expert by any means but if there are some
> (simple) tests you would like me to run on them then I will see if I can
> find some time.
>    

I can see this issues only on MPC837x, i.e. *not* on MPC834x.

> Andy.
>
>    

Regards,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/11/04 13:14:37:
>
> Andy,
> >> Sure, but until freescale or someone else with eq. and motivation
> >> researches it, we are stuck. I am not sure anyone else has tried
> >> 83xx based boards yet. If someone has please report. Also
> >> include weather booted from NAND or NOR, CPU type(e300cX) and
> >> what reset vector is used.
> >>
> > I have a couple of Freescale reference boards here (8313ERDB and
> > 8349-MITX-GP).  I'm not a powerpc expert by any means but if there are some
> > (simple) tests you would like me to run on them then I will see if I can
> > find some time.
> >
>
> I can see this issues only on MPC837x, i.e. *not* on MPC834x.

-E_TOO_LITTLE_INFO

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

>> Andy,
>>      
>>>> Sure, but until freescale or someone else with eq. and motivation
>>>> researches it, we are stuck. I am not sure anyone else has tried
>>>> 83xx based boards yet. If someone has please report. Also
>>>> include weather booted from NAND or NOR, CPU type(e300cX) and
>>>> what reset vector is used.
>>>>
>>>>          
>>> I have a couple of Freescale reference boards here (8313ERDB and
>>> 8349-MITX-GP).  I'm not a powerpc expert by any means but if there are some
>>> (simple) tests you would like me to run on them then I will see if I can
>>> find some time.
>>>
>>>        
>> I can see this issues only on MPC837x, i.e. *not* on MPC834x.
>>      
> -E_TOO_LITTLE_INFO
>    

sorry.

I meant that e.g. mvblm7 board (=MPC8343) works like a charm from 
current mainline U-Boot.

My latest MPC8377 board does not even start without your suggested 4 nops.
It does not start (i.e. serial line completely dead) with any USB 
functionality defined.
I also have random hangs depending on activated code, e.g. 
CONFIG_CMD_something or SPI drivers etc.

To me it looks like an alignment problem *somewhere*.


As said before I'm still digging and try to get more useful information.

Do you think porting the board to an earlier (maybe 2009) version is 
worth a try ?
I could start bisecting if we could get a stable version.


Regards,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/11/04 13:28:27:
>
>
> >> Andy,
> >>
> >>>> Sure, but until freescale or someone else with eq. and motivation
> >>>> researches it, we are stuck. I am not sure anyone else has tried
> >>>> 83xx based boards yet. If someone has please report. Also
> >>>> include weather booted from NAND or NOR, CPU type(e300cX) and
> >>>> what reset vector is used.
> >>>>
> >>>>
> >>> I have a couple of Freescale reference boards here (8313ERDB and
> >>> 8349-MITX-GP).  I'm not a powerpc expert by any means but if there are some
> >>> (simple) tests you would like me to run on them then I will see if I can
> >>> find some time.
> >>>
> >>>
> >> I can see this issues only on MPC837x, i.e. *not* on MPC834x.
> >>
> > -E_TOO_LITTLE_INFO
> >
>
> sorry.
>
> I meant that e.g. mvblm7 board (=MPC8343) works like a charm from
> current mainline U-Boot.

still -E_TOO_LITTLE_INFO:
"include weather booted from NAND or NOR, CPU type(e300cX) and
 what reset vector is used."

>
> My latest MPC8377 board does not even start without your suggested 4 nops.
> It does not start (i.e. serial line completely dead) with any USB
> functionality defined.

Something else is broken here, no idea what.

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Jocke,

[snip]

> still -E_TOO_LITTLE_INFO:
>    

sorry - thought it was clear already.

> "include weather booted from NAND or NOR, CPU type(e300cX) and
>   what reset vector is used."
>    
CPU:   e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz

- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset Vector 0x100, i.e. low boot.

Initial RAM ...

#define CONFIG_SYS_INIT_RAM_LOCK       1
#define CONFIG_SYS_INIT_RAM_ADDR       0xE6000000
#define CONFIG_SYS_INIT_RAM_SIZE        0x1000
#define CONFIG_SYS_GBL_DATA_SIZE        0x100
#define CONFIG_SYS_GBL_DATA_OFFSET  (CONFIG_SYS_INIT_RAM_SIZE - 
CONFIG_SYS_GBL_DATA_SIZE)

... mapped by BAT5

#define CONFIG_SYS_IBAT5L       (CONFIG_SYS_INIT_RAM_ADDR | BATL_PP_10)
#define CONFIG_SYS_IBAT5U       (CONFIG_SYS_INIT_RAM_ADDR | BATU_BL_128K 
| BATU_VS | BATU_VP)
#define CONFIG_SYS_DBAT5L       CONFIG_SYS_IBAT5L
#define CONFIG_SYS_DBAT5U       CONFIG_SYS_IBAT5U


Of course ELDK-4.2 toolchain.

>> My latest MPC8377 board does not even start without your suggested 4 nops.
>> It does not start (i.e. serial line completely dead) with any USB
>> functionality defined.
>>      
> Something else is broken here, no idea what.
>
>    
If it's an alignment or linking problem it could have the same root cause.
Just want to give as much information as I can.


Cheers,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/11/04 14:32:15:
>
> Jocke,
>
> [snip]
>
> > still -E_TOO_LITTLE_INFO:
> >
>
> sorry - thought it was clear already.
>
> > "include weather booted from NAND or NOR, CPU type(e300cX) and
> >   what reset vector is used."
> >
> CPU:   e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
>
> - Boot from NOR Flash
> - HRCW from I2C EEPROM
> - Reset Vector 0x100, i.e. low boot.

OK, almost the same as me, but I got a:
CPU:   e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz

However, I think I just found the problem.
My tree is a bit messy now so no patch but it will be:

Stick an isync (or sync) in
map_flash_by_law1
....
	stw r4, LBLAWAR1(r3) /* LBLAWAR1 <= 8MB Flash Size */
	isync //HERE !! HERE !! HERE
	blr

I am guessing it takes a while for the stw r4, LBLAWAR1(r3)
to hit the HW so one must wait for it, not sure what is
best though, sync or isync?

There is nothing wrong with my reset vector

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Jocke,

>> CPU:   e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
>>
>> - Boot from NOR Flash
>> - HRCW from I2C EEPROM
>> - Reset Vector 0x100, i.e. low boot.
>>      
> OK, almost the same as me, but I got a:
> CPU:   e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz
>
> However, I think I just found the problem.
>    

excellent !

> My tree is a bit messy now so no patch but it will be:
>
> Stick an isync (or sync) in
> map_flash_by_law1
> ....
> 	stw r4, LBLAWAR1(r3) /* LBLAWAR1<= 8MB Flash Size */
> 	isync //HERE !! HERE !! HERE
> 	blr
>    

ok - works for me, i.e. no quad-nop needed anymore.

> I am guessing it takes a while for the stw r4, LBLAWAR1(r3)
> to hit the HW so one must wait for it, not sure what is
> best though, sync or isync?
>    
If it is a timing issue why should have the nops influenced this ?
I still wonder if this is the real problem and whether we might need 
more (i)syncs elsewhere ...
> There is nothing wrong with my reset vector
>
>    
ok.



Cheers,
Andr?



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/11/04 15:49:06:
>
> Jocke,
>
> >> CPU:   e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
> >>
> >> - Boot from NOR Flash
> >> - HRCW from I2C EEPROM
> >> - Reset Vector 0x100, i.e. low boot.
> >>
> > OK, almost the same as me, but I got a:
> > CPU:   e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz
> >
> > However, I think I just found the problem.
> >
>
> excellent !
>
> > My tree is a bit messy now so no patch but it will be:
> >
> > Stick an isync (or sync) in
> > map_flash_by_law1
> > ....
> >    stw r4, LBLAWAR1(r3) /* LBLAWAR1<= 8MB Flash Size */
> >    isync //HERE !! HERE !! HERE
> >    blr
> >
>
> ok - works for me, i.e. no quad-nop needed anymore.

Does both your boards work now?

>
> > I am guessing it takes a while for the stw r4, LBLAWAR1(r3)
> > to hit the HW so one must wait for it, not sure what is
> > best though, sync or isync?
> >
> If it is a timing issue why should have the nops influenced this ?
> I still wonder if this is the real problem and whether we might need
> more (i)syncs elsewhere ...

You can try replacing the isync with 4 nops. That works
for me. moving the 4 nops after the blr doesn't work.

I think it worked earlier by chance but the removal of
the flags changed timing, probably a cache line crossing
at the wrong place.

     Jocke

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Jocke,
>> ok - works for me, i.e. no quad-nop needed anymore.
>>      
> Does both your boards work now?
>    

MPC8343 @ 400MHz never had any issues - it's still working with your 
patch applied.

MPC8377 works fine up to 533MHz ... 600MHz+ still hangs.

Looks like there are more sync missing.

>>> I am guessing it takes a while for the stw r4, LBLAWAR1(r3)
>>> to hit the HW so one must wait for it, not sure what is
>>> best though, sync or isync?
>>>
>>>        
>> If it is a timing issue why should have the nops influenced this ?
>> I still wonder if this is the real problem and whether we might need
>> more (i)syncs elsewhere ...
>>      
> You can try replacing the isync with 4 nops. That works
> for me. moving the 4 nops after the blr doesn't work.
>
> I think it worked earlier by chance but the removal of
> the flags changed timing, probably a cache line crossing
> at the wrong place.
>    

"works by chance" is probably not what we want.

Anyway - good catch. Thanks again.


Cheers,
Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Reinhard Meyer]

Dear Joakim Tjernlund schrieb:
> no, the nops has to be directly after _start:
> 	. = EXC_OFF_SYS_RESET
> 
> 	.globl	_start
> _start: /* time t 0 */
> 	nop
> 	nop
> 	nop
> 	nop
> 
> My theory is that e300c2(no FPU) CPUs configured for low
> boot vector, 0x100, really uses 0x110 instead.


How about a simple test:

_start:
	bra	case1
	org	_start+0x10
	bra	case2
...
case1:	"turn on red led"
	bra	case1

case2:	"turn on green led"
	bra	case2


You get the idea :)

Best Regards
Reinhard

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Jocke,

[snip]
>> finally I got both some time and hardware :
>>
>> 4 nops after _start does the trick, i.e. the board is up and running fine.
>>
>>
>> Diffing both System.maps and U-Boot hexdump gives only trivial results :
>>
>> - "in_flash" and "_start_of_vectors" adress increment = 0x10.
>> - offset calculation for relative branch instruction also increases by 0x10.
>>
>>
>> Let me know if you need more information or something else tested.
>>      
> How is this going? If nothing else I think you should send
> a patch for 83xx, adding the 4 nop's as your(and mine) board is
> broken otherwise. Freescale guys seems busy with other things so
> I think this is the best thing to do.
>    

currently I can see no light at the end of the tunnel so that I don't 
dare send any kind of patch.

Actually I got some time to analyze and further optimize the memory bus.
During relocation the board hangs in flush_dcache.
I can see the DDR-II signal levels change to a non-working state ... 
maybe this is caused by some internal reset - don't know.

But approx. 1 out of 20 tries (power cycles) U-Boot makes it past that 
point and continues working.
Then there's a console and the system is memtesting for hours. PCI, LAN 
and Flash are also running fine.
No issues after flush_dcache succeeded.



Second strange issue is that the serial line is dead again as soon as I 
#define USB functionality withing board config, i.e. U-Boot does not 
even run from flash.
This is reproducable - removing the USB #defines makes U-Boot work again.

Removing the 4 "nop" doesn't help either.


I definitely need some time to dig a little deeper.

Any help or pointers are welcome.


Regards,

Andr?

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Wolfgang Denk]

Dear Andre Schwarz,

In message <4CC58B1B.8040005@matrix-vision.de> you wrote:
> 
> Diffing both System.maps and U-Boot hexdump gives only trivial results :
> 
> - "in_flash" and "_start_of_vectors" adress increment = 0x10.

Hey, stop here.

How can _start_of_vectors shift? It i supposed to be at a fixed
location, i. e. at 0x100.

Hmmm... seems 83xx does not use _start_of_vectors at all. We should
either fix _start_of_vectors or remove it completely.

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
The price of curiosity is a terminal experience.
                         - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 2010/11/04 10:50:38:
>
> Dear Andre Schwarz,
>
> In message <4CC58B1B.8040005@matrix-vision.de> you wrote:
> >
> > Diffing both System.maps and U-Boot hexdump gives only trivial results :
> >
> > - "in_flash" and "_start_of_vectors" adress increment = 0x10.
>
> Hey, stop here.
>
> How can _start_of_vectors shift? It i supposed to be at a fixed
> location, i. e. at 0x100.

_start_of_vectors isn't used on 83xx. It is just a pointless symbol
as far as I can tell. 83xx uses _start and that symbol is fixed at 0x100


>
> Hmmm... seems 83xx does not use _start_of_vectors at all. We should
> either fix _start_of_vectors or remove it completely.

Yes.

>
> 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
> The price of curiosity is a terminal experience.
>                          - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 2010/10/24 22:18:32:
>
> Dear "Schwarz,Andre",
>
> In message <1702240919.111.1287950899754.JavaMail.open-xchange@proteus> you wrote:
> >
> > Since I assume Wolfgang won't accept a board specific "add 4 nops after
> > _start"-patch I'd like to solve this without trial and error.
>
> To the best of my knowledge no board made use f this "warmboot" entry
> point. OK, I wasn't aware that Jocke obviously did something lioke
> this, so there might be other boards as well - but it's unlikely.

I am not intentionally doing that and I am still not sure this is the
case either. Our reset sequence is somewhat different that standard so
I cannot be sure and I haven't had the time to look at
this as some high prio stuff landed at my feet that I need
to deal with 100% until done.