From chiubr at muss.cis.mcmaster.ca  Thu Aug  1 13:54:21 2002
From: chiubr at muss.cis.mcmaster.ca (Rita Chiu)
Date: Wed, 31 Jul 2002 23:54:21 -0400
Subject: how to make 64bit cross compiler work
Message-ID: <web-18371808@cgpsrv1.cis.mcmaster.ca>


I am using a 43p150 machine (32bit machine, uname -m == ppc), and I am
trying to build a gcc compiler that can produce 64bit application.

I follow the instruction on http://www.penguinppc64.org/toolchain.shtml
and used binutils-2.12.1-ppc64.diff to build the binutils and
gcc-20020730-ppc64.diff.gz to build the gcc compiler.  Binutils and gcc
built and installed successfully.  However, everytime I tried to run
this compiler (powerpc64-linux-gcc), no matter what I tried to compile,
it gave me /lib/libc.so.6 error all the time. ("/lib/libc.so.6: could
not read symbols: Invalid operation").

What do I need to make this compiler work on my ppc machine (not
ppc64)?  Or this compiler can only run in a 64bit environment (64bit
kernel? or 64bit glibc?)?  I am confused on what I have just built, and
how to use it.  Please give me some advice.  Thank you very much.

Here is how I invoke the gcc:
/build/usr/local/bin/powerpc64-linux-gcc -v -I/usr/include -B/usr/lib
-L/usr/lib v.c

The error that I got is:
/lib/libc.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

The source file of v.c:
int main () { return 0; }

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/



From aprasad at in.ibm.com  Thu Aug  1 15:09:44 2002
From: aprasad at in.ibm.com (Anil K Prasad)
Date: Thu, 1 Aug 2002 10:39:44 +0530
Subject: how to make 64bit cross compiler work
Message-ID: <OF8477FB3C.17C8CCF2-ON65256C08.001BFEC6@in.ibm.com>


Hi,
64bit glibc is still not ready for ppc64 linux. You can only run 32 bit
applications, though all kernel modules and kernel is running 64 bit.


gcc64 installed on your system is for compiling kernel code and kernel
modules.

Regards,
Anil.






                      "Rita Chiu"
                      <chiubr at muss.cis.mcmaster.ca        To:       linuxppc64-dev at lists.linuxppc.org
                      >                                   cc:
                      Sent by:                            Subject:  how to make 64bit cross compiler work
                      owner-linuxppc64-dev at lists.l
                      inuxppc.org


                      08/01/2002 09:24 AM






I am using a 43p150 machine (32bit machine, uname -m == ppc), and I am
trying to build a gcc compiler that can produce 64bit application.

I follow the instruction on http://www.penguinppc64.org/toolchain.shtml
and used binutils-2.12.1-ppc64.diff to build the binutils and
gcc-20020730-ppc64.diff.gz to build the gcc compiler.  Binutils and gcc
built and installed successfully.  However, everytime I tried to run
this compiler (powerpc64-linux-gcc), no matter what I tried to compile,
it gave me /lib/libc.so.6 error all the time. ("/lib/libc.so.6: could
not read symbols: Invalid operation").

What do I need to make this compiler work on my ppc machine (not
ppc64)?  Or this compiler can only run in a 64bit environment (64bit
kernel? or 64bit glibc?)?  I am confused on what I have just built, and
how to use it.  Please give me some advice.  Thank you very much.

Here is how I invoke the gcc:
/build/usr/local/bin/powerpc64-linux-gcc -v -I/usr/include -B/usr/lib
-L/usr/lib v.c

The error that I got is:
/lib/libc.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

The source file of v.c:
int main () { return 0; }


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From bergner at brule.borg.umn.edu  Thu Aug  1 23:28:48 2002
From: bergner at brule.borg.umn.edu (Peter Bergner)
Date: Thu, 1 Aug 2002 08:28:48 -0500
Subject: how to make 64bit cross compiler work
In-Reply-To: <web-18371808@cgpsrv1.cis.mcmaster.ca>
References: <web-18371808@cgpsrv1.cis.mcmaster.ca>
Message-ID: <20020801082848.A862324@brule.borg.umn.edu>


Rita Chiu wrote:
: I am using a 43p150 machine (32bit machine, uname -m == ppc), and I am
: trying to build a gcc compiler that can produce 64bit application.

To build 64-bit applications, you will need to config, build and
install binutils, gcc and glibc.  Note that you will not be able
to execute 64-bit applications on your 32-bit 43p150 machine.
You'll need a 64-bit machine running a ppc64 kernel to do that.
In addition, the kernel that is installed on the SuSE SLES7 distro
does _not_ have the capability to execute 64-bit dynamically linked
applications...it will execute 64-bit statically linked applications
though (powerpc64-linux-gcc -static hello.c).



: I follow the instruction on http://www.penguinppc64.org/toolchain.shtml
: and used binutils-2.12.1-ppc64.diff to build the binutils and
: gcc-20020730-ppc64.diff.gz to build the gcc compiler.  Binutils and gcc
: built and installed successfully.

The toolchain you have built is only useful for compiling the Linux kernel
which does not require or use glibc.  To build 64-bit applications, you will
also need to build the 64-bit glibc.  There are some directions for building
binutils/gcc/glibc at:

    http://www.penguinppc64.org/glibc-alpha.shtml

I'm currently trying to update the directions.  If you run into trouble,
post here or jump onto #ppc64 (irc.openprojects.net).



: However, everytime I tried to run this compiler (powerpc64-linux-gcc),
: no matter what I tried to compile, it gave me /lib/libc.so.6 error all
: the time. ("/lib/libc.so.6: could not read symbols: Invalid operation").

You're trying to link against the 32-bit glibc.  That is wrong, you need
to link against the 64-bit glibc.


: What do I need to make this compiler work on my ppc machine (not
: ppc64)?  Or this compiler can only run in a 64bit environment (64bit
: kernel? or 64bit glibc?)?  I am confused on what I have just built, and
: how to use it.  Please give me some advice.  Thank you very much.

The binutils/gcc used to produce 64-bit applications are actually 32-bit
applications so they should run fine on your system, but the 64-bit
application they produce will never run on your 32-bit box.  The only
thing you are missing is the 64-bit glibc.



: Here is how I invoke the gcc:
: /build/usr/local/bin/powerpc64-linux-gcc -v -I/usr/include -B/usr/lib
: -L/usr/lib v.c

Until a properly installed 64-bit toolchain is installed (eg, via a rpm
from a distro), never, ever use any of the include files from /usr/include.
And even if you have a properly installed toolchain, never ever link against
any of the libs in /usr/lib or /lib.

Until you have a properly installed toolchain, all the *.h files in /usr/include
are for your 32-bit ppc system.  Eventually, those header files will be bi-arch
and support both ppc32 and ppc64, but until then don't use them.

The libs in /lib and /usr/lib will always be 32-bit libs so don't ever use them.
The 64-bit libs will eventually be located in /lib64 and /usr/lib64.


Peter

--
Peter Bergner Ph.D.
Linux PPC64 Kernel & GLIBC Development
IBM Rochester, MN
bergner at vnet.ibm.com


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From chiubr at muss.cis.mcmaster.ca  Fri Aug  2 06:20:24 2002
From: chiubr at muss.cis.mcmaster.ca (Rita Chiu)
Date: Thu, 01 Aug 2002 16:20:24 -0400
Subject: how to make 64bit cross compiler work
In-Reply-To: <20020801082848.A862324@brule.borg.umn.edu>
Message-ID: <web-18405069@cgpsrv1.cis.mcmaster.ca>


Hi Peter,

Thanks for your reply.

I tried to build the glibc following the instruction in this page:
http://www.penguinppc64.org/glibc-alpha.shtml.  However, I have no luck
into configuring it.  The error is that my Linux header files are TOO
OLD.  However, the kernel I am using is version 2.4.2, also it
shouldn't have check my system's
/usr/src/linux-2.4.2.SuSE/include/linux/version.h since I used
--with-headers option (right?).
Additionally, I couldn't find a <linux/version.h> under the
--with-headers directory.

The kernel souces I used for the kernel header files (--with-headers)
are from the linux-2.4.13.tar.gz file from ftp.kernel.org and I patched
in linuxppc64-2.4.13-ibm-27.patch.gz from ftp.linuxppc64.org page.  I
am not sure if this is what <PPC64 Kernel headers> means from the glibc
instruction.  Also, I am not sure if my kernel is really too old to
build the glibc.

Would you please give me some advice?  Thanks again!

The information from my system using uname -smrpv:
Linux 2.4.2 #1 Mon Mar 12 12:20:25 GMT 2001 ppc unknown

The content of /usr/src/linux-2.4.2.SuSE/include/linux/version.h:
#define UTS_RELEASE "2.4.2"
#define LINUX_VERSION_CODE 132098
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))


This is the configure command that I used:
../src/glibc-2.2.5/configure --prefix=/build/usr/local/powerpc64-linux
--with-headers=/build/kernel/linux/include --without-cvs
--enable-add-ons=linuxthreads --disable-profile --enable-shared
>/build/log/glibc-configure.log 2>&1


This is the error message that I got:
running configure fragment for
../src/glibc-2.2.5/sysdeps/unix/sysv/linux
checking installed Linux kernel header files... TOO OLD!
configure: error: GNU libc requires kernel header files from
Linux 2.0.10 or later to be installed before configuring.
The kernel header files are found usually in /usr/include/asm and
/usr/include/linux; make sure these directories use files from
Linux 2.0.10 or later.  This check uses <linux/version.h>, so
make sure that file was built correctly when installing the kernel
header
files.  To use kernel headers not from /usr/include/linux, use the
configure option --with-headers.


Best Regards,

Rita Chiu

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From ken at tossell.net  Fri Aug  2 09:28:51 2002
From: ken at tossell.net (Ken Tossell)
Date: Thu, 1 Aug 2002 19:28:51 -0400 (EDT)
Subject: how to make 64bit cross compiler work
In-Reply-To: <web-18405069@cgpsrv1.cis.mcmaster.ca>
Message-ID: <Pine.LNX.4.44.0208011928130.2766-100000@router-internal.tossell.net>


the glibc-alpha  page is ONLY for ppc64 with 64bit kernels.

ken tossell


On Thu, 1 Aug 2002, Rita Chiu wrote:

>
> Hi Peter,
>
> Thanks for your reply.
>
> I tried to build the glibc following the instruction in this page:
> http://www.penguinppc64.org/glibc-alpha.shtml.  However, I have no luck
> into configuring it.  The error is that my Linux header files are TOO
> OLD.  However, the kernel I am using is version 2.4.2, also it
> shouldn't have check my system's
> /usr/src/linux-2.4.2.SuSE/include/linux/version.h since I used
> --with-headers option (right?).
> Additionally, I couldn't find a <linux/version.h> under the
> --with-headers directory.
>
> The kernel souces I used for the kernel header files (--with-headers)
> are from the linux-2.4.13.tar.gz file from ftp.kernel.org and I patched
> in linuxppc64-2.4.13-ibm-27.patch.gz from ftp.linuxppc64.org page.  I
> am not sure if this is what <PPC64 Kernel headers> means from the glibc
> instruction.  Also, I am not sure if my kernel is really too old to
> build the glibc.
>
> Would you please give me some advice?  Thanks again!
>
> The information from my system using uname -smrpv:
> Linux 2.4.2 #1 Mon Mar 12 12:20:25 GMT 2001 ppc unknown
>
> The content of /usr/src/linux-2.4.2.SuSE/include/linux/version.h:
> #define UTS_RELEASE "2.4.2"
> #define LINUX_VERSION_CODE 132098
> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
>
>
> This is the configure command that I used:
> ../src/glibc-2.2.5/configure --prefix=/build/usr/local/powerpc64-linux
> --with-headers=/build/kernel/linux/include --without-cvs
> --enable-add-ons=linuxthreads --disable-profile --enable-shared
> >/build/log/glibc-configure.log 2>&1
>
>
> This is the error message that I got:
> running configure fragment for
> ../src/glibc-2.2.5/sysdeps/unix/sysv/linux
> checking installed Linux kernel header files... TOO OLD!
> configure: error: GNU libc requires kernel header files from
> Linux 2.0.10 or later to be installed before configuring.
> The kernel header files are found usually in /usr/include/asm and
> /usr/include/linux; make sure these directories use files from
> Linux 2.0.10 or later.  This check uses <linux/version.h>, so
> make sure that file was built correctly when installing the kernel
> header
> files.  To use kernel headers not from /usr/include/linux, use the
> configure option --with-headers.
>
>
> Best Regards,
>
> Rita Chiu
>
>
>


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From mac at melware.de  Fri Aug  2 19:28:15 2002
From: mac at melware.de (Armin Schindler)
Date: Fri, 2 Aug 2002 11:28:15 +0200 (MEST)
Subject: 32bit pointer in 64bit kernel code
In-Reply-To: <20020801082848.A862324@brule.borg.umn.edu>
Message-ID: <Pine.LNX.4.31.0208021114500.17746-100000@phoenix.one.melware.de>


Hi,

I'm new in linux ppc64 and it would be great if someone can help on
some questions. I use SuSE SLES7.

I want to port a PCI card driver to be 64bit compatible and my current
problem is how to tell the cross gcc to produce 32bit pointers.
This is necessary for a structure which is used on the PCI cards
shared memory. This structure, somthing like
struct x {
  int number;
  unsigned char * addr;
  unsigned short val;
}
need to be correctly aligned and the pointer is 32bit.

I know, I could use unsigned int here, but is there some
kind of __attribute__ for example to tell the 64bit gcc that
this is 32bit pointer ?

Thanx,
Armin


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From tinglett at vnet.ibm.com  Sat Aug  3 01:52:39 2002
From: tinglett at vnet.ibm.com (Todd Inglett)
Date: 02 Aug 2002 10:52:39 -0500
Subject: 32bit pointer in 64bit kernel code
In-Reply-To: 
	<Pine.LNX.4.31.0208021114500.17746-100000@phoenix.one.melware.de>
References: 
	<Pine.LNX.4.31.0208021114500.17746-100000@phoenix.one.melware.de>
Message-ID: <1028303560.991.43.camel@q.rchland.ibm.com>


On Fri, 2002-08-02 at 04:28, Armin Schindler wrote:
> I want to port a PCI card driver to be 64bit compatible and my current
> problem is how to tell the cross gcc to produce 32bit pointers.

Well, by "pointer" I assume you really mean a PCI bus address (or "DMA
address").  Remember that system memory addresses (what I would call a
"pointer") and PCI bus addresses are two different address spaces.  What
confuses the issue is that 32-bit machines (mainly PCs) have a
one-to-one mapping between these spaces, so you may be working with a
driver that has made this mistake.

In Linux you should use the "dma_addr_t"  as your data type for these
addresses (it is a 32-bit value by PCI definition).  You will need to
use the pci mapping functions to map between system memory addresses
(i.e. "pointers") and dma_addr_t.  These are declared in <linux/pci.h>.

The simplest such function is pci_alloc_consistent(dev, size, &bus_addr)
which will allocate "size" bytes of system memory and return its address
and it will also create the mapping for the given PCI device and return
the bus_addr (dma_addr_t).

If you are doing this on the fly with memory you have already allocated
you can use other pci mapping functions.  See
Documentation/DMA-mapping.txt for all the details.

Finally, note that bus_to_virt() and virt_to_bus() are not implemented
on ppc64 (nor on sparc64).  These functions are gone in the 2.5 kernel
anyway.  If you need to translate system addresses vs. bus addresses for
mappings you have made, you need to keep track of the address pairs.
This is rare in existing drivers but, if I recall, the SCSI middle layer
does it.

-todd


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From mac at melware.de  Sat Aug  3 02:46:53 2002
From: mac at melware.de (Armin Schindler)
Date: Fri, 2 Aug 2002 18:46:53 +0200 (MEST)
Subject: 32bit pointer in 64bit kernel code
In-Reply-To: <1028303560.991.43.camel@q.rchland.ibm.com>
Message-ID: <Pine.LNX.4.31.0208021836130.23032-100000@phoenix.one.melware.de>


Hi Todd,

thanx for your hint, but I know dma_addr_t. I think I didn't explain
my problem very good. The PCI card runs with its own CPU and software
on board. The PCI memory space is some kind of dual-ported memory.
The card now stores the data my driver wants to read in a defined structure,
which need to be aligned like my structure definition. One member of
this structure is an internal 32bit pointer which I like to define
as 32bit pointer and not u32.
I think I will change it to u32, it seems better...

Thanx,
Armin

On 2 Aug 2002, Todd Inglett wrote:

> On Fri, 2002-08-02 at 04:28, Armin Schindler wrote:
> > I want to port a PCI card driver to be 64bit compatible and my current
> > problem is how to tell the cross gcc to produce 32bit pointers.
>
> Well, by "pointer" I assume you really mean a PCI bus address (or "DMA
> address").  Remember that system memory addresses (what I would call a
> "pointer") and PCI bus addresses are two different address spaces.  What
> confuses the issue is that 32-bit machines (mainly PCs) have a
> one-to-one mapping between these spaces, so you may be working with a
> driver that has made this mistake.
>
> In Linux you should use the "dma_addr_t"  as your data type for these
> addresses (it is a 32-bit value by PCI definition).  You will need to
> use the pci mapping functions to map between system memory addresses
> (i.e. "pointers") and dma_addr_t.  These are declared in <linux/pci.h>.
>
> The simplest such function is pci_alloc_consistent(dev, size, &bus_addr)
> which will allocate "size" bytes of system memory and return its address
> and it will also create the mapping for the given PCI device and return
> the bus_addr (dma_addr_t).
>
> If you are doing this on the fly with memory you have already allocated
> you can use other pci mapping functions.  See
> Documentation/DMA-mapping.txt for all the details.
>
> Finally, note that bus_to_virt() and virt_to_bus() are not implemented
> on ppc64 (nor on sparc64).  These functions are gone in the 2.5 kernel
> anyway.  If you need to translate system addresses vs. bus addresses for
> mappings you have made, you need to keep track of the address pairs.
> This is rare in existing drivers but, if I recall, the SCSI middle layer
> does it.
>
> -todd
>


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From tinglett at vnet.ibm.com  Sat Aug  3 05:22:29 2002
From: tinglett at vnet.ibm.com (Todd Inglett)
Date: 02 Aug 2002 14:22:29 -0500
Subject: 32bit pointer in 64bit kernel code
In-Reply-To: 
	<Pine.LNX.4.31.0208021836130.23032-100000@phoenix.one.melware.de>
References: 
	<Pine.LNX.4.31.0208021836130.23032-100000@phoenix.one.melware.de>
Message-ID: <1028316150.991.50.camel@q.rchland.ibm.com>


On Fri, 2002-08-02 at 11:46, Armin Schindler wrote:
>
> Hi Todd,
>
> thanx for your hint, but I know dma_addr_t. I think I didn't explain
> my problem very good. The PCI card runs with its own CPU and software
> on board. The PCI memory space is some kind of dual-ported memory.
> The card now stores the data my driver wants to read in a defined structure,
> which need to be aligned like my structure definition. One member of
> this structure is an internal 32bit pointer which I like to define
> as 32bit pointer and not u32.
> I think I will change it to u32, it seems better...

If the pointer truly is just an opaque value to the hardware then you
can put any value you want in there.  But of course if you cast a
pointer into that u32 you are going to lose the upper bits and you won't
be able to cast it back to become a pointer again.  I'm not sure how
useful that would be.

If you really want to preserve a pointer you'll have to stuff it
somewhere (perhaps an array) and use some 32-bit token value (perhaps an
index to the array) to retrieve it.  This token value would work well in
your hardware's struct.

-todd

-todd


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From bergner at borg.umn.edu  Tue Aug  6 23:11:26 2002
From: bergner at borg.umn.edu (Peter Bergner)
Date: Tue, 6 Aug 2002 08:11:26 -0500
Subject: how to make 64bit cross compiler work
In-Reply-To: <web-18405069@cgpsrv1.cis.mcmaster.ca>
References: <20020801082848.A862324@brule.borg.umn.edu> <web-18405069@cgpsrv1.cis.mcmaster.ca>
Message-ID: <20020806131126.GA10847@congo.borg.umn.edu>


Sorry for the delay in replying, but I've been away from work...


Rita Chiu wrote:
: I tried to build the glibc following the instruction in this page:
: http://www.penguinppc64.org/glibc-alpha.shtml.  However, I have no luck
: into configuring it.  The error is that my Linux header files are TOO
: OLD.  However, the kernel I am using is version 2.4.2, also it
: shouldn't have check my system's
: /usr/src/linux-2.4.2.SuSE/include/linux/version.h since I used
: --with-headers option (right?).
: Additionally, I couldn't find a <linux/version.h> under the
: --with-headers directory.
:
: The kernel souces I used for the kernel header files (--with-headers)
: are from the linux-2.4.13.tar.gz file from ftp.kernel.org and I patched
: in linuxppc64-2.4.13-ibm-27.patch.gz from ftp.linuxppc64.org page.  I
: am not sure if this is what <PPC64 Kernel headers> means from the glibc
: instruction.  Also, I am not sure if my kernel is really too old to
: build the glibc.

Those kernel sources should be fine.  However, you'll need to do a
"make {,old,menu,x}config" and "make dep" before you can point your
GLIBC build at those header files.  Make sure you config for PPC64
and not PPC!

Peter


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From olh at suse.de  Wed Aug  7 04:23:10 2002
From: olh at suse.de (Olaf Hering)
Date: Tue, 6 Aug 2002 20:23:10 +0200
Subject: 2.4 zImage rework
In-Reply-To: <20020723012834.GM30362@bubble.sa.bigpond.net.au>
References: <20020723005749.GB20719@krispykreme> <20020723012834.GM30362@bubble.sa.bigpond.net.au>
Message-ID: <20020806202310.A4425@suse.de>


begin  On Tue, Jul 23, Alan Modra wrote:

>
> On Tue, Jul 23, 2002 at 10:57:49AM +1000, Anton Blanchard wrote:
> >
> > /usr/local/ppc64/bin/powerpc64-linux-objcopy zImage.o \
> > 	--add-section=.kernel:vmlinux=kernel-vmlinux.gz \
> > 	--set-section-flags=.kernel:vmlinux=contents,alloc,load,readonly,data
> > /usr/local/ppc64/bin/powerpc64-linux-objcopy: stnXfLy8: Bad value
> > make[1]: *** [vmlinux] Error 1
> > make[1]: Leaving directory
> > `/home/anton/ppc64/linuxppc64_2_4/arch/ppc64/boot'
> > make: *** [zImage.initrd] Error 2
> >
> > If I rm arch/ppc64/boot/zImage.o and make again it works OK.
>
> I guess zImage.o isn't being recompiled, so you're trying to add a
> .kernel section that already exists.  objcopy ought to give a better
> error message, but it sounds like you need to fix the makefile too.

Is this the right fix?

--- arch/ppc64/boot/Makefile~   Sat Aug  3 02:39:43 2002
+++ arch/ppc64/boot/Makefile    Tue Aug  6 20:20:42 2002
@@ -95,6 +95,7 @@

 vmlinux .config System.map: % : $(TOPDIR)/%
        gzip -cvf9 $(TOPDIR)/$@ > kernel-$@.gz
+       rm -f zImage.o
        $(OBJCOPY) zImage.o \
                --add-section=.kernel:$@=kernel-$@.gz \
                --set-section-flags=.kernel:$@=$(OBJCOPYFLAGS)





--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From bergner at borg.umn.edu  Wed Aug  7 06:51:57 2002
From: bergner at borg.umn.edu (Peter Bergner)
Date: Tue, 6 Aug 2002 15:51:57 -0500
Subject: 2.4 zImage rework
In-Reply-To: <20020806202310.A4425@suse.de>
References: <20020723005749.GB20719@krispykreme> <20020723012834.GM30362@bubble.sa.bigpond.net.au> <20020806202310.A4425@suse.de>
Message-ID: <20020806205157.GA21450@congo.borg.umn.edu>


On Tue, Aug 06, 2002 at 08:23:10PM +0200, Olaf Hering wrote:
:
: begin  On Tue, Jul 23, Alan Modra wrote:
:
: >
: > On Tue, Jul 23, 2002 at 10:57:49AM +1000, Anton Blanchard wrote:
: > >
: > > /usr/local/ppc64/bin/powerpc64-linux-objcopy zImage.o \
: > > 	--add-section=.kernel:vmlinux=kernel-vmlinux.gz \
: > > 	--set-section-flags=.kernel:vmlinux=contents,alloc,load,readonly,data
: > > /usr/local/ppc64/bin/powerpc64-linux-objcopy: stnXfLy8: Bad value
: > > make[1]: *** [vmlinux] Error 1
: > > make[1]: Leaving directory
: > > `/home/anton/ppc64/linuxppc64_2_4/arch/ppc64/boot'
: > > make: *** [zImage.initrd] Error 2
: > >
: > > If I rm arch/ppc64/boot/zImage.o and make again it works OK.
: >
: > I guess zImage.o isn't being recompiled, so you're trying to add a
: > .kernel section that already exists.  objcopy ought to give a better
: > error message, but it sounds like you need to fix the makefile too.
:
: Is this the right fix?
:
: --- arch/ppc64/boot/Makefile~   Sat Aug  3 02:39:43 2002
: +++ arch/ppc64/boot/Makefile    Tue Aug  6 20:20:42 2002
: @@ -95,6 +95,7 @@
:
:  vmlinux .config System.map: % : $(TOPDIR)/%
:         gzip -cvf9 $(TOPDIR)/$@ > kernel-$@.gz
: +       rm -f zImage.o
:         $(OBJCOPY) zImage.o \
:                 --add-section=.kernel:$@=kernel-$@.gz \
:                 --set-section-flags=.kernel:$@=$(OBJCOPYFLAGS)


No, we need the zImage.o to objcopy into, so we can't delete it.
An easy solution would be to just delete the section from zImage.o
before trying to add it.  I'm guessing though we're just missing
some makefile dependancy.  I'll have a look.  Anton, do you remember
what you did to get this error?

Peter


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From amodra at bigpond.net.au  Wed Aug  7 21:37:56 2002
From: amodra at bigpond.net.au (Alan Modra)
Date: Wed, 7 Aug 2002 21:07:56 +0930
Subject: 2.4 zImage rework
In-Reply-To: <20020806202310.A4425@suse.de>; from olh@suse.de on Tue, Aug 06, 2002 at 08:23:10PM +0200
References: <20020723005749.GB20719@krispykreme> <20020723012834.GM30362@bubble.sa.bigpond.net.au> <20020806202310.A4425@suse.de>
Message-ID: <20020807210756.E20056@bubble.sa.bigpond.net.au>


On Tue, Aug 06, 2002 at 08:23:10PM +0200, Olaf Hering wrote:
> Is this the right fix?

Nope.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From engebret at vnet.ibm.com  Fri Aug  9 08:59:11 2002
From: engebret at vnet.ibm.com (Dave Engebretsen)
Date: Thu, 08 Aug 2002 17:59:11 -0500
Subject: 2.5 htab.c
Message-ID: <3D52F7BF.37A65FF0@vnet.ibm.com>


Anton,

As I have been merging iSeries into 2.5 & syncing the 2.4 / 2.5 little
fault handlers, a couple of things have come up.

First the easy one, in lpar_insert_hpte you have a comment asking about
why for guarded pages we turn off the coherent bit.  The history there
is that during bringup, guarded pages were marked as coherent as well.
The HV just rejects this combination of flags and does not insert the
PTE.  And yes, that one was fun to figure out :)  So, it is a relic that
could be fixed in a better way, if it has not been already.

Second, in a couple of places, you had removed the complete checks we
had for verifing a PTE before it is modified.  I believe this results in
the code being incorrect.  For example, in the updatepp path, we must
validate the entry before changing the pp bits, as the slot information
is really only a hint.  Just checking the avpn and valid bit is not
sufficient.  The hash group must also be checked as well.  I suspect you
were following the pSeries LPAR interface where the AVPN is used as a
hint on the PTE update paths.  The downside here is we now have 2
H-calls on the updatepp path.

The net of this is that the updatepp code has additional checks which
are required, I believe.  The hpte_invalidate path was also changed to
use the bolted tag, rather than the avpn hint.  This is needed for some
of the dynamic bolting work I have been doing.  It may result in a
slight increase in imprecise invalidations, but that would seem like a
very small hit.

Dave.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From engebret at vnet.ibm.com  Sat Aug 10 06:00:51 2002
From: engebret at vnet.ibm.com (Dave Engebretsen)
Date: Fri, 09 Aug 2002 15:00:51 -0500
Subject: [announce] New ppc64 kernel available (2.4.19)
Message-ID: <3D541F73.DBE81DEB@vnet.ibm.com>


A new patch for the linux/ppc64 kernel has been released for the iSeries
and pSeries PowerPC platforms.

This patch updates the kernel to 2.4.19.

A change log as well as links to the patch and the base code it applies
against can be found at:

http://www.linuxppc64.org/source.shtml

Dave Engebretsen, IBM

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From bergner at vnet.ibm.com  Sat Aug 24 06:04:39 2002
From: bergner at vnet.ibm.com (Peter Bergner)
Date: Fri, 23 Aug 2002 15:04:39 -0500
Subject: Fwd: 64bit syscalls
Message-ID: <3D669557.1080804@vnet.ibm.com>


Just forwarding this to the external mailing list.

Peter


-------- Original Message --------
Subject: [Linuxppc-dev] 64bit syscalls
Date: Fri, 23 Aug 2002 18:33:46 +1000
From: Anton Blanchard <anton at au1.ibm.com>


Hi,

Here is a first pass at potential 64bit syscalls we can remove.

First the easy ones:

sys_stat
sys_fstat
sys_lstat:

 >From memory these were deprecated back in the 2.0 days. They give a
nasty printk warning when they are used. In 2.5 I have removed these
in the 32 and 64 bit path, due to the glibc cacheline bug its unlikely
anyone could ever run a binary with these syscalls in it on a ppc64
machine.


sys_oldumount
sys_olduname
sys_uname
sys_sgetmask
sys_ssetmask
sys_old_getrlimit:

Some more old calls which can be safely removed from the 64 bit syscall
path.


sys_iopl
sys_vm86
sys_modify_ldt:

These make no sense, I have removed them in both the 32 and 64 bit path.


sys_pciconfig_read
sys_pciconfig_write:

We should be moving towards the mmap(/proc/bus/pci...) method, and as
such these calls should not be required.


sys_llseek:

No need for a syscall that takes a long long offset, sys_lseek will
suffice.


old_readdir:

We start moving onto the less obvious ones. Will 64bit glibc always
use getdents these days? If so we should remove old_readdir.


sys_getdents:

We have sys_getdents64, is there any nead for sys_getdents?


sys_waitpid
sys_alarm
sys_utime
sys_signal:

I havent looked closely at any of these, but the kernel source mentions
all of the above can be implemented in glibc using other existing syscalls.

Anton
_______________________________________________


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/



From engebret at vnet.ibm.com  Wed Aug 28 01:38:45 2002
From: engebret at vnet.ibm.com (Dave Engebretsen)
Date: Tue, 27 Aug 2002 10:38:45 -0500
Subject: VSID allocation
Message-ID: <3D6B9D05.D07267CA@vnet.ibm.com>


Anton,

You had brought up the topic of VSID allocation and problems you saw
with the distribution in the HPT.  Can you provide a few more details of
the specifcs and the workload that was being run?  I would like to
consider recreating the environment.

Thanks -

Dave.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From olh at suse.de  Thu Aug 29 02:30:01 2002
From: olh at suse.de (Olaf Hering)
Date: Wed, 28 Aug 2002 18:30:01 +0200
Subject: [timr@probo.com: Re: XFree86 5.0]
Message-ID: <20020828183001.A27845@suse.de>


Hi,


this one is about the appearently wrong pci layout on some pSeries
systems. I'm pretty sure that there are cases where the graphics card is
on a bus number > 256, probably a p660.
In this case, its a p630.

What is wrong in this picture?


Gruss Olaf

----- Forwarded message from Tim Roberts <timr at probo.com> -----

Date: Wed, 28 Aug 2002 09:22:37 -0700
Subject: Re: XFree86 5.0
From: "Tim Roberts" <timr at probo.com>
To: "devel at xfree86.org" <devel at xfree86.org>

On Wed, 28 Aug 2002 17:56:28 +0200, Olaf Hering wrote:

>begin  On Wed, Aug 28, Marc Aurele La France wrote:
>
>> On Wed, 28 Aug 2002, Olaf Hering wrote:
>>
>> > I'm not a member, just a user.
>> > But if that one can be fixed in a clean way, what would help alot, it is
>> > perhaps related to the pci domain stuff:
>>
>> > ./programs/Xserver/hw/xfree86/os-support/bus/Pci.h
>> > ...
>> > #define MAX_PCI_BUSES   256     /* Max number of PCI buses           */
>> > ...
>>
>> > Real life example:
>>
>> > 102:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP
(rev 85)
>>
>> As per the PCI specs, a tag has only 8 bits for the bus number.   What
>> architecture/OS is this?
>
>I have never read the PCI spec, I wish I had...
>...
>Are you really sure that this bus number 0x102 should never happen?

Yes.  The bus number field in the CONFIG_ADDRESS register, which is used to
address PCI configuration requests, is 8 bits wide.  The bus number field in
the configuration space of a PCI-to-PCI bridge, which is the only way to
ASSIGN a bus number to a specific bus, is also 8 bits wide.

I have no idea what the "102" might mean, unless this machine us using bit 8
to signal AGP vs PCI.  That would be wrong.

--
- Tim Roberts, timr at probo.com
  Providenza & Boekelheide, Inc.


----- End forwarded message -----

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From tinglett at vnet.ibm.com  Fri Aug 30 22:59:02 2002
From: tinglett at vnet.ibm.com (Todd Inglett)
Date: 30 Aug 2002 07:59:02 -0500
Subject: new scanlog code and RTAS
Message-ID: <1030712343.30626.22.camel@q.rchland.ibm.com>


I just wrote a proc interface to scanlog data that will be in the next
patch (it's in IBM internal CVS already).

One related change I made was to add an exported buffer in rtas.[ch]
called rtas_data_buf (size RTAS_DATA_BUF_SIZE = 1024 right now) which is
declared in rtas.c and therefore should always have a pa < 4GB.  This is
protected by rtas_data_buf_lock.

I figure this as a "cheap" alternative to having a true memory allocator
(or a zone) for memory < 4GB.  RTAS calls are pretty few and far between
so I don't expect any real contention for this buffer.  As for lock
ordering I just get and release the buffer immediately around the rtas
call (copying to a local buffer).  The RTAS interface has a lock, RTAS
itself will never obtain another lock :).

Another solution would be to write RTAS "wrapper" functions for each
RTAS function.  For RTAS functions that take data pointers we could hide
this "bounce buffer" internally.  I kind of like this idea.  The
rtas_call() interface is *really* error prone anyway....

Thoughts?

-todd


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From anton at samba.org  Sat Aug 31 11:11:59 2002
From: anton at samba.org (Anton Blanchard)
Date: Sat, 31 Aug 2002 11:11:59 +1000
Subject: VSID allocation
In-Reply-To: <3D6B9D05.D07267CA@vnet.ibm.com>
References: <3D6B9D05.D07267CA@vnet.ibm.com>
Message-ID: <20020831011159.GA17428@krispykreme>


> You had brought up the topic of VSID allocation and problems you saw
> with the distribution in the HPT.  Can you provide a few more details of
> the specifcs and the workload that was being run?  I would like to
> consider recreating the environment.

Basically I am looking to change VSID allocation from:

ordinal = (((ea >> 28) & 0x1fff) * LAST_USER_CONTEXT) | context;

to

ordinal = context * LAST_USER_CONTEXT | (((ea >> 28) & 0x1fff);

The problem is that with 256k+ contexts the old scheme shifts the
address bits too far and since the hashtable uses the lower n bits, we
end up with kernel segments mapping into the same bucket. In some cases
we overflow the bucket.

Anton

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From anton at samba.org  Sat Aug 31 11:13:25 2002
From: anton at samba.org (Anton Blanchard)
Date: Sat, 31 Aug 2002 11:13:25 +1000
Subject: naca and paca exports
Message-ID: <20020831011325.GB17428@krispykreme>


Hi,

We had a discussion a while ago about /proc/ppc64/naca and /proc/ppc64/paca.
Im keen to get this finalised before applications start using it.

Which bits of the following have application writers actually asked for?

        u8  eye_catcher[6];             /* Eyecatcher: PPC64 0x00 */
        u16 version;                    /* Version number 0x06 */
        u16 platform;                   /* Platform flags 0x08 */
        u16 processor;                  /* Processor type 0x0A */
        u32 processorCount;             /* # of physical processors 0x0C */
        u64 physicalMemorySize;         /* Size of real memory(B) 0x10 */

        u16 dCacheL1Size;               /* L1 d-cache size 0x18 */
        u16 dCacheL1LineSize;           /* L1 d-cache line size 0x1A */
        u16 dCacheL1LogLineSize;        /* L1 d-cache line size Log2 0x1C */
        u16 dCacheL1LinesPerPage;       /* L1 d-cache lines / page 0x1E */
        u16 dCacheL1Assoc;              /* L1 d-cache associativity 0x20 */

        u16 iCacheL1Size;               /* L1 i-cache size 0x22 */
        u16 iCacheL1LineSize;           /* L1 i-cache line size 0x24 */
        u16 iCacheL1LogLineSize;        /* L1 i-cache line size Log2 0x26 */
        u16 iCacheL1LinesPerPage;       /* L1 i-cache lines / page 0x28 */
        u16 iCacheL1Assoc;              /* L1 i-cache associativity 0x2A */

        u16 cacheL2Size;                /* L2 cache size 0x2C */
        u16 cacheL2Assoc;               /* L2 cache associativity 0x2E */

        u64 tb_orig_stamp;              /* Timebase at boot 0x30 */
        u64 tb_ticks_per_sec;           /* Timebase tics / sec 0x38 */
        u64 tb_to_xs;                   /* Inverse of TB to 2^20 0x40 */
        u64 stamp_xsec;                 /* 0x48 */
        volatile u64 tb_update_count;   /* Timebase atomicity ctr 0x50 */
        u32 tz_minuteswest;             /* Minutes west of Greenwich 0x58 */
        u32 tz_dsttime;                 /* Type of dst correction 0x5C */

        u64 resv1[4];                   /* Reserverd          0x60 - 0x7F */

I can see the need for processor, processorCount, physicalMemorySize
and timebase frequency, although we already have all that information in
/proc/cpuinfo and /proc/meminfo. BTW what does processorCount and
physicalMemorySize mean in light of hotplug?

We can always add things to the structure but we cant remove them once
we have them in. We also need to have something we can share with the
ppc32 guys.

Anton

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/




From anton at samba.org  Sat Aug 31 11:15:33 2002
From: anton at samba.org (Anton Blanchard)
Date: Sat, 31 Aug 2002 11:15:33 +1000
Subject: flight recorder
Message-ID: <20020831011532.GC17428@krispykreme>


In an effort to avoid yet another debug interface, I held off on adding
flight recorder support into 2.5. I notice it has just got added back
into the cvs tree.

Al, have you looked at the existing projects like event logging? Do they
satisfy your requirements?

Im hoping a combination of event logging and kernel probes will allow
us to remove a bunch of our arch specific debug hooks, like the PPCDBG
stuff.

Anton

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/