Which way to store log in flash on mpc8xx?
Hi, just catching up on this problem as I have another unit that showed the same symptom. My system looks like this MPC852T 128Mbytes SDRAM 64Mbytes Flash Flash partitions 2*1.25Mbytes partitions for Kernel 61.5Mbytes for rootfs and applications. Remaining 1Mbyte for U-boot, u-boot env and spare. I get that same problem as well. kernel BUG at gc.c: 139 I have compiled Perl, Openssl, Openssh, etc running NFS so SDRAM is definitely not the issue. David: have you gotten any new insights since? Regards, David Ho On 9/20/05, Wolfgang Denk wrote: > In message <200509201117.40454.david.jander at protonic.nl> you wrote: > > > > Is there something like memtest86 for linux-ppc (i.e. written in portable > > C)? > > Yes, there is. Run the system with root file system mounted over NFS, > and then put some load on the system, like by compiling the linux > kernel on the target. Anything else which adds DMA load does not > hurt, either. In such a situation, with a lots of context switches, > stress on the memory management system and having a lots of DMA > traffic going on you may see some memory problems. Unfortunately none > of the standard memory tests will catch thse, as the tests usually > provide only plain read / write accesses, while the problems show up > only in burst mode, i. e. when filling the caches and/or doing DMA. > > There is an attempt of a burst mode memory test in the U-Boot code, > but I have to admit that I didn't work to show the exact problem on > the system it was written for. > > > Hmm, but there is no data corruption. I have not seen one file on flash > > that had other data than intended, and that inspite of the GC freaking out. > > Maybe there is no corruption of the data in flash. But are you sure > that correct data are loaded to and read from RAM? We had a similar > problem on a board where data got corrupted only when doing a lot of > transfers flash->RAM. > > > That commit only changed 3 files, non of them directly related to jffs2 > > code, > > This is correct. > > > and only seemed to add support for FUJITSU flash chips. What am I missing? > > MTD developers say that cvs from march-2005 _is_ broken, so there must be > > some > > Yes, of course it's broken. Like all computer code. There are a > couple of known issues (especially with NAND flash), but I don't > think they could explain the type of problems you are seeing. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de > Einstein argued that there must be simplified explanations of nature, > because God is not capricious or arbitrary. No such faith comforts > the software engineer. - Fred Brooks, Jr. > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
NPTL support on PPC
glibc used on ELDK 3.0 is still using linuxthreads. David bash-2.05# ./libc.so.6 GNU C Library stable release version 2.3.1, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1). Compiled on a Linux 2.4.24-pre2 system on 2004-02-17. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk software FPU emulation by Richard Henderson, Jakub Jelinek and others Report bugs using the `glibcbug' script to . On 10/13/05, David Ho wrote: > > Hi all, > > Just out of curiosity, is NPTL support already available on PPC? > > I believe there are 2 parts to it. Kernel support which is probably > already there in 2.6. And the other is glibc, is there a generally > available toolchain (i.e. ELDK) that already support NPTL? > > Thanks, David > -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051013/bba2bd8b/attachment.htm
NPTL support on PPC
Hi all, Just out of curiosity, is NPTL support already available on PPC? I believe there are 2 parts to it. Kernel support which is probably already there in 2.6. And the other is glibc, is there a generally available toolchain (i.e. ELDK) that already support NPTL? Thanks, David -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051013/e712cff9/attachment.htm
Meet at OLS2005
Grant, The CE Linux forum is holding a embedded linux BOF at Les Suites at the same time. It is probably more ARM based, but it will have lots of interested talks about XIP, PM suspend/resume, etc. Not sure if you are interested to attend there as well. David On 7/20/05, Grant Likely wrote: > I talked to Kumar on the last break. We're going to have the > ppcembedded BOF on Thursday at 7:00 in the downstairs lounge. I'm > about to post an announcement on the mailing list. Let everyone know > > g. > > On 7/20/05, David Ho wrote: > > btw, Marcelo is asking when/where the ppc BOF will take place, I'm in > > Room C again from 3-4pm, the last talk ran late. Maybe meet at the > > Sofas outside Room C at 4pm. > > Can talk about ppc BOF, I'm interested. > > > > David > > > > On 7/20/05, Grant Likely wrote: > > > I just got back online after lunch, so I probably missed you; I'm > > > available between now and the next session. At the moment I'm on the > > > 3rd floor at the DConf BOF. I'll have my email up that whole time > > > also. > > > > > > Cheers > > > g. > > > > > > On 7/20/05, David Ho wrote: > > > > Do you want to meet up now? I'm at Room C at the bottom floor. There > > > > are a bunch of sofas outside so it might be a better place to > > > > chill/chat. > > > > > > > > David > > > > > > > > On 7/20/05, Grant Likely wrote: > > > > > David, Kumar; > > > > > > > > > > I'd like to meet both of you today, but as I don't know what either of > > > > > you look like it's hard to track you down :-) > > > > > > > > > > When you get this, could you please either call me on my cell (403) > > > > > 399-0195 or email me back? > > > > > > > > > > At the moment, I'm in the NLKD session in Room A. (Middle section, > > > > > 4th row back, dark blue tee-shirt.) > > > > > > > > > > Thanks, > > > > > 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 > > > > > > > > -- > "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 >
How reliable is jffs2 really (denx cvs devel kernel)?
Wolfgang, It must have be more than a year ago that I did this. And I have not done any testing with the latest devel kernel from your CVS so I am not making any conclusion about the latest kernel. Just trying to be helpful. The mount time issue is fixed a long time ago, so your back port most probably has this fix. David On 7/19/05, Wolfgang Denk wrote: > In message <4dd15d1805071905573ebcba61 at mail.gmail.com> you wrote: > > > > I updated the JFFS2 portion of the Denx devel kernel with the latest > > from CVS and it solved the initial mount time problem. But it was a > > while a ago when I did this. Both the devel kernel and the CVS head > > has changed quite a bit since then. > > I would rally appreciate if you mentioned which exact version of the > kernel you are talking about. "The Denx devel kernel" can be anything > - either yesterday or 3 years old. > > At the moment our CVS tree contains a snapshot from MTD CVS of March > 13, 2005; yes, we did the necessary backport to the 2.4 kernel. > > Do you want to say that this version still has mount time issues? > Please provide details! > > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de > The word "fit", as I understand it, means "appropriate to a purpose", > and I would say the body of the Dean is supremely appropriate to the > purpose of sitting around all day and eating big heavy meals. > - Terry Pratchett, _Moving Pictures_ > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
How reliable is jffs2 really (denx cvs devel kernel)?
I ran into similar problems, I had talked to David Woodhouse about a number of issues with JFFS2. But he has no plans to support 2.4 kernels. There are a bunch of people that back ports the latest JFFS2 code from 2.6 and snapshots are found here ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/. I updated the JFFS2 portion of the Denx devel kernel with the latest from CVS and it solved the initial mount time problem. But it was a while a ago when I did this. Both the devel kernel and the CVS head has changed quite a bit since then. But some people on the mailing list seem to indicate timing resolution in the 2.4 leading to race condition, or some other deficiency from what I recall. The people in the mailing list were not interested in fixing these so called kernel bugs. And since JFFS2 code is too complex for my spare time and it does not cause the kernel to hang, I have yet to figure out a fix for it. I like to know other's experience with JFFS2 on 2.4 as well. David On 7/19/05, David Jander wrote: > > Hi, > > I have seen some strange problems with jffs2. I have been victim of the BUG() > in fs/jffs2/gc.c, line 139. I have been battling with kgdb to see what > happens there. Here are my findings until now (I am still working on this): > > c->checked_ino starts counting from 0 > c->highest_ino is 92 () > > Isn't this a little low? > > Flash partition size is 15Mbyte, it probably has been mistreated by writing > large files (logfiles) line by line, wasting a lot of space until it gets > almost full. > When debugging the for(;;) loop, used size starts from a few kb counting up, > dirty size is around 5 Mb and unchecked size is about 9.9Mb, so when it gets > past inode 92 it most probably has still a lot of unchecked space.===> BUG(). > > Googleing for this bug, I have found discouraging e-mails (luckily most of > them from 2003 or older) saying that this is common and nobody (back then) > seemed to know where it came from. Bugs in fjjs2 code, etc > > This is scaring me. > > Anybody knows more about this problem, why it is caused, and hopefully how to > prevent this? > > Thanks, > > -- > David Jander > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
[OLS 2005] Ottawa pub ideas - V 2.0
Minor update. Some links were broken. David --- D'arcy McGee's Irish Pub 44 Sparks Street Ottawa, ON Tel:(613)230-4433 http://www.darcymcgees.ca/ottawa/ It's Ottawa's authentic Irish Pub, designed and built in Ireland. A large selection of Irish Whiskeys, Single Malt Scotches, Bourbons, Cognacs, and Ports awaits those with discerning tastes. Darcy's offers live entertainment four nights a week (from Wednesday to Saturday night) featuring Celtic, Maritime, Irish and a mix of contemporary songs. Parliament Pub 101 Sparks Street Ottawa , ON Tel:(613) 563-0636 www.parliamentpub.com The Parliament Pub combines Dining and Political Fun. It is directly across the street from Parliament Hill. It's an inviting spot for lunch and dinner where excellent food and beverages can be enjoyed against a political backdrop. The Parliament Pub serves great sandwiches and wraps and creative salads. A fine selection of beers (with no political agenda) is on tap. Heart and Crown Irish Pub 67 Clarence Street Ottawa , ON (613) 562-0674 http://www.irishvillage.ca/ Live entertainment Wednesday to Saturday night with the finest bands, offering a wide range of Popular, Traditional, Scottish and Irish music. The Fox and Feather Pub 283 Elgin Street Ottawa, ON (613) 233-2219 http://www.foxandfeather.ca The Fox and Feather Pub is a great place to have a quiet pint, throw a party or share an evening of fun with friends. They have got a complimentary pool table, dartboards and board games to add to the entertainment, and their large selection of beers on-tap covers everything from Irish brews to Canadian microbreweries. Pub Italia 434 Preston Street Ottawa, ON http://www.pubitalia.ca/welcome.html Fine Italian food doubles as pub fare, and Wednesdays to Saturdays you can order dishes after midnight . Pub Italia represents the perfect marriage between an Italian trattoria and an Irish pub with its combination of wonderful pizza and pasta dishes, and an incredible selection of over 200 beers. Other notables - Honest Lawyer 141 George Street Ottawa, ON K1N 5W5 http://www.honestlawyer.com/ Newly opened Restaurant/Lounge Milestone's Restaurant 700 Susses Drive Ottawa, ON http://www.milestonesrestaurants.com/
[OLS 2005] Ottawa pub ideas
Sorry for the wait, and I hope everyone has access to their email in Ottawa. David --- D'arcy McGee's Irish Pub 44 Sparks Street Ottawa, ON Tel:(613)230-4433 http://www.heartandcrown.com/ It's Ottawa's authentic Irish Pub, designed and built in Ireland. A large selection of Irish Whiskeys, Single Malt Scotches, Bourbons, Cognacs, and Ports awaits those with discerning tastes. Darcy's offers live entertainment four nights a week (from Wednesday to Saturday night) featuring Celtic, Maritime, Irish and a mix of contemporary songs. Parliament Pub 101 Sparks Street Ottawa , ON Tel:(613) 563-0636 www.parliamentpub.com The Parliament Pub combines Dining and Political Fun. It is directly across the street from Parliament Hill. It's an inviting spot for lunch and dinner where excellent food and beverages can be enjoyed against a political backdrop. The Parliament Pub serves great sandwiches and wraps and creative salads. A fine selection of beers (with no political agenda) is on tap. Heart and Crown Irish Pub 67 Clarence Street Ottawa , ON (613) 562-0674 http://www.heartandcrown.com/ Live entertainment Wednesday to Saturday night with the finest bands, offering a wide range of Popular, Traditional, Scottish and Irish music. The Fox and Feather Pub 283 Elgin Street Ottawa, ON (613) 233-2219 http://www.foxandfeather.ca The Fox and Feather Pub is a great place to have a quiet pint, throw a party or share an evening of fun with friends. They have got a complimentary pool table, dartboards and board games to add to the entertainment, and their large selection of beers on-tap covers everything from Irish brews to Canadian microbreweries. Pub Italia 434 Preston Street Ottawa, ON http://www.pubitalia.ca/welcome.html Fine Italian food doubles as pub fare, and Wednesdays to Saturdays you can order dishes after midnight . Pub Italia represents the perfect marriage between an Italian trattoria and an Irish pub with its combination of wonderful pizza and pasta dishes, and an incredible selection of over 200 beers. Other notables - Honest Lawyer 141 George Street Ottawa, ON K1N 5W5 http://www.honestlawyer.com/ Newly opened Restaurant/Lounge Milestone's Restaurant 700 Susses Drive Ottawa, ON http://www.milestonesrestaurants.com/
OLS 2005
Heads up for ppl coming to Ottawa next week, it is 34 degrees Celsius all this week, and the weather has been like that for a few weeks. It's gonna be hot and sweaty... David On 7/12/05, Grant Likely wrote: > On 7/11/05, Greg KH wrote: > > On Mon, Jul 11, 2005 at 10:04:30PM -0600, Grant Likely wrote: > > > On 7/6/05, Kumar Gala wrote: > > > > On Jul 6, 2005, at 12:49 PM, Grant Likely wrote: > > > > > On 4/27/05, Kumar Gala wrote: > > > > > > > > > >> I wondering if we can get a PPC BoF together, ... > > > The schedule is now posted on the OLS website. Thursday and Friday > > > evenings are set for scheduled BOFs. Why don't we tentatively plan an > > > unoffical PPCembedded BOF Thursday evening? > > > > > > We should try to meet each other during the day Wednesday and choose a > > > good time. > > > > > > > > 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. > > > > > > > > > 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. > > > > > > > How 'bout it Greg? Can we get some of your time? > > > > Sure, grab me, but I'll have just taught 6 hours of tutorials and will > > probably want a beer or three :) > > Maybe I'll just need to buy you one of those beers to keep you cooperative. > > g. > > > > thanks, > > > > greg k-h > > > > > -- > "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 > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
crosstool-0.37
Hi, Thanks to Tim Hayman (my boss =), Crosstool-0.37 can now build a cross-compiling GCJ using GCC 4.0.x source and an older GCC core (the GCC core is used to build glibc which is required for the actual GCC build when you select more complex features such as C++ and Java). This is of course tested on MPC8xx our favourite platform at Nanometrics. David
PPC bn_div_words routine rewrite
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. 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 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=35, w=10) (decimal > numbers). It then calls the bn_div_words with (h=0, l=35, > d=10) 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 0x8000. So this is the return value from bn_div_words, as seen > in register R3. > > So what happens next is BN_div_word modifies "a" (1st parameter) with > the result (0x8000) 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. > > The next thing I did naturally was to fix the case when you have h=0, > 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. > > More to come... > > > On 7/5/05, David Ho 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 wrote: > > > First pass debugging results from gdb on ppc8xx. Executing ssh-keygen > > > 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=0x1002d9f0) at bn_print.c:136 > > > 136 *lp=BN_div_word(t,BN_DEC_CONV); > > > > > > (gdb) i r > > > r0 0x0 0 > > > r1 0x7fffd580 2147472768 > > > r2 0x30012868 805382248 > > > r3 0x8000 2147483648 > > > r4 0xfef33fc267334652 > > > r5 0x25 37 > > > r6 0xfccdef8265084664 > > > r7 0x7fffd4c0 2147472576 > > > r8 0xfbad2887 4222429319 > > > r9 0x84044022 2214871074 > > > r100x0 0 > > > r110x2 2 > > > r120xfef2054267329620 > > > r130x10030bc8 268635080 > > > r140x0 0 > > > r150x0 0 > > > r160x0 0 > > > r170x0 0 > > > r180x0 0 > > > r190x0 0 > > > r200x0 0 > > > r210x0 0 > > > r220x0 0 > > > r230x64 100 > > > r240x5 5 > > > r250x1002d438 268620856 > > > r260x1002d9f0 268622320 > > > r270x1002c578 268617080 > > > r280x1 1 > > > r290x10031000 268636160 > >
PPC bn_div_words routine rewrite
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=10) (decimal numbers). It then calls the bn_div_words with (h=0, l=35, d=10) 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 0x8000. So this is the return value from bn_div_words, as seen in register R3. So what happens next is BN_div_word modifies "a" (1st parameter) with the result (0x8000) 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. The next thing I did naturally was to fix the case when you have h=0, 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. More to come... On 7/5/05, David Ho 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 wrote: > > First pass debugging results from gdb on ppc8xx. Executing ssh-keygen > > 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=0x1002d9f0) at bn_print.c:136 > > 136 *lp=BN_div_word(t,BN_DEC_CONV); > > > > (gdb) i r > > r0 0x0 0 > > r1 0x7fffd580 2147472768 > > r2 0x30012868 805382248 > > r3 0x8000 2147483648 > > r4 0xfef33fc267334652 > > r5 0x25 37 > > r6 0xfccdef8265084664 > > r7 0x7fffd4c0 2147472576 > > r8 0xfbad2887 4222429319 > > r9 0x84044022 2214871074 > > r100x0 0 > > r110x2 2 > > r120xfef2054267329620 > > r130x10030bc8 268635080 > > r140x0 0 > > r150x0 0 > > r160x0 0 > > r170x0 0 > > r180x0 0 > > r190x0 0 > > r200x0 0 > > r210x0 0 > > r220x0 0 > > r230x64 100 > > r240x5 5 > > r250x1002d438 268620856 > > r260x1002d9f0 268622320 > > r270x1002c578 268617080 > > r280x1 1 > > r290x10031000 268636160 > > r300xffbf7d0268171216 > > r310x1002d9f0 268622320 > > pc 0xfef2058267329624 > > ps 0xd032 53298 > > cr 0x24044022 604258338 > > lr 0xfef2054267329620 > > ctr0xfccefa0265088928 > > xer0x2000 536870912 > > fpscr 0x0 0 > > vscr 0x0 0 > > vrsave 0x0 0 > > > > (gdb) p/x $pc > > $1 = 0xfef2058 > > > > 0x0fef2058 : stw r3,0(r29) > > > > (gdb) x 0x10031000 > > 0x10031000: Cannot access memory at address 0x10031000 > > > > > > > > > > > > > > > > > > > > > > On 7/5/05, David Ho wrote: > > > This is the second confirmed report of the same problem on the ppc8xx. > > > > > > 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 > > > Date: Jul 1, 2005 9:46 AM > > > Subject: RE: PPC bn_div_words routine rewrite > > > To: David Ho > > > > > > > > > David, > > > I had observed the same issue on ppc 8xx machines after upgrading to the > > > asm > > > version of the BN routines. Thank you very much for your work for the > > > fix. > > >
PPC bn_div_words routine rewrite
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 wrote: > First pass debugging results from gdb on ppc8xx. Executing ssh-keygen > 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=0x1002d9f0) at bn_print.c:136 > 136 *lp=BN_div_word(t,BN_DEC_CONV); > > (gdb) i r > r0 0x0 0 > r1 0x7fffd580 2147472768 > r2 0x30012868 805382248 > r3 0x8000 2147483648 > r4 0xfef33fc267334652 > r5 0x25 37 > r6 0xfccdef8265084664 > r7 0x7fffd4c0 2147472576 > r8 0xfbad2887 4222429319 > r9 0x84044022 2214871074 > r100x0 0 > r110x2 2 > r120xfef2054267329620 > r130x10030bc8 268635080 > r140x0 0 > r150x0 0 > r160x0 0 > r170x0 0 > r180x0 0 > r190x0 0 > r200x0 0 > r210x0 0 > r220x0 0 > r230x64 100 > r240x5 5 > r250x1002d438 268620856 > r260x1002d9f0 268622320 > r270x1002c578 268617080 > r280x1 1 > r290x10031000 268636160 > r300xffbf7d0268171216 > r310x1002d9f0 268622320 > pc 0xfef2058267329624 > ps 0xd032 53298 > cr 0x24044022 604258338 > lr 0xfef2054267329620 > ctr0xfccefa0265088928 > xer0x2000 536870912 > fpscr 0x0 0 > vscr 0x0 0 > vrsave 0x0 0 > > (gdb) p/x $pc > $1 = 0xfef2058 > > 0x0fef2058 : stw r3,0(r29) > > (gdb) x 0x10031000 > 0x10031000: Cannot access memory at address 0x10031000 > > > > > > > > > > > On 7/5/05, David Ho wrote: > > This is the second confirmed report of the same problem on the ppc8xx. > > > > 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 > > Date: Jul 1, 2005 9:46 AM > > Subject: RE: PPC bn_div_words routine rewrite > > To: David Ho > > > > > > David, > > I had observed the same issue on ppc 8xx machines after upgrading to 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 ppc BN > > routines after observing this issue or do you think they might have similiar > > problems? > > Thanks. > > Chris > > > > -Original Message- > > From: David Ho [mailto:davidkwho at gmail.com] > > Sent: Thursday, June 30, 2005 6:22 PM > > To: openssl-dev at openssl.org; linuxppc-embedded at 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 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. > > > > Regards, > > David > > > > On 6/30/05, David Ho wrote: > > > Hi all, > > > > > > This is a rewrite of the bn_div_words routine for the PowerPC arch, > > > tested on a MPC8xx processor. > > > I initially thought there is maybe a small mistake in the code that > > > 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
PPC bn_div_words routine rewrite
First pass debugging results from gdb on ppc8xx. Executing ssh-keygen
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=0x1002d9f0) at bn_print.c:136
136 *lp=BN_div_word(t,BN_DEC_CONV);
(gdb) i r
r0 0x0 0
r1 0x7fffd580 2147472768
r2 0x30012868 805382248
r3 0x8000 2147483648
r4 0xfef33fc267334652
r5 0x25 37
r6 0xfccdef8265084664
r7 0x7fffd4c0 2147472576
r8 0xfbad2887 4222429319
r9 0x84044022 2214871074
r100x0 0
r110x2 2
r120xfef2054267329620
r130x10030bc8 268635080
r140x0 0
r150x0 0
r160x0 0
r170x0 0
r180x0 0
r190x0 0
r200x0 0
r210x0 0
r220x0 0
r230x64 100
r240x5 5
r250x1002d438 268620856
r260x1002d9f0 268622320
r270x1002c578 268617080
r280x1 1
r290x10031000 268636160
r300xffbf7d0268171216
r310x1002d9f0 268622320
pc 0xfef2058267329624
ps 0xd032 53298
cr 0x24044022 604258338
lr 0xfef2054267329620
ctr0xfccefa0265088928
xer0x2000 536870912
fpscr 0x0 0
vscr 0x0 0
vrsave 0x0 0
(gdb) p/x $pc
$1 = 0xfef2058
0x0fef2058 : stw r3,0(r29)
(gdb) x 0x10031000
0x10031000: Cannot access memory at address 0x10031000
On 7/5/05, David Ho wrote:
> This is the second confirmed report of the same problem on the ppc8xx.
>
> 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
> Date: Jul 1, 2005 9:46 AM
> Subject: RE: PPC bn_div_words routine rewrite
> To: David Ho
>
>
> David,
> I had observed the same issue on ppc 8xx machines after upgrading to 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 ppc BN
> routines after observing this issue or do you think they might have similiar
> problems?
> Thanks.
> Chris
>
> -Original Message-
> From: David Ho [mailto:davidkwho at gmail.com]
> Sent: Thursday, June 30, 2005 6:22 PM
> To: openssl-dev at openssl.org; linuxppc-embedded at 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 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.
>
> Regards,
> David
>
> On 6/30/05, David Ho wrote:
> > Hi all,
> >
> > This is a rewrite of the bn_div_words routine for the PowerPC arch,
> > tested on a MPC8xx processor.
> > I initially thought there is maybe a small mistake in the code that
> > 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 testing.
> >
> > 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 == 0) return 0x;
> >
> > /* do simple 32-bit divide */
> > if (h == 0) return l/d;
> >
> > i_q = h/d;
> > i_r = h - (i_q*d);
> > ret_q = i_q;
> >
> > i_cntr = 32;
> >
> > while (i_cntr--)
&g
Fwd: PPC bn_div_words routine rewrite
This is the second confirmed report of the same problem on the ppc8xx.
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 <[EMAIL PROTECTED]>
Date: Jul 1, 2005 9:46 AM
Subject: RE: PPC bn_div_words routine rewrite
To: David Ho
David,
I had observed the same issue on ppc 8xx machines after upgrading to 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 ppc BN
routines after observing this issue or do you think they might have similiar
problems?
Thanks.
Chris
-Original Message-
From: David Ho [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 6:22 PM
To: openssl-dev at openssl.org; linuxppc-embedded at 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 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.
Regards,
David
On 6/30/05, David Ho wrote:
> Hi all,
>
> This is a rewrite of the bn_div_words routine for the PowerPC arch,
> tested on a MPC8xx processor.
> I initially thought there is maybe a small mistake in the code that
> 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 testing.
>
> 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 == 0) return 0x;
>
> /* do simple 32-bit divide */
> if (h == 0) return l/d;
>
> i_q = h/d;
> i_r = h - (i_q*d);
> ret_q = i_q;
>
> i_cntr = 32;
>
> while (i_cntr--)
> {
> i_carry = (l & 0x8000) ? 1:0;
> l = l << 1;
>
> i_h = (i_r << 1) | i_carry;
> i_q = i_h/d;
> i_r = i_h - (i_q*d);
>
> ret_q = (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 openssl
> 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 = h
> # r4 = l
> # r5 = d
>
> cmplwi 0,r5,0 # compare r5 and 0
> bc BO_IF_NOT,CR0_EQ,.Lppcasm_div1 # proceed if d!=0
> li r3,-1 # d=0 return -1
> bclrBO_ALWAYS,CR0_LT
> .Lppcasm_div1:
> cmplwi 0,r3,0 # compare r3 and 0
> bc BO_IF_NOT,CR0_EQ,.Lppcasm_div2 # proceed if h != 0
> divwu r3,r4,r5# ret_q = l/d
> bclrBO_ALWAYS,CR0_LT# return result in r3
> .Lppcasm_div2:
> divwu r9,r3,r5# i_q = h/d
> mullw r10,r9,r5 # i_r = h - (i_q*d)
> subfr10,r10,r3
> mr r3,r9 # req_q = i_q
> .Lppcasm_set_ctr:
> li r12,32 # ctr = bitsizeof(d)
> mtctr r12
> .Lppcasm_div_loop:
> addcr4,r4,r4# l = l << 1 -> i_carry
> adder11,r10,r10 # i_h = (i_r << 1) | i_carry
> divwu r9,r11,r5 # i_q = i_h/d
> mullw r10,r9,r5 # i_r = i_h - (i_q*d)
> subfr10,r10,r11
> add r3,r3,r3# ret_q = ret_q << 1 | i_q
> add r3,r3,r9
> bc BO_dCTR_NZERO,CR0_EQ,.Lppcasm_div_loop
> .Lppc_div_end:
> bclrBO_ALWAYS,CR0_LT# return result in r3
> .long 0x
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
PPC bn_div_words routine rewrite
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 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.orig2004-04-28 00:05:50.0 +0200 > +++ crypto/bn/asm/ppc.pl 2005-07-01 18:58:21.105656512 +0200 > @@ -1717,7 +1717,7 @@ > li r9,1# r9=1 > $SHLr10,r9,r8 # r9<<=r8 > $UCMP 0,r3,r10# > - bc BO_IF,CR0_GT,Lppcasm_div2 #or if (h > (1< + bc BO_IF_NOT,CR0_GT,Lppcasm_div2 #or if (h > (1< $UDIV r3,r3,r0#if not assert(0) divide by 0! > #that's how we signal overflow > bclrBO_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.
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 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.
Regards,
David
On 6/30/05, David Ho wrote:
> Hi all,
>
> This is a rewrite of the bn_div_words routine for the PowerPC arch,
> tested on a MPC8xx processor.
> I initially thought there is maybe a small mistake in the code that
> 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 testing.
>
> 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 == 0) return 0x;
>
> /* do simple 32-bit divide */
> if (h == 0) return l/d;
>
> i_q = h/d;
> i_r = h - (i_q*d);
> ret_q = i_q;
>
> i_cntr = 32;
>
> while (i_cntr--)
> {
> i_carry = (l & 0x8000) ? 1:0;
> l = l << 1;
>
> i_h = (i_r << 1) | i_carry;
> i_q = i_h/d;
> i_r = i_h - (i_q*d);
>
> ret_q = (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 openssl
> 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 = h
> # r4 = l
> # r5 = d
>
> cmplwi 0,r5,0 # compare r5 and 0
> bc BO_IF_NOT,CR0_EQ,.Lppcasm_div1 # proceed if d!=0
> li r3,-1 # d=0 return -1
> bclrBO_ALWAYS,CR0_LT
> .Lppcasm_div1:
> cmplwi 0,r3,0 # compare r3 and 0
> bc BO_IF_NOT,CR0_EQ,.Lppcasm_div2 # proceed if h != 0
> divwu r3,r4,r5# ret_q = l/d
> bclrBO_ALWAYS,CR0_LT# return result in r3
> .Lppcasm_div2:
> divwu r9,r3,r5# i_q = h/d
> mullw r10,r9,r5 # i_r = h - (i_q*d)
> subfr10,r10,r3
> mr r3,r9 # req_q = i_q
> .Lppcasm_set_ctr:
> li r12,32 # ctr = bitsizeof(d)
> mtctr r12
> .Lppcasm_div_loop:
> addcr4,r4,r4# l = l << 1 -> i_carry
> adder11,r10,r10 # i_h = (i_r << 1) | i_carry
> divwu r9,r11,r5 # i_q = i_h/d
> mullw r10,r9,r5 # i_r = i_h - (i_q*d)
> subfr10,r10,r11
> add r3,r3,r3# ret_q = ret_q << 1 | i_q
> add r3,r3,r9
> bc BO_dCTR_NZERO,CR0_EQ,.Lppcasm_div_loop
> .Lppc_div_end:
> bclrBO_ALWAYS,CR0_LT# return result in r3
> .long 0x
>
PowerPC bn_div_words routine rewrite
Hi all,
This is a rewrite of the bn_div_words routine for the PowerPC arch, tested
on a MPC8xx processor.
I initially thought there is maybe a small mistake in the code that
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 testing.
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 == 0) return 0x;
/* do simple 32-bit divide */
if (h == 0) return l/d;
i_q = h/d;
i_r = h - (i_q*d);
ret_q = i_q;
i_cntr = 32;
while (i_cntr--)
{
i_carry = (l & 0x8000) ? 1:0;
l = l << 1;
i_h = (i_r << 1) | i_carry;
i_q = i_h/d;
i_r = i_h - (i_q*d);
ret_q = (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 openssl 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 = h
# r4 = l
# r5 = d
cmplwi 0,r5,0 # compare r5 and 0
bc BO_IF_NOT,CR0_EQ,.Lppcasm_div1 # proceed if d!=0
li r3,-1 # d=0 return -1
bclrBO_ALWAYS,CR0_LT
.Lppcasm_div1:
cmplwi 0,r3,0 # compare r3 and 0
bc BO_IF_NOT,CR0_EQ,.Lppcasm_div2 # proceed if h != 0
divwu r3,r4,r5# ret_q = l/d
bclrBO_ALWAYS,CR0_LT# return result in r3
.Lppcasm_div2:
divwu r9,r3,r5# i_q = h/d
mullw r10,r9,r5 # i_r = h - (i_q*d)
subfr10,r10,r3
mr r3,r9 # req_q = i_q
.Lppcasm_set_ctr:
li r12,32 # ctr = bitsizeof(d)
mtctr r12
.Lppcasm_div_loop:
addcr4,r4,r4# l = l << 1 -> i_carry
adder11,r10,r10 # i_h = (i_r << 1) | i_carry
divwu r9,r11,r5 # i_q = i_h/d
mullw r10,r9,r5 # i_r = i_h - (i_q*d)
subfr10,r10,r11
add r3,r3,r3# ret_q = ret_q << 1 | i_q
add r3,r3,r9
bc BO_dCTR_NZERO,CR0_EQ,.Lppcasm_div_loop
.Lppc_div_end:
bclrBO_ALWAYS,CR0_LT# return result in r3
.long 0x
JVM for PPC405
At nanometrics, we have tried numerous different JVMs but we ended up using GCJ instead, it gives us the speed to run applications on a tiny 66MHz MPC8xx so if you are evaluating JVM options, I suggest you try GCJ included in GCC 4.0. David On 6/13/05, colui77 at virgilio.it wrote: > Hi all, > I need to installa a JVM on montavista linux for ML300 (PPC405). > I tried the Blackdown 1.3.1 for PPC but it doesn't seems to work > (at the command > $ java > I received > illegal istruction) > Any suggestion? Please I need help... > Luigi > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
libssl in ELDK3.0
Hi Wolfgang, I noticed that the libssl.so and libcrypto.so in the ELDK3.0 development rootfs are built with the linux-elf option on the ppc when it should have been built with linux-ppc. When I was trying to build ssh with these libs, it would not work with an i386 Linux box. I had to build libssl from scratch. David
OLS 2005
Is anyone interested in going to the OLS this year? I've been working in Ottawa for 4 years so if you are interested I can give anyone more information about things to do in Ottawa. Just heads up for those planning to go, the deadline for early bird registration is May 1 I think. You save CAN $150 (350 as opposed to 500). http://www.linuxsymposium.org/2005/ David
Browsers that support javascript and Nano-X
Hi, At Nanometrics, we have compiled Konqueror-embedded, kdenox, and qt-embedded for our Motorola PowerPC 8xx platform. Total memory usage of the browser is around 20Megs. I don't believe ppc8xx is not too much different from the PowerPC 405, but I might be wrong. If you need help you can post questions at konq-e at kde.org David Vijesh VH To Sent by: linuxppc-embedded at ozlabs.org, linuxppc-embedded NanoGUI Mailing List -bounces at ozlabs.o rg cc Subject 04/27/2005 09:09 Browsers that support javascript AMand Nano-X Please respond to Vijesh VH Hi, Has any one tried cross compiling (for PowerPc4 05)any javascript supported browser. If so please help me out in selection of the open source browsers. Architecture:PowerPC 405 Embedded Processor GUI: NanoX -- Thanks and Regards, Vijesh V H ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
modem control for 8xx serial
Hi all, Has anyone implemented modem control in arch/ppc/8xx_io/serial.c. I don't want to reinvent the wheel if someone's already done it. I'll be glad to do the dirty work and submit it if anyone is interested. Thanks, David H.
Testing ISP1362 USB network device driver.
Hi Wolfgang, I'm testing the device side of the ISP1362 using your USB network driver. I can get a PC to enumerate with the 1362 but then I don't have a windows driver to route IP traffic to it. I'm just curious how you test the driver? Do you have a Linux host side driver to communicate with the 1362 as a USB NIC device? Thanks, David H.
How to port ppc-linux to new custom boards? (virtexII)
> > Finally, do not overestimate the commercial support, to my experience; > > the collaborative mailing lists are often as good if not better to point > > you in the correct direction due to the diverse expertises of the ppl on > > the list. > > Correct. > > I'd like to add, though, that commercial support is somthing you payed for, > and which you can *claim*, so IMHO you shouldn't underestimate it. A > guaranteed support line can be very critical at certain stages of your > project. > Sorry to stick my nose in your discussion, but I have a strong opinion on commerial support. Working in a small company, we have never gotten the level of commitment we would expect from companies like ISI (vendor of pSOS) and Timesys. You can get the basic installation support fine. But when you need to get into the nitty gritty detail their value is a lot less compared to mailing lists. The way I see it is being large commercial OS vendor that they are, they seem to funnel their resource to the big customers who are willing to pay the big bucks to get stuff done. When choosing commercial support, one critical factor is their customer base. Big fish don't go after the tiny ticks in the sea, they go for seals. And you really have to find the right sized OS vender to give you the attention you need. Regards, David Ho Nanometrics Inc. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
How to remove JFFS2 'Making dirty' display on RPXlite DW?
> When creating a JFFS2 filesytem with DENX SELF ramdisk > as follows,the target displayed some wired > message,what would be problem be? > > = > > After unpacking SELF,I use the following command to > create a jffs2 filesystem: > > eraseall /dev/mtd3 > > mkfs.jffs2 -r /tmp/tmp -e 0x1 -o image.jffs2 -b > > dd if=image.jffs2 of=/dev/mtd3 bs=256k > > mount -t jffs2 /dev/mtdblock3 /mnt > > What is the block size you specified when you do a mkfs.jffs2? It has to match with your flash erase block size. Care should be taken if you have paralle banks. I'm not sure this is your problem but it is a problem I ran into. David ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx block address mapping...
Dan, I am just curious about how the 8xx does a block mapping (e.g. mapping a video frame buffer) without BATs. Here are the 2 possilbilities I can think of for a 2 megabyte block. - it allocates the smallest possible page size for the block requested. i.e. it will have to allocate an 8-Myte page for the 2-Mbyte block, very wasteful it seems. - pages can be allocated such that a contiguous region of physical memory can be mapped to the 2-Mbyte block, I can't imagine how this can take place in the 8xx MMU. Could you shed some light on how this works. It will help me assess how efficient block mapping is on the 8xx. Thanks a lot, David Ho ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
owner-linuxppc-embedded at lists.linuxppc.org wrote on 07/27/2004 06:30:28 PM: > > Just to add to the complexity: are you aware that the parameter RAM > relocation may be different between 8xx processors? For example it > seems that on the 866 family you can relocate PRAM even without > loading any uCode by just writing the correct offset to (for example) > the spi_rpbase register. > I just had a conversation with Wolfgang on the 866 uCode patch situation. It appears that the I2C/SPI patch is already incorporated in this silicon rev. Please look at the follow post for detail of my findings. http://sourceforge.net/mailarchive/message.php?msg_id=9072298 Hope this help you along the way. Or it might not. Regards, David Ho Nanometrics Inc. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
How to set current time to 8xx RTC through Linux application?
If you are using ELDK-3.0 and it's development root filesystem, hwclock does the trick. David > > I added 8xx RTC driver both on U-Boot and Linux > kernel.And I could set current time right under > U-Boot.But I have no idea on making it through Linux > application?I could read it with following code but > how to set it? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
no core dump from the kernel on SIGSEGV
> > >
> > > I'm looking at making the kernel core dump on a process that seg
vaulted.
> > > What I did was recompiled the kernel specifying a non-zero core file
size
> > > rlim[RLIMIT_CORE] = { RLIM_INFINITY, RLIM_INFINITY }. I was still
not
> > > getting a core dump.
> >
> > Please, read about ulimit shell command.
> Okay, your point taken. I assume ulimit will have the same effect of
> assigning it a non-zero value.
> What is troubling me is why it doesn't go to the core_dump function
> in fs/binfmt_elf.c
Oh, it's working all along. One person on our team claims it was a problem
in the kernel. But I proved it otherwise.
Thanks, David
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
no core dump from the kernel on SIGSEGV
> >
> > I'm looking at making the kernel core dump on a process that seg
vaulted.
> > What I did was recompiled the kernel specifying a non-zero core file
size
> > rlim[RLIMIT_CORE] = { RLIM_INFINITY, RLIM_INFINITY }. I was still not
> > getting a core dump.
> >
>
> DO NOT TOUCH the kernel!
>
> Please, read about ulimit shell command.
Okay, you point taken. I assume ulimit will have the same effect of
assigning it a non-zero value.
What is troubling me is why it doesn't go to the core_dump function in
fs/binfmt_elf.c
David
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
no core dump from the kernel on SIGSEGV
Hi all,
I'm looking at making the kernel core dump on a process that seg vaulted.
What I did was recompiled the kernel specifying a non-zero core file size
rlim[RLIMIT_CORE] = { RLIM_INFINITY, RLIM_INFINITY }. I was still not
getting a core dump.
The following test program was used to signal a seg vault (SIGSEGV).
#include
int main(int argc, char** argv) {
unsigned int* pointer = (unsigned int*) 0x12345678;
/* generate a SIGSEGV - invalid memory reference */
*pointer = 0xdeadbeef;
return 0;
}
Anyone can shred some light on this?
Thanks a lot,
David
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
RTC no longer exist on the 866/87x/88x
Hi 8xx gurus, I just noticed the RTC is no longer documented/tested/supported on the duet. How does this impact the current 2.4 8xx tree? I know the /dev/rtc still uses RTC on the processor, it appears to work fine, but I wouldn't bet my life on it for production units. How about the kernel's timing service and scheduling, does it use the timebase register instead? Are these services effected at all? Thanks a lot, David Ho Nanometrics Inc. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
patch for cpu/mpc8xx/cpu.c:get_tbclk - correction
Now that I think of it, the _multiplier_ (as I declared it here) cannot be
an integer, so this is all wrong.
I don't know how I got this working... I have a 50 Mhz oscillator with 66
Mhz system clock.
Why not use the oscillator define (CFG_8XX_XIN) for MPC866_et_al?
David
owner-linuxppc-embedded at lists.linuxppc.org wrote on 05/27/2004 03:19:26 PM:
>
> > The last if condition is wrong in this function. The change is made
> > against 0.4.8. AFAIK, 1.0.2 still has the same problem.
> >
> > And I wonder why it has to reverse engineer the oscclk when I pass the
> > value as a define to come up with the gd->cpu_clk for the MPC866
> family...
> > It is a bit useless I think.
> >
>
> Sorry, the last patch breaks on the old 8xx.
>
> This is a bit better.
>
>
> /*
> * Get timebase clock frequency (like cpu_clk in Hz)
> *
> * See table 15-5 pp. 15-16, and SCCR[RTSEL] pp. 15-27.
> */
> unsigned long get_tbclk (void)
> {
> DECLARE_GLOBAL_DATA_PTR;
>
> volatile immap_t *immr = (volatile immap_t *) CFG_IMMR;
> ulong oscclk, factor, multiplier;
>
> if (immr->im_clkrst.car_sccr & SCCR_TBS) {
> return (gd->cpu_clk / 16);
> }
> #define PLPRCR_val(a) (((CFG_PLPRCR) & PLPRCR_ ## a ## _MSK) >> PLPRCR_
##
> a ## _SHIFT)
> #ifdef CONFIG_MPC866_et_al
> /* MFN
> MFI + ---
>MFD + 1
> factor = -
> (PDF + 1) * 2^S
> */
>
> factor = (PLPRCR_val(MFI) + PLPRCR_val(MFN)/(PLPRCR_val(MFD)+1));
>
> multiplier = (PLPRCR_val(MFI) +
> PLPRCR_val(MFN)/(PLPRCR_val(MFD)+1))/
> (PLPRCR_val(PDF)+1) / (1< #else
> multiplier = factor = PLPRCR_val(MF)+1;
> #endif
>
> oscclk = gd->cpu_clk / multiplier;
>
> if ((immr->im_clkrst.car_sccr & SCCR_RTSEL) == 0 || factor > 2) {
> return (oscclk / 4);
> }
> return (oscclk / 16);
> }
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
patch for cpu/mpc8xx/cpu.c:get_tbclk - correction
> The last if condition is wrong in this function. The change is made
> against 0.4.8. AFAIK, 1.0.2 still has the same problem.
>
> And I wonder why it has to reverse engineer the oscclk when I pass the
> value as a define to come up with the gd->cpu_clk for the MPC866
family...
> It is a bit useless I think.
>
Sorry, the last patch breaks on the old 8xx.
This is a bit better.
/*
* Get timebase clock frequency (like cpu_clk in Hz)
*
* See table 15-5 pp. 15-16, and SCCR[RTSEL] pp. 15-27.
*/
unsigned long get_tbclk (void)
{
DECLARE_GLOBAL_DATA_PTR;
volatile immap_t *immr = (volatile immap_t *) CFG_IMMR;
ulong oscclk, factor, multiplier;
if (immr->im_clkrst.car_sccr & SCCR_TBS) {
return (gd->cpu_clk / 16);
}
#define PLPRCR_val(a) (((CFG_PLPRCR) & PLPRCR_ ## a ## _MSK) >> PLPRCR_ ##
a ## _SHIFT)
#ifdef CONFIG_MPC866_et_al
/* MFN
MFI + ---
MFD + 1
factor = -
(PDF + 1) * 2^S
*/
factor = (PLPRCR_val(MFI) + PLPRCR_val(MFN)/(PLPRCR_val(MFD)+1));
multiplier = (PLPRCR_val(MFI) +
PLPRCR_val(MFN)/(PLPRCR_val(MFD)+1))/
(PLPRCR_val(PDF)+1) / (1im_clkrst.car_sccr & SCCR_RTSEL) == 0 || factor > 2) {
return (oscclk / 4);
}
return (oscclk / 16);
}
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
patch for cpu/mpc8xx/cpu.c:get_tbclk
Hi Wolfgang,
The last if condition is wrong in this function. The change is made
against 0.4.8. AFAIK, 1.0.2 still has the same problem.
And I wonder why it has to reverse engineer the oscclk when I pass the
value as a define to come up with the gd->cpu_clk for the MPC866 family...
It is a bit useless I think.
David
/*
* Get timebase clock frequency (like cpu_clk in Hz)
*
* See table 15-5 pp. 15-16, and SCCR[RTSEL] pp. 15-27.
*/
unsigned long get_tbclk (void)
{
DECLARE_GLOBAL_DATA_PTR;
volatile immap_t *immr = (volatile immap_t *) CFG_IMMR;
ulong oscclk, factor, mf;
if (immr->im_clkrst.car_sccr & SCCR_TBS) {
return (gd->cpu_clk / 16);
}
#define PLPRCR_val(a) (((CFG_PLPRCR) & PLPRCR_ ## a ## _MSK) >> PLPRCR_ ##
a ## _SHIFT)
#ifdef CONFIG_MPC866_et_al
/* MFN
MFI + ---
MFD + 1
factor = -
(PDF + 1) * 2^S
*/
mf = (PLPRCR_val(MFI) + PLPRCR_val(MFN)/(PLPRCR_val(MFD)+1));
factor = (PLPRCR_val(MFI) + PLPRCR_val(MFN)/(PLPRCR_val(MFD)+1))/
(PLPRCR_val(PDF)+1) / (1im_clkrst.car_sccr & SCCR_RTSEL) == 0 || mf > 2) {
return (oscclk / 4);
}
return (oscclk / 16);
}
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx linux maintenance
Please don't mind correcting me on what I said here. I would love to hear some feedback from the community, and possibly the folks at Motorola, Timesys, Montavista. Regards, David Ho Nanometrics, Inc > > Hi all, > > Just wondering, do we have a person from Motorola or a well known embedded > linux company that actively ensures the operation of the Linux kernel on > mpc8xx, 2.6 in particular? > > I noticed that is a lot of work being done by Montavista on the IBM PowerPC > chips and Timesys is working heavily on the Motorola 82xx for the 2.6 > kernel. But not that much noise is made from these companies in regard to > the mpc8xx. Should this be a concern? > > Wolfgeng mentioned in his interview with Linux Device ( > http://linuxdevices.com/articles/AT2240586951.html) that 2.6 may be slow, > but if there are so many 2.6 features that are beneficial to embedded > development (http://www.linuxjournal.com/article.php?sid=7477), why is > mpc8xx , as I see it, being somewhat left behind. > > Regards, > > David Ho > Nanometrics, Inc > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx linux maintenance
Hi all, Just wondering, do we have a person from Motorola or a well known embedded linux company that actively ensures the operation of the Linux kernel on mpc8xx, 2.6 in particular? I noticed that is a lot of work being done by Montavista on the IBM PowerPC chips and Timesys is working heavily on the Motorola 82xx for the 2.6 kernel. But not that much noise is made from these companies in regard to the mpc8xx. Should this be a concern? Wolfgeng mentioned in his interview with Linux Device ( http://linuxdevices.com/articles/AT2240586951.html) that 2.6 may be slow, but if there are so many 2.6 features that are beneficial to embedded development (http://www.linuxjournal.com/article.php?sid=7477), why is mpc8xx , as I see it, being somewhat left behind. Regards, David Ho Nanometrics, Inc ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Running CompactFlash and HDD on mpc8xx
Hi all, I am looking a way to have CompactFlash and HDD working together on a MPC8xx platform. Ultimately both (IDE, IDE_CS) systems calls m8xx_ide_init_hwif_ports to initialize ATA register location/hardware. Right now this function is pretty stupid: it assumes that it is being called from the same subsystem and initialize stuff as if it is always a hard drive hanging off of the processor bus. One idea I have is to make m8xx_ide_init_hwif_ports smarter and have it identify from the parameters passed which stack it is being called from so that it can initialize to the appropriate hardware. Right now I don't see anything that can indicate/differentiate between the two. Would anyone else has any ideas about this. I would appreciate hearing your suggestions. I am cross posting this to Linux PCMCIA forums as well. Regards, David Ho Nanometrics Seimological Instruments ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
user access to physical memory
> > > > I know this question has been asked before, but I can't seem to find it in > > the archive. > > You mean a simple search for "physical memory" like this one: > > http://lists.linuxppc.org/results.html?restrict=linuxppc- > embedded&words=physical+memory > > didn't give you any results? Strange... I get quite a lot of messages. > searching for /dev/mem gave me more useful results. David ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
user access to physical memory
Hi all, I know this question has been asked before, but I can't seem to find it in the archive. How do I get access to physical memory from user space? I want to write a simple test problem to access the frame buffer directly on the LCD controller. Thanks, David Ho Nanometrics Inc. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
libjpeg
> > Is there an idiot's guide to run the configure script to generate a > > "configure --help" may help ;-) > > > makefile that uses a cross-compiler instead of the native gcc. I like to > > build it from my ix86 box. I'm getting a headache from googling... > This seems to do the trick. CC=ppc-linux-gcc ./configure --disable-shared ppc-linux --prefix=/home/davidho/usr/local David ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
libjpeg
> > I'm trying to build Qtopia-free 1.7 using ELDK 3.0 and I noticed it does > > not contain a jpeg library which is required by Qtopia/QPE. Do you know > > anyone who've already built that for the ELDK? Otherwise I'll have to > > build it myself. > > Try it out; it should be pretty straightforward. Is there an idiot's guide to run the configure script to generate a makefile that uses a cross-compiler instead of the native gcc. I like to build it from my ix86 box. I'm getting a headache from googling... David ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
libjpeg
Hi Wolfgang, I'm trying to build Qtopia-free 1.7 using ELDK 3.0 and I noticed it does not contain a jpeg library which is required by Qtopia/QPE. Do you know anyone who've already built that for the ELDK? Otherwise I'll have to build it myself. Regards, David Ho Nanometrics Inc. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
