* 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
* Re: PCC440GX custom board configuration
From: Ralph Siemsen @ 2005-07-04 18:41 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <003101c57d66$9de20a20$f201a8c0@SN7606>
David Grab wrote:
> Now i want to configure Linux to match my custom board. I ported my board
> based on ocotea board configuration files and excluded all the stuff i don´t
> need. My kernel seems to load but get stuck on calibrating delay loop and
> loops between update_proces_times and __delay (at address 0xC0003400) until
> it reboots. Seems like i didn´t match the BogoMips calculation. Actually i
> don´t use the RTC (i comment out all TODC functions). I think this cause the
> problem. So what i have to do to boot without RTC or has someone my RTC
> running with linux?
You are most likely not passing the clock speed from bootloader
correctly. You can set it forcibly in the beginning of ocotea.c, or
else fixup the structure passed between bootloader and kernel so that
both sides match. Doing the latter will fix a lot of other troubles
that you will encounter later on as well. See also:
http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel
-R
^ permalink raw reply
* initrd rootfs ramdisk
From: David Grab @ 2005-07-05 6:36 UTC (permalink / raw)
To: linuxppc-embedded
Good morning,
i solved my problem last problem and now i get console output. :) So next
step is to setup the root file system. I want to use an image loaded into
ramdisk, but seems i´m missing something. I´m using u-boot to load the
ramdisk and linux kernel. Actually i don´t know how the kernel gets the
location of the loaded ramdisk. I only added the support (see Kernel
configuration) and the command line parameter root=/dev/ram rw. But the boot
command arguments from u-boot seems not recognized from the linux kernel.
Should the option CONFIG_BOOT_LOAD point on the address of the ramdisk? I
hope someone could help me to trigger out my problem.
Thanks and Best regards,
David
Console output:
## Booting image at ff000000 ...
Image Name: Linux-2.6.11.6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 657688 Bytes = 642.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x1FF9DB40 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF10
bd address = 0x1FF9DF54
memstart = 0x00000000
memsize = 0x20000000
flashstart = 0xFF000000
flashsize = 0x01000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x0A080007
intfreq = 500 MHz
busfreq = 166.666 MHz
ethaddr = 00:04:AC:E3:28:8A
eth1addr = 00:04:AC:E3:28:8B
eth2addr = 00:04:AC:E3:28:8C
eth3addr = 00:04:AC:E3:28:8D
IP addr = 192.168.0.116
baudrate = 115200 bps
## Loading RAMDisk Image at ff800000 ...
Image Name: Test Ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1629365 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0xFF800040 ... 0xFF98DCF4 (len=1629365=0x18DCB5)
Loading Ramdisk to 1fe0f000, end 1ff9ccb5 ... OK
## Transferring control to Linux (at address 00000000) ...
Linux version 2.6.11.6 (david@FedoraDG) (gcc-Version 3.3.3 (DENX ELDK 3.1
3.3.3-8)) #1 Mon Jul 4 07:34:21 CEST 2005
IBM
Built 1 zonelists
Kernel command line: root=/dev/ram rw ip=on console=ttyS1,115200
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 517760k available (996k kernel code, 352k data, 96k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Linux NoNET1.0 for Linux 2.6
PCI: Probing PCI hardware
SCSI subsystem initialized
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)
<0>Rebooting in 180 seconds..
Kernel configuration:
#
# Automatically generated make config: don't edit
#
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
CONFIG_BROKEN_ON_SMP=y
#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
# CONFIG_IKCONFIG is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor
#
# CONFIG_6xx is not set
# CONFIG_40x is not set
CONFIG_44x=y
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E500 is not set
CONFIG_BOOKE=y
CONFIG_PTE_64BIT=y
# CONFIG_MATH_EMULATION is not set
# CONFIG_CPU_FREQ is not set
CONFIG_4xx=y
#
# IBM 4xx options
#
# CONFIG_EBONY is not set
# CONFIG_OCOTEA is not set
CONFIG_HIMA=y
CONFIG_440GX=y
CONFIG_440A=y
CONFIG_IBM_OCP=y
CONFIG_IBM_EMAC4=y
# CONFIG_PM is not set
CONFIG_NOT_COHERENT_CACHE=y
#
# Platform options
#
# CONFIG_PC_KEYBOARD is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_HIGHMEM is not set
CONFIG_KERNEL_ELF=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="root=/dev/ram rw ip=on console=ttyS1,115200"
#
# Bus options
#
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_NAMES is not set
#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x01000000
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_CARMEL is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
#
# SCSI device support
#
CONFIG_SCSI=y
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Macintosh device drivers
#
#
# Networking support
#
# CONFIG_NET=y
#
# Networking options
#
# CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
# CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET=y
# CONFIG_MII=y
# CONFIG_OAKNET is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_EMAC=y
# CONFIG_IBM_EMAC_ERRMSG is not set
# CONFIG_IBM_EMAC_RXB=128
# CONFIG_IBM_EMAC_TXB=128
# CONFIG_IBM_EMAC_FGAP=8
# CONFIG_IBM_EMAC_SKBRES=0
# CONFIG_NET_PCI is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
# CONFIG_INPUT is not set
#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
# CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
# CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
# CONFIG_SOUND_GAMEPORT is not set
# CONFIG_SERIO is not set
# CONFIG_SERIO_I8042 is not set
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_QIC02_TAPE is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Misc devices
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FB is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_FAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
# CONFIG_ROOT_NFS=y
# CONFIG_LOCKD=y
# CONFIG_EXPORTFS is not set
# CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
# CONFIG_NLS is not set
#
# Library routines
#
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set
CONFIG_BDI_SWITCH=y
CONFIG_DEBUG_INFO=y
# CONFIG_SERIAL_TEXT_DEBUG is not set
CONFIG_PPC_OCP=y
#
# Security options
#
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
^ 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