Problem with memcpy on ppc8536

Problem with memcpy on ppc8536

[Fahd Abidi]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

Hello, 

I am trying to debug a crash during memcpy while copying data from the
FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough
through my BDI3000 to see that the entire contents of the fcm buffer I
want moved are actually moved off to memory location I specify. The
crash comes after it memcpy finishes copying and performs the
instruction "2: cmplwi 0,r5,4": 

memcpy: 
rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */ 
addi r6,r3,-4 
addi r4,r4,-4 
beq 2f /* if less than 8 bytes to do */ 
andi. r0,r6,3 /* get dest word aligned */ 
mtctr r7 
bne 5f 
1: lwz r7,4(r4) 
lwzu r8,8(r4) 
stw r7,4(r6) 
stwu r8,8(r6) 
bdnz 1b 
andi. r5,r5,7 
2: cmplwi 0,r5,4 

contents of r5 are 0x0 showing that the entire 0x1000 size transfer I
specified correctly finished. At this point I can check the memory
contents through my BDI and verify all the data is in the ddr as I
expect. Now the strange thing happens, if I execute the "cmplwi 0,r5,4"
the program takes an exception and eventually gets struck at exception
vector 0x700 which I saw from start.S is an "Alignment" exception. I am
not sure what this exception means, can someone help me understand what
is happening? 

Does this exception somehow mean that memcpy did not move all the data?
Does memcpy expect contents of r5 to be 4 and not 0 when it hits the
cmplwi instruction? 


Fahd Abidi
Product Manager - Technical Tools and Development
Ultimate Solutions, Inc.
================================================================
Your Single Source for Professional Development Tools and Embedded
Solutions
Ph: 978-455-3383 x255
Fx: 978-926-3091
Email: fabidi@ultsol.com
Visit: http://www.ultsol.com <http://www.ultsol.com/>  
 

[-- Attachment #2: Type: text/html, Size: 3136 bytes --]

RE: Problem with memcpy on ppc8536

[Liu Dave-R63238]

I believe the question should be sent to u-boot@lists.denx.de,
not linuxppc-dev list.

What is the TLB settings for NAND FCM buffer? Pay attention
to set the TLB as cache inhibited and guarded attribute.

If not set the guarded bit, it is possible to cause the speculate
load from FCM buffer below the cmplwi and blt inst.

IIRC, the FCM buffer only has the 4KB. So if it has one speculated
Load above the 4KB, it will run into problem.

The 0x700 is not alignment exception, it is program exception.

If you can dump the exception error information from console
to us, maybe we can give better help.

Thanks, Dave

________________________________

	From:
linuxppc-dev-bounces+daveliu=3Dfreescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+daveliu=3Dfreescale.com@lists.ozlabs.org] =
On
Behalf Of Fahd Abidi
	Sent: Friday, June 19, 2009 4:34 AM
	To: linuxppc-dev@ozlabs.org
	Subject: Problem with memcpy on ppc8536
=09
=09
	Hello,=20
=09
	I am trying to debug a crash during memcpy while copying data
from the FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy
enough through my BDI3000 to see that the entire contents of the fcm
buffer I want moved are actually moved off to memory location I specify.
The crash comes after it memcpy finishes copying and performs the
instruction "2: cmplwi 0,r5,4":=20
=09
	memcpy:=20
	rlwinm. r7,r5,32-3,3,31 /* r0 =3D r5 >> 3 */=20
	addi r6,r3,-4=20
	addi r4,r4,-4=20
	beq 2f /* if less than 8 bytes to do */=20
	andi. r0,r6,3 /* get dest word aligned */=20
	mtctr r7=20
	bne 5f=20
	1: lwz r7,4(r4)=20
	lwzu r8,8(r4)=20
	stw r7,4(r6)=20
	stwu r8,8(r6)=20
	bdnz 1b=20
	andi. r5,r5,7=20
	2: cmplwi 0,r5,4=20
=09
	contents of r5 are 0x0 showing that the entire 0x1000 size
transfer I specified correctly finished. At this point I can check the
memory contents through my BDI and verify all the data is in the ddr as
I expect. Now the strange thing happens, if I execute the "cmplwi
0,r5,4" the program takes an exception and eventually gets struck at
exception vector 0x700 which I saw from start.S is an "Alignment"
exception. I am not sure what this exception means, can someone help me
understand what is happening?=20
=09
	Does this exception somehow mean that memcpy did not move all
the data? Does memcpy expect contents of r5 to be 4 and not 0 when it
hits the cmplwi instruction?=20
=09

	Fahd Abidi
	Product Manager - Technical Tools and Development
	Ultimate Solutions, Inc.
	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
	Your Single Source for Professional Development Tools and
Embedded Solutions
	Ph: 978-455-3383 x255
	Fx: 978-926-3091
	Email: fabidi@ultsol.com
	Visit: http://www.ultsol.com <http://www.ultsol.com/> =20

Re: Problem with memcpy on ppc8536

[Lorenz Kolb]

Could you please try the following patch, I am quite sure that checking 
for > 4 was accidentially done within io.c instead of >= 4 as if it's 4 
we still can copy a 32-bit word. Some hardware might not be happy about 
8-bit accesses...

Index: 2.6.30-source/arch/powerpc/kernel/io.c
===================================================================
--- a/2.6.30-source/arch/powerpc/kernel/io.c
+++ b/2.6.30-source/arch/powerpc/kernel/io.c

@@ -162,5 +162,5 @@
                  n--;
          }
-        while(n > 4) {
+        while(n >= 4) {
                  *((u32 *)dest) = *((volatile u32 *)vsrc);
                  eieio();
@@ -191,5 +191,5 @@
                  n--;
          }
-        while(n > 4) {
+        while(n >= 4) {
                  *((volatile u32 *)vdest) = *((volatile u32 *)src);
                  src += 4;

Fahd Abidi wrote:
> Hello, 
> 
> I am trying to debug a crash during memcpy while copying data from the
> FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough
> through my BDI3000 to see that the entire contents of the fcm buffer I
> want moved are actually moved off to memory location I specify. The
> crash comes after it memcpy finishes copying and performs the
> instruction "2: cmplwi 0,r5,4": 
> 
> memcpy: 
> rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */ 
> addi r6,r3,-4 
> addi r4,r4,-4 
> beq 2f /* if less than 8 bytes to do */ 
> andi. r0,r6,3 /* get dest word aligned */ 
> mtctr r7 
> bne 5f 
> 1: lwz r7,4(r4) 
> lwzu r8,8(r4) 
> stw r7,4(r6) 
> stwu r8,8(r6) 
> bdnz 1b 
> andi. r5,r5,7 
> 2: cmplwi 0,r5,4 
> 
> contents of r5 are 0x0 showing that the entire 0x1000 size transfer I
> specified correctly finished. At this point I can check the memory
> contents through my BDI and verify all the data is in the ddr as I
> expect. Now the strange thing happens, if I execute the "cmplwi 0,r5,4"
> the program takes an exception and eventually gets struck at exception
> vector 0x700 which I saw from start.S is an "Alignment" exception. I am
> not sure what this exception means, can someone help me understand what
> is happening? 
> 
> Does this exception somehow mean that memcpy did not move all the data?
> Does memcpy expect contents of r5 to be 4 and not 0 when it hits the
> cmplwi instruction? 
> 
> 
> Fahd Abidi
> Product Manager - Technical Tools and Development
> Ultimate Solutions, Inc.
> ================================================================
> Your Single Source for Professional Development Tools and Embedded
> Solutions
> Ph: 978-455-3383 x255
> Fx: 978-926-3091
> Email: fabidi@ultsol.com
> Visit: http://www.ultsol.com <http://www.ultsol.com/>  
>  
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Problem with memcpy on ppc8536

[Lorenz Kolb]

Could you please try the following patch, I am quite sure that checking 
for > 4 was accidentially done within io.c instead of >= 4 as if it's 4 
we still can copy a 32-bit word. Some hardware might not be happy about 
8-bit accesses...

Index: 2.6.30-source/arch/powerpc/kernel/io.c
===================================================================
--- a/2.6.30-source/arch/powerpc/kernel/io.c
+++ b/2.6.30-source/arch/powerpc/kernel/io.c

@@ -162,5 +162,5 @@
                  n--;
          }
-        while(n > 4) {
+        while(n >= 4) {
                  *((u32 *)dest) = *((volatile u32 *)vsrc);
                  eieio();
@@ -191,5 +191,5 @@
                  n--;
          }
-        while(n > 4) {
+        while(n >= 4) {
                  *((volatile u32 *)vdest) = *((volatile u32 *)src);
                  src += 4;

Fahd Abidi wrote:
> Hello, 
> 
> I am trying to debug a crash during memcpy while copying data from the
> FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough
> through my BDI3000 to see that the entire contents of the fcm buffer I
> want moved are actually moved off to memory location I specify. The
> crash comes after it memcpy finishes copying and performs the
> instruction "2: cmplwi 0,r5,4": 
> 
> memcpy: 
> rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */ 
> addi r6,r3,-4 
> addi r4,r4,-4 
> beq 2f /* if less than 8 bytes to do */ 
> andi. r0,r6,3 /* get dest word aligned */ 
> mtctr r7 
> bne 5f 
> 1: lwz r7,4(r4) 
> lwzu r8,8(r4) 
> stw r7,4(r6) 
> stwu r8,8(r6) 
> bdnz 1b 
> andi. r5,r5,7 
> 2: cmplwi 0,r5,4 
> 
> contents of r5 are 0x0 showing that the entire 0x1000 size transfer I
> specified correctly finished. At this point I can check the memory
> contents through my BDI and verify all the data is in the ddr as I
> expect. Now the strange thing happens, if I execute the "cmplwi 0,r5,4"
> the program takes an exception and eventually gets struck at exception
> vector 0x700 which I saw from start.S is an "Alignment" exception. I am
> not sure what this exception means, can someone help me understand what
> is happening? 
> 
> Does this exception somehow mean that memcpy did not move all the data?
> Does memcpy expect contents of r5 to be 4 and not 0 when it hits the
> cmplwi instruction? 
> 
> 
> Fahd Abidi
> Product Manager - Technical Tools and Development
> Ultimate Solutions, Inc.
> ================================================================
> Your Single Source for Professional Development Tools and Embedded
> Solutions
> Ph: 978-455-3383 x255
> Fx: 978-926-3091
> Email: fabidi@ultsol.com
> Visit: http://www.ultsol.com <http://www.ultsol.com/>  
>  
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Problem with memcpy on ppc8536

[Albrecht Dreß]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

Am 19.06.09 19:06 schrieb(en) Lorenz Kolb:
> Could you please try the following patch, I am quite sure that  
> checking for > 4 was accidentially done within io.c instead of >= 4  
> as if it's 4 we still can copy a 32-bit word. Some hardware might not  
> be happy about 8-bit accesses...

I submitted the same patch a while ago, see  
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html>  
and  
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073065.html>,  
maybe you can add a tested/revied for it?

If it is a problem with *byte* accesses, you might want to have a look  
at  
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072903.html>.

Best, Albrecht.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Problem with memcpy on ppc8536

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Fri, Jun 19, 2009 at 07:06:18PM +0200, Lorenz Kolb wrote:

> Could you please try the following patch, I am quite sure that checking  
> for > 4 was accidentially done within io.c instead of >= 4 as if it's 4  
> we still can copy a 32-bit word. Some hardware might not be happy about  
> 8-bit accesses...

There seems to be desire for this fix:

http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html

If it works here, too, then you could maybe also ack it?

BTW, I can't find the original patch in patchwork, maybe the patch was missed
because of that?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]