* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Olaf Hering @ 2005-07-05 20:27 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050705195819.GD6878@smtp.west.cox.net>
On Tue, Jul 05, Tom Rini wrote:
> On Tue, Jul 05, 2005 at 09:54:41PM +0200, Olaf Hering wrote:
> > On Tue, Jul 05, Tom Rini wrote:
> >
> > > gcc info page says that -mcpu=powerpc won't work for 601.
> >
> > -mcpu=common may work for everyone, after a quick grep in
> > gcc/config/rs6000
>
> It does, and that's the code bloat you're trying to get rid of :)
3397494 579544 519704 4496742 449d66 ../O-ppc-cpucommon/vmlinux
3469857 579544 519704 4569105 45b811 ../O-ppc-default/vmlinux
-mcpu=powerpc reduces text size still more than -mcpu=750
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Tom Rini @ 2005-07-05 21:22 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20050705202717.GA26014@suse.de>
On Tue, Jul 05, 2005 at 10:27:17PM +0200, Olaf Hering wrote:
> On Tue, Jul 05, Tom Rini wrote:
>
> > On Tue, Jul 05, 2005 at 09:54:41PM +0200, Olaf Hering wrote:
> > > On Tue, Jul 05, Tom Rini wrote:
> > >
> > > > gcc info page says that -mcpu=powerpc won't work for 601.
> > >
> > > -mcpu=common may work for everyone, after a quick grep in
> > > gcc/config/rs6000
> >
> > It does, and that's the code bloat you're trying to get rid of :)
>
> 3397494 579544 519704 4496742 449d66 ../O-ppc-cpucommon/vmlinux
> 3469857 579544 519704 4569105 45b811 ../O-ppc-default/vmlinux
That's very wierd. What is the default then? Thinking back to May, I
thought it was 'common', and that was why Paul wanted to change things.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PPC bn_div_words routine rewrite
From: Andy Polyakov @ 2005-07-05 21:22 UTC (permalink / raw)
To: openssl-dev; +Cc: linuxppc-embedded
In-Reply-To: <4dd15d18050705132178b5fd92@mail.gmail.com>
> Let's take first call to BN_div_word for example from BN_bn2dec, the
> parameter being passed to BN_div_word is (a=35, w=1000000000) (decimal
> numbers). It then calls the bn_div_words with (h=0, l=35,
> d=1000000000) if you examine the code in linux_ppc32.s it will exit
> early on because h is 0. the routine returns a divide by 0, which is
> undefined according to the manual. In the case of ppc8xx the result
> is 0x80000000.
And on the PPC machine I have access to it returns 0. This is
explanation why I never experienced any SEGV, but a sparse decimal
output. And it does explain why BN_is_zero condition never met on your
system and you hit sbrk(0) limit and suffer the penalty. However! Note
that updated routine,
http://cvs.openssl.org/getfile/openssl/crypto/bn/asm/ppc.pl?v=1.4 never
issues divide by 0 [it traps instead, but the condition is never met now
when called from BN_div_words] and it does return correct answer to me.
Can you really confirm that updated subroutine doesn't work for you? And
if so, how does problem manifest? Still SEGV? At same point?
It should pointed out that bug in ppc.pl is encountered only in 0.9.7
context, as 0.9.8 avoids it by normalizing divisor [and adjusting
dividend accordingly]. BTW, I can confirm that 0.9.7 produces correct
decimal ASCII with your routine [but no luck with make test_bn], but in
0.9.8 context decimal printout comes out truncated [not sparse with some
significant digits there and there, but truncated] if your routine is
pasted in. A.
^ permalink raw reply
* Re: PPC bn_div_words routine rewrite
From: David Ho @ 2005-07-05 21:25 UTC (permalink / raw)
To: appro, linuxppc-embedded, openssl-dev
In-Reply-To: <4dd15d18050705132178b5fd92@mail.gmail.com>
Okay, having actually did what Andy suggested, i.e. the one liner fix
in the assembly code, bn_div_words returns the correct results.
At this point, my conclusion is, up to openssl-0.9.8-beta6, the ppc32
bn_div_words routine generated from crypto/bn/ppc.pl is still busted.=20
Your solution is either to use the one liner fix andy provided in his
reply or my routine. My solution is a complete rewrite of the
routine, which is tested to work on ppc8xx. I personally do not know
why it would not work on other ppc32 systems but if you have time to
spare you are welcome to give it a try on your ppc32, because it is by
far the most straight-forward algorithm for division. If you have
done long division on paper from your primary school days, this
function mimics exactly the long division steps in binary (as opposed
to decimal). Way easier to fix if you know what the algorithm is
trying to do.
Comments I have for the old routine are:
Why do you signal an overflow condition when it appears functions that
call bn_div_words do not check for overflow conditions? That's why in
my routine I just let the register overflow.
Why the complexity, does it offer performance advantage? Obviously
code size is huge compared to mine.
David
On 7/5/05, David Ho <davidkwho@gmail.com> wrote:
> Let's take first call to BN_div_word for example from BN_bn2dec, the
> parameter being passed to BN_div_word is (a=3D35, w=3D1000000000) (decima=
l
> numbers). It then calls the bn_div_words with (h=3D0, l=3D35,
> d=3D1000000000) if you examine the code in linux_ppc32.s it will exit
> early on because h is 0. the routine returns a divide by 0, which is
> undefined according to the manual. In the case of ppc8xx the result
> is 0x80000000. So this is the return value from bn_div_words, as seen
> in register R3.
>=20
> So what happens next is BN_div_word modifies "a" (1st parameter) with
> the result (0x80000000) and returns 23 as the remainder of the
> division. So "a" is never zero as a result and hence the test for
> BN_is_zero is always false. The problem fails the very first time it
> uses bn_div_words.
>=20
> The next thing I did naturally was to fix the case when you have h=3D0,
> which you can quite easy do it with the native divwu instruction. Lo
> and behold I was once again disappointed when h is not equal to 0.
>=20
> More to come...
>=20
>=20
> On 7/5/05, David Ho <davidkwho@gmail.com> wrote:
> > I can tell you with certainty, with reference to the function
> > BN_bn2dec, that since lp is a pointer, and within the while loop
> > around bn_print.c:136 lp is being incremented. Because the test
> > BN_is_zero(t) is always false, you have a pointer that is going off
> > into the stratosphere, hence the segfault on ppc8xx.
> >
> > More analysis to come.
> >
> > On 7/5/05, David Ho <davidkwho@gmail.com> wrote:
> > > First pass debugging results from gdb on ppc8xx. Executing ssh-keyge=
n
> > > with following arguments.
> > >
> > > (gdb) show args
> > > Argument list to give program being debugged when it is started is
> > > "-t rsa1 -f /etc/ssh/ssh_host_key -N """.
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > BN_bn2dec (a=3D0x1002d9f0) at bn_print.c:136
> > > 136 *lp=3DBN_div_word(t,BN_DEC_CONV);
> > >
> > > (gdb) i r
> > > r0 0x0 0
> > > r1 0x7fffd580 2147472768
> > > r2 0x30012868 805382248
> > > r3 0x80000000 2147483648
> > > r4 0xfef33fc 267334652
> > > r5 0x25 37
> > > r6 0xfccdef8 265084664
> > > r7 0x7fffd4c0 2147472576
> > > r8 0xfbad2887 4222429319
> > > r9 0x84044022 2214871074
> > > r10 0x0 0
> > > r11 0x2 2
> > > r12 0xfef2054 267329620
> > > r13 0x10030bc8 268635080
> > > r14 0x0 0
> > > r15 0x0 0
> > > r16 0x0 0
> > > r17 0x0 0
> > > r18 0x0 0
> > > r19 0x0 0
> > > r20 0x0 0
> > > r21 0x0 0
> > > r22 0x0 0
> > > r23 0x64 100
> > > r24 0x5 5
> > > r25 0x1002d438 268620856
> > > r26 0x1002d9f0 268622320
> > > r27 0x1002c578 268617080
> > > r28 0x1 1
> > > r29 0x10031000 268636160
> > > r30 0xffbf7d0 268171216
> > > r31 0x1002d9f0 268622320
> > > pc 0xfef2058 267329624
> > > ps 0xd032 53298
> > > cr 0x24044022 604258338
> > > lr 0xfef2054 267329620
> > > ctr 0xfccefa0 265088928
> > > xer 0x20000000 536870912
> > > fpscr 0x0 0
> > > vscr 0x0 0
> > > vrsave 0x0 0
> > >
> > > (gdb) p/x $pc
> > > $1 =3D 0xfef2058
> > >
> > > 0x0fef2058 <BN_bn2dec+472>: stw r3,0(r29)
> > >
> > > (gdb) x 0x10031000
> > > 0x10031000: Cannot access memory at address 0x10031000
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 7/5/05, David Ho <davidkwho@gmail.com> wrote:
> > > > This is the second confirmed report of the same problem on the ppc8=
xx.
> > > >
> > > > After reading my email. I must say I was the unfriendly one, I
> > > > apologize for that.
> > > >
> > > > More debugging evidence to come.
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Murch, Christopher <cmurch@mrv.com>
> > > > Date: Jul 1, 2005 9:46 AM
> > > > Subject: RE: PPC bn_div_words routine rewrite
> > > > To: David Ho <davidkwho@gmail.com>
> > > >
> > > >
> > > > David,
> > > > I had observed the same issue on ppc 8xx machines after upgrading t=
o the asm
> > > > version of the BN routines. Thank you very much for your work for =
the fix.
> > > > My question is, do you have high confidence in the other new asm pp=
c BN
> > > > routines after observing this issue or do you think they might have=
similiar
> > > > problems?
> > > > Thanks.
> > > > Chris
> > > >
> > > > -----Original Message-----
> > > > From: David Ho [mailto:davidkwho@gmail.com]
> > > > Sent: Thursday, June 30, 2005 6:22 PM
> > > > To: openssl-dev@openssl.org; linuxppc-embedded@ozlabs.org
> > > > Subject: Re: PPC bn_div_words routine rewrite
> > > >
> > > >
> > > > The reason I had to redo this routine, in case anyone is wondering,=
is
> > > > because ssh-keygen segfaults when this assembly routine returns ju=
nk
> > > > 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 asci=
i
> > > > decimal.
> > > >
> > > > Regards,
> > > > David
> > > >
> > > > On 6/30/05, David Ho <davidkwho@gmail.com> wrote:
> > > > > Hi all,
> > > > >
> > > > > This is a rewrite of the bn_div_words routine for the PowerPC arc=
h,
> > > > > tested on a MPC8xx processor.
> > > > > I initially thought there is maybe a small mistake in the code th=
at
> > > > > requires a one-liner change but it turns out I have to redo the
> > > > > routine.
> > > > > I guess this routine is not called very often as I see that most =
other
> > > > > routines are hand-crafted, whereas this routine is compiled from =
a C
> > > > > function that apparently has not gone through a whole lot of test=
ing.
> > > > >
> > > > > I wrote a C function to confirm correctness of the code.
> > > > >
> > > > > unsigned long div_words (unsigned long h,
> > > > > unsigned long l,
> > > > > unsigned long d)
> > > > > {
> > > > > unsigned long i_h; /* intermediate dividend */
> > > > > unsigned long i_q; /* quotient of i_h/d */
> > > > > unsigned long i_r; /* remainder of i_h/d */
> > > > >
> > > > > unsigned long i_cntr;
> > > > > unsigned long i_carry;
> > > > >
> > > > > unsigned long ret_q; /* return quotient */
> > > > >
> > > > > /* cannot divide by zero */
> > > > > if (d =3D=3D 0) return 0xffffffff;
> > > > >
> > > > > /* do simple 32-bit divide */
> > > > > if (h =3D=3D 0) return l/d;
> > > > >
> > > > > i_q =3D h/d;
> > > > > i_r =3D h - (i_q*d);
> > > > > ret_q =3D i_q;
> > > > >
> > > > > i_cntr =3D 32;
> > > > >
> > > > > while (i_cntr--)
> > > > > {
> > > > > i_carry =3D (l & 0x80000000) ? 1:0;
> > > > > l =3D l << 1;
> > > > >
> > > > > i_h =3D (i_r << 1) | i_carry;
> > > > > i_q =3D i_h/d;
> > > > > i_r =3D i_h - (i_q*d);
> > > > >
> > > > > ret_q =3D (ret_q << 1) | i_q;
> > > > > }
> > > > >
> > > > > return ret_q;
> > > > > }
> > > > >
> > > > >
> > > > > Then I handcrafted the routine in PPC assembly.
> > > > > The result is a 26 line assembly that is easy to understand and
> > > > > predictable as opposed to a 81liner that I am still trying to
> > > > > decipher...
> > > > > If anyone is interested in incorporating this routine to the open=
ssl
> > > > > code I'll be happy to assist.
> > > > > At this point I think I will be taking a bit of a break from this=
3
> > > > > day debugging/fixing marathon.
> > > > >
> > > > > Regards,
> > > > > David Ho
> > > > >
> > > > >
> > > > > #
> > > > > # Handcrafted version of bn_div_words
> > > > > #
> > > > > # r3 =3D h
> > > > > # r4 =3D l
> > > > > # r5 =3D d
> > > > >
> > > > > cmplwi 0,r5,0 # compare r5 and 0
> > > > > bc BO_IF_NOT,CR0_EQ,.Lppcasm_div1 # proceed if d!=
=3D0
> > > > > li r3,-1 # d=3D0 return -1
> > > > > bclr BO_ALWAYS,CR0_LT
> > > > > .Lppcasm_div1:
> > > > > cmplwi 0,r3,0 # compare r3 and 0
> > > > > bc BO_IF_NOT,CR0_EQ,.Lppcasm_div2 # proceed if h !=
=3D 0
> > > > > divwu r3,r4,r5 # ret_q =3D l/d
> > > > > bclr BO_ALWAYS,CR0_LT # return result in r3
> > > > > .Lppcasm_div2:
> > > > > divwu r9,r3,r5 # i_q =3D h/d
> > > > > mullw r10,r9,r5 # i_r =3D h - (i_q*d)
> > > > > subf r10,r10,r3
> > > > > mr r3,r9 # req_q =3D i_q
> > > > > .Lppcasm_set_ctr:
> > > > > li r12,32 # ctr =3D bitsizeof(d)
> > > > > mtctr r12
> > > > > .Lppcasm_div_loop:
> > > > > addc r4,r4,r4 # l =3D l << 1 -> i_carry
> > > > > adde r11,r10,r10 # i_h =3D (i_r << 1) | i_=
carry
> > > > > divwu r9,r11,r5 # i_q =3D i_h/d
> > > > > mullw r10,r9,r5 # i_r =3D i_h - (i_q*d)
> > > > > subf r10,r10,r11
> > > > > add r3,r3,r3 # ret_q =3D ret_q << 1 | =
i_q
> > > > > add r3,r3,r9
> > > > > bc BO_dCTR_NZERO,CR0_EQ,.Lppcasm_div_loop
> > > > > .Lppc_div_end:
> > > > > bclr BO_ALWAYS,CR0_LT # return result in r3
> > > > > .long 0x00000000
> > > > >
> > > > _______________________________________________
> > > > Linuxppc-embedded mailing list
> > > > Linuxppc-embedded@ozlabs.org
> > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > > >
> > >
> >
>
^ permalink raw reply
* Re: PPC bn_div_words routine rewrite
From: Andy Polyakov @ 2005-07-05 21:49 UTC (permalink / raw)
To: openssl-dev; +Cc: linuxppc-embedded
In-Reply-To: <4dd15d180507051425589dbf69@mail.gmail.com>
> Okay, having actually did what Andy suggested, i.e. the one liner fix
> in the assembly code, bn_div_words returns the correct results.
Note that the final version, one committed to all relevant OpenSSL
branches since couple of days ago and one which actually made to just
released 0.9.8, is a bit different from originally suggested one-line
fix, see for example http://cvs.openssl.org/chngview?cn=14199.
> At this point, my conclusion is, up to openssl-0.9.8-beta6, the ppc32
> bn_div_words routine generated from crypto/bn/ppc.pl is still busted.
Yes. Though it should be noted that 0.9.8 was inadvertently avoiding the
bug condition. Recall that original problem report was for 0.9.7.
> Why do you signal an overflow condition when it appears functions that
> call bn_div_words do not check for overflow conditions?
That's question to IBM. By the time they submitted the code, I've
explicitly asked what would be appropriate way to generate *fatal*
condition at that point, i.e. one which would result in a core dump, and
it came out as division by 0 instruction. By that time I had no access
to any PPC machine and had to just go with it. Now it actually came as
surprise that division by 0 does not raise an exception, but silently
returns implementation-specific value... A.
^ permalink raw reply
* AMCC 440SPe support?
From: Roland Dreier @ 2005-07-06 3:51 UTC (permalink / raw)
To: linuxppc-embedded
Are patches to support the AMCC PowerPC 440SPe processor available?
Mainline 2.6 apparently does not contain anything related to the
440SPe. We're planning on using the 440SPe in a project, and I'm
wondering if I'll have to do the bringup myself.
If no one has released this yet, I'll be happy to start posting
patches once my eval boards arrive. I just don't want to duplicate
effort if someone has already brought up Linux on the 440SPe.
Thanks,
Roland
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Sam Song @ 2005-07-06 4:10 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050705194532.GA6878@smtp.west.cox.net>
Tom Rini <trini@kernel.crashing.org> wrote:
> [snip]
> > OK, it just stoped before init process. Is there
> > any necessary to fix sth on RAMDISK like add
> > netconsole device node?
>
> Nope, that's how netconsole works, it's not
> interactive (like console is
> after init is spawned).
Not interactive? I meant to use netconsole to repalce
the mointor serial console. Meanwhile, I implemented
netconsole on the target in u-boot and it did get a
interactive console. Maybe I can try telnet after
netconsole to get a net console in Linux? Sound a
little bit complicated than what I thought:-)
Uh, is this the real reason that netconsole in Linux
_must_ disable ethernet interrupt whereas network
does need it?
Thanks a lot,
Sam
___________________________________________________________
雅虎免费G邮箱－No.1的防毒防垃圾超大邮箱
http://cn.mail.yahoo.com/?id=77072
^ permalink raw reply
* Linux 2.4.25 problems after initrd detected
From: Russell McGuire @ 2005-07-06 4:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050706020002.F244267CA0@ozlabs.org>
Hello all,
I am running ELDK 3.1.1, Linux version 2.4.25, on a MPC8280 CPU, U-boot
1.1.2 to load linux.
This is a new prototype board we are developing; I can include the .config
information in a later post, if anyone needs to know something from it.
I am using the uRamdisk image, from the denx ftp for the initRd image.
I have added a couple lines to the cpuc.c file to add support for the
MPC8280 CPU, I think its only that one file, so perhaps linux is not
detecting the CPU correctly.
Two questions:
1) Does the "Warning: Real time clock stuck" pose any problem to getting the
initrd loaded? Or perhaps interrupts?
2) Does the MTD physical mapping driver have to be enabled for the initrd to
work, I haven't been able to get my driver to successfully complete a
ioremap if I enable it. I am using AMD 32MB flash mapped physically at
0xE0000000 at least in Uboot.
I know the kernel is still marginally alive as I can step into the kernel
debugger over the serial port at this point, if I press control C, its in
the interrupt routines waiting for UART interrupts.
I apologize in advance if I have not provided enough info, as its my first
post.
Russell McGuire
Here is the output, from Uboot.
## Booting image at e0080000 ...
Image Name: Linux-2.4.25
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 661411 Bytes = 645.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x021339A0 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF10
bd address = 0x02133FB4
memstart = 0x00000000
memsize = 0x02200000
flashstart = 0xE0000000
flashsize = 0x04000000
flashoffset = 0x00036000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xF0000000
bootflags = 0x00000001
vco = 528 MHz
sccfreq = 132 MHz
brgfreq = 33 MHz
intfreq = 396 MHz
cpmfreq = 264 MHz
busfreq = 66 MHz
ethaddr = EA:53:0E:4B:8A:46
IP addr = 192.168.5.50
baudrate = 115200 bps
## Loading RAMDisk Image at e0200000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1400198 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0xE0200040 ... 0xE0355DC5 (len=1400198=0x155D86)
Loading Ramdisk to 01fdd000, end 02132d86 ... OK
## Transferring control to Linux (at address 00000000) ...
Memory BAT mapping: BAT2=32Mb, BAT3=2Mb, residual: 0Mb
Linux version 2.4.25 (root@FedoraCore2) (gcc version 3.3.3 (DENX ELDK 3.1
3.3.3-8)) #94 Tue Jul 5 18:59:08 PDT 2005
On node 0 totalpages: 8704
zone(0): 8704 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram rw
Warning: real time clock seems stuck!
Calibrating delay loop... 263.78 BogoMIPS
Memory: 31472k available (1128k kernel code, 372k data, 56k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 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: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
CPM UART driver version 0.01
ttyS0 on SMC1 at 0x0000, BRG7
ttyS1 on SMC2 at 0x0040, BRG8
ttyS2 on SCC1 at 0x8000, BRG1
ttyS3 on SCC2 at 0x8100, BRG2
eth0: FCC2 ENET Version 0.4, EA:53:0E:4B:8A:47
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1367k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 56k init
<-- No more output, unless control C is pressed and "sometimes" it will
enter into the KGDB.
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Tom Rini @ 2005-07-06 5:11 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20050706041038.70258.qmail@web15810.mail.cnb.yahoo.com>
On Wed, Jul 06, 2005 at 12:10:38PM +0800, Sam Song wrote:
> Tom Rini <trini@kernel.crashing.org> wrote:
> > [snip]
> > > OK, it just stoped before init process. Is there
> > > any necessary to fix sth on RAMDISK like add
> > > netconsole device node?
> >
> > Nope, that's how netconsole works, it's not
> > interactive (like console is
> > after init is spawned).
>
> Not interactive? I meant to use netconsole to repalce
> the mointor serial console. Meanwhile, I implemented
> netconsole on the target in u-boot and it did get a
> interactive console. Maybe I can try telnet after
> netconsole to get a net console in Linux? Sound a
> little bit complicated than what I thought:-)
So netconsole is a write-only kernel console. Kernel messages will go
out, but your init process, etc will not. For syslog type things, you
may want to look into a syslogd that does network. I don't know how
netconsole support in u-boot works, but it sounds like it's a network
aware application that you can telnet into, rather than Linux's
netconsole.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Compact flash sandisk and kingston speed
From: somshekar chandrashekar kadam @ 2005-07-06 5:36 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-embedded-request
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
HI ,
i have kingston Compact flash of 1GB which is of slow speed type may be 4X speed and Sandisk Compact flash of 1 GB which is latest called Xtreme which is 133X (150kb/sec = 1X),
i have linux-2.4.18 running on my custom controller using mpc862 using 64mb ram , but i dont find speed difference when i replace kingston with sandisk compact flash , we found the test results of read and write to compact flash is the same for both compact flash .. what could be wrong ?
or is the processor the limitation ?
is it that i need to do some chnages on my driver ?
or is it something to do with the buffer read write if am not wrong , please let me know ,
i dont know much abt this driver
Thanks In Advance
NEELU
[-- Attachment #2: Type: text/html, Size: 1060 bytes --]
^ permalink raw reply
* Compact flash driver linuxppc
From: somshekar chandrashekar kadam @ 2005-07-06 6:34 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-embedded-request
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
HI ,
i have kingston Compact flash of 1GB which is of slow
speed type may be 4X speed and Sandisk Compact flash
of 1 GB which is latest called Xtreme which is 133X (
150kb/sec = 1X),
i have linux-2.4.18 running on my custom controller
using mpc862 using 64mb ram , but i dont find speed
difference when i replace kingston with sandisk
compact flash , we found the test results of read and
write to compact flash is the same for both compact
flash .. what could be wrong ?
or is the processor the limitation ?
is it that i need to do some chnages on my driver ?
or is it something to do with the buffer read write if
am not wrong , please let me know ,
i dont know much abt this driver
Thanks In Advance
Neelu
[-- Attachment #2: Type: text/html, Size: 1156 bytes --]
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Olaf Hering @ 2005-07-06 6:38 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050705212213.GA8358@smtp.west.cox.net>
On Tue, Jul 05, Tom Rini wrote:
> That's very wierd. What is the default then? Thinking back to May, I
> thought it was 'common', and that was why Paul wanted to change things.
This is an odd biarch compiler, the one that Paul talked about:
Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --enable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.1 --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--without-system-libunwind --with-cpu=default32
--host=powerpc64-suse-linux
Thread model: posix
gcc version 4.0.1 20050701 (prerelease) (SUSE Linux)
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Yuli Barcohen @ 2005-07-06 8:58 UTC (permalink / raw)
To: Tom Rini; +Cc: linux-ppc-embedded
In-Reply-To: <20050705195328.GC6878@smtp.west.cox.net>
>>>>> Tom Rini writes:
Yuli> [...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.
Yuli> [...deleted...]
Yuli> I investigated the problem a bit when I had trouble with a
Yuli> self-compiled glibc a year or so ago. IIRC, I found bug in the
Yuli> memset code, not in the chip. The code was just wrong for
Yuli> cache line sizes not equal to 32. So memset.S is good for 60x
Yuli> series (PQII included) but for 8xx it fails. We use dcbX
Yuli> instructions in some kernel drivers and since we never had any
Yuli> problems with those drivers I'm a bit surprised to hear that
Yuli> all 8xx chips have got that bug.
Tom> It's also OK on a multiple of 32, iirc, but not smaller. And
Tom> using the information the kernel does export would be too slow.
Tom> Or at least no one figured out a good way to do it, userspace
Tom> side.
IMHO the cache line size from cputable is not used in the kernel but
only passed to the ELF interpreter. I did not want to re-build glibc so
I changed the entry for mpc8xx to pass 0 instead of 16. This disabled
the assembler implementation of memset and since then all our
mpc8xx-based boards work properly. In any case, since it looks like a
coding bug and not CPU errata, maybe the glibc maintainer would be
willing to fix it?
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply
* AW: AW: initrd rootfs ramdisk
From: David Grab @ 2005-07-06 9:07 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <20050705160149.3BDF7353A5E@atlas.denx.de>
>> >But the kernel prints the boot parameters just fine.
>>
>> Maybe because i defined it in kernel configuration! But from u-boot i
don´t
>> get any arguments.
>Then you must be using a wrong image type. Are you sure you use "make
>uImage" to build your kernel image for U-Boot?
No, i´m using kernel 2.6.11.6 from kernel.org. It´s compiled with the actual
ELDK and made with "make uImage".
>> I thougt i can give the linux kernel position from u-boot where initrd is
>> located, but i have the same problem.
>You don;t. U-Boot passes this information automatically.
>> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>> loop: loaded (max 8 devices)
>> VFS: Cannot open root device "<NULL>" or unknown-block(3,1)
>> Please append a correct "root=" boot option
>> Kernel panic - not syncing: VFS: Unable to mount root fs on
>> unknown-block(3,1)
>Block device 3, 1 is /dev/hda1 - is your ramdisk known to be working?
Ramdisk is from ELDK build with mkimage like mentioned in FAQ.
I debugged to see what happens. First of all machine init in
\arch\ppc\kernel\setup.c is called. In this function a call to platform_init
is made. But the platform init of my own board files are called not the
implementation of setup.c which is only available if
CONFIG_PPC_MULTIPLATFORM is set. In my own platform_init is only a call to
find_bootinfo which is resulting in NULL because rec->tag is 0. That´s the
reason why parse_bootinfo don´t set the CMD_LINE, etc..
struct bi_record *find_bootinfo(void)
{
struct bi_record *rec;
rec = (struct bi_record *)_ALIGN((ulong)__bss_start+(1<<20)-1,(1<<20));
if ( rec->tag != BI_FIRST ) {
/*
* This 0x10000 offset is a terrible hack but it will go away when
* we have the bootloader handle all the relocation and
* prom calls -- Cort
*/
rec = (struct bi_record
*)_ALIGN((ulong)__bss_start+0x10000+(1<<20)-1,(1<<20));
if ( rec->tag != BI_FIRST )
return NULL;
}
return rec;
}
In this line rec is set to 0xc0300000
rec = (struct bi_record *)_ALIGN((ulong)__bss_start+(1<<20)-1,(1<<20));
if definitions are in both lines true because rec->tag is 0
in this line rec address is also 0xc0300000
rec = (struct bi_record
*)_ALIGN((ulong)__bss_start+0x10000+(1<<20)-1,(1<<20));
The following line in my own board.c platform_init gets the board
information. So u-boot pass the informations quite well.
if (r3)
__res = *(bd_t *)(r3 + KERNELBASE);
So what is wrong with my find_bootinfo function? Why is rec->tag zero?
Thx for advice,
David
^ permalink raw reply
* Re: Linux 2.4.25 problems after initrd detected
From: Wolfgang Denk @ 2005-07-06 9:10 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <20050706004122.GA42545@mail19d.g19.rapidsite.net>
In message <20050706004122.GA42545@mail19d.g19.rapidsite.net> you wrote:
>
> Two questions:
> 1) Does the "Warning: Real time clock stuck" pose any problem to getting the
> initrd loaded? Or perhaps interrupts?
It should not affect thte opration of the ramdisk, but it's obviously
something you should fix.
> 2) Does the MTD physical mapping driver have to be enabled for the initrd to
> work, I haven't been able to get my driver to successfully complete a
> ioremap if I enable it. I am using AMD 32MB flash mapped physically at
> 0xE0000000 at least in Uboot.
Ramdisk and MTD have nothingin common. You don;t need MTD to use a ramdisk
> I know the kernel is still marginally alive as I can step into the kernel
> debugger over the serial port at this point, if I press control C, its in
> the interrupt routines waiting for UART interrupts.
>
> I apologize in advance if I have not provided enough info, as its my first
> post.
Well, the most important thing you missed to tell us is what exactly
your problem is.
> Here is the output, from Uboot.
....
> Kernel command line: root=/dev/ram rw
...
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 56k init
>
> <-- No more output, unless control C is pressed and "sometimes" it will
So what? You did not pass any "console=ttyS0,$(baudrate)" or somilar
boot argument, so where is your console expected to show up?
Can you ping the system? Our standard ramdisk images have telnet and
FTP enabled. Can you telnet into the system?
Did you try booting with root file system mounted over NFS? This is
MUCH easier to debug.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I wish Captain Vimes were here. He wouldn't have known what to do
either, but he's got a much better vocabulary to be baffled in.
- Terry Pratchett, _Guards! Guards!_
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Wolfgang Denk @ 2005-07-06 9:12 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050706051139.GB8358@smtp.west.cox.net>
In message <20050706051139.GB8358@smtp.west.cox.net> you wrote:
>
> may want to look into a syslogd that does network. I don't know how
> netconsole support in u-boot works, but it sounds like it's a network
> aware application that you can telnet into, rather than Linux's
> netconsole.
It's an implementation which is compatible with (and derived from)
Linux' netconsole, but with an added input channel so you have
interactive control over ethernet.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You got to learn three things. What's real, what's not real, and
what's the difference." - Terry Pratchett, _Witches Abroad_
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Sam Song @ 2005-07-06 9:34 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050706051139.GB8358@smtp.west.cox.net>
Tom Rini <trini@kernel.crashing.org> wrote:
> > > [snip]
> > > Nope, that's how netconsole works, it's not
> > > interactive (like console is
> > > after init is spawned).
> >
> > Not interactive? I meant to use netconsole to
> > repalce the mointor serial console. Meanwhile, I
> > implemented netconsole on the target in u-boot
> > and it did get a interactive console. Maybe I can
> > try telnet after netconsole to get a net console
> > in Linux? Sound a little bit complicated than
> > what I thought:-)
>
> So netconsole is a write-only kernel console.
> Kernel messages will go out, but your init process,
> etc will not. For syslog type things, you
> may want to look into a syslogd that does network.
> I don't know how netconsole support in u-boot
> works, but it sounds like it's a network
> aware application that you can telnet into, rather
> than Linux's netconsole.
OK. I get it. The netconsole in kernel is different
from the one implemented in u-boot. The u-boot
netconsole is a interactive console whereas kernel
netconsole is just a simulated one after booting up.
No wawnder I need to wait 6-8 seconds to get the
network output after loading kernel.
Thanks so much for your clarification,
Sam
___________________________________________________________
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
http://cn.mail.yahoo.com/?id=77071
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Wolfgang Denk @ 2005-07-06 9:04 UTC (permalink / raw)
To: Sam Song; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <20050706041038.70258.qmail@web15810.mail.cnb.yahoo.com>
In message <20050706041038.70258.qmail@web15810.mail.cnb.yahoo.com> you wrote:
>
> > Nope, that's how netconsole works, it's not
> > interactive (like console is
> > after init is spawned).
>
> Not interactive? I meant to use netconsole to repalce
> the mointor serial console. Meanwhile, I implemented
> netconsole on the target in u-boot and it did get a
> interactive console. Maybe I can try telnet after
It seems you failed to read the doc/README.NetConsole fle that comes
with the U-Boot sources. This explains clearly that while in U-Boot
the netconsole implementation is bidirectional, the Linux coede is
unidirectional only.
> netconsole to get a net console in Linux? Sound a
> little bit complicated than what I thought:-)
You should not use telnet for obvious security problems. Use ssh
instead. But from the technical side it is perfectly fine to use a
remote login through telnet or rsh or ssh...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Nail here --X-- for new monitor.
^ permalink raw reply
* Re: mpc5200 i2c bus problem
From: postmaster @ 2005-07-06 10:24 UTC (permalink / raw)
To: Frederic Janot; +Cc: linuxppc-embedded
In-Reply-To: <00aa01c5807d$192ca230$b31010ac@pc179>
Hi
> 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.
Well, at the end of the day, you might be better by using two GPIO to do I2C
bit-banging ... Thanks for sharing the info, that might spare us long hours of
searching were the problem lies.
Unfortunatly the I2C port on the 5200 can't be turned to GPIO so that requires
some hardware modification ;(
Sylvain
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* AW: AW: initrd rootfs ramdisk
From: David Grab @ 2005-07-06 10:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000c01c5820a$19fc5be0$f201a8c0@SN7606>
i solved my problem with u-boot and linux. Now i have my rootfs ramdisk
mounted and functioning. But one output is weird.
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 1024) 4194304
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 96k init
ifconfig: socket: Function not implemented
### Application running ...
BusyBox v0.60.5 (2004.11.10-15:02+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
# ls
bin dev etc ftp home lib proc sbin tmp usr var
#
why incomplete write? RAMDISK: incomplete write (-28 != 1024) 4194304
Thx for help,
David
^ permalink raw reply
* bitkeeper issues
From: mcnernbm @ 2005-07-06 11:49 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
I have tried to download the latest 2.4 develpement kernel using
bitkeeper. I am using he following to do so:
bk clone bk://source.mvista.com/linuxppc_2_4_devel
But when it finishes downloading them all I get a message complaing
bitkeeper is not free after july 5th 2005. So I can not do a bk -r edit
to unlokck the files and everything. I am tryong to access this one cause
it contains all the xilinx drivers and ppc405 patches already. Is there
another location I can download a kernel with the xilinx drivers and
ppc405 patches applied? I am trying to get ppc linux running on a xilinx
ml403 board.
Thanks
Brett
[-- Attachment #2: Type: text/html, Size: 912 bytes --]
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Sam Song @ 2005-07-06 12:27 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <20050706090448.A91BC353A6A@atlas.denx.de>
Wolfgang Denk <wd@denx.de> wrote:
[snip]
> It seems you failed to read the
> doc/README.NetConsole fle that comes
> with the U-Boot sources. This explains clearly
> that while in U-Boot the netconsole implementation
> is bidirectional, the Linux coede is
> unidirectional only.
Oops, I read README.NetConsole again and found the
line in the last part. Sorry for that. I tend to
make a mistake to do sth in the first time:-)
> > netconsole to get a net console in Linux? Sound a
> > little bit complicated than what I thought:-)
>
> You should not use telnet for obvious security
> problems. Use ssh instead. But from the
> technical side it is perfectly fine to use a
> remote login through telnet or rsh or ssh...
OK, good idea to try.
Thanks very much indeed,
Sam
___________________________________________________________
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
http://cn.mail.yahoo.com/?id=77071
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Tom Rini @ 2005-07-06 16:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050706091200.5E060353A6A@atlas.denx.de>
On Wed, Jul 06, 2005 at 11:12:00AM +0200, Wolfgang Denk wrote:
> In message <20050706051139.GB8358@smtp.west.cox.net> you wrote:
> >
> > may want to look into a syslogd that does network. I don't know how
> > netconsole support in u-boot works, but it sounds like it's a network
> > aware application that you can telnet into, rather than Linux's
> > netconsole.
>
> It's an implementation which is compatible with (and derived from)
> Linux' netconsole, but with an added input channel so you have
> interactive control over ethernet.
That's quite cool. Any chance that could be ported back to Linux (I
know netpoll supports it, kgdboe works in the kernel).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: OLS 2005
From: Grant Likely @ 2005-07-06 17:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <caa74808cb385f021bedcf5769502e1d@freescale.com>
On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> I wondering if we can get a PPC BoF together, however not sure exactly
> what we would talk about. Any ideas?
>=20
> - kumar
I'd like to discuss the platform bus a bit. As was discussed a month
or so ago, there is no clean way of matching multiple device drivers
to a single device type, like with PSCs on the MPC5200.
g.
--=20
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life."
-- Charles Shultz
^ permalink raw reply
* Re: OLS 2005
From: Kumar Gala @ 2005-07-06 18:20 UTC (permalink / raw)
To: Grant Likely; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <528646bc0507061049739157cf@mail.gmail.com>
We should try to see if we can find GregKH to discuss what changes
would need to be made to the driver core to allow this.
- kumar
On Jul 6, 2005, at 12:49 PM, Grant Likely wrote:
> On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
>
>> I wondering if we can get a PPC BoF together, however not sure
>> exactly
>> what we would talk about. Any ideas?
>>
>> - kumar
>>
> I'd like to discuss the platform bus a bit. As was discussed a month
> or so ago, there is no clean way of matching multiple device drivers
> to a single device type, like with PSCs on the MPC5200.
>
> g.
>
> --
> "Why do musicians compose symphonies and poets write poems? They do it
> because life wouldn't have any meaning for them if they didn't.
> That's why I draw cartoons. It's my life."
>
> -- Charles Shultz
>
^ 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