PPC kernel hangs
On Tue, 12 Oct 2004 14:36:34 -0700, Eugene Surovegin ebs at ebshome.net wrote: Did you use ioremap to get valid kernel virtual address for your device registers? You generally cannot just use physical address to access device from the device driver. Possibly also use io_block_mapping on ppc to map a block of IO memory before ioremapping. Jon.
PPC kernel hangs
On Wed, 13 Oct 2004 00:03:21 +0100, Jon Masters jonmasters at gmail.com wrote: Possibly also use io_block_mapping on ppc to map a block of IO memory before ioremapping. Actually, in this case that's a bad idea. Ignore that. Jon.
FW: NPTL support on PPC32 (MPC5200) ?
On Tue, Oct 12, 2004 at 11:18:55PM -0600, Jim Freeman wrote: I find that I have to apply the attached patch to contrib/crosstool-0.28-rc34-nptl_fixes.patch ... [ ARCH=ppc, but dirname = powerpc/ ] The build hasn't finished yet, but at least it no longer dies at this spot. Phbbt - dies later with powerpc-8540-linux-gnu-gcc ../sysdeps/powerpc/elf/libc-start.c -c -std=gnu99 -O -Wa,-me500 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -mno-string -msoft-float -msoft-float -mnew-mnemonics -I../nptl -I../include -I. -I/opt/src/crosstool-0.28-rc37/build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/build-glibc-startfiles/csu -I.. -I../libio -I../nptl -I/opt/src/crosstool-0.28-rc37/build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/build-glibc-startfiles -I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf -I../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../nptl/sysdeps/unix/sysv/linux/powerpc -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/powerpc -I../sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/soft-fp -I../sysdeps/powerpc/nofpu -I../sysdeps/powerpc -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /opt/src/crosstool-0.28-rc37/result/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/lib/gcc/powerpc-8540-linux-gnu/3.4.2/include -isystem /opt/src/crosstool-0.28-rc37/result/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/powerpc-8540-linux-gnu/include -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -o /opt/src/crosstool-0.28-rc37/build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/build-glibc-startfiles/csu/libc-start.o -MD -MP -MF /opt/src/crosstool-0.28-rc37/build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/build-glibc-startfiles/csu/libc-start.o.dt In file included from ../sysdeps/powerpc/elf/libc-start.c:55: ../sysdeps/generic/libc-start.c: In function `generic_start_main': ../sysdeps/generic/libc-start.c:93: sorry, unimplemented: function 'generic_start_main' can never be inlined because it uses setjmp make[2]: *** [/opt/src/crosstool-0.28-rc37/build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/build-glibc-startfiles/csu/libc-start.o] Error 1 make[2]: Leaving directory `/opt/src/crosstool-0.28-rc37/build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/glibc-2.3.3/csu' make[1]: *** [csu/subdir_lib] Error 2 make[1]: Leaving directory `/opt/src/crosstool-0.28-rc37/build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/glibc-2.3.3' make: *** [csu/subdir_lib] Error 2 Tired, bed (I'm a wimp).
bridge, promiscous mode andcpm2
Thanks (After some days of holydays). Now, promiscous mode works fine, so board is bridging ok. Best regards, Alex -Original Message- From: Rune Torgersen [SMTP:runet at innovsys.com] Sent: Friday, October 08, 2004 4:02 PM To: alebas at televes.com Cc: linuxppc-embedded at ozlabs.org Subject:RE: Bridge, promiscous mode andCPM2 Hi Assuming CPM2 = 82xx or 85xx CPU. In the old 8260_io/fcc_enet.c the set_multicast_list function is present, bu has an early return nine lines in. If you delete that return, promiscous mode works great. I have no idea who or why that early return was put in, but it does disable multicast and promiscous mode on the FCC ethernets.
Embedded linux port for PowerPC ?
Mukund JB. wrote: Hello all, This is my first visit to the mailists. I have assigned to port Embedded Linux to PowerPC Board. Where do I get the Embedded Linux kernel Source code for PowerPC? Can you provide me with some documents related to porting Embedded Linux to PowerPC Board? Start reading http://www.denx.de/twiki/bin/view/DULG/Manual and http://penguinppc.org/ -- Steven
Embedded linux port for PowerPC ?
From: linuxppc-embedded-bounces at ozlabs.org [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Mukund JB. Sent: Wednesday, October 13, 2004 6:45 AM To: linuxppc-embedded at ozlabs.org Subject: Embedded linux port for PowerPC ? Hello all, This is my first visit to the mailists. I have assigned to port Embedded Linux to PowerPC Board. Where do I get the Embedded Linux kernel Source code for PowerPC? Can you provide me with some documents related to porting Embedded Linux to PowerPC Board? How do I know the available Embedded Linux ports for PowerPC? Regards, Mukund jampala See http://denx.de/e/index1.php?head=solution-se-head Download the Embedded Linux Development Kit (ELDK) from http://www.denx.de http://denx.de/e/index1.php?head=docs-headmain=docssubnav=docs-subnav; logo=logo-semainnav=docsnavbottom=bottom-se This is the #1 easiest solution (in my book at least) to a cross development environment. Read the documentation there DENX U-Boot and Linux Guide (DULG) -- while it says 8xx, it generally applies to all PowerPCs. http://www.denx.de/twiki/bin/view/DULG/Manual If you need a boot loader (quite likely), look at u-boot. Download it and read the README file for instructions on how to port it to your hardware. U-boot is also associated with Wolfgang Denks (denx.de). http://sourceforge.net/projects/u-boot Good luck and read carefully. There is a wealth of good information in those resources. gvb ** The following messages are brought to you by the Lawyers' League of IdioSpeak: ** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. **
Booting Linux using a PlanetCore BootLoader
Thanks for the reply Dan. Just before I got your mail, I was going through the fcc ethernet driver from mvista and I noticed the BCSR hack code to make the PHY work on an EP8260. I went back to the manual for the EP8280 and realized that they did something similar on this board, just as you guessed. I will add code to manage the PHY using these bits later. Meanwhile, this board also has BCSR bits to control enabling and powering on the PHY. I was able to add a bit of code to my ethernet driver and I can now see the blinking lights on the ethernet port, similar to the ones I see during tftp transfers from the boot monitors. Interestingly, the boot monitor turns off all the PHYs while the ethernet port is not being access from the boot monitor. I fail to understand the reasoning. Anyways, I am able to enable and power the PHY device and it looks like the port is seeing ethernet activity. But my driver doesn't work and complains about a TX timeout. I am sure I am missing something. Can you suggest something that I could try? Thank you. --- Dan Malek dan at embeddededge.com wrote: On Oct 12, 2004, at 5:02 PM, annamaya wrote: I am now trying to do an NFS mount of the root file system. Looks like the EP8280 uses LXT971A PHY device. I have one of their first 8260 boards that I used to do the initial Linux port long ago. At that time, they had some weird CPLD implementation of MDIO that I could never get to work properly. Not a bad idea, just didn't seem to be implemented properly. I know they have done a second revision of this board, and I suspect the 8280 is just a glue into the same location design. With that board you should have received sufficient information to determine what to do, although they have always been quite secretive about releasing enough information to successfully write software. In the interim, just compile the driver without any MDIO control, hack the call to fcc_restart() at the end of init_fcc_startup() to just force half or full duplex (0 or 1) based upon the switch you are using. Good Luck. -- Dan __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
newbie ti Embedded Linux
Hai anamayya, I need to port linux to PowerPC based Board? Could you give me some specific information about this? For example, which embedded linux kernel (not commercial) is good for this job? Regards, Mukund jampala
newbie ti Embedded Linux
VanBaren has already answered your question in detail. Use the Linux Kernel from www.denx.de and you should be fine. Once you have the kernel, start looking into the arch/ppc/ sub-directory and you will be able to find all the stuff that you will need to port your new board. And which boot monitor are you planning to use. Just like VanBaren suggested, I'd go with U-Boot. --- Mukund JB. mukundjb at esntechnologies.co.in wrote: Hai anamayya, I need to port linux to PowerPC based Board? Could you give me some specific information about this? For example, which embedded linux kernel (not commercial) is good for this job? Regards, Mukund jampala ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
MPC8560 problem to launch user application like /sbin/init
) [c0004510] [c000bf8c] [c000bcd4] [c0037644] [c00042b8] rpciodS 0 7 1 6 (L-TLB) [c0004510] [c000bf8c] [c00de400] [c00042b8] ??? nothing more ??? -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041013/174442a4/attachment.htm
I2C versus IIC
i was just about to rename some of my variables and macros to be consistent with what i *thought* was the standard nomenclature of IIC as opposed to I2C. just checked include/asm-ppc, and grepped for case-insensitive instances of both strings ... oh, god. there's really no preferred usage, is there? rday
I2C versus IIC
- Original Message - From: Robert P. J. Day [EMAIL PROTECTED] To: Embedded PPC Linux list linuxppc-embedded at ozlabs.org Sent: Wednesday, October 13, 2004 2:26 PM Subject: I2C versus IIC My vote, since nobody asked, would be I2C. I've always heard people say I squared C, and since only CBS can get superscripts out of ASCII I2C is about as close as you can get. I2C is more unique and hence a more readily recognizable acronym. But I'm sure we could get about 50/50 voting on this. Mark
Booting Linux using a PlanetCore BootLoader
I looked at the driver again and it looks like the TX and RX clock signals are board specific. I will also have to program the CMXFCR clock route register with the appropriate clocks. Am I on the right track here? --- annamaya annamaya at yahoo.com wrote: I was able to use the same driver on a PQ2-FADS board with an MPC8275 processor. Are you telling me that some of these pins are board specific? Thanks for your help. --- Dan Malek dan at embeddededge.com wrote: On Oct 13, 2004, at 10:49 AM, annamaya wrote: . But my driver doesn't work and complains about a TX timeout. I am sure I am missing something. Can you suggest something that I could try? You are going to have to track down the clock and control signals for the FCC and make sure they are still connected the same way as the 8260. Sounds like they aren't. There are #defines at the top of the driver file that map the GPIO pins to the FCC signals. -- Dan ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I2C versus IIC
On Wed, Oct 13, 2004 at 02:26:23PM -0400, Robert P. J. Day wrote: i was just about to rename some of my variables and macros to be consistent with what i *thought* was the standard nomenclature of IIC as opposed to I2C. just checked include/asm-ppc, and grepped for case-insensitive instances of both strings ... oh, god. there's really no preferred usage, is there? Philips' documentation uses I2C, not IIC, so I guess this is _official_ name of the _bus_. Some vendors (like IBM in their 4xx parts) use IIC to name I2C _interface_ to distinguish it from I2C _bus_ (they specifically mention this in the chip manual). For example, in the corresponding 4xx driver I used iic because it was written for IBM IIC _interface_. -- Eugene.
Meaning of BSP and LSP
In message 20041013193959.57540.qmail at web15605.mail.cnb.yahoo.com you wrote: I'd like to make sure about the meaning of BSP and LSP. There is sth unclear in my mind, I am afraid. Don't worry. These terms are not clearly defined at all. IMHO, BSP includes Board's Hardware Scheme and Boot Loader Code in Binary format or Source code. LSP should be composed of Development Kit like ELDK and Linux Kernel Source for special Board. I am right? No. Both BSP and LSP are terms used by peple who try to turn software into products that can be sold. They have vendor specific meanings. Some vendors may bundle boot loader code with thei BSP, others don't. Only if you buy the BSP from a hardware manufacturer there is a chance that you will receive board schematics with it; etc. etc. And LSP is just another marketing term to hide that somebody tries to sell free software the same way other RTOS vendors sell BSP's. If it includes tools or not depends again on the vendor. My recommendation: don't care about these terms. 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 management question ... is not _whether_ to build a pilot system and throw it away. You _will_ do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. - Fred Brooks, The Mythical Man Month
I2C versus IIC
-Original Message- From: linuxppc-embedded-bounces at ozlabs.org [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Eugene Surovegin Sent: Wednesday, October 13, 2004 3:34 PM To: Robert P. J. Day Cc: Embedded PPC Linux list Subject: Re: I2C versus IIC On Wed, Oct 13, 2004 at 02:26:23PM -0400, Robert P. J. Day wrote: i was just about to rename some of my variables and macros to be consistent with what i *thought* was the standard nomenclature of IIC as opposed to I2C. just checked include/asm-ppc, and grepped for case-insensitive instances of both strings ... oh, god. there's really no preferred usage, is there? Philips' documentation uses I2C, not IIC, so I guess this is _official_ name of the _bus_. Some vendors (like IBM in their 4xx parts) use IIC to name I2C _interface_ to distinguish it from I2C _bus_ (they specifically mention this in the chip manual). For example, in the corresponding 4xx driver I used iic because it was written for IBM IIC _interface_. -- Eugene. Just to mess with your minds... I2C is a trademark of Philips Electronics N.V. so that is probably not the best choice from a legalistic point of view. gvb ** The following messages are brought to you by the Lawyers' League of IdioSpeak: ** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. **
I2C versus IIC
On Wed, Oct 13, 2004 at 02:18:03PM -0600, VanBaren, Gerald (AGRE) wrote: Just to mess with your minds... I2C is a trademark of Philips Electronics N.V. so that is probably not the best choice from a legalistic point of view. It's been related to me several times that this is the reason why most implementers refer to their interface/bus as IIC in documentation. -Matt
I2C versus IIC
On Wed, Oct 13, 2004 at 02:18:03PM -0600, VanBaren, Gerald (AGRE) wrote: Just to mess with your minds... I2C is a trademark of Philips Electronics N.V. so that is probably not the best choice from a legalistic point of view. It's been related to me several times that this is the reason why most implementers refer to their interface/bus as IIC in documentation. -Matt Assuming this to be true, it still may be a bit misguided. Using 'i2c' to refer to a legal implementation is no more illegal than a restaurant putting 'Coke' on their menu. What does Philips want? They want royalties from implementations of i2c, and they do not want the term diluted by using it to refer to other similar protocols. So I don't think that just changing to 'iic' would pacify them in either of these cases. If it's truly i2c I don't think they care what you call your variables, (just so the chip manufacturer pays up) and if it's not, find a completely different name. Mark C.
I2C versus IIC
On Wed, Oct 13, 2004 at 04:48:34PM -0400, Mark Chambers wrote: On Wed, Oct 13, 2004 at 02:18:03PM -0600, VanBaren, Gerald (AGRE) wrote: Just to mess with your minds... I2C is a trademark of Philips Electronics N.V. so that is probably not the best choice from a legalistic point of view. It's been related to me several times that this is the reason why most implementers refer to their interface/bus as IIC in documentation. Assuming this to be true, it still may be a bit misguided. Using 'i2c' to refer to a legal implementation is no more illegal than a restaurant putting 'Coke' on their menu. What does Philips want? They want royalties from implementations of i2c, and they do not want the term diluted by using it to refer to other similar protocols. So I don't think that just changing to 'iic' would pacify them in either of these cases. If it's truly i2c I don't think they care what you call your variables, (just so the chip manufacturer pays up) and if it's not, find a completely different name. I was talking about the trademark infringement. You are talking about something completely different, patent-encumbered licensable technology. The naming is subject only to trademark considerations. Whether a bus implementation is subject to Philips licensing requirements (if any) is another area I'm not interested in. :) -Matt
MPC8560 problem to launch user application like /sbin/init
On Oct 13, 2004, at 1:07 PM, Laurent Lagrange wrote: The console is mapped on SCC1 port. CCSRBAR is mapped at 0xF800 and immr at 0xF808. I would suggest using the standard memory map the rest of us use for 8560. It makes the porting lots easier. I open 2 TLBs on memory and a big TLB for all IOs included CSSRBAR. Due to IO TLB, I don't io_remap cpm2_immr. How do you to this? The linux ppc kernel already manages all of this mapping for you. All things run fine until I launch the /sbin/init file from a nfs networK. Seems like a memory mapping problem. If you are using an 8260 file system, have you also enabled the math emulation in the kernel? I don't know if uboot sets other things than TLBs to access IOs and if my own boot is incomplete. I don't know if cpm must be io_remapped instead of using TLBs. The u-boot will configure all of the LAWs, and like your boot rom will also configure some of the TLBs for main memory mapping. The Linux kernel will change all of the TLBs using the boot rom TLB maps as a hint. Any ideas would be welcome. Download linuxppc-2.4 from BitKeeper, use one of the existing 85xx ports as a guide for your board. Keep things consistent with the other board ports. Take a look at one of the board ports for u-boot to see how it configures the LAWs and TLBs. -- Dan
I2C versus IIC
On Wed, Oct 13, 2004 at 01:54:44PM -0700, Matt Porter wrote: On Wed, Oct 13, 2004 at 04:48:34PM -0400, Mark Chambers wrote: On Wed, Oct 13, 2004 at 02:18:03PM -0600, VanBaren, Gerald (AGRE) wrote: Just to mess with your minds... I2C is a trademark of Philips Electronics N.V. so that is probably not the best choice from a legalistic point of view. It's been related to me several times that this is the reason why most implementers refer to their interface/bus as IIC in documentation. Assuming this to be true, it still may be a bit misguided. Using 'i2c' to refer to a legal implementation is no more illegal than a restaurant putting 'Coke' on their menu. What does Philips want? They want royalties from implementations of i2c, and they do not want the term diluted by using it to refer to other similar protocols. So I don't think that just changing to 'iic' would pacify them in either of these cases. If it's truly i2c I don't think they care what you call your variables, (just so the chip manufacturer pays up) and if it's not, find a completely different name. I was talking about the trademark infringement. You are talking about something completely different, patent-encumbered licensable technology. The naming is subject only to trademark considerations. Whether a bus implementation is subject to Philips licensing requirements (if any) is another area I'm not interested in. :) Never mind. I lied about not being interestered (damn curiousity). Here's the scoop on licensing from the Opencores I2C implementation page. http://www.opencores.org/projects.cgi/web/i2c/faq -Matt
Booting Linux using a PlanetCore BootLoader
I verified that the TX and RX clock signals are correct and the CMXFCR route register is programmed correctly for FCC2. I still see TX timeout errors. I am stumped. :-( --- Dan Malek dan at embeddededge.com wrote: On Oct 13, 2004, at 3:21 PM, annamaya wrote: I looked at the driver again and it looks like the TX and RX clock signals are board specific. I will also have to program the CMXFCR clock route register with the appropriate clocks. Am I on the right track here? Yep. :-) -- Dan __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
I2C versus IIC
On Wed, 13 Oct 2004, Eugene Surovegin wrote: Yeah, the most extreme variant being two-wire serial interface, without even mentioning I2C or IIC. You need some familiarity with bus protocol to figure out that this is really I2C :). oh, gawd, i'm sorry i started this. :-P rday
I2C versus IIC
I was talking about the trademark infringement. You are talking about something completely different, Well, actually I was talking about both issues, but here's what I think about Philips patenting i2c: It's great work if you can get it. And I think I'm going to wrap it up for the day, and if i2c is still here when I get up in the morning I'm going to throw it out on its ear. Mark
PPC kernel hangs
On Tue, Oct 12, 2004 at 04:34:32PM -0700, Eugene Surovegin wrote: On Wed, Oct 13, 2004 at 12:03:21AM +0100, Jon Masters wrote: On Tue, 12 Oct 2004 14:36:34 -0700, Eugene Surovegin ebs at ebshome.net wrote: Did you use ioremap to get valid kernel virtual address for your device registers? You generally cannot just use physical address to access device from the device driver. Possibly also use io_block_mapping on ppc to map a block of IO memory before ioremapping. Yes, this is possible but considered obsoleted and not-recommended way of accessing device registers. I realised that after I said it, old habbit. Jon.
Booting Linux using a PlanetCore BootLoader
On Oct 13, 2004, at 5:23 PM, annamaya wrote: I verified that the TX and RX clock signals are correct and the CMXFCR route register is programmed correctly for FCC2. I still see TX timeout errors. I am stumped. :-( Do you have the FCC MAC set up properly for full or half duplex? If you don't have MDIO working, you are going to have to force this to the proper setting for your switch. I mentioned this in a previous message. If that doesn't work, take a look at the CPM memory map and ensure the special FCC area is mapped properly. I don't remember if the 8280 has the big CPM like the 8260, or the small one like the 8272. There is a configuration option that moves this memory address for the FCC fifos and special buffers. -- Dan
FW: NPTL support on PPC32 (MPC5200) ?
The attached script (wrapper/setup to crosstool.sh) gets me
a toolchain sufficient to build the default-config ppc kernel
(2.6.8.1, NPTL, gcc-3.4.2, glibc-2.3.3).
It tweaks the patch Dan references below for a ppc-ism,
then adds a patch (thanks Google!) to mask an issue that
gcc-3.4.2 has with inline functions calling setjmp() ( see
http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/ftp.suse.com/pub/projects/powerpc/ftp.linuxppc64.org/pub/people/janis/old/README.20040130
)
The toolchain build fails near the end while linking
build-glibc/elf/sln with undefined references to
`_Unwind_Resume' and `__gcc_personality_v0' (which Google
hints is/was a popular problem, but I don't have time to
track it down). In any case, 'sln' isn't needed for kernel
building, so it's good enough for me for now.
...jfree
On Tue, Oct 12, 2004 at 08:29:58AM -0700, Dan Kegel wrote:
Hi Stephen,
to build NPTL, you need to apply
contrib/crosstool-0.28-rc34-nptl_fixes.patch
Then see demo-x86_64-nptl.sh
Enough people need this that I've been intending for two weeks to merge it
asap,
but I haven't gotten around to it.
That patch was only tested for x86, but ppc32 shouldn't be any
harder, right? :-)
- Dan
Stephen Warren wrote:
Hi. I'm attempting to use your crosstool to build a NPTL capable GLIBC
and toolchain for a 32-bit PowerPC target.
...
Thanks for any pointers at all!
Subject: NPTL support on PPC32 (MPC5200) ?
From: Stephen Warren SWarren at nvidia.com
...
My question is - can anybody tell me, or point me at a website that
definitively tells me:
1) Is NPTL available on PPC at all? I assume so, since I found one of
the original announcement of NPTL, which mentions performance on a large
SMP PPC system.
...
-- next part --
#!/bin/bash
set -x
# http://kegel.com/crosstool/
# http://sources.redhat.com/ml/binutils/2003-10/msg00448.html
# http://sources.redhat.com/ml/crossgcc/2004-03/msg00162.html
# http://sources.redhat.com/ml/binutils/2001-10/msg00186.html
##
http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/ftp.suse.com/pub/projects/powerpc/ftp.linuxppc64.org/pub/people/janis/old/README.20040130
##
http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/ftp.suse.com/pub/projects/powerpc/ftp.linuxppc64.org/pub/people/janis/old/glibc.patch.20040121
;
[ ! -f crosstool-0.28-rc37.tar.gz ] \
wget http://kegel.com/crosstool/crosstool-0.28-rc37.tar.gz || true
tar xzf crosstool-0.28-rc37.tar.gz
cd crosstool-0.28-rc37
pwd
## NPTL patch: when ARCH=ppc, dirname needs to be powerpc
## patch the patch ...
patch -p 0 HERE
--- contrib/crosstool-0.28-rc34-nptl_fixes.patch2004/10/13 04:48:11
1.1
+++ contrib/crosstool-0.28-rc34-nptl_fixes.patch2004/10/13 04:48:45
@@ -164,7 +164,7 @@
+# will have to manually be copied from under the tree of the desired
+# target pthread implementation.
+cp \${GLIBC_DIR}/nptl/sysdeps/pthread/pthread.h \$HEADERDIR/pthread.h
-+cp
\${GLIBC_DIR}/nptl/sysdeps/unix/sysv/linux/\${ARCH}/bits/pthreadtypes.h
\$HEADERDIR/bits/pthreadtypes.h
++cp
\${GLIBC_DIR}/nptl/sysdeps/unix/sysv/linux/\${ARCH/ppc/powerpc}/bits/pthreadtypes.h
\$HEADERDIR/bits/pthreadtypes.h
+
+# On s390, powerpc and sparc we also require bits/wordsize.h.
+case \$TARGET in
HERE
# now apply the patch ...
patch -p 1 contrib/crosstool-0.28-rc34-nptl_fixes.patch
## gcc3.4.2 disallows setjmp() in inline functions:
##
http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/ftp.suse.com/pub/projects/powerpc/ftp.linuxppc64.org/pub/people/janis/old/README.20040130
## then fixup to only use first part of patch (and doctor for patch -p1) ...
( cd patches/glibc-2.3.3;
wget
http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/ftp.suse.com/pub/projects/powerpc/ftp.linuxppc64.org/pub/people/janis/old/glibc.patch.20040121
;
ed glibc.patch.20040121 HERE
/Makefile
.,\$d
,s#sysdeps#foo/sysdeps#g
wq
HERE
)
TARBALLS_DIR=`pwd`/.. \
TARGET=powerpc-8540-linux-gnu \
TARGET_CFLAGS=-O -msoft-float -mno-string -Wa,-me500 \
GCC_EXTRA_CONFIG= \
GCC_LANGUAGES=c \
GLIBC_EXTRA_CONFIG=--without-fp \
GLIBC_ADDON_NPTL=1 \
BINUTILS_DIR=binutils-2.15 \
GCC_DIR=gcc-3.4.2 \
GLIBC_DIR=glibc-2.3.3 \
LINUX_DIR=linux-2.6.8.1 \
./all.sh --testlinux
# now,
# cd build/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/linux-2.6.8.1
# ( or wherever your kernel of interest lives )
# make V=1 ARCH=ppc
CROSS_COMPILE=/work/src/crosstool-0.28-rc37/result/powerpc-8540-linux-gnu/gcc-3.4.2-glibc-2.3.3/bin/powerpc-8540-linux-gnu-
MPC8560 problem to launch user application like /sbin/init
Have you turned on emulation of FP in the kernel? - kumar On Oct 13, 2004, at 4:01 PM, Dan Malek wrote: On Oct 13, 2004, at 1:07 PM, Laurent Lagrange wrote: The console is mapped on SCC1 port. CCSRBAR is mapped at 0xF800 and immr at 0xF808. I would suggest using the standard memory map the rest of us use for 8560.? It makes the porting lots easier. I open 2 TLBs on memory and a big TLB for all IOs included CSSRBAR. Due to IO TLB, I don't io_remap cpm2_immr. How do you to this?? The linux ppc kernel already manages all of this mapping for you. All things run fine until I launch the /sbin/init file from a nfs networK. Seems like a memory mapping problem.? If you are using an 8260 file system, have you also enabled the math emulation in the kernel? I don't know if uboot sets other things than TLBs to access IOs and if my own boot is incomplete. I don't know if cpm must be io_remapped instead of using TLBs. The u-boot will configure all of the LAWs, and like your boot rom will also configure some of the TLBs for main memory mapping. The Linux kernel will change all of the TLBs using the boot rom TLB maps as a hint. Any ideas would be welcome. Download linuxppc-2.4 from BitKeeper, use one of the existing 85xx ports as a guide for your board.? Keep things consistent with the other board ports.? Take a look at one of the board ports for u-boot to see how it configures the LAWs and TLBs. ??? -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
