From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id 9BCC5B71D0 for ; Fri, 19 Jun 2009 06:59:45 +1000 (EST) Received: from ultsol.com (unknown [216.117.139.109]) by ozlabs.org (Postfix) with ESMTP id BE5D1DDD1B for ; Fri, 19 Jun 2009 06:59:44 +1000 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F054.1C91C81F" Subject: Problem with memcpy on ppc8536 Date: Thu, 18 Jun 2009 16:33:53 -0400 Message-ID: <71DEA556544D7A4F9C6848402D8184340C4A13@usi01.ultsol.local> From: "Fahd Abidi" To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F054.1C91C81F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello,=20 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 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 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 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 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 =20 =20 ------_=_NextPart_001_01C9F054.1C91C81F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I am trying = to debug a=20 crash during memcpy while copying data from the FCM buffer of an mpc8536 = to the=20 ddr ram. I debugged memcpy enough through my BDI3000 to see that the = entire=20 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 =3D r5 >> 3 */
addi r6,r3,-4 =
addi=20 r4,r4,-4
beq 2f /* if less than 8 bytes to do */
andi. r0,r6,3 = /* get=20 dest word aligned */
mtctr r7
bne 5f
1: lwz r7,4(r4) =
lwzu=20 r8,8(r4)
stw r7,4(r6)
stwu r8,8(r6)
bdnz 1b
andi. = r5,r5,7
2:=20 cmplwi 0,r5,4

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

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

Fahd = Abidi
Product=20 Manager - Technical Tools and Development

Ultimate = Solutions,=20 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=20 for Professional Development Tools and Embedded=20 Solutions
Ph: = 978-455-3383=20 x255
Fx: 978-926-3091
Email: fabidi@ultsol.com
Visit: http://www.ultsol.com =

------_=_NextPart_001_01C9F054.1C91C81F-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id E45CEB71A6 for ; Fri, 19 Jun 2009 14:42:51 +1000 (EST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 9DB3ADDD01 for ; Fri, 19 Jun 2009 14:42:49 +1000 (EST) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n5J4gk7X015270 for ; Thu, 18 Jun 2009 21:42:46 -0700 (MST) Received: from zch01exm21.fsl.freescale.net (zch01exm21.ap.freescale.net [10.192.129.205]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n5J4giLB001093 for ; Thu, 18 Jun 2009 23:42:45 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Problem with memcpy on ppc8536 Date: Fri, 19 Jun 2009 12:42:44 +0800 Message-ID: In-Reply-To: <71DEA556544D7A4F9C6848402D8184340C4A13@usi01.ultsol.local> References: <71DEA556544D7A4F9C6848402D8184340C4A13@usi01.ultsol.local> From: "Liu Dave-R63238" To: "Fahd Abidi" , Cc: u-boot@lists.denx.de List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 =20 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id 81A48B7271 for ; Sat, 20 Jun 2009 03:06:39 +1000 (EST) Received: from smtp.esic-solutions.com (h1371364.stratoserver.net [85.214.87.145]) by ozlabs.org (Postfix) with ESMTP id 903C5DDD1C for ; Sat, 20 Jun 2009 03:06:38 +1000 (EST) Message-ID: <4A3BC58A.7050408@missinglinkelectronics.com> Date: Fri, 19 Jun 2009 19:06:18 +0200 From: Lorenz Kolb MIME-Version: 1.0 To: Fahd Abidi Subject: Re: Problem with memcpy on ppc8536 References: <71DEA556544D7A4F9C6848402D8184340C4A13__24467.8549039692$1245370891$gmane$org@usi01.ultsol.local> In-Reply-To: <71DEA556544D7A4F9C6848402D8184340C4A13__24467.8549039692$1245370891$gmane$org@usi01.ultsol.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id E120BB7249 for ; Sat, 20 Jun 2009 03:51:35 +1000 (EST) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [92.198.50.35]) by ozlabs.org (Postfix) with ESMTP id 48835DDD0C for ; Sat, 20 Jun 2009 03:51:34 +1000 (EST) Date: Fri, 19 Jun 2009 19:51:05 +0200 From: Wolfram Sang To: Lorenz Kolb Subject: Re: Problem with memcpy on ppc8536 Message-ID: <20090619175105.GA16015@pengutronix.de> References: <71DEA556544D7A4F9C6848402D8184340C4A13__24467.8549039692$1245370891$gmane$org@usi01.ultsol.local> <4A3BC58A.7050408@missinglinkelectronics.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" In-Reply-To: <4A3BC58A.7050408@missinglinkelectronics.com> Cc: linuxppc-dev@ozlabs.org, Fahd Abidi List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 = =20 > for > 4 was accidentially done within io.c instead of >=3D 4 as if it's 4= =20 > we still can copy a 32-bit word. Some hardware might not be happy about = =20 > 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 miss= ed because of that? Regards, Wolfram --=20 Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko70AkACgkQD27XaX1/VRuHmACgo1pRdxxR+l8OC2qvVg9gNcPh rz0An3A/EIDx9bC7oXm+19D1A4STzVKK =sEUy -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.112]) by bilbo.ozlabs.org (Postfix) with ESMTP id C372CB7249 for ; Sat, 20 Jun 2009 03:57:56 +1000 (EST) Received: from antares (xdsl-87-79-186-157.netcologne.de [87.79.186.157]) by smtp2.netcologne.de (Postfix) with ESMTP id 8079C4342 for ; Fri, 19 Jun 2009 19:28:20 +0200 (MEST) Received: from antares (localhost [127.0.0.1]) by antares (Postfix) with ESMTPS id 6C586BA042 for ; Fri, 19 Jun 2009 19:28:20 +0200 (CEST) Date: Fri, 19 Jun 2009 19:28:12 +0200 From: Albrecht =?iso-8859-1?b?RHJl3w==?= Subject: Re: Problem with memcpy on ppc8536 To: linuxppc-dev@lists.ozlabs.org In-Reply-To: <4A3BC58A.7050408@missinglinkelectronics.com> (from lorenz@missinglinkelectronics.com on Fri Jun 19 19:06:18 2009) Message-Id: <1245432500.3294.0@antares> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; protocol="application/pgp-signature"; boundary="=-9KUEsSQ9CMqeonWXrWkE" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --=-9KUEsSQ9CMqeonWXrWkE Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 19.06.09 19:06 schrieb(en) Lorenz Kolb: > Could you please try the following patch, I am quite sure that =20 > checking for > 4 was accidentially done within io.c instead of >=3D 4 =20 > as if it's 4 we still can copy a 32-bit word. Some hardware might not =20 > be happy about 8-bit accesses... I submitted the same patch a while ago, see =20 =20 and =20 , =20 maybe you can add a tested/revied for it? If it is a problem with *byte* accesses, you might want to have a look =20 at =20 . Best, Albrecht. --=-9KUEsSQ9CMqeonWXrWkE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQBKO8q0n/9unNAn/9ERAv/lAJ46Wuzz4RuXs/ERcQ5huZ/JnNED5QCeM2aX Ah78LwfPsdutv5/GQhaa6jY= =Nf+m -----END PGP SIGNATURE----- --=-9KUEsSQ9CMqeonWXrWkE-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id B14F9B726A for ; Sat, 20 Jun 2009 03:31:31 +1000 (EST) Received: from smtp.esic-solutions.com (h1371364.stratoserver.net [85.214.87.145]) by ozlabs.org (Postfix) with ESMTP id 44E87DDD0C for ; Sat, 20 Jun 2009 03:31:29 +1000 (EST) Message-ID: <4A3BC503.80400@uni-ulm.de> Date: Fri, 19 Jun 2009 19:04:03 +0200 From: Lorenz Kolb MIME-Version: 1.0 To: Fahd Abidi Subject: Re: Problem with memcpy on ppc8536 References: <71DEA556544D7A4F9C6848402D8184340C4A13__24467.8549039692$1245370891$gmane$org@usi01.ultsol.local> In-Reply-To: <71DEA556544D7A4F9C6848402D8184340C4A13__24467.8549039692$1245370891$gmane$org@usi01.ultsol.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev