From jmauricio at mexico.com Wed Apr 9 02:28:20 2003 From: jmauricio at mexico.com (Jorge Mauricio Hernandez) Date: Wed, 09 Apr 2003 00:28:20 +0800 Subject: Power 3-II Message-ID: <20030408162820.18896.qmail@mexico.com> Anybody knows if LINUX can be install in Risc 6000 Power3-II? more accurately in model 7028-6E1 or who is working on it. Thanks in advance. PS Sorry my poor english. -- _______________________________________________ http://mail.mexico.com ?Disponible Ya! Utiliza el Outlook y Outlook Express para bajar tus correos por solo US$24.95 al a?o Now available! Download your mail into your computer with Outlook and Outlook Express US$24.95/yr Powered by www.M3xico.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From kaena at us.ibm.com Wed Apr 9 03:17:16 2003 From: kaena at us.ibm.com (Kaena Freitas) Date: Tue, 8 Apr 2003 12:17:16 -0500 Subject: Power 3-II Message-ID: Hello Jorge - SLES 8 supports this pSeries hardware. You can view more on the following website: http://www-1.ibm.com/servers/eserver/pseries/linux/ Aloha, Kaena D. Kaena Freitas Linux on pSeries Release Architect kaena at us.ibm.com Office: (512)838-2676 cell: (512)762-3884 "Jorge Mauricio Hernandez" To: linuxppc64-dev at lists.linuxppc.org Sent by: cc: owner-linuxppc64-dev at lists.l Subject: Power 3-II inuxppc.org 04/08/2003 11:28 AM Anybody knows if LINUX can be install in Risc 6000 Power3-II? more accurately in model 7028-6E1 or who is working on it. Thanks in advance. PS Sorry my poor english. -- ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Thu Apr 10 00:53:15 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Wed, 9 Apr 2003 16:53:15 +0200 Subject: Additional machines for the list of supported machines on http://www.penguinppc64.org/boxes.shtml Message-ID: The list isn't upto date. D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ----- Forwarded by Denis J Barrow/Germany/Contr/IBM on 04/09/03 04:54 PM ----- Denis J Barrow To: engebret at us.ibm.com, jsmith at penguinppc.org, 04/09/03 04:50 PM grifter at penguinppc.org cc: From: Denis J Barrow/Germany/Contr/IBM at IBMDE Subject: Additional machines for the list of supported machines on http://www.penguinppc64.org/boxes.shtml The 630 and 650 are supported. See http://www-1.ibm.com/servers/eserver/pseries/linux/ D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From froetschl at 8hertz.com Fri Apr 11 05:57:42 2003 From: froetschl at 8hertz.com (=?ISO-8859-1?Q?Bernhard_Fr=F6tschl?=) Date: Thu, 10 Apr 2003 21:57:42 +0200 Subject: Problem installing redhat on pSeries 610 References: Message-ID: <3E95CCB6.3030508@8hertz.com> Hi all, We have a Problem installing redhat on pSeries 610, model 6C1 Just got a SCSI CDROM and connected it to the internal SCSI-bus. Problem now: The exact syntax to boot from there. I tried commands like: boot /pci at fef00000/scsi at c/sd at a:0,\ppc\bootinfo.txt After that, the cdrom-drive will be accessed (blinking red), but the system will not boot. After some Minutes (!) the screen flashes and the ok-prompt appears. And I can try again ... I think I have to replace sd at a:0 with something else, but I do not know which device-adress the cdrom has. Could you help us with the syntax and the meaning of the parameters? Regards, Bernhard Fr?tschl 8hertz.com ********************************************************************************* > Hello all, > > thanks for the info. Wouldn't it be possible to load the install > kernel from the scsi harddisk or over ethernet? Exactly. Or via a SCSI CDROM, they aren't that hard to find. > What would the syntax be like in open firmware for booting over the > ethernet? Yes that would work too. > Which filesystems does open firmware support? Not much. Essentially MSDOS (for grabbing off of floppy) and ISO9660. Yaboot on the other hand has the brain to read ext2, ext3, Reiser and so on. > I've got two scsi harddisk in the p610. One of them contains a AIX > 5.1 Installation. The other one is empty. Can I just copy the redhat > install files to the scsi harddisk with AIX installed and boot from > that? How would the OF syntax look like in this case? Hmmm well you'd need to cross build some utilities on AIX, like fdisk, the e2fsprogs ... but probably not toooo hard in the grand scheme of things. You might consider looking at the linux from scratch web site. > > Any help is appreciated, since we don't have a scsi cd-rom drive here > to boot from. Also we really would like to install redhat on this > machine, since we are all familiar with it. Open firmware is still a > bit tricky for us. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From tom_gall at vnet.ibm.com Fri Apr 11 07:24:07 2003 From: tom_gall at vnet.ibm.com (Tom Gall) Date: Thu, 10 Apr 2003 16:24:07 -0500 Subject: Problem installing redhat on pSeries 610 In-Reply-To: <3E95CCB6.3030508@8hertz.com> Message-ID: On Thursday, April 10, 2003, at 02:57 PM, Bernhard Fr?tschl wrote: > Hi all, > We have a Problem installing redhat on pSeries 610, model 6C1 > Just got a SCSI CDROM and connected it to the internal SCSI-bus. > > Problem now: The exact syntax to boot from there. I tried commands > like: > boot /pci at fef00000/scsi at c/sd at a:0,\ppc\bootinfo.txt > After that, the cdrom-drive will be accessed (blinking red), but the > system > will not boot. After some Minutes (!) the screen flashes and the > ok-prompt > appears. And I can try again ... Hi Bernhard! Assuming this is the device: boot /pci at fef00000/scsi at c/sd at a:1,\ppc\bootinfo.txt Note the change from 0 to 1! That indicates which "partition" to load from. You should also be able to use the multi-boot menu (F1 at bootup instead of F8) and choose the device to boot from. Enjoy! > I think I have to replace sd at a:0 with something else, but I do not know > which device-adress the cdrom has. > Could you help us with the syntax and the meaning of the > parameters? > > Regards, > Bernhard Fr?tschl > 8hertz.com Tom Gall - [Embedded] [PPC64 | PPC32] Linux Peace, Love & Linux "Where's the kaboom? There was Technology Center supposed to be an earth shattering (w) tom_gall at vnet.ibm.com kaboom! " -- Marvin Martian (h) tgall at rochcivictheatre.org ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Wed Apr 16 00:54:26 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Tue, 15 Apr 2003 20:24:26 +0530 Subject: Preparing toolchain on a Pentium III Redhat 7.0 Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A0D@chn-ex02.cvns.corp.covansys.com> Hello, I acquired a p630 6E4 with a AIX 5.1 (target operating system with no development environment) on it. My goal is to install a PPC64 linux on it. However, progress was completely blocked because AIX 5.1 is not receptive to GNU tools. So I acquired a Pentium III with Redhat 7.0 and used CVS to download latest sources for the kernel, binutils, gcc & glibc - this is with the hope of cross building the toolchain and cross compiling the kernel. In the url http://penguinppc64.org/toolchain.shtml, the configuration parameters for "binutils" for the first pass state "--target=powerpc-linux". Should this not be "--target=powerpc64-linux" instead? When I execute "config.guess" on the Pentium III Redhat 7.0, I receive the output "i686-pc-linux-gnu". So, when I set up the configuration parameters for the cross-build, should I replace every occurence of "powerpc-linux" (displayed in the url) to "i686-pc-linux-gnu" and at the same time keep every occurence of "powerpc64-linux" the same? Is it possible to cross build the PPC64 kernel and toolchain even though the Pentium III is a 32 bit machine? I really would appreciate an answer Thanks Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jan at smith.pp.se Wed Apr 16 05:48:56 2003 From: jan at smith.pp.se (Jan Smith) Date: 15 Apr 2003 21:48:56 +0200 Subject: Preparing toolchain on a Pentium III Redhat 7.0 In-Reply-To: <207D6ADFC044A84686D44CA11B297EEA02018A0D@chn-ex02.cvns.corp.covansys.com> References: <207D6ADFC044A84686D44CA11B297EEA02018A0D@chn-ex02.cvns.corp.covansys.com> Message-ID: <1050436136.24574.9.camel@frodo.smith.pp.se> On Tue, 2003-04-15 at 16:54, VAKKALANKA RAO Sridhar wrote: > Hello, > > I acquired a p630 6E4 with a AIX 5.1 (target operating system with no development environment) on it. My goal is to install a PPC64 linux on it. However, progress was completely blocked because AIX 5.1 is not receptive to GNU tools. So I acquired a Pentium III with Redhat 7.0 and used CVS to download latest sources for the kernel, binutils, gcc & glibc - this is with the hope of cross building the toolchain and cross compiling the kernel. > > In the url http://penguinppc64.org/toolchain.shtml, the configuration parameters for "binutils" for the first pass state "--target=powerpc-linux". Should this not be "--target=powerpc64-linux" instead? > > When I execute "config.guess" on the Pentium III Redhat 7.0, I receive the output "i686-pc-linux-gnu". So, when I set up the configuration parameters for the cross-build, should I replace every occurence of "powerpc-linux" (displayed in the url) to "i686-pc-linux-gnu" and at the same time keep every occurence of "powerpc64-linux" the same? > > Is it possible to cross build the PPC64 kernel and toolchain even though the Pentium III is a 32 bit machine? > > I really would appreciate an answer I'd really sugest you to use another version of RH as just v7.0 has a totally broken gcc. Choose 8.0 or 9 instead or if you want to use an old version take v6.2. gcc v2.96 which is a beta version of GCC3 are building very bad binaries. Another solutions is to install a 32bit PPC-Linux and start from there. That will probably be much easier. I've tried to do that for the kernel on a pSeries 640 B80 with great success. But it was just a test as I didn't have any 64bit glibc at that time. (There were no one available 18 months ago.) Good luck /Jan Smith ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From streeter at redhat.com Wed Apr 16 06:15:15 2003 From: streeter at redhat.com (Guy M. Streeter) Date: 15 Apr 2003 15:15:15 -0500 Subject: Preparing toolchain on a Pentium III Redhat 7.0 In-Reply-To: <1050436136.24574.9.camel@frodo.smith.pp.se> References: <207D6ADFC044A84686D44CA11B297EEA02018A0D@chn-ex02.cvns.corp.covansys.com> <1050436136.24574.9.camel@frodo.smith.pp.se> Message-ID: <1050437715.1050.29.camel@jarjar.hsv.redhat.com> The version of gcc that is already on the system makes very little difference, since you are building a new compiler. gcc 2.96 is a fine compiler for x86, and is more than sufficient for bootstrapping a new compiler. I'm fairly sure that the toolchain instructions on linucppc64.org are instructions for building the toolchain on a ppc system. I expect that a considerable amount of additional work would be necessary to create a cross-build ppc64 toolchain on an x86 system. Additionally, parts of the kernel build process depend on a native 32bit ppc compiler. If you want to build the kernel for ppc64 on an x86 system, you will need to create a 32bit ppc cross-build toolchain, and modify parts of the kernel Makefiles to invoke it where the 32bit ppc compiler is expected. It will be far easier to build the ppc64 kernel on a ppc system. --Guy On Tue, 2003-04-15 at 14:48, Jan Smith wrote: > On Tue, 2003-04-15 at 16:54, VAKKALANKA RAO Sridhar wrote: > > Hello, > > > > I acquired a p630 6E4 with a AIX 5.1 (target operating system with no development environment) on it. My goal is to install a PPC64 linux on it. However, progress was completely blocked because AIX 5.1 is not receptive to GNU tools. So I acquired a Pentium III with Redhat 7.0 and used CVS to download latest sources for the kernel, binutils, gcc & glibc - this is with the hope of cross building the toolchain and cross compiling the kernel. > > > > In the url http://penguinppc64.org/toolchain.shtml, the configuration parameters for "binutils" for the first pass state "--target=powerpc-linux". Should this not be "--target=powerpc64-linux" instead? > > > > When I execute "config.guess" on the Pentium III Redhat 7.0, I receive the output "i686-pc-linux-gnu". So, when I set up the configuration parameters for the cross-build, should I replace every occurence of "powerpc-linux" (displayed in the url) to "i686-pc-linux-gnu" and at the same time keep every occurence of "powerpc64-linux" the same? > > > > Is it possible to cross build the PPC64 kernel and toolchain even though the Pentium III is a 32 bit machine? > > > > I really would appreciate an answer > > I'd really sugest you to use another version of RH as just v7.0 has a > totally broken gcc. Choose 8.0 or 9 instead or if you want to use an old > version take v6.2. gcc v2.96 which is a beta version of GCC3 are > building very bad binaries. > Another solutions is to install a 32bit PPC-Linux and start from there. > That will probably be much easier. I've tried to do that for the kernel > on a pSeries 640 B80 with great success. But it was just a test as I > didn't have any 64bit glibc at that time. (There were no one available > 18 months ago.) > > Good luck > > /Jan Smith > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From amodra at bigpond.net.au Wed Apr 16 11:59:38 2003 From: amodra at bigpond.net.au (Alan Modra) Date: Wed, 16 Apr 2003 11:29:38 +0930 Subject: Preparing toolchain on a Pentium III Redhat 7.0 In-Reply-To: <1050437715.1050.29.camel@jarjar.hsv.redhat.com> References: <207D6ADFC044A84686D44CA11B297EEA02018A0D@chn-ex02.cvns.corp.covansys.com> <1050436136.24574.9.camel@frodo.smith.pp.se> <1050437715.1050.29.camel@jarjar.hsv.redhat.com> Message-ID: <20030416015937.GN1189@bubble.sa.bigpond.net.au> On Tue, Apr 15, 2003 at 03:15:15PM -0500, Guy M. Streeter wrote: > I'm fairly sure that the toolchain instructions on linucppc64.org are > instructions for building the toolchain on a ppc system. I expect that a > considerable amount of additional work would be necessary to create a > cross-build ppc64 toolchain on an x86 system. It's really no more difficult. You're cross-compiling in both cases. The thing that makes things difficult is that the instructions on the web-site aren't exactly comprehensive enough.. > Additionally, parts of the kernel build process depend on a native > 32bit ppc compiler. If you want to build the kernel for ppc64 on an x86 > system, you will need to create a 32bit ppc cross-build toolchain, and > modify parts of the kernel Makefiles to invoke it where the 32bit ppc > compiler is expected. True. > It will be far easier to build the ppc64 kernel on a ppc system. I regularly build on x86, and once the toolchains are built there's no difference. > > On Tue, 2003-04-15 at 16:54, VAKKALANKA RAO Sridhar wrote: > > > In the url http://penguinppc64.org/toolchain.shtml, the configuration parameters for "binutils" for the first pass state "--target=powerpc-linux". Should this not be "--target=powerpc64-linux" instead? No, you're building ppc32 and ppc64 capable binutils. > > > When I execute "config.guess" on the Pentium III Redhat 7.0, I receive the output "i686-pc-linux-gnu". So, when I set up the configuration parameters for the cross-build, should I replace every occurence of "powerpc-linux" (displayed in the url) to "i686-pc-linux-gnu" and at the same time keep every occurence of "powerpc64-linux" the same? No. > > > Is it possible to cross build the PPC64 kernel and toolchain even though the Pentium III is a 32 bit machine? Yes. On my x86 box, I use the following configure lines /src/binutils-current/configure --prefix=/usr/local \ --build=i586-linux --host=i586-linux --target=powerpc-linux \ --enable-targets=powerpc64-linux --disable-nls /src/gcc-ppc64-33/configure --prefix=/usr/local \ --build=i686-linux --host=i686-linux --target=powerpc64-linux \ --disable-nls --with-headers=/usr/local/powerpc64-linux/include \ --enable-languages=c,c++,f77 /src/libc-current/configure --prefix=/usr/local/powerpc64-linux \ --build=i686-linux --host=powerpc64-linux --target=powerpc64-linux \ --with-headers=/src/linux-2.5.67-ppc/include --without-cvs --enable-add-ons \ --enable-shared --disable-sanity-checks These are suitable once you already have a toolchain installed. It's a little more difficult getting the very first toolchain built! For instance, the first gcc build needs to --disable-shared --disable-threads --enable-languages=c and you don't have headers. In fact, even with these options, lack of headers will cause a failure in the build of libgcc, but it's possible to hack around that by disabling the code that needs the missing headers. Or you can cheat and use headers from some other arch (x86 even) given that the first gcc only needs to be able to build the kernel and glibc. -- Alan Modra IBM OzLabs - Linux Technology Centre ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Wed Apr 23 17:27:20 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Wed, 23 Apr 2003 12:57:20 +0530 Subject: Preparing toolchain on a Pentium III Redhat 7.0 Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A14@chn-ex02.cvns.corp.covansys.com> > > > > Is it possible to cross build the PPC64 kernel and toolchain even though the Pentium III is a 32 bit machine? > Yes. On my x86 box, I use the following configure lines > /src/binutils-current/configure --prefix=/usr/local \ > --build=i586-linux --host=i586-linux --target=powerpc-linux \ > --enable-targets=powerpc64-linux --disable-nls > /src/gcc-ppc64-33/configure --prefix=/usr/local \ > --build=i686-linux --host=i686-linux --target=powerpc64-linux \ > --disable-nls --with-headers=/usr/local/powerpc64-linux/include \ > --enable-languages=c,c++,f77 > /src/libc-current/configure --prefix=/usr/local/powerpc64-linux \ > --build=i686-linux --host=powerpc64-linux --target=powerpc64-linux \ > --with-headers=/src/linux-2.5.67-ppc/include --without-cvs --enable-add-ons \ > --enable-shared --disable-sanity-checks > These are suitable once you already have a toolchain installed. It's > a little more difficult getting the very first toolchain built! For > instance, the first gcc build needs to --disable-shared --disable-threads > --enable-languages=c and you don't have headers. In fact, even with > these options, lack of headers will cause a failure in the build of > libgcc, but it's possible to hack around that by disabling the code > that needs the missing headers. Or you can cheat and use headers > from some other arch (x86 even) given that the first gcc only needs to > be able to build the kernel and glibc. Okay, I have reached a point the first pass has been completed for gcc and binutils. I made a few discoveries that must have known to experienced folks for a long time: (1) The original (Redhat) 2.96 gcc first looks for include files in the path /usr/lib/gcc-lib/i386-redhat-linux/2.96/include before looking for them anywhere else. The next default search, obviously, is /usr/include. Now, the gcc (vers. 3.3) compiler that I built looks only for files in the path /opt/ppc64/lib/gcc-lib/powerpc64-linux/3.3/include and nowhere else (for the configuration example given above, the search path would be /usr/local/lib/gcc-lib/powerpc64-linux/3.3/include). So, how do I configure my cross-compile gcc such that it makes subsequent path searches without forcing me to add the -I flag to the Makefiles. (2) I managed to get around the above problem for now. When building the kernel, I executed the "make mrproper", "make oldconfig" (because "make config" asks too many hardware questions that I don't have answers to) and "make dep" in the same order as specified by the instructions. Executing "make dep" caused a problem - it generated an executable called "mkdep" which is targeted for powerpc64-linux and not for i686-linux. In order to step further into the compilation process, the Makefile tries to execute "mkdep" and I get the error that "mkdep" cannot execute on this machine. How do I get around that? I would much appreciate an answer. Thanks in advance Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From gb at clozure.com Sun Apr 27 10:27:42 2003 From: gb at clozure.com (Gary Byers) Date: Sat, 26 Apr 2003 18:27:42 -0600 (MDT) Subject: 2.5 kernel on Power3 Message-ID: Hi. I've been trying for some time (off and on ...) to build a working 2.5 kernel for a Power3 system (a dual-processor 43P/260). I've been compiling with an up-to-date CVS+patches GCC 3.3, and have tried using both the 2.5.66 source from kernel.org and the bk treee from source.scl.amselab.gov. In all of my attempts, I've just done "make menuconfig" and saved the generated .config file. Nothing in that .config loooks grossly implausible to me, but I suppose that it might to someone who actually knew what they were doing ... The generated kernels all hang at the same point (the last message is "returning from prom_init"). I've tried pulling the video card (a repackaged Matrox Mystique, or something like it) and the only difference is that the "returning from prom_init" message is diverted to a serial console. There are probably lots of subtle things that could be going wrong at this point; it'd certainly be nice if there was something blatant and obvious at the root of the problem ... Is anyone running 2.5.x on a Power3 ? If not, is this known not to work currently ? If so, was it necessary to change any of the configuration defaults (or do something else differently from what I've tried ?) Thanks in advance for any suggestions. Gary Byers gb at clozure.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From tinglett at vnet.ibm.com Mon Apr 28 22:49:04 2003 From: tinglett at vnet.ibm.com (Todd Inglett) Date: 28 Apr 2003 07:49:04 -0500 Subject: 2.5 kernel on Power3 In-Reply-To: References: Message-ID: <1051534143.32383.6.camel@q.rchland.ibm.com> On Sat, 2003-04-26 at 19:27, Gary Byers wrote: > Hi. > > I've been trying for some time (off and on ...) to build a working > 2.5 kernel for a Power3 system (a dual-processor 43P/260). I've > been compiling with an up-to-date CVS+patches GCC 3.3, and have tried > using both the 2.5.66 source from kernel.org and the bk treee from > source.scl.amselab.gov. Hmm...the ameslab tree should work. At least I always test it on my 2-way 44P/270 which is very similar to your 260. [...] > The generated kernels all hang at the same point (the last message > is "returning from prom_init"). I've tried pulling the video > card (a repackaged Matrox Mystique, or something like it) and the > only difference is that the "returning from prom_init" message is > diverted to a serial console. Eliminating the video adapter was a good move. The console should now go to ttyS0, but you can force it with console=ttyS0 anyway (this shouldn't be needed). Do you see anything at all on the LEDs? It might be as simple as having the serial cable attached to ttyS1. I'm pretty sure the 260 has two serial ports. The next message out should be "Starting Linux PPC64 ..." and it is forced to go out ttyS0. -- Todd Inglett ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Apr 29 01:58:59 2003 From: anton at samba.org (Anton Blanchard) Date: Tue, 29 Apr 2003 01:58:59 +1000 Subject: 2.5 kernel on Power3 In-Reply-To: <1051534143.32383.6.camel@q.rchland.ibm.com> References: <1051534143.32383.6.camel@q.rchland.ibm.com> Message-ID: <20030428155859.GB10973@krispykreme> > Hmm...the ameslab tree should work. At least I always test it on my > 2-way 44P/270 which is very similar to your 260. And Andrew Morton's tree is probably the most up to date 2.5 tree, he regularly tests on a ppc64 box. He outpaces even my tree a lot of the time :) Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From gb at clozure.com Tue Apr 29 04:00:20 2003 From: gb at clozure.com (Gary Byers) Date: Mon, 28 Apr 2003 12:00:20 -0600 (MDT) Subject: 2.5 kernel on Power3 In-Reply-To: <1051534143.32383.6.camel@q.rchland.ibm.com> Message-ID: On 28 Apr 2003, Todd Inglett wrote: > On Sat, 2003-04-26 at 19:27, Gary Byers wrote: > > Hi. > > > > I've been trying for some time (off and on ...) to build a working > > 2.5 kernel for a Power3 system (a dual-processor 43P/260). I've > > been compiling with an up-to-date CVS+patches GCC 3.3, and have tried > > using both the 2.5.66 source from kernel.org and the bk treee from > > source.scl.amselab.gov. > > Hmm...the ameslab tree should work. At least I always test it on my > 2-way 44P/270 which is very similar to your 260. > That's good to know; thanks. Since I'm just fishing: do you compile the kernel with GCC 3.3, and do you accept the default configuration ? > [...] > > The generated kernels all hang at the same point (the last message > > is "returning from prom_init"). I've tried pulling the video > > card (a repackaged Matrox Mystique, or something like it) and the > > only difference is that the "returning from prom_init" message is > > diverted to a serial console. > > Eliminating the video adapter was a good move. The console should now > go to ttyS0, but you can force it with console=ttyS0 anyway (this > shouldn't be needed). > I tried an explicit "console=ttyS0" with the video card unplugged; the exact output is: instantiating rtas at 0x000000001ffd7000... done starting cpu /cpus/PowerPC,POWER3 at 2... ok opened /pci at fef00000 open success opened /pci at fee00000 open success (translate ok) returning from prom_init and then ... silence. I tried pinging the machine several minutes after this, just in case it had somehow booted but was having difficulty telling anyone. No luck. > Do you see anything at all on the LEDs? The front panel says "E105"; I -think- that that means something like "control transferred to the OS." > It might be as simple as having > the serial cable attached to ttyS1. I'm pretty sure the 260 has two > serial ports. It does. The cable's connected to a PC running a terminal emulator at 9600/N/8/1, and it works fine as ttyS0 when I boot under a 2.4 kernel. > > The next message out should be "Starting Linux PPC64 ..." and > it is forced to go out ttyS0. > My understanding is that there's a lot that could go wrong right after the return from prom_init(): the kernel relocates itself in memory, the MMU's enabled, stacks are initialized, etc. I suppose that there's also stuff that could go wrong in prom_init() itself, if it somehow garbles information that later stages depend on. Assuming that there's nothing in the default ppc64 configuration that's inappropriate and given the fact that this is known to run on your system, it seems reasonable to be suspicious of GCC 3.3. I'll try to build a GCC 3.2 and see if that's a factor. > -- > Todd Inglett > Thanks. Gary Byers gb at clozure.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Tue Apr 29 14:32:19 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Tue, 29 Apr 2003 10:02:19 +0530 Subject: Cross compiling the kernel Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A19@chn-ex02.cvns.corp.covansys.com> Hello, The URL http://penguinppc.org/embedded/cross-compiling shows how to cross-compile the kernel for a 32-bit powerpc machine, namely, from an ix86 machine. I successfully built the toolchain for a ppc64 on an i686 (Pentium III) for both passes 1 & 2. However, I am not succeeding at compiling the kernel. Can anyone share their experiences with me on that? i.e. what sequence of steps would be required to accomplish this task? Thanks Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Tue Apr 29 16:43:48 2003 From: olh at suse.de (Olaf Hering) Date: Tue, 29 Apr 2003 08:43:48 +0200 Subject: Cross compiling the kernel In-Reply-To: <207D6ADFC044A84686D44CA11B297EEA02018A19@chn-ex02.cvns.corp.covansys.com> References: <207D6ADFC044A84686D44CA11B297EEA02018A19@chn-ex02.cvns.corp.covansys.com> Message-ID: <20030429064348.GA24061@suse.de> On Tue, Apr 29, VAKKALANKA RAO Sridhar wrote: > The URL http://penguinppc.org/embedded/cross-compiling shows how to > cross-compile the kernel for a 32-bit powerpc machine, namely, from an > ix86 machine. I successfully built the toolchain for a ppc64 on an > i686 (Pentium III) for both passes 1 & 2. However, I am not succeeding > at compiling the kernel. Can anyone share their experiences with me on > that? i.e. what sequence of steps would be required to accomplish this > task? My experience is that it works without problems. Telling us the exact error message might be a good start to fix the issue. Gruss Olaf -- USB is for mice, FireWire is for men! ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Tue Apr 29 22:49:12 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Tue, 29 Apr 2003 18:19:12 +0530 Subject: Cross compiling the kernel Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A1A@chn-ex02.cvns.corp.covansys.com> Hi Gruss, I really appreciate your help. Here are the sequence of steps taken by me: (1) Download linux-2.4.20 kernel source, patch-2.4.21-pre4, ppc64-patch-2.4.21-pre4, ppc64-patch-2.4.21-pre4-2 and unzip them all. (2) Untar the kernel source and run the three patches in the same order specified above (I had no problems). (3) Add /opt/ppc64/bin to the PATH environment variable (I followed the toolchain instructions in the URL very closely). (4) In the top level Makefile, hardcode ARCH to ppc64 (in subsequent trials, I searched for all occurences of "uname -m" and performed hardcoding for all, but that didn't work either). (5) In the same top level Makefile, set CROSS_COMPILE = powerpc64-linux- . (6) Run "make menuconfig" at the shell prompt and take care of all hardware issues. (7) Run "make dep" at the shell (there were no problems). (8) Run "make clean" at the shell (again no problems). (9) Run "make zImage" at the shell. Running "make zImage" gave the following output. powerpc64-linux-gcc -D__KERNEL__ -I/home/penguin/kernel/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -fsigned-char -msoft-float -pipe -Wno-uninitialized -mminimal-toc -fno-builtin -mtraceback=full -DKBUILD_BASENAME=main -c -o init/main.o init/main.c In file included from /home/penguin/kernel/linux/include/asm/io.h:248, from /home/penguin/kernel/linux/include/linux/blkdev.h:11, from /home/penguin/kernel/linux/include/linux/blk.h:4, from init/main.c:25: /home/penguin/kernel/linux/include/asm/eeh.h: In function `eeh_readb': /home/penguin/kernel/linux/include/asm/eeh.h:105: warning: comparison of promoted ~unsigned with constant /home/penguin/kernel/linux/include/asm/eeh.h: In function `eeh_readw': /home/penguin/kernel/linux/include/asm/eeh.h:116: warning: comparison of promoted ~unsigned with constant /home/penguin/kernel/linux/include/asm/eeh.h: In function `eeh_inb': /home/penguin/kernel/linux/include/asm/eeh.h:162: warning: comparison of promoted ~unsigned with constant /home/penguin/kernel/linux/include/asm/eeh.h: In function `eeh_inw': /home/penguin/kernel/linux/include/asm/eeh.h:177: warning: comparison of promoted ~unsigned with constant /home/penguin/kernel/linux/include/asm/unistd.h: In function `init': /home/penguin/kernel/linux/include/asm/unistd.h:442: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:442: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h: In function `write': /home/penguin/kernel/linux/include/asm/unistd.h:437: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:437: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h: In function `read': /home/penguin/kernel/linux/include/asm/unistd.h:438: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:438: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h: In function `lseek': /home/penguin/kernel/linux/include/asm/unistd.h:439: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:439: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h: In function `execve': /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:441: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h: In function `open': /home/penguin/kernel/linux/include/asm/unistd.h:442: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:442: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h: In function `waitpid': /home/penguin/kernel/linux/include/asm/unistd.h:445: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:445: error: asm-specifier for variable `__sc_5' conflicts with asm clobber list /home/penguin/kernel/linux/include/asm/unistd.h:445: confused by earlier errors, bailing out make: *** [init/main.o] Error 1 I hope you are able to help me out with this. Thanks in advance Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Tue Apr 29 23:38:32 2003 From: olh at suse.de (Olaf Hering) Date: Tue, 29 Apr 2003 15:38:32 +0200 Subject: Cross compiling the kernel In-Reply-To: <207D6ADFC044A84686D44CA11B297EEA02018A1A@chn-ex02.cvns.corp.covansys.com> References: <207D6ADFC044A84686D44CA11B297EEA02018A1A@chn-ex02.cvns.corp.covansys.com> Message-ID: <20030429133832.GA5733@suse.de> On Tue, Apr 29, VAKKALANKA RAO Sridhar wrote: > /home/penguin/kernel/linux/include/asm/unistd.h: In function `init': > /home/penguin/kernel/linux/include/asm/unistd.h:442: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list Do you use gcc3.3 or gcc3.2.x? Try this patch in case of gcc-3.3: diff -Nru a/include/asm-ppc64/unistd.h b/include/asm-ppc/unistd.h --- a/include/asm-ppc64/unistd.h Mon Feb 3 06:03:58 2003 +++ b/include/asm-ppc64/unistd.h Mon Feb 3 06:03:58 2003 @@ -244,173 +244,102 @@ #define __NR(n) #n - -#define __syscall_return(type) \ - return (__sc_err & 0x10000000 ? errno = __sc_ret, __sc_ret = -1 : 0), \ - (type) __sc_ret - -#define __syscall_clobbers \ - "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12" +/* On powerpc a system call basically clobbers the same registers like a + * function call, with the exception of LR (which is needed for the + * "sc; bnslr" sequence) and CR (where only CR0.SO is clobbered to signal + * an error return status). + */ + +#define __syscall_nr(nr, type, name, args...) \ + unsigned long __sc_ret, __sc_err; \ + { \ + register unsigned long __sc_0 __asm__ ("r0"); \ + register unsigned long __sc_3 __asm__ ("r3"); \ + register unsigned long __sc_4 __asm__ ("r4"); \ + register unsigned long __sc_5 __asm__ ("r5"); \ + register unsigned long __sc_6 __asm__ ("r6"); \ + register unsigned long __sc_7 __asm__ ("r7"); \ + \ + __sc_loadargs_##nr(name, args); \ + __asm__ __volatile__ \ + ("sc \n\t" \ + "mfcr %0 " \ + : "=&r" (__sc_0), \ + "=&r" (__sc_3), "=&r" (__sc_4), \ + "=&r" (__sc_5), "=&r" (__sc_6), \ + "=&r" (__sc_7) \ + : __sc_asm_input_##nr \ + : "cr0", "ctr", "memory", \ + "r8", "r9", "r10","r11", "r12"); \ + __sc_ret = __sc_3; \ + __sc_err = __sc_0; \ + } \ + if (__sc_err & 0x10000000) \ + { \ + errno = __sc_ret; \ + __sc_ret = -1; \ + } \ + return (type) __sc_ret + +#define __sc_loadargs_0(name, dummy...) \ + __sc_0 = __NR_##name +#define __sc_loadargs_1(name, arg1) \ + __sc_loadargs_0(name); \ + __sc_3 = (unsigned long) (arg1) +#define __sc_loadargs_2(name, arg1, arg2) \ + __sc_loadargs_1(name, arg1); \ + __sc_4 = (unsigned long) (arg2) +#define __sc_loadargs_3(name, arg1, arg2, arg3) \ + __sc_loadargs_2(name, arg1, arg2); \ + __sc_5 = (unsigned long) (arg3) +#define __sc_loadargs_4(name, arg1, arg2, arg3, arg4) \ + __sc_loadargs_3(name, arg1, arg2, arg3); \ + __sc_6 = (unsigned long) (arg4) +#define __sc_loadargs_5(name, arg1, arg2, arg3, arg4, arg5) \ + __sc_loadargs_4(name, arg1, arg2, arg3, arg4); \ + __sc_7 = (unsigned long) (arg5) + +#define __sc_asm_input_0 "0" (__sc_0) +#define __sc_asm_input_1 __sc_asm_input_0, "1" (__sc_3) +#define __sc_asm_input_2 __sc_asm_input_1, "2" (__sc_4) +#define __sc_asm_input_3 __sc_asm_input_2, "3" (__sc_5) +#define __sc_asm_input_4 __sc_asm_input_3, "4" (__sc_6) +#define __sc_asm_input_5 __sc_asm_input_4, "5" (__sc_7) #define _syscall0(type,name) \ type name(void) \ { \ - unsigned long __sc_ret, __sc_err; \ - { \ - register unsigned long __sc_0 __asm__ ("r0"); \ - register unsigned long __sc_3 __asm__ ("r3"); \ - \ - __sc_0 = __NR_##name; \ - __asm__ __volatile__ \ - ("sc \n\t" \ - "mfcr %1 " \ - : "=&r" (__sc_3), "=&r" (__sc_0) \ - : "0" (__sc_3), "1" (__sc_0) \ - : __syscall_clobbers); \ - __sc_ret = __sc_3; \ - __sc_err = __sc_0; \ - } \ - __syscall_return (type); \ + __syscall_nr(0, type, name); \ } #define _syscall1(type,name,type1,arg1) \ type name(type1 arg1) \ { \ - unsigned long __sc_ret, __sc_err; \ - { \ - register unsigned long __sc_0 __asm__ ("r0"); \ - register unsigned long __sc_3 __asm__ ("r3"); \ - \ - __sc_3 = (unsigned long) (arg1); \ - __sc_0 = __NR_##name; \ - __asm__ __volatile__ \ - ("sc \n\t" \ - "mfcr %1 " \ - : "=&r" (__sc_3), "=&r" (__sc_0) \ - : "0" (__sc_3), "1" (__sc_0) \ - : __syscall_clobbers); \ - __sc_ret = __sc_3; \ - __sc_err = __sc_0; \ - } \ - __syscall_return (type); \ + __syscall_nr(1, type, name, arg1); \ } #define _syscall2(type,name,type1,arg1,type2,arg2) \ type name(type1 arg1, type2 arg2) \ { \ - unsigned long __sc_ret, __sc_err; \ - { \ - register unsigned long __sc_0 __asm__ ("r0"); \ - register unsigned long __sc_3 __asm__ ("r3"); \ - register unsigned long __sc_4 __asm__ ("r4"); \ - \ - __sc_3 = (unsigned long) (arg1); \ - __sc_4 = (unsigned long) (arg2); \ - __sc_0 = __NR_##name; \ - __asm__ __volatile__ \ - ("sc \n\t" \ - "mfcr %1 " \ - : "=&r" (__sc_3), "=&r" (__sc_0) \ - : "0" (__sc_3), "1" (__sc_0), \ - "r" (__sc_4) \ - : __syscall_clobbers); \ - __sc_ret = __sc_3; \ - __sc_err = __sc_0; \ - } \ - __syscall_return (type); \ + __syscall_nr(2, type, name, arg1, arg2); \ } #define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \ type name(type1 arg1, type2 arg2, type3 arg3) \ { \ - unsigned long __sc_ret, __sc_err; \ - { \ - register unsigned long __sc_0 __asm__ ("r0"); \ - register unsigned long __sc_3 __asm__ ("r3"); \ - register unsigned long __sc_4 __asm__ ("r4"); \ - register unsigned long __sc_5 __asm__ ("r5"); \ - \ - __sc_3 = (unsigned long) (arg1); \ - __sc_4 = (unsigned long) (arg2); \ - __sc_5 = (unsigned long) (arg3); \ - __sc_0 = __NR_##name; \ - __asm__ __volatile__ \ - ("sc \n\t" \ - "mfcr %1 " \ - : "=&r" (__sc_3), "=&r" (__sc_0) \ - : "0" (__sc_3), "1" (__sc_0), \ - "r" (__sc_4), \ - "r" (__sc_5) \ - : __syscall_clobbers); \ - __sc_ret = __sc_3; \ - __sc_err = __sc_0; \ - } \ - __syscall_return (type); \ + __syscall_nr(3, type, name, arg1, arg2, arg3); \ } #define _syscall4(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4) \ type name(type1 arg1, type2 arg2, type3 arg3, type4 arg4) \ { \ - unsigned long __sc_ret, __sc_err; \ - { \ - register unsigned long __sc_0 __asm__ ("r0"); \ - register unsigned long __sc_3 __asm__ ("r3"); \ - register unsigned long __sc_4 __asm__ ("r4"); \ - register unsigned long __sc_5 __asm__ ("r5"); \ - register unsigned long __sc_6 __asm__ ("r6"); \ - \ - __sc_3 = (unsigned long) (arg1); \ - __sc_4 = (unsigned long) (arg2); \ - __sc_5 = (unsigned long) (arg3); \ - __sc_6 = (unsigned long) (arg4); \ - __sc_0 = __NR_##name; \ - __asm__ __volatile__ \ - ("sc \n\t" \ - "mfcr %1 " \ - : "=&r" (__sc_3), "=&r" (__sc_0) \ - : "0" (__sc_3), "1" (__sc_0), \ - "r" (__sc_4), \ - "r" (__sc_5), \ - "r" (__sc_6) \ - : __syscall_clobbers); \ - __sc_ret = __sc_3; \ - __sc_err = __sc_0; \ - } \ - __syscall_return (type); \ + __syscall_nr(4, type, name, arg1, arg2, arg3, arg4); \ } #define _syscall5(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4,type5,arg5) \ type name(type1 arg1, type2 arg2, type3 arg3, type4 arg4, type5 arg5) \ { \ - unsigned long __sc_ret, __sc_err; \ - { \ - register unsigned long __sc_0 __asm__ ("r0"); \ - register unsigned long __sc_3 __asm__ ("r3"); \ - register unsigned long __sc_4 __asm__ ("r4"); \ - register unsigned long __sc_5 __asm__ ("r5"); \ - register unsigned long __sc_6 __asm__ ("r6"); \ - register unsigned long __sc_7 __asm__ ("r7"); \ - \ - __sc_3 = (unsigned long) (arg1); \ - __sc_4 = (unsigned long) (arg2); \ - __sc_5 = (unsigned long) (arg3); \ - __sc_6 = (unsigned long) (arg4); \ - __sc_7 = (unsigned long) (arg5); \ - __sc_0 = __NR_##name; \ - __asm__ __volatile__ \ - ("sc \n\t" \ - "mfcr %1 " \ - : "=&r" (__sc_3), "=&r" (__sc_0) \ - : "0" (__sc_3), "1" (__sc_0), \ - "r" (__sc_4), \ - "r" (__sc_5), \ - "r" (__sc_6), \ - "r" (__sc_7) \ - : __syscall_clobbers); \ - __sc_ret = __sc_3; \ - __sc_err = __sc_0; \ - } \ - __syscall_return (type); \ + __syscall_nr(5, type, name, arg1, arg2, arg3, arg4, arg5); \ } -- USB is for mice, FireWire is for men! ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From gb at clozure.com Wed Apr 30 02:24:53 2003 From: gb at clozure.com (Gary Byers) Date: Tue, 29 Apr 2003 10:24:53 -0600 (MDT) Subject: 2.5 kernel on Power3 In-Reply-To: Message-ID: On Mon, 28 Apr 2003, Gary Byers wrote: > > Assuming that there's nothing in the default ppc64 configuration that's > inappropriate and given the fact that this is known to run on your > system, it seems reasonable to be suspicious of GCC 3.3. I'll try to > build a GCC 3.2 and see if that's a factor. > I'm still not sure whether that's a factor: a kernel built with GCC 3.2 (3.2.3 + latest ppc64 patch) just booted successfully, but there may have been some operator error involved in building the 3.3 compiler that failed (failure to set --host and --build correctly when building under a 64-bit 2.4 kernel.) I'd tried this several times and would find it hard (but not impossible) to believe that I botched the GCC 3.3 configuration every time. If there's evidence that a properly configured GCC 3.3 has trouble compiling a 2.5 kernel for this platform, I'll try to isolate the problem and report it; at the moment, it looks like "operator error" is a plausible explanation for the difficulties I've been having. Thanks. Gary Byers gb at clozure.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Wed Apr 30 15:16:45 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Wed, 30 Apr 2003 10:46:45 +0530 Subject: Cross compiling the kernel Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A1B@chn-ex02.cvns.corp.covansys.com> I am using gcc 3.3. Please accept my thanks for sending me this patch. Before I go further, please tell me the URL where you obtained it. Also, are there any other patches I must apply against /include/asm-ppc64 (or any other files within the kernel source tree if I am using gcc 3.3)? Thanks again Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Wed Apr 30 19:02:39 2003 From: olh at suse.de (Olaf Hering) Date: Wed, 30 Apr 2003 11:02:39 +0200 Subject: Cross compiling the kernel In-Reply-To: <207D6ADFC044A84686D44CA11B297EEA02018A1B@chn-ex02.cvns.corp.covansys.com> References: <207D6ADFC044A84686D44CA11B297EEA02018A1B@chn-ex02.cvns.corp.covansys.com> Message-ID: <20030430090239.GA5050@suse.de> On Wed, Apr 30, VAKKALANKA RAO Sridhar wrote: > I am using gcc 3.3. > > Please accept my thanks for sending me this patch. Before I go > further, please tell me the URL where you obtained it. Also, are there > any other patches I must apply against > /include/asm-ppc64 (or any other files within the > kernel source tree if I am using gcc 3.3)? I dont know if there are other patches, we made that patch to fix compilation, but it seems only the ppc32 part was submitted upstream. Gruss Olaf -- USB is for mice, FireWire is for men! ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From edrJulie at email.com Wed Apr 30 21:31:47 2003 From: edrJulie at email.com (edrJulie at email.com) Date: Wed, 30 Apr 2003 13:31:47 +0200 Subject: page Message-ID: <200304301131.GAA24956@lists.linuxppc.org> http://www.hoop-land.com Hello, This is that website I was telling you about where I got a 5% 30 year fixed. It is amazing, lenders try and compete for your business. Here it is! http://www.hoop-land.com Thanks, Bill Murphy Remove: http://www.hoop-land.com/rm.html ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/