Re: Problem with memcpy on ppc8536
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: fab...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with memcpy on ppc8536
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/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with memcpy on ppc8536
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. pgp3SiMGPWYf4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with memcpy on ppc8536
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: fab...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Problem with memcpy on ppc8536
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: fab...@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
I believe the question should be sent to u-b...@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=freescale@lists.ozlabs.org [mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org] On Behalf Of Fahd Abidi Sent: Friday, June 19, 2009 4:34 AM To: linuxppc-...@ozlabs.org Subject: Problem with memcpy on ppc8536 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: fab...@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
