* Re: MPC85xx DMA support for Kernel 2.6?
From: Clemens Koller @ 2005-07-01 7:47 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <427c70958bb995dad4fbad2e6ff121bc@embeddededge.com>
Hi, Dan!
Dan Malek wrote:
> Before you start, just make sure such a thing is really a performance
> enhancement. Yes, the DMA does run in parallel with the core, but often
> the overhead of the set up and clean up interrupt is more code and time
> that if you just copied the data in a loop. If possible, integrate the DMA
> processing into other driver work, clean up a previous DMA the next time
> the driver needs to use it, not with a separate completion handler.
Well... thanks. But the CPU is intended to do image processing while
data comes in. And currently, when I access (memcopy) the SRAM on my
Local Bus via UPM I cannot get it to generate bursts yet, so I hope the
DMA will speed up those things, too.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Clemens Koller @ 2005-07-01 7:54 UTC (permalink / raw)
To: Murray.Jensen; +Cc: linuxppc-embedded
In-Reply-To: <931.1120150666@gerd>
Hi, Murray!
Hello, Jason!
Thank you very much! It seems like you saved my holiday! :-)))
I will have a look and see what I can find there.
Is there any interest to publish this and the other patches
and get it into 2.6 if not already planned?
Best regards,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Murray.Jensen@csiro.au wrote:
> On Thu, 30 Jun 2005 17:56:30 +0200, Clemens Koller writes:
>
>>But is there any code available for recycling?
>
>
> Jason McMullan has some code for mpc85xx dma here:
>
> http://www.evillabs.net/~gus/patches/mpc85xx_dma.patch
>
> Looks like it wouldn't take much to get it working. Cheers!
> Murray...
> --
> Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
> Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
> Internet: Murray.Jensen@csiro.au
>
> To the extent permitted by law, CSIRO does not represent, warrant and/or
> guarantee that the integrity of this communication has been maintained or
> that the communication is free of errors, virus, interception or interference.
>
> The information contained in this e-mail may be confidential or privileged.
> Any unauthorised use or disclosure is prohibited. If you have received this
> e-mail in error, please delete it immediately and notify Murray Jensen on
> +61 3 9662 7763. Thank you.
>
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Murray.Jensen @ 2005-07-01 8:36 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <42C4F6C4.1070908@anagramm.de>
On Fri, 01 Jul 2005 09:54:44 +0200, Clemens Koller writes:
>Is there any interest to publish this and the other patches
>and get it into 2.6 if not already planned?
Well, I'd certainly be interested. Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Kumar Gala @ 2005-07-01 13:59 UTC (permalink / raw)
To: Murray.Jensen; +Cc: linuxppc-embedded
In-Reply-To: <1835.1120206984@gerd>
Well, this goes back to my comment on there not being a set of
generic kernel APIs for general purpose DMA engines.
Otherwise, I'd rather leave this out of the kernel proper.
- kumar
On Jul 1, 2005, at 3:36 AM, <Murray.Jensen@csiro.au> wrote:
> On Fri, 01 Jul 2005 09:54:44 +0200, Clemens Koller writes:
>
>> Is there any interest to publish this and the other patches
>> and get it into 2.6 if not already planned?
>>
>
> Well, I'd certainly be interested. Cheers!
>
> Murray...
> --
> Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3
> 9662
> 7763
> Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3
> 9662
> 7853
> Internet: Murray.Jensen@csiro.au
>
> To the extent permitted by law, CSIRO does not represent, warrant
> and/or
> guarantee that the integrity of this communication has been maintained
> or
> that the communication is free of errors, virus, interception or
> interference.
>
> The information contained in this e-mail may be confidential or
> privileged.
> Any unauthorised use or disclosure is prohibited. If you have received
> this
> e-mail in error, please delete it immediately and notify Murray Jensen
> on
> +61 3 9662 7763. Thank you.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Dan Malek @ 2005-07-01 14:02 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <42C4F50D.3050405@anagramm.de>
On Jul 1, 2005, at 3:47 AM, Clemens Koller wrote:
> .... And currently, when I access (memcopy) the SRAM on my
> Local Bus via UPM I cannot get it to generate bursts yet, so I hope the
> DMA will speed up those things, too.
If the CPU won't do it, the DMA won't either. You better get that
UPM working first :-)
-- Dan
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Mark Chambers @ 2005-07-01 14:15 UTC (permalink / raw)
To: Dan Malek, Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <d946affc11510f7116710026d2a8d1f3@embeddededge.com>
>
> On Jul 1, 2005, at 3:47 AM, Clemens Koller wrote:
>
> > .... And currently, when I access (memcopy) the SRAM on my
> > Local Bus via UPM I cannot get it to generate bursts yet, so I hope the
> > DMA will speed up those things, too.
>
> If the CPU won't do it, the DMA won't either. You better get that
> UPM working first :-)
>
>
> -- Dan
>
Is the SRAM being cached? I don't think the CPU will generate bursts
unless it's cached, right?
Mark Chambers
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Marcelo Tosatti @ 2005-07-01 9:44 UTC (permalink / raw)
To: Anton Wöllert; +Cc: linux-ppc-embedded
In-Reply-To: <faba7798050630071347d4ad63@mail.gmail.com>
Hi Anton,
(moving to ppc-embedded since it might be of interesting for other=20
8xx users)
On Thu, Jun 30, 2005 at 04:13:30PM +0200, Anton W=F6llert wrote:
> Hello Marcelo
>=20
> I suggest you should find out why binaries hang and where.
> >=20
> > You can see where processes are sleeping with:
> >=20
> > ps -axeo "command nwchan"
> >=20
>=20
> thank you for that tip. but i found out (what i should have had to do=20
> before), that the application doesn't hang in kernel-mode. so wchan doe=
sn't=20
> say anything. but with gdb i saw the problem, the application hangs in =
the=20
> function memset at the instruction dcbz, this should be a instruction, =
that=20
> loops until it something is zero or so ( sorry, that i didn't looked up=
it=20
> yet, i will do that ). and because of the bug of these dcbx instruction=
s on=20
> 8xx i think, that this is the cause. here my gdb-session, i hope you ma=
y=20
> find it helpful or give me an advise how to fix that :
>=20
> awoeller@zwiebel
> :~/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/busybox-1.00$po=
werpc-linux-gdb
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and yo=
u are
> welcome to change it and/or distribute copies of it under certain=20
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for detai=
ls.
> This GDB was configured as "--host=3Di686-linux --target=3Dpowerpc-linu=
x".
> (gdb) set solib-absolute-prefix /tmp/fakelibc=20
> (gdb) file busybox
> Reading symbols from=20
> /home/awoeller/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/bus=
ybox-
> 1.00/busybox...done.
> (gdb) b main
> Breakpoint 1 at 0x1000398c: file=20
> /home/awoeller/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/bus=
ybox-
> 1.00/applets/busybox.c, line 75.
> (gdb) target remote tqm850l:123
> Remote debugging using tqm850l:123
> 0x300103f4 in ?? ()
> (gdb) cont
> Continuing.
> # here i interrupt, because it hangs
> Program received signal SIGINT, Interrupt.
> 0x30013e58 in ?? ()
> (gdb) return
> Make selected stack frame return now? (y or n) y
> #0 0x3000e374 in ?? ()
> (gdb) cont
> Continuing.
>=20
> Breakpoint 1, main (argc=3D1, argv=3D0x7ffffeb4) at=20
> /home/awoeller/ToolChains/new.usr.chain/powerpc-linux-toolchain/src/bus=
ybox-
> 1.00/applets/busybox.c:75
> 75 bb_applet_name =3D argv[0];
>=20
> (gdb) disas 0x30013e58
> Dump of assembler code for function memset:
> 0x30013ba4 <memset+0>: cmplwi cr1,r5,4
> 0x30013ba8 <memset+4>: andi. r7,r3,3
> 0x30013bac <memset+8>: mr r6,r3
> 0x30013bb0 <memset+12>: ble- cr1,0x30013d40 <memset+412>
> 0x30013bb4 <memset+16>: cmplwi cr5,r5,31
> 0x30013bb8 <memset+20>: rlwimi r4,r4,8,16,23
> 0x30013bbc <memset+24>: beq+ 0x30013be0 <memset+60>
> 0x30013bc0 <memset+28>: mtcrf 1,r3
> 0x30013bc4 <memset+32>: subfic r7,r7,4
> 0x30013bc8 <memset+36>: add r6,r6,r7
> 0x30013bcc <memset+40>: subf r5,r7,r5
> 0x30013bd0 <memset+44>: bns+ cr7,0x30013bdc <memset+56>
> 0x30013bd4 <memset+48>: stb r4,0(r3)
> 0x30013bd8 <memset+52>: beq- cr7,0x30013be0 <memset+60>
> 0x30013bdc <memset+56>: sth r4,-2(r6)
> 0x30013be0 <memset+60>: mtcrf 1,r5
> 0x30013be4 <memset+64>: rlwimi r4,r4,16,0,15
> 0x30013be8 <memset+68>: ble- cr5,0x30013d80 <memset+476>
> 0x30013bec <memset+72>: andi. r7,r6,28
> 0x30013bf0 <memset+76>: subfic r7,r7,32
> 0x30013bf4 <memset+80>: beq- 0x30013c34 <memset+144>
> 0x30013bf8 <memset+84>: mtcrf 1,r7
> 0x30013bfc <memset+88>: add r6,r6,r7
> 0x30013c00 <memset+92>: subf r5,r7,r5
> 0x30013c04 <memset+96>: cmplwi cr1,r7,16
> 0x30013c08 <memset+100>: mr r8,r6
> 0x30013c0c <memset+104>: bge- cr7,0x30013c18 <memset+116>
> 0x30013c10 <memset+108>: stw r4,-4(r8)
> 0x30013c14 <memset+112>: stwu r4,-8(r8)
> 0x30013c18 <memset+116>: blt- cr1,0x30013c2c <memset+136>
> 0x30013c1c <memset+120>: stw r4,-4(r8)
> 0x30013c20 <memset+124>: stw r4,-8(r8)
> 0x30013c24 <memset+128>: stw r4,-12(r8)
> 0x30013c28 <memset+132>: stwu r4,-16(r8)
> 0x30013c2c <memset+136>: ble- cr7,0x30013c34 <memset+144>
> 0x30013c30 <memset+140>: stw r4,-4(r8)
> 0x30013c34 <memset+144>: cmplwi cr1,r4,0
> 0x30013c38 <memset+148>: rlwinm. r7,r5,0,0,26
> 0x30013c3c <memset+152>: mtcrf 1,r5
> 0x30013c40 <memset+156>: beq- cr1,0x30013de0 <memset+572>
> 0x30013c44 <memset+160>: rlwinm r0,r7,27,5,31
> 0x30013c48 <memset+164>: mtctr r0
> 0x30013c4c <memset+168>: beq- 0x30013d80 <memset+476>
> 0x30013c50 <memset+172>: clrlwi. r5,r5,27
> 0x30013c54 <memset+176>: add r6,r6,r7
> 0x30013c58 <memset+180>: li r8,-64
> 0x30013c5c <memset+184>: bdz- 0x30013c90 <memset+236>
> 0x30013c60 <memset+188>: dcbtst r8,r6
> 0x30013c64 <memset+192>: stw r4,-4(r6)
> 0x30013c68 <memset+196>: stw r4,-8(r6)
> 0x30013c6c <memset+200>: stw r4,-12(r6)
> 0x30013c70 <memset+204>: stw r4,-16(r6)
> 0x30013c74 <memset+208>: nop
> 0x30013c78 <memset+212>: stw r4,-20(r6)
> 0x30013c7c <memset+216>: stw r4,-24(r6)
> 0x30013c80 <memset+220>: nop
> 0x30013c84 <memset+224>: stw r4,-28(r6)
> 0x30013c88 <memset+228>: stwu r4,-32(r6)
> 0x30013c8c <memset+232>: bdnz+ 0x30013c60 <memset+188>
> 0x30013c90 <memset+236>: stw r4,-4(r6)
> 0x30013c94 <memset+240>: stw r4,-8(r6)
> 0x30013c98 <memset+244>: stw r4,-12(r6)
> 0x30013c9c <memset+248>: stw r4,-16(r6)
> 0x30013ca0 <memset+252>: stw r4,-20(r6)
> 0x30013ca4 <memset+256>: cmplwi cr1,r5,16
> 0x30013ca8 <memset+260>: stw r4,-24(r6)
> 0x30013cac <memset+264>: stw r4,-28(r6)
> 0x30013cb0 <memset+268>: stwu r4,-32(r6)
> 0x30013cb4 <memset+272>: beqlr=20
> 0x30013cb8 <memset+276>: add r6,r6,r7
> 0x30013cbc <memset+280>: b 0x30013d84 <memset+480>
> 0x30013cc0 <memset+284>: nop
> 0x30013cc4 <memset+288>: clrlwi r5,r5,27
> 0x30013cc8 <memset+292>: mtcrf 2,r7
> 0x30013ccc <memset+296>: rlwinm. r0,r7,25,7,31
> ---Type <return> to continue, or q <return> to quit---=20
> 0x30013cd0 <memset+300>: mtctr r0
> 0x30013cd4 <memset+304>: li r7,32
> 0x30013cd8 <memset+308>: li r8,-64
> 0x30013cdc <memset+312>: cmplwi cr1,r5,16
> 0x30013ce0 <memset+316>: bne- cr6,0x30013cec <memset+328>
> 0x30013ce4 <memset+320>: dcbz r0,r6
> 0x30013ce8 <memset+324>: addi r6,r6,32
> 0x30013cec <memset+328>: li r9,-32
> 0x30013cf0 <memset+332>: ble- cr6,0x30013d00 <memset+348>
> 0x30013cf4 <memset+336>: dcbz r0,r6
> 0x30013cf8 <memset+340>: dcbz r7,r6
> 0x30013cfc <memset+344>: addi r6,r6,64
> 0x30013d00 <memset+348>: cmplwi cr5,r5,0
> 0x30013d04 <memset+352>: beq- 0x30013d80 <memset+476>
> 0x30013d08 <memset+356>: dcbz r0,r6
> 0x30013d0c <memset+360>: dcbz r7,r6
> 0x30013d10 <memset+364>: addi r6,r6,128
> 0x30013d14 <memset+368>: dcbz r8,r6
> 0x30013d18 <memset+372>: dcbz r9,r6
> 0x30013d1c <memset+376>: bdnz+ 0x30013d08 <memset+356>
> 0x30013d20 <memset+380>: beqlr cr5
> 0x30013d24 <memset+384>: b 0x30013d84 <memset+480>
> 0x30013d28 <memset+388>: nop
> 0x30013d2c <memset+392>: nop
> 0x30013d30 <memset+396>: nop
> 0x30013d34 <memset+400>: nop
> 0x30013d38 <memset+404>: nop
> 0x30013d3c <memset+408>: nop
> 0x30013d40 <memset+412>: cmplwi cr5,r5,1
> 0x30013d44 <memset+416>: cmplwi cr1,r5,3
> 0x30013d48 <memset+420>: bltlr cr5
> 0x30013d4c <memset+424>: stb r4,0(r6)
> 0x30013d50 <memset+428>: beqlr cr5
> 0x30013d54 <memset+432>: nop
> 0x30013d58 <memset+436>: stb r4,1(r6)
> 0x30013d5c <memset+440>: bltlr cr1
> 0x30013d60 <memset+444>: stb r4,2(r6)
> 0x30013d64 <memset+448>: beqlr cr1
> 0x30013d68 <memset+452>: nop
> 0x30013d6c <memset+456>: stb r4,3(r6)
> 0x30013d70 <memset+460>: blr
> 0x30013d74 <memset+464>: nop
> 0x30013d78 <memset+468>: nop
> 0x30013d7c <memset+472>: nop
> 0x30013d80 <memset+476>: cmplwi cr1,r5,16
> 0x30013d84 <memset+480>: add r6,r6,r5
> 0x30013d88 <memset+484>: bso- cr7,0x30013da8 <memset+516>
> 0x30013d8c <memset+488>: beq- cr7,0x30013db0 <memset+524>
> 0x30013d90 <memset+492>: bgt- cr7,0x30013db8 <memset+532>
> 0x30013d94 <memset+496>: bge- cr1,0x30013dc0 <memset+540>
> 0x30013d98 <memset+500>: bgelr cr7
> 0x30013d9c <memset+504>: stw r4,-4(r6)
> 0x30013da0 <memset+508>: stw r4,-8(r6)
> 0x30013da4 <memset+512>: blr
> 0x30013da8 <memset+516>: stbu r4,-1(r6)
> 0x30013dac <memset+520>: bne- cr7,0x30013d90 <memset+492>
> 0x30013db0 <memset+524>: sthu r4,-2(r6)
> 0x30013db4 <memset+528>: ble- cr7,0x30013d94 <memset+496>
> 0x30013db8 <memset+532>: stwu r4,-4(r6)
> 0x30013dbc <memset+536>: blt- cr1,0x30013dd0 <memset+556>
> 0x30013dc0 <memset+540>: stw r4,-4(r6)
> 0x30013dc4 <memset+544>: stw r4,-8(r6)
> 0x30013dc8 <memset+548>: stw r4,-12(r6)
> 0x30013dcc <memset+552>: stwu r4,-16(r6)
> 0x30013dd0 <memset+556>: bgelr cr7
> 0x30013dd4 <memset+560>: stw r4,-4(r6)
> 0x30013dd8 <memset+564>: stw r4,-8(r6)
> 0x30013ddc <memset+568>: blr
> 0x30013de0 <memset+572>: mflr r0
> 0x30013de4 <memset+576>: beq+ 0x30013d80 <memset+476>
> 0x30013de8 <memset+580>: bl 0x30029000 <_dl_auxv+180>
> 0x30013dec <memset+584>: mflr r9
> 0x30013df0 <memset+588>: lwz r9,1832(r9)
> 0x30013df4 <memset+592>: lwz r8,0(r9)
> 0x30013df8 <memset+596>: mtlr r0
> 0x30013dfc <memset+600>: cmplwi cr1,r8,0
> ---Type <return> to continue, or q <return> to quit---
> 0x30013e00 <memset+604>: beq+ cr1,0x30013c44 <memset+160>
> 0x30013e04 <memset+608>: cmplwi cr1,r8,32
> 0x30013e08 <memset+612>: beq+ cr1,0x30013cc4 <memset+288>
> 0x30013e0c <memset+616>: dcbtst r0,r6
> 0x30013e10 <memset+620>: addi r9,r8,-1
> 0x30013e14 <memset+624>: cmplwi cr1,r5,32
> 0x30013e18 <memset+628>: and. r0,r9,r6
> 0x30013e1c <memset+632>: blt- cr1,0x30013e68 <memset+708>
> 0x30013e20 <memset+636>: beq- 0x30013e50 <memset+684>
> 0x30013e24 <memset+640>: addi r6,r6,32
> 0x30013e28 <memset+644>: addi r5,r5,-32
> 0x30013e2c <memset+648>: stw r4,-32(r6)
> 0x30013e30 <memset+652>: stw r4,-28(r6)
> 0x30013e34 <memset+656>: stw r4,-24(r6)
> 0x30013e38 <memset+660>: stw r4,-20(r6)
> 0x30013e3c <memset+664>: stw r4,-16(r6)
> 0x30013e40 <memset+668>: stw r4,-12(r6)
> 0x30013e44 <memset+672>: stw r4,-8(r6)
> 0x30013e48 <memset+676>: stw r4,-4(r6)
> 0x30013e4c <memset+680>: b 0x30013e14 <memset+624>
> 0x30013e50 <memset+684>: cmplw cr1,r5,r8
> 0x30013e54 <memset+688>: blt- cr1,0x30013e68 <memset+708>
>=20
>=20
> 0x30013e58 <memset+692>: dcbz r0,r6 #<--- the problem
>=20
>=20
> 0x30013e5c <memset+696>: subf r5,r8,r5
> 0x30013e60 <memset+700>: add r6,r6,r8
> 0x30013e64 <memset+704>: b 0x30013e50 <memset+684>
> 0x30013e68 <memset+708>: rlwinm. r7,r5,0,0,26
> 0x30013e6c <memset+712>: b 0x30013c44 <memset+160>
> 0x30013e70 <memset+716>: nop
> 0x30013e74 <memset+720>: nop
> 0x30013e78 <memset+724>: nop
> 0x30013e7c <memset+728>: nop
Can you please examine in more detail what is going on here?=20
What are the contents of the r0 and r6 registers, where exactly is the
task stopped.
I _guess_ it might be some form of "dcbz" misbehaviour, in such case I=20
imagine that either the task would loop forever or execute an invalid
exception/instruction.
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Jason McMullan @ 2005-07-01 14:55 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Anton Wöllert, linux-ppc-embedded
In-Reply-To: <20050701094438.GA11121@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Fri, 2005-07-01 at 06:44 -0300, Marcelo Tosatti wrote:
> Hi Anton,
>
>
> (moving to ppc-embedded since it might be of interesting for other
> 8xx users)
>
Apply this patch to glibc, and recompile:
rm -f glibc/sysdeps/powerpc/powerpc32/memset.S
The PPC32 dbcz semantics don't seem to work properly on 8xx
in all cases. Removing the '.S' file makes glibc fall back on
the .c implementation.
--
Jason McMullan <jason.mcmullan@gmail.com>
"Sure, send me the latest Knoppix DVD as an attachment..."
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Marcelo Tosatti @ 2005-07-01 10:17 UTC (permalink / raw)
To: Jason McMullan; +Cc: Anton Wöllert, linux-ppc-embedded
In-Reply-To: <1120229717.21507.9.camel@jmcmullan.timesys>
On Fri, Jul 01, 2005 at 10:55:16AM -0400, Jason McMullan wrote:
> On Fri, 2005-07-01 at 06:44 -0300, Marcelo Tosatti wrote:
> > Hi Anton,
> >
> >
> > (moving to ppc-embedded since it might be of interesting for other
> > 8xx users)
> >
>
> Apply this patch to glibc, and recompile:
>
> rm -f glibc/sysdeps/powerpc/powerpc32/memset.S
>
>
> The PPC32 dbcz semantics don't seem to work properly on 8xx
> in all cases. Removing the '.S' file makes glibc fall back on
> the .c implementation.
Hi Jason,
That was a quick response - thanks.
Two questions:
- Do you happen to know about details of dcbz's (mis)behaviour on 8xx?
I ask that mainly because I worry about in-kernel dcbz users.
- Shouldnt upstream glibc have that fixed for 8xx by now?
^ permalink raw reply
* [PATCH] ppc32: explicitly disable 440GP IRQ compatibility mode in 440GX setup
From: Eugene Surovegin @ 2005-07-01 17:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Andrew,
the following patch adds explicit disabling of 440GP IRQ compatibility
mode when configuring 440GX interrupt controller. This helps when
board firmware for some reason uses this compatibility mode and
leaves it enabled. It breaks 440GX interrupt code because it assumes
native 440GX IRQ mode. People seems to be continuously bitten by this.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/arch/ppc/syslib/ppc4xx_pic.c b/arch/ppc/syslib/ppc4xx_pic.c
--- a/arch/ppc/syslib/ppc4xx_pic.c
+++ b/arch/ppc/syslib/ppc4xx_pic.c
@@ -110,6 +110,10 @@ static int ppc4xx_pic_get_irq(struct pt_
static void __init ppc4xx_pic_impl_init(void)
{
+#if defined(CONFIG_440GX)
+ /* Disable 440GP compatibility mode if it was enabled in firmware */
+ SDR_WRITE(DCRN_SDR_MFR, SDR_READ(DCRN_SDR_MFR) & ~DCRN_SDR_MFR_PCM);
+#endif
/* Configure Base UIC */
mtdcr(DCRN_UIC_CR(UICB), 0);
mtdcr(DCRN_UIC_TR(UICB), 0);
^ permalink raw reply
* Re: PPC bn_div_words routine rewrite
From: Andy Polyakov @ 2005-07-01 17:36 UTC (permalink / raw)
To: openssl-dev; +Cc: linuxppc-embedded
In-Reply-To: <4dd15d1805063015226379a52c@mail.gmail.com>
> The reason I had to redo this routine, in case anyone is wondering, is
> because ssh-keygen segfaults when this assembly routine returns junk
> to the BN_div_word function. On a ppc, if you issue the command
>
> ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
>
> The program craps out when it tries to write the public key in ascii decimal.
If would help if you provide evidence such as debugger stack trace and
program output. Provided description makes no sense. "seg-faults when
routine returns junk to BN_div_word"? Seg-fault [segmentation violation]
can occur when you write something to memory and nothing gets written to
memory upon result return. BN_div_word does write to memory, but I fail
to see how a bogus value could possibly trigger seg-fault. The only
possibility is that assembler doesn't follow ABI convention and corrupts
registers, which caller is using/expects to be preserved by callee.
There're several PPC ABI flavors in use, but OpenSSL routines were
designed ABI-neutral, Well, "neutrality" really means "common
denominator for ABI specs examined at the moment of coding," so there is
a window of opportunity that it won't be "neutral" to future ABI, but is
it really case? That your system uses some newly designed PPC ABI? You
never mentioned what's your system...
But you're apparently right about a bug being present in PPC assembler.
I too have got insane [with very few significant digits] decimal
printout of public key generated by ssh-keygen...
>>This is a rewrite of the bn_div_words routine for the PowerPC arch,
>>tested on a MPC8xx processor.
Well, suggested routine apparently sends ssh-keygen on the PPC-based
32-bit system I have access to to an end-less loop... And (cd test; make
test_bn) fails early in BN_sqr... And test/exptest fails miserably with
"bad reciprocal"...
>>I initially thought there is maybe a small mistake in the code that
>>requires a one-liner change
But apparently this appears to be the case! Please verify following:
--- crypto/bn/asm/ppc.pl.orig 2004-04-28 00:05:50.000000000 +0200
+++ crypto/bn/asm/ppc.pl 2005-07-01 18:58:21.105656512 +0200
@@ -1717,7 +1717,7 @@
li r9,1 # r9=1
$SHL r10,r9,r8 # r9<<=r8
$UCMP 0,r3,r10 #
- bc BO_IF,CR0_GT,Lppcasm_div2 #or if (h > (1<<r8))
+ bc BO_IF_NOT,CR0_GT,Lppcasm_div2 #or if (h > (1<<r8))
$UDIV r3,r3,r0 #if not assert(0) divide by 0!
#that's how we signal overflow
bclr BO_ALWAYS,CR0_LT #return. NEVER REACHED.
A.
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Jason McMullan @ 2005-07-01 18:56 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Anton Wöllert, linux-ppc-embedded
In-Reply-To: <20050701101713.GC11121@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
On Fri, 2005-07-01 at 07:17 -0300, Marcelo Tosatti wrote:
> That was a quick response - thanks.
>
> Two questions:
>
> - Do you happen to know about details of dcbz's (mis)behaviour on 8xx?
>
> I ask that mainly because I worry about in-kernel dcbz users.
IIRC, it isn't used in any 8xx code paths.
> - Shouldnt upstream glibc have that fixed for 8xx by now?
Ha. Funny. The glibc powerpc maintainer doesn't want any embedded
fixes in the mainline. Last I checked, that was for 'the tools
vendors' to fix.
"We won't work around processor bugs" is their philosophy.
I went through a similar (unsuccessful) battle with the
amcc 440ep's "blrl" errata and gcc/glibc.
It would be nice if the politics there have changed
(maybe they just didn't like me personally), but I don't have
much hope.
--
Jason McMullan <jason.mcmullan@gmail.com>
"Sure, send me the latest Knoppix DVD as an attachment..."
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Marcelo Tosatti @ 2005-07-01 14:42 UTC (permalink / raw)
To: Jason McMullan; +Cc: Anton Wöllert, linux-ppc-embedded
In-Reply-To: <1120244191.18872.3.camel@jmcmullan.timesys>
On Fri, Jul 01, 2005 at 02:56:30PM -0400, Jason McMullan wrote:
> On Fri, 2005-07-01 at 07:17 -0300, Marcelo Tosatti wrote:
> > That was a quick response - thanks.
> >
> > Two questions:
> >
> > - Do you happen to know about details of dcbz's (mis)behaviour on 8xx?
> >
> > I ask that mainly because I worry about in-kernel dcbz users.
>
> IIRC, it isn't used in any 8xx code paths.
OK!
> > - Shouldnt upstream glibc have that fixed for 8xx by now?
>
> Ha. Funny. The glibc powerpc maintainer doesn't want any embedded
> fixes in the mainline.
Who is that?
> Last I checked, that was for 'the tools vendors' to fix.
Silly - so embedded developers are supposed rely on "embedded vendors"
and not on the mainstream software distributions?
> "We won't work around processor bugs" is their philosophy.
>
> I went through a similar (unsuccessful) battle with the
> amcc 440ep's "blrl" errata and gcc/glibc.
>
> It would be nice if the politics there have changed
> (maybe they just didn't like me personally), but I don't have
> much hope.
If enough people complain they will, hopefully, listen.
^ permalink raw reply
* mpc8xx and ld.so problem
From: Tjernlund @ 2005-07-01 18:40 UTC (permalink / raw)
To: linuxppc-embedded
> > The PPC32 dbcz semantics don't seem to work properly on 8xx
> > in all cases. Removing the '.S' file makes glibc fall back on
> > the .c implementation.
>
> Hi Jason,
>
> That was a quick response - thanks.
>
> Two questions:
>
> - Do you happen to know about details of dcbz's (mis)behaviour on 8xx?
This is the famus dcbX bug on 8xx CPUs. 8xx dcbX instructions don't update the
DAR register when they cause a TLB Miss/Error. This bug is undocumented but
Motorola/Freescale has verified that it is there.
Jocke (going on vacation now, won't read email for a week)
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Dan Malek @ 2005-07-01 21:49 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <004001c57e47$5cae9410$0301a8c0@chuck2>
On Jul 1, 2005, at 10:15 AM, Mark Chambers wrote:
> Is the SRAM being cached? I don't think the CPU will generate bursts
> unless it's cached, right?
I don't really remember :-) I know the 8xx will not burst if the line
isn't
cached, and I know the 7xxx will. I thought the 82xx and 85xx would
also burst if you had sufficient sequential operations queued. On
83/85xx you have to further qualify the discussion based upon the DDR2
or the local bus interface :-) The CPM and DMA will burst on all
buses for 8xx/82xx/83xx/85xx if the memory controller is configured
to do so.
I always end up writing code to test it, then those brain cells get
replaced by more meaningful experiences before I have to use
them again :-)
Thanks.
-- Dan
^ permalink raw reply
* ºô¸ô¶}©±Àu´f¤è®×¡I ¦n§·m¥ý³ø¡I
From: ¼w«aºô¸ô @ 2005-07-03 5:13 UTC (permalink / raw)
To: linuxer, linuxppc-embedded, linxda, linz, lin-chih, lin.tm
[-- Attachment #1: Type: text/html, Size: 3897 bytes --]
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Anton Wöllert @ 2005-07-03 16:01 UTC (permalink / raw)
To: Marcelo Tosatti, linuxppc-embedded
In-Reply-To: <20050701094438.GA11121@logos.cnet>
Marcelo Tosatti wrote:
> Hi Anton,
>
>
> (moving to ppc-embedded since it might be of interesting for other
> 8xx users)
>
> On Thu, Jun 30, 2005 at 04:13:30PM +0200, Anton Wöllert wrote:
>
>
> Can you please examine in more detail what is going on here?
>
> What are the contents of the r0 and r6 registers, where exactly is the
> task stopped.
with backtrace in gdb i found out, that memset() (which is exactly the
routine at sysdeps/powerpc/powerpc32/memset.S) called by
_dl_allocate_tls_storage (sysdeps/generic/dl-tls.c). btw. memset is
called 3 times before and there it works fine.
well, _dl_allocate_tls_storage invokes __libc_memalign
(elf/dl-minimal.c). __libc_memalign should return an aligned area of
memory for the tls-stuff (which later then will be memset'd with zero).
__libc_memalign now allocates an aligned memory block, but first looks
if there is unused space in the previous page of its data-segment. if
there is some, it will use that. if more than this is needed, it will
call mmap with MAP_ANON|MAP_PRIVATE and PROT_READ|PROT_WRITE. it then
looks, if the returned address lies at the end of the old page, if not,
the old one will not be used (because then it wouldn't return an
continuegous area of memory). will gdb, i saw, that mmap returns a
address right after the previous page and so the block continuegous.
this block is now returned and given to memset.
memset now zeros out a part of the returned block. as long, as dcbz
zeros out the memory, that lies in the old page (before 0x30001000) it
works, but when it steps over that address (the page boundary), stepi in
gdb just hangs and doesn't return anything ( except i press ctrl-c ).
i think, dcbz should cause a page fault, because the new page was
allocated with PROT_READ|PROT_WRITE. i expect, that there is no handling
for dcbz's in the page fault handler (which should be do_page_fault in
arch/ppc/kernel/fault.c if i'm right).
other possibilities, like false cache_line_size etc should explain that,
because they are all set right (with gdb i inspected nearly
everything, and memset should work as expected, and it does so in other
scenarios).
sorry for not delivering the registers and so on, but actually i have no
access to the board for one week :). i will post them later, if really
needed, but throug my gdb-sessions, they seemed all to be right.
>
> I _guess_ it might be some form of "dcbz" misbehaviour, in such case I
> imagine that either the task would loop forever or execute an invalid
> exception/instruction.
>
so what should be the real solution, deleting memset.S because the use
of dcbz is not allowed or eventually fix the page-fault handler, because
he didn't recognize dcbz's (if i'm right).
thanks for your help, anton
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Olaf Hering @ 2005-07-03 17:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, trini
In-Reply-To: <17016.29775.224816.691409@cargo.ozlabs.ibm.com>
On Wed, May 04, Paul Mackeras wrote:
> What do people think of this patch? The motivation for it is that a
> biarch gcc-4.0 will by default tune for POWER4, even for a 32-bit
> compile, meaning that we end up with a lot of nops we don't need.
> This also takes out -mstring.
>
> With this, the text size reduces by about 120k for my normal config
> when compiling with a biarch gcc-4.0. The text size also reduces
> slightly when compiling with the Debian gcc-3.3.5 (32-bit only, not
> biarch).
>
> If there are no objections I'll send this to Andrew and Linus.
What will be done about this patch? -mcpu=750 reduces .text by 70k.
text data bss dec hex filename
3397801 579544 519704 4497049 449e99 ../O-ppc-cpu601/vmlinux
3397502 579544 519704 4496750 449d6e ../O-ppc-cpu604/vmlinux
3397953 579544 519704 4497201 449f31 ../O-ppc-cpu750/vmlinux
3469857 579544 519704 4569105 45b811 ../O-ppc-default/vmlinux
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Tom Rini @ 2005-07-03 18:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20050703172955.GA25976@suse.de>
On Sun, Jul 03, 2005 at 07:29:55PM +0200, Olaf Hering wrote:
> On Wed, May 04, Paul Mackeras wrote:
>
> > What do people think of this patch? The motivation for it is that a
> > biarch gcc-4.0 will by default tune for POWER4, even for a 32-bit
> > compile, meaning that we end up with a lot of nops we don't need.
> > This also takes out -mstring.
> >
> > With this, the text size reduces by about 120k for my normal config
> > when compiling with a biarch gcc-4.0. The text size also reduces
> > slightly when compiling with the Debian gcc-3.3.5 (32-bit only, not
> > biarch).
> >
> > If there are no objections I'll send this to Andrew and Linus.
>
> What will be done about this patch? -mcpu=750 reduces .text by 70k.
The fix for the real problem is now in. Perhaps, based off gcc's info
page, we should update (from what 2.6.12 looks like) to do:
cpu-as-y = -Wa,-mcpu=powerpc # Pure ppc32
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
cpu-as-$(CONFIG_PPC_601) := -Wa,-mcpu=601 # Or whatever the 601 option is
cpu-as-$(CONFIG_PPC64BRIDGE) := -Wa,mcpu=powerpc64
< add 4xx/BookE here >
And see what we get. I really don't think we should fall into the i386
ugly trap of i386/i486/i586/i586tsc/... 20 other options ..., esp since
it looks like the main win is switching from 100% generic powerpc to
something more specific. And going with the generic name means if gcc
starts doing something different on 750 vs 7400 vs 604, we win.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* linux ppc 405 boot problem using nfs.
From: vinod b @ 2005-07-04 8:19 UTC (permalink / raw)
To: linuxppc-embedded, ebs, rcblach, samlinuxppc
Iam trying to boot linux on Powerpc405GP board(walnut).
When i do it using ram disk concept.I do not have any problem.
But when i mount file system from the remote system i have problem.
can any one help me..........
I am sending the minicom out put of both using ram disk concept anf
nfs mounting.
Can any body tell if there is any problem in the walnut board in
sending packets...................
This output is in the case of using nfs to mount the file system .
=20
Welcome to minicom 2.1
OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Jun 15 2003, 14:35:38.
Press CTRL-A Z for help on special keys
405GP 1.13 ROM Monitor (4/7/00)
--------------------- System Info ----------------------
Processor =3D 405GP, PVR: 40110082
Processor speed =3D 200 MHz
PLB speed =3D 100 MHz
OPB speed =3D 50 MHz
Ext Bus speed =3D 50 MHz
PCI Bus speed =3D 33 MHz (Sync)
Amount of SDRAM =3D 32 MBytes
Internal PCI arbiter enabled
--------------------------------------------------------
--- Device Configuration ---
Power-On Test Devices:
000 Disabled System Memory [RAM]
001 Disabled Ethernet [ENET]
004 Disabled Serial Port 2 [S2]
----------------------------
Boot Sources:
001 Enabled Ethernet [ENET]
local=3D192.0.1.253 remote=3D192.0.1.53 hwaddr=3D0004ac=
e30f38
004 Disabled Serial Port 2 [S2]
local=3D192.0.1.253 remote=3D192.0.1.50 hwaddr=3Dffffff=
ffffff
005 Disabled Serial Port 1 [S1]
Baud =3D 9600
----------------------------
Debugger: Disabled
----------------------------
1 - Enable/disable tests
2 - Enable/disable boot devices
3 - Change IP addresses
4 - Ping test
5 - Toggle ROM monitor debugger
6 - Toggle automatic menu
7 - Display configuration
8 - Save changes to configuration
9 - Set baud rate for s1 boot
A - Enable/disable I cache (Enabled )
B - Enable/disable D cache (Enabled )
0 - Exit menu and continue
->0
ENET Speed is 100 Mbs...
FULL duplex connection
Booting from [ENET] Ethernet ...
Sending bootp request ...
Loading file "/tftpboot/zImage.treeboot" ...
Sending tftp boot request ...
Transfer Complete ...
Loaded successfully ...
Entry point at 0x500000 ...
loaded at: 00500000 0059E1F8
relocated to: 00400000 0049E1F8
board data at: 0049B128 0049B168
relocated to: 004054AC 004054EC
zimage at: 004059E8 0049ABCB
avail ram: 0049F000 02000000
Linux/PPC load: console=3DttyS0,9600 root=3D/dev/nfs rw ip=3Don init=3D/bin=
/bash
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.18_mvl30-405ep_eval (root@Aum-Sai) (gcc version
3.2.1 20020930 (Mon5
IBM Walnut (IBM405GP) Platform
Port by MontaVista Software, Inc. (source@mvista.com)
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3DttyS0,9600 root=3D/dev/nfs rw ip=3Don init=
=3D/bin/bash
Calibrating delay loop... 199.47 BogoMIPS
Memory: 30788k available (1024k kernel code, 344k data, 72k init, 0k highme=
m)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
OCP uart ver 1.2.1 init complete
Starting kswapd
Disabling the Out Of Memory Killer
i2c-core.o: i2c core module version 2.6.2 (20011118)
initialize_kbd: Keyboard reset failed, no ACK
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0xef600300 (irq =3D 0) is a 16550A
ttyS01 at 0xef600400 (irq =3D 1) is a 16550A
block: 64 slots per queue, batch=3D16
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Phy @ 0x1, type DP83843 (0x20005c10)
Reset ethernet interfaces
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
opening eth0 on emac 0
eth0: IBM EMAC: link up, 100 Mbps Full Duplex, auto-negotiation complete.
eth0: IBM EMAC: MAC 00:04:ac:e3:0f:38.
eth0: IBM EMAC: open completed
Sending BOOTP and RARP requests . OK
IP-Config: Got BOOTP answer from 192.0.1.53, my address is 192.0.1.253
IP-Config: Complete:
device=3Deth0, addr=3D192.0.1.253, mask=3D255.255.255.0, gw=3D255.255=
.255.255,
host=3D192.0.1.253, domain=3D, nis-domain=3D(none),
bootserver=3D192.0.1.53, rootserver=3D192.0.1.53, rootpath=3D/home/wal=
nut/target
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.0.1.53
Looking up port of RPC 100005/1 on 192.0.1.53
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 72k init
nfs server: 192.0.1.53 not responding, still trying ...
nfs server: 192.0.1.53 ok
nfs server: 192.0.1.53 not responding, still trying ...
nfs server: 192.0.1.53 ok
Now the out put when file system is used as ram disk........
=20
405GP 1.13 ROM Monitor (4/7/00)
--------------------- System Info ----------------------
Processor =3D 405GP, PVR: 40110082
Processor speed =3D 200 MHz
PLB speed =3D 100 MHz
OPB speed =3D 50 MHz
Ext Bus speed =3D 50 MHz
PCI Bus speed =3D 33 MHz (Sync)
Amount of SDRAM =3D 32 MBytes
Internal PCI arbiter enabled
--------------------------------------------------------
--- Device Configuration ---
Power-On Test Devices:
000 Disabled System Memory [RAM]
001 Disabled Ethernet [ENET]
004 Disabled Serial Port 2 [S2]
----------------------------
Boot Sources:
001 Enabled Ethernet [ENET]
local=3D192.0.1.253 remote=3D192.0.1.50 hwaddr=3D0004ac=
e30f38
004 Disabled Serial Port 2 [S2]
local=3D192.0.1.253 remote=3D192.0.1.50 hwaddr=3Dffffff=
ffffff
005 Disabled Serial Port 1 [S1]
Baud =3D 9600
----------------------------
Debugger: Disabled
----------------------------
1 - Enable/disable tests
2 - Enable/disable boot devices
3 - Change IP addresses
4 - Ping test
5 - Toggle ROM monitor debugger
6 - Toggle automatic menu
7 - Display configuration
8 - Save changes to configuration
9 - Set baud rate for s1 boot
A - Enable/disable I cache (Enabled )
B - Enable/disable D cache (Enabled )
0 - Exit menu and continue
->0
ENET Speed is 100 Mbs...
FULL duplex connection
Booting from [ENET] Ethernet ...
Sending bootp request ...
Loading file "/tftpboot/zImage.treeboot" ...
Sending tftp boot request ...
Transfer Complete ...
Loaded successfully ...
Entry point at 0x500000 ...
loaded at: 00500000 007E51F8
relocated to: 00400000 006E51F8
board data at: 006E2128 006E2168
relocated to: 004054A0 004054E0
zimage at: 004059DC 0049AA0C
initrd at: 0049B000 006E1B21
avail ram: 006E6000 02000000
Linux/PPC load: console=3DttyS0,9600 root=3D/dev/ram init=3D/bin/bash
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.18_mvl30-405ep_eval (root@Aum-Sai) (gcc version
3.2.1 20020930 (MontaVista)) #1 Fri Jun 24 11:19:36 IST 5
IBM Walnut (IBM405GP) Platform
Port by MontaVista Software, Inc. (source@mvista.com)
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3DttyS0,9600 root=3D/dev/ram init=3D/bin/bash
Calibrating delay loop... 199.47 BogoMIPS
Memory: 28456k available (1024k kernel code, 344k data, 72k init, 0k highme=
m)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
OCP uart ver 1.2.1 init complete
Starting kswapd
Disabling the Out Of Memory Killer
i2c-core.o: i2c core module version 2.6.2 (20011118)
initialize_kbd: Keyboard reset failed, no ACK
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0xef600300 (irq =3D 0) is a 16550A
ttyS01 at 0xef600400 (irq =3D 1) is a 16550A
block: 64 slots per queue, batch=3D16
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Phy @ 0x1, type DP83843 (0x20005c10)
Reset ethernet interfaces
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
opening eth0 on emac 0
eth0: IBM EMAC: link up, 100 Mbps Full Duplex, auto-negotiation complete.
eth0: IBM EMAC: MAC 00:04:ac:e3:0f:38.
eth0: IBM EMAC: open completed
Sending BOOTP and RARP requests . OK
IP-Config: Got BOOTP answer from 192.0.1.53, my address is 192.0.1.253
IP-Config: Complete:
device=3Deth0, addr=3D192.0.1.253, mask=3D255.255.255.0, gw=3D255.255=
.255.255,
host=3D192.0.1.253, domain=3D, nis-domain=3D(none),
bootserver=3D192.0.1.53, rootserver=3D192.0.1.53, rootpath=3D/home/wal=
nut/target
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 2330k freed
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 72k init
init-2.04# ls
=20
--=20
vinod
S.S.S.I.H.L
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Yuli Barcohen @ 2005-07-04 8:22 UTC (permalink / raw)
To: Jason McMullan; +Cc: linux-ppc-embedded
In-Reply-To: <1120244191.18872.3.camel@jmcmullan.timesys>
>>>>> Jason McMullan writes:
[...deleted...]
Jason> Ha. Funny. The glibc powerpc maintainer doesn't want any
Jason> embedded fixes in the mainline. Last I checked, that was for
Jason> 'the tools vendors' to fix.
Jason> "We won't work around processor bugs" is their philosophy.
[...deleted...]
I investigated the problem a bit when I had trouble with a self-compiled
glibc a year or so ago. IIRC, I found bug in the memset code, not in the
chip. The code was just wrong for cache line sizes not equal to 32. So
memset.S is good for 60x series (PQII included) but for 8xx it fails. We
use dcbX instructions in some kernel drivers and since we never had any
problems with those drivers I'm a bit surprised to hear that all 8xx
chips have got that bug.
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Clemens Koller @ 2005-07-04 9:03 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <d67d2bddad7bf2be742b8d53768482bf@embeddededge.com>
Hi, Dan and Mark!
Dan Malek wrote:
> On Jul 1, 2005, at 10:15 AM, Mark Chambers wrote:
>
>> Is the SRAM being cached? I don't think the CPU will generate bursts
>> unless it's cached, right?
>
> I don't really remember :-) I know the 8xx will not burst if the line
> isn't
> cached, and I know the 7xxx will. I thought the 82xx and 85xx would
> also burst if you had sufficient sequential operations queued. On
> 83/85xx you have to further qualify the discussion based upon the DDR2
> or the local bus interface :-) The CPM and DMA will burst on all
> buses for 8xx/82xx/83xx/85xx if the memory controller is configured
> to do so.
Thanks, for your comments! I'll have a look at it during the
next days and let you know about my mileage :-)
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* mpc5200 i2c bus problem
From: Frederic Janot @ 2005-07-04 9:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I send a message here to indicate an hardware problem with mpc5200 i2c
module. This bug is not describe in the mpc5200 errata document.
I can reproduce it on revA and revB of the silicium. After contacting
Freescale, they recognize the problem.
The problem is that, sometime, the 9th pulse clock on SCL is missing !!!!
I can send a scope screen capture which shows that if someone wants.
When it happens, the slave does not release SDA bus because it waits to send
its acknowledge
=> the bus is locked (we cannot get slave status and we cannot generate stop
condition to release the bus)
The problem appears more frequently with IPB clock at 132MHz than with IPB
clock at 66MHz (looks like a timing problem into i2c module)
Freescale advice to set i2c clock at 86 kHz but the problem still appears
with my board !
I used a kernel based on Denk's one (2.4.25). The i2c driver call
wait_for_bb (bus busy) with a timeout. When the bus is locked, this function
always return with an error code => no more i2c transferts possible.
To workaround this problem, the solution is to "manually" generate the 9th
pulse clock.
The sequence is the following :
mcr = 0x00 (disable i2c module)
mcr = 0x80 (re-enable i2c module)
mcr = 0x30 (re-disabling i2c bus, it makes SCL goes high) => not
really sure if we should send 0x30 or if 0x00 is enough, I will try
mcr = 0xb0 (generate a start condition, it makes SCL goes low)
mcr = 0x80 (generate a stop condition, it makes SCL goes high)
After that, the bus is available again.
We have to re-send last i2c transfert (the one which locked the bus) because
we can not be sure that slave well understand the i2c request.
Hope it can help,
Frederic
^ permalink raw reply
* AW: AW: AW: AW: compact flash
From: somshekar kadam @ 2005-07-04 12:33 UTC (permalink / raw)
To: linuxppc-embedded
hi Alex ,
I was just going throught compact flash driver on
linnux , i dont know wether u remeber me i had got my
Compact flash driver working with ur help .
go through this link in ur free time
http://ozlabs.org/pipermail/linuxppc-embedded/2003-October/012292.html
i had one question , 2 yrs back i had kingston compact
flash which is slow , now i have 20x sandisk , then
performance should increase of read and write to
compact flash. This is not happeneing , can u please
suggest where could i be going wrong or else what
should i be looking at
Thanks And Regards
Somshekar
_______________________________________________________
Too much spam in your inbox? Yahoo! Mail gives you the best spam protection for FREE! http://in.mail.yahoo.com
^ permalink raw reply
* Re: PPC bn_div_words routine rewrite
From: David Ho @ 2005-07-04 14:35 UTC (permalink / raw)
To: openssl-dev; +Cc: linuxppc-embedded
In-Reply-To: <42C57F30.902@fy.chalmers.se>
[-- Attachment #1: Type: text/plain, Size: 5108 bytes --]
Good morning gentleman,
Let's start the week off with less hostility and more productive
criticism on this topic. As I see it, the popular Linux distributions
are not that interested on ppc32 since neither Novell nor Redhat
openly support this arch. We will have to put our heads together to
make ppc32 a stable Linux platform.
On 7/1/05, Andy Polyakov <appro@fy.chalmers.se> wrote:
> BN_div_word does write to memory, but I fail
> to see how a bogus value could possibly trigger seg-fault.
Assuming that you are a maintainer of the openssl code, which I gather
you are, would you even care to take the time to examine the code in
suspect, or find someone who is capable of doing that, I'm sure you
must have a lot of friends, at least one who is knowledgeable in the
ppc32 arch.
> The only
> possibility is that assembler doesn't follow ABI convention and corrupts
> registers, which caller is using/expects to be preserved by callee.
> There're several PPC ABI flavors in use, but OpenSSL routines were
> designed ABI-neutral, Well, "neutrality" really means "common
> denominator for ABI specs examined at the moment of coding," so there is
> a window of opportunity that it won't be "neutral" to future ABI, but is
> it really case?
I don't understand the terminology you use here. As I understand it
ABI is there so binaries can inter-operate in the case of dynamic
loading, when the ABI is consistent you can use any compiler that
conforms to the ABI and those binaries can work together. As I see it
I'm building openssl and openssh with the same compiler so what is the
real issue here? Or is it an issue at all?
If you are referring to C calling convention, then I can only guess
you have figured it out or otherwise none of the assembly routine will
work.
> That your system uses some newly designed PPC ABI? You
> never mentioned what's your system...
In my very first email, I have already said quote "tested on a MPC8xx
processor" and I am using 2.4.24 which is nothing close to the
bleeding edge so I reckon the ABI is fairly standard.
Do you have any experience with the PowerPC arch?
> But you're apparently right about a bug being present in PPC assembler.
So you are saying there is a bug in the GCC assembler? How confident
are you in that? Is the first correct step to examine the assembly
code for errors before jumping to any conclusion that the GCC
assembler is bad?
> >>This is a rewrite of the bn_div_words routine for the PowerPC arch,
> >>tested on a MPC8xx processor.
>
> Well, suggested routine apparently sends ssh-keygen on the PPC-based
> 32-bit system I have access to to an end-less loop...
If you care to read the c function I supplied or if you don't believe
it: If you understand ppc 32-bit instructions, as specified in the
PowerPC Microprocessor Family: Programming Environments for 32-Bit
Microprocessors. My routine would not be able to find a condition
that will make it go into an end-less loop,unless you messed up bad
somewhere.
> And (cd test; make
> test_bn) fails early in BN_sqr... And test/exptest fails miserably with
> "bad reciprocal"...
I don't know what you did but (make test_bn) works for me. So I
question how diligently you are in setting up the tests. If you are
busy, please get one of your ppc friends to do it.
> >>I initially thought there is maybe a small mistake in the code that
> >>requires a one-liner change
>
> But apparently this appears to be the case! Please verify following:
>
> --- crypto/bn/asm/ppc.pl.orig 2004-04-28 00:05:50.000000000 +0200
> +++ crypto/bn/asm/ppc.pl 2005-07-01 18:58:21.105656512 +0200
> @@ -1717,7 +1717,7 @@
> li r9,1 # r9=1
> $SHL r10,r9,r8 # r9<<=r8
> $UCMP 0,r3,r10 #
> - bc BO_IF,CR0_GT,Lppcasm_div2 #or if (h > (1<<r8))
> + bc BO_IF_NOT,CR0_GT,Lppcasm_div2 #or if (h > (1<<r8))
> $UDIV r3,r3,r0 #if not assert(0) divide by 0!
> #that's how we signal overflow
> bclr BO_ALWAYS,CR0_LT #return. NEVER REACHED.
>
You don't think I have gone in and fix that before realizing it's
worse than that? I am sure you didn't think I spend 3 days out in the
beach and somehow come up with an idea of clobbering some useful
routine because I think my routine is better?
In summary, what I am trying to provide the community is an
alternative to do something, the current implementation of which is
very questionable. You might resist change which is understandable.
But I were a diligent maintainer and I realize something is broken in
my code, then I will put the time to investigate the problem. If I
don't have the time, I will delagate it to a friend. If I don't have
a friend with that expertise then, I will try to make friends with the
reporter of the bug since he will most likely have spent hours fixing
the problem.
Regards,
David Ho.
[-- Attachment #2: test_bn.txt --]
[-- Type: text/plain, Size: 3397 bytes --]
bash-2.05b# make test_bn
starting big number library test, could take a while...
test BN_add
test BN_sub
test BN_lshift1
test BN_lshift (fixed)
test BN_lshift
test BN_rshift1
test BN_rshift
test BN_sqr
test BN_mul
test BN_div
test BN_div_recp
test BN_mod
test BN_mod_mul
test BN_mont
test BN_mod_exp
test BN_exp
test BN_kronecker
...++++++
....................................................................................................
test BN_mod_sqrt
.....
.....
.....
.....
.....
.....
.....
.....
.......++++++++++++
.....
......++++++++++++
.....
...++++++++++++
.....
..++++++++++++
.....
...++++++++++++
.....
........++++++++++++
.....
.................++++++++++++
.....
...........++++++++++++
.....
running bc
verify BN_add....................................................................................................
verify BN_sub......................................................................................................................................................
verify BN_lshift1....................................................................................................
verify BN_lshift (fixed)....................................................................................................
verify BN_lshift....................................................................................................
verify BN_rshift1....................................................................................................
verify BN_rshift....................................................................................................
verify BN_sqr....................................................................................................
verify BN_mul......................................................................................................................................................
verify BN_div............................................................................................................................................................................................................................................................................................................
verify BN_div_recp............................................................................................................................................................................................................................................................................................................
verify BN_mod....................................................................................................
verify BN_mod_mul............................................................................................................................................................................................................................................................................................................
verify BN_mont.....
verify BN_mod_exp.....
verify BN_exp.....
verify BN_kronecker
verify BN_mod_sqrt
2015 tests passed
test a^b%c implementations
../util/shlib_wrap.sh ./exptest
........................................................................................................................................................................................................ done
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox