From owner-freebsd-ppc@FreeBSD.ORG Tue Jul 15 11:27:26 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C89C037B401 for ; Tue, 15 Jul 2003 11:27:26 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A0C343F3F for ; Tue, 15 Jul 2003 11:27:26 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h6FIRPju074402 for ; Tue, 15 Jul 2003 11:27:25 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h6FIRO3k074391 for freebsd-ppc@freebsd.org; Tue, 15 Jul 2003 11:27:24 -0700 (PDT) Date: Tue, 15 Jul 2003 11:27:24 -0700 From: "David O'Brien" To: freebsd-ppc@freebsd.org Message-ID: <20030715182724.GA70768@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: How to determine amount of RAM installed? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 18:27:27 -0000 How can one get RAM properties from OBP? Specifically how much RAM is installed? thanks, -- -- David (obrien@FreeBSD.org) From owner-freebsd-ppc@FreeBSD.ORG Tue Jul 15 12:21:34 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 078EE37B401; Tue, 15 Jul 2003 12:21:34 -0700 (PDT) Received: from fafoe.narf.at (chello212186121237.14.vie.surfer.at [212.186.121.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECAC243F75; Tue, 15 Jul 2003 12:21:32 -0700 (PDT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.2.102]) by fafoe.narf.at (Postfix) with ESMTP id 6874440C2; Tue, 15 Jul 2003 21:21:30 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 3C56DD1; Tue, 15 Jul 2003 21:21:30 +0200 (CEST) Date: Tue, 15 Jul 2003 21:21:30 +0200 From: Stefan Farfeleder To: David O'Brien Message-ID: <20030715192129.GG574@wombat.fafoe.narf.at> References: <20030715182724.GA70768@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030715182724.GA70768@dragon.nuxi.com> User-Agent: Mutt/1.5.4i cc: freebsd-ppc@freebsd.org Subject: Re: How to determine amount of RAM installed? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 19:21:34 -0000 On Tue, Jul 15, 2003 at 11:27:24AM -0700, David O'Brien wrote: > How can one get RAM properties from OBP? Specifically how much RAM is > installed? dev /memory .properties The first value of 'available' should be the start address, the second one the number of bytes of installed memory. Regards, Stefan Farfeleder From owner-freebsd-ppc@FreeBSD.ORG Tue Jul 15 13:10:33 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7841B37B404; Tue, 15 Jul 2003 13:10:33 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3126E43FB1; Tue, 15 Jul 2003 13:10:32 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h6FKbvcU015120; Tue, 15 Jul 2003 16:37:57 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h6FKABgw040647; Tue, 15 Jul 2003 13:10:11 -0700 (PDT) (envelope-from jmg) Date: Tue, 15 Jul 2003 13:10:11 -0700 From: John-Mark Gurney To: Stefan Farfeleder Message-ID: <20030715201011.GK35337@funkthat.com> References: <20030715182724.GA70768@dragon.nuxi.com> <20030715192129.GG574@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030715192129.GG574@wombat.fafoe.narf.at> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-ppc@freebsd.org Subject: Re: How to determine amount of RAM installed? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 20:10:33 -0000 Stefan Farfeleder wrote this message on Tue, Jul 15, 2003 at 21:21 +0200: > On Tue, Jul 15, 2003 at 11:27:24AM -0700, David O'Brien wrote: > > How can one get RAM properties from OBP? Specifically how much RAM is > > installed? > > dev /memory > .properties > > The first value of 'available' should be the start address, the second > one the number of bytes of installed memory. Ok, this is a start but not very useful (esspecially wrt 64bit ppc).. To properly parse the reg or available property, you need to get the #address-cells and #size-cells property from the parent node. If the address-cells doesn't exist, assume it to be 2, and if the size-cells property doesn't exist, assume it to be 1. The available property is memory that hasn't been allocated by the OFW, and reg is the absolute physical memory. So, on a g3 notebook, you have something like: 0 > dev / ok 0 > .properties [...] #address-cells 00000001 #size-cells 00000001 [...] ok 0 > dev /memory ok 0 > .properties [...] reg 00000000 04000000 04000000 10000000 available 00003000 13dfd000 and a cell is defined as 4 bytes. So, you can see where the memory is and the size of it. The first 0x3000 bytes of memory is currently used by OFW, with 0x13dfd000 memory available. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-ppc@FreeBSD.ORG Tue Jul 15 15:06:35 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2025F37B401 for ; Tue, 15 Jul 2003 15:06:35 -0700 (PDT) Received: from fafoe.narf.at (chello212186121237.14.vie.surfer.at [212.186.121.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1384643FBF for ; Tue, 15 Jul 2003 15:06:33 -0700 (PDT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.2.102]) by fafoe.narf.at (Postfix) with ESMTP id 6D8543FC4 for ; Wed, 16 Jul 2003 00:06:31 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 1C5B0D1; Wed, 16 Jul 2003 00:06:30 +0200 (CEST) Date: Wed, 16 Jul 2003 00:06:30 +0200 From: Stefan Farfeleder To: freebsd-ppc@freebsd.org Message-ID: <20030715220630.GH574@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: diff to fix GCC build problems X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 22:06:35 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, in the latest GCC import the file config/rs6000/rs6000-c.c was added to GCC, and the PowerPC cross-build from i386 currently fails because the file is needed but missing from the Makefile in gnu/usr.bin/cc/cc_int: %% cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/i386/usr\" -DCROSS_COMPILE -I/freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/i386/freebsd/ppc-uchar/src/gnu/usr.bin/cc/cc1/../cc_tools -I/freebsd/ppc-uchar/src/gnu/usr.bin/cc/cc1/../cc_tools -I/freebsd/ppc-uchar/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/freebsd/ppc-uchar/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I. -I/freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/i386/legacy/usr/include -static -L/freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/i386/legacy/usr/lib -o cc1 main.o c-parse+%DIKED.o c-lang.o c-decl.o c-opts.o /freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/i386/freebsd/ppc-uchar/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a -legacy /freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/i386/freebsd/ppc-uchar/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a(c-pragma.o): In function `init_pragma': c-pragma.o(.text+0x6a8): undefined reference to `rs6000_pragma_longcall' /freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/i386/freebsd/ppc-uchar/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a(c-common.o): In function `cb_register_builtins': c-common.o(.text+0x8009): undefined reference to `rs6000_cpu_cpp_builtins' *** Error code 1 %% Attached is a diff to add the file. I've taken a more generic approach than just doing .if ${GCC_CPU} == "rs6000" as this looks like a consistent naming scheme; ia64/ia64-c.c exists but doesn't seem to be needed at the moment. I'd be glad if someone could check whether the diff doesn't break ia64 though. Regards, Stefan Farfeleder --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gcc-Makefile.diff" Index: src/gnu/usr.bin/cc/cc_int/Makefile =================================================================== RCS file: /usr/home/ncvs/src/gnu/usr.bin/cc/cc_int/Makefile,v retrieving revision 1.34 diff -u -r1.34 Makefile --- src/gnu/usr.bin/cc/cc_int/Makefile 11 Jul 2003 05:37:23 -0000 1.34 +++ src/gnu/usr.bin/cc/cc_int/Makefile 15 Jul 2003 21:26:53 -0000 @@ -27,6 +27,10 @@ attribs.c cselib.c debug.c rtl-error.c tree-dump.c tree-inline.c SRCS+= ${GCC_CPU}.c +.if exists(${GCC_CPU}-c.c) +SRCS+= ${GCC_CPU}-c.c +.endif + SRCS+= bb-reorder.c conflict.c ggc-common.c \ ggc-page.c ifcvt.c lists.c predict.c regrename.c resource.c sibcall.c \ --+HP7ph2BbKc20aGI-- From owner-freebsd-ppc@FreeBSD.ORG Tue Jul 15 16:01:31 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8726937B401 for ; Tue, 15 Jul 2003 16:01:31 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC65C43FB1 for ; Tue, 15 Jul 2003 16:01:30 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h6FN1Lv1000471; Tue, 15 Jul 2003 16:01:21 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.9/8.12.9/Submit) id h6FN1L0O000470; Tue, 15 Jul 2003 16:01:21 -0700 (PDT) (envelope-from marcel) Date: Tue, 15 Jul 2003 16:01:21 -0700 From: Marcel Moolenaar To: Stefan Farfeleder Message-ID: <20030715230121.GA329@ns1.xcllnt.net> References: <20030715220630.GH574@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030715220630.GH574@wombat.fafoe.narf.at> User-Agent: Mutt/1.5.1i cc: freebsd-ppc@freebsd.org Subject: Re: diff to fix GCC build problems X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 23:01:31 -0000 On Wed, Jul 16, 2003 at 12:06:30AM +0200, Stefan Farfeleder wrote: > > SRCS+= ${GCC_CPU}.c > +.if exists(${GCC_CPU}-c.c) > +SRCS+= ${GCC_CPU}-c.c > +.endif > + I haven't tested it, but the patch should be harmless. The file (ia64-c.c) contains support for ``#pragma builtin'', which is an HP contributed feature to better support their libm. The support functions have to be registered before they are used and that happens in hpux.h. Assuming that we steer clear from that header, all we would have on ia64 is the compilation of a source file that's not going to be used. Feel free to pass this on to kan@, he's the one that ultimately makes the change. I don't see a problem. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-ppc@FreeBSD.ORG Tue Jul 15 17:30:07 2003 Return-Path: Delivered-To: freebsd-ppc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAD8237B401 for ; Tue, 15 Jul 2003 17:30:07 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B2D43FBF for ; Tue, 15 Jul 2003 17:30:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6G0U4Up022337 for ; Tue, 15 Jul 2003 17:30:05 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6G0U4od022336; Tue, 15 Jul 2003 17:30:04 -0700 (PDT) Resent-Date: Tue, 15 Jul 2003 17:30:04 -0700 (PDT) Resent-Message-Id: <200307160030.h6G0U4od022336@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-ppc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Stefan Farfeleder Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60A9037B404 for ; Tue, 15 Jul 2003 17:26:14 -0700 (PDT) Received: from fafoe.narf.at (chello212186121237.14.vie.surfer.at [212.186.121.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 544DF43F85 for ; Tue, 15 Jul 2003 17:26:13 -0700 (PDT) (envelope-from stefan@fafoe.dyndns.org) Received: from frog.fafoe.narf.at (frog.fafoe.narf.at [192.168.2.101]) by fafoe.narf.at (Postfix) with ESMTP id F25113FC4; Wed, 16 Jul 2003 02:26:08 +0200 (CEST) Received: by frog.fafoe.narf.at (Postfix, from userid 1001) id B4FE5324; Wed, 16 Jul 2003 02:26:06 +0200 (CEST) Message-Id: <20030716002606.B4FE5324@frog.fafoe.narf.at> Date: Wed, 16 Jul 2003 02:26:06 +0200 (CEST) From: Stefan Farfeleder To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 cc: stefan@fafoe.narf.at Subject: powerpc/54526: [patch] Teach crunchide(1) about PowerPC ELF X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Stefan Farfeleder List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 00:30:08 -0000 >Number: 54526 >Category: powerpc >Synopsis: [patch] Teach crunchide(1) about PowerPC ELF >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-ppc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Tue Jul 15 17:30:04 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Stefan Farfeleder >Release: FreeBSD 5.1-CURRENT i386 >Organization: >Environment: System: FreeBSD frog.fafoe.narf.at 5.1-CURRENT FreeBSD 5.1-CURRENT #21: Sat Jul 12 15:28:48 CEST 2003 freebsd@frog.fafoe.narf.at:/freebsd/frog/obj/freebsd/frog/src/sys/FROG i386 >Description: The file exec_elf32.c currently doesn't know about the PowerPC ELF format, for that reason a PowerPC buildworld currently fails with: %% cc -O -pipe -c rescue.c echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >cat_stub.c cc -O -pipe -c cat_stub.c ld -dc -r -o cat.lo cat_stub.o /freebsd/ppc-uchar/obj/powerpc/freebsd/ppc-uchar/src/rescue/rescue//freebsd/ppc-uchar/src/bin/cat/cat.o crunchide -k _crunched_cat_stub cat.lo cat.lo: unknown executable format *** Error code 1 %% >How-To-Repeat: >Fix: All that is needed is to add case EM_PPC to the switch. For consistency with the other "exotic" architectures EM_PPC is defined if it isn't already. --- crunchide.diff begins here --- Index: src/usr.sbin/crunch/crunchide/exec_elf32.c =================================================================== RCS file: /usr/home/ncvs/src/usr.sbin/crunch/crunchide/exec_elf32.c,v retrieving revision 1.11 diff -u -r1.11 exec_elf32.c --- src/usr.sbin/crunch/crunchide/exec_elf32.c 3 Jun 2003 01:37:32 -0000 1.11 +++ src/usr.sbin/crunch/crunchide/exec_elf32.c 15 Jul 2003 23:46:00 -0000 @@ -160,6 +160,10 @@ #define EM_IA_64 50 #endif case EM_IA_64: break; +#ifndef EM_PPC +#define EM_PPC 20 +#endif + case EM_PPC: break; #ifndef EM_SPARCV9 #define EM_SPARCV9 43 #endif --- crunchide.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-ppc@FreeBSD.ORG Wed Jul 16 01:27:10 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 701A837B401 for ; Wed, 16 Jul 2003 01:27:10 -0700 (PDT) Received: from cubical.fi (gw.cubical.fi [212.226.173.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8BC543F75 for ; Wed, 16 Jul 2003 01:27:08 -0700 (PDT) (envelope-from jussi.liukkonen@snorkkeli.homeip.net) Received: (from root@localhost) by cubical.fi (8.11.6/8.11.6) id h6G8R7K12893; Wed, 16 Jul 2003 11:27:07 +0300 (EEST) (envelope-from jussi.liukkonen@snorkkeli.homeip.net) Received: from snorkkeli.homeip.net (dhcp-46.cs-intra.net [192.168.42.46]) by cubical.fi (8.11.6/8.11.6av) with ESMTP id h6G8R5m12879; Wed, 16 Jul 2003 11:27:06 +0300 (EEST) (envelope-from jussi.liukkonen@snorkkeli.homeip.net) Message-ID: <3F150C56.2030605@snorkkeli.homeip.net> Date: Wed, 16 Jul 2003 11:27:02 +0300 From: Juha-Matti Liukkonen Organization: Headache, Inc User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <20030715182724.GA70768@dragon.nuxi.com> <20030715192129.GG574@wombat.fafoe.narf.at> <20030715201011.GK35337@funkthat.com> In-Reply-To: <20030715201011.GK35337@funkthat.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080708050205000306010607" X-Virus-Scanned: by AMaViS perl-11 cc: Stefan Farfeleder cc: freebsd-ppc@freebsd.org Subject: Re: How to determine amount of RAM installed? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 08:27:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080708050205000306010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John-Mark Gurney wrote: : > and a cell is defined as 4 bytes. So, you can see where the memory is > and the size of it. The first 0x3000 bytes of memory is currently used > by OFW, with 0x13dfd000 memory available. I suppose the low 0x3000 is for the PPC exception vector? Br, Jussi -- Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE protocol error: invalid directory syntax in pmgmt/ --------------ms080708050205000306010607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM6jCC ArswggIkoAMCAQICCwEAAAAAAPXVTuLqMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAyIENBMR4wHAYD VQQDExVHbG9iYWxTaWduIENsYXNzIDIgQ0EwHhcNMDMwNjE3MTAyODI0WhcNMDQwNjIxMTQw MjE5WjBhMQswCQYDVQQGEwJGSTEdMBsGA1UEAxMUSnVoYS1NYXR0aSBMaXVra29uZW4xMzAx BgkqhkiG9w0BCQEWJGp1c3NpLmxpdWtrb25lbkBzbm9ya2tlbGkuaG9tZWlwLm5ldDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA2wqbg0qKSKtRFq9JnjYjKG3gW068UlyKN+i6u6FK qhK+pOBAU1ylZBx0qwJIrcTKM/xINeh7SLbGZqanmCE+HcQGo/6GsO6zsJBgKWLG5JbhRmWu 8OTfi6ffFjYxrg3GaSXCwhcyPafp4FEeq55uGRFqQJsCezoQse98vf71sCMCAwEAAaN9MHsw EQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE8DAfBgNVHSMEGDAWgBQRbteRYMsG 5FcAV6icgL12M+VZUTA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLmdsb2JhbHNpZ24u bmV0L2NsYXNzMi5jcmwwDQYJKoZIhvcNAQEFBQADgYEAXemUUqHz2o86W7bePOdMaBQvqQOs QRYyCFzb8gSW0+LJ8AhqOpjyAR8xK1L0RdnNQbuX2VEOB8FNc+RervobPgp2wMk1fmburHuI Tj2zDmEtTRK2J37T2r8e6rXF/RWR8BhY8EyIWKAN/kTVt+ABo/fvrdQr0xoAnEsm8g4V2Dcw ggK7MIICJKADAgECAgsBAAAAAAD11U7i6jANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTETMBEGA1UECxMKQ2xhc3MgMiBDQTEeMBwG A1UEAxMVR2xvYmFsU2lnbiBDbGFzcyAyIENBMB4XDTAzMDYxNzEwMjgyNFoXDTA0MDYyMTE0 MDIxOVowYTELMAkGA1UEBhMCRkkxHTAbBgNVBAMTFEp1aGEtTWF0dGkgTGl1a2tvbmVuMTMw MQYJKoZIhvcNAQkBFiRqdXNzaS5saXVra29uZW5Ac25vcmtrZWxpLmhvbWVpcC5uZXQwgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANsKm4NKikirURavSZ42Iyht4FtOvFJcijfouruh SqoSvqTgQFNcpWQcdKsCSK3EyjP8SDXoe0i2xmamp5ghPh3EBqP+hrDus7CQYClixuSW4UZl rvDk34un3xY2Ma4NxmklwsIXMj2n6eBRHquebhkRakCbAns6ELHvfL3+9bAjAgMBAAGjfTB7 MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBPAwHwYDVR0jBBgwFoAUEW7XkWDL BuRXAFeonIC9djPlWVEwNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5nbG9iYWxzaWdu Lm5ldC9jbGFzczIuY3JsMA0GCSqGSIb3DQEBBQUAA4GBAF3plFKh89qPOlu23jznTGgUL6kD rEEWMghc2/IEltPiyfAIajqY8gEfMStS9EXZzUG7l9lRDgfBTXPkXq76Gz4KdsDJNX5m7qx7 iE49sw5hLU0Stid+09q/Huq1xf0VkfAYWPBMiFigDf5E1bfgAaP3763UK9MaAJxLJvIOFdg3 MIIDgTCCAmmgAwIBAgILBAAAAAAA8HYD6N4wDQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3Mg MiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQcmltYXJ5IENsYXNzIDIgQ0EwHhcNOTkwMTI4 MTIwMDAxWhcNMDQwMTI4MTIwMDAwWjBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTETMBEGA1UECxMKQ2xhc3MgMiBDQTEeMBwGA1UEAxMVR2xvYmFsU2lnbiBD bGFzcyAyIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYUVsPk8dJYHdRFI7jnXV1 HsmFDn9MAxkZdqTueiv8gwYDx5wWmr6OThEKQH+sMonTwXn8+UTRh1PP29O7LV8pufq6EftU otvG0+a1wIgvtU4Ch9zLmxl59r/dNHreM4Va6DJ1z0NhRQ3jyIc7RxCh5d8tbAcGR/lO2Pv2 hJ4MwwIDAQABo4G1MIGyMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQRbteRYMsG5FcAV6icgL12M+VZUTA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8v Y3JsLmdsb2JhbHNpZ24ubmV0L1ByaW1DbGFzczIuY3JsMBEGCWCGSAGG+EIBAQQEAwIBBjAf BgNVHSMEGDAWgBR857KxLN6xp2vpdgzho/1ObMe59jANBgkqhkiG9w0BAQUFAAOCAQEAj3sq vS2XI/lDRwLx41EZ3zjd9pO61A1CsqfnqK7PVw6Yw4DLbhAmRe9Gm0O4kqtb2oZRzh0w8eR4 5WkCaKJ8I0WqQUbxf6q7EJ5Q/yMsQ2zIT6af3D9Vsd+Y2mkDapZbtoKJEZ2aWEkmaNX+cH/p H51pLMvkENrc/rCJ9zG/NuA7L4lmUi60dKCLfdjyd1H0tc4vACvdI3avIxhKxgx72/OyaAU0 U0VJU5ENV67zoYbHYQOel74Q0x279YgB3C0jbHuB/eWNZKKENGbrEKRNWUoS0f93XaGdTy9P HmjVoXBGdAKztg4jc0EIGn07uqWtIAekUycBpBT9DSA3oj4x3TCCA+MwggLLoAMCAQICCwQA AAAAAPB2A9l8MA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTkwMTI4MTIwMDAwWhcNMDkwMTI4MTIwMDAwWjBtMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEbMBkGA1UECxMSUHJpbWFyeSBDbGFzcyAyIENB MSYwJAYDVQQDEx1HbG9iYWxTaWduIFByaW1hcnkgQ2xhc3MgMiBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJKM/u/0RY4XQW782L8hb6sGnVLBLACdP46FuH9Kj72gYyrK SSeuWoL0dOJVkv/C0ap5orb61Z2CBE/GssZeY6c6utju64pvn7a7KEHAIvtOSBoGkte/18+5 2b04TzsNRG5VQf78CdvYv/OOIfHoErX2E6XTxkyTIrAC/+4dDMSoa091aFbo3CgSUPeoJJ0u JDn7CQXe5aNkSSHQaH5xMJGxYOA59FD4ek2YAGt8ebpOzkriujYdt8U2FZWcZELqX8S69UAF vuE6Wb2Epxm43k1TUM4H0dJR0+8NgWzm523LXXw/fMzsT4MnJf9wUPaDWXWEBmZYLN6JjQCm SfmlQ3cCAwEAAaOBmTCBljAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUfOeysSzesadr6XYM4aP9TmzHufYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC5nbG9iYWxzaWduLm5ldC9Sb290LmNybDAfBgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo //z9SzANBgkqhkiG9w0BAQUFAAOCAQEAjkl1wViA8QMctmYqInWVW2S5nnESN9G33sxPFmBF FAJHvmyI9/UbHaadqhlufBw6hKTFjak8Mf4N6ELfIVAi7nEBgahkM5TxrZ1aWwA34qRc5CCq YHSUPeuw6SGdHTSppjSDQV7jOv8hHtIbqe12Lb4vTyhceanglpH+ygwq7kWOdSorJr2Orgjd i7lXjf9tC6sIRgyf+YIovB+uDHJWDXeaoIhXeCc4jS91K9RxahRIpbqGyd98JhOeLWzIW/Vr fB84Zy+O1Neo2YXtCuDymGnZGpemUJecxz0kWW6xob2NpjIRnVQBWyuC4f2NxWhDDeC4JlSe fxPeEKdp+rIqgTGCAsMwggK/AgEBMGwwXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh bFNpZ24gbnYtc2ExEzARBgNVBAsTCkNsYXNzIDIgQ0ExHjAcBgNVBAMTFUdsb2JhbFNpZ24g Q2xhc3MgMiBDQQILAQAAAAAA9dVO4uowCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwNzE2MDgyNzAyWjAjBgkqhkiG9w0BCQQx FgQUTtF09LYIOSdL71YTXZFU0hTC960wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw ewYJKwYBBAGCNxAEMW4wbDBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBu di1zYTETMBEGA1UECxMKQ2xhc3MgMiBDQTEeMBwGA1UEAxMVR2xvYmFsU2lnbiBDbGFzcyAy IENBAgsBAAAAAAD11U7i6jB9BgsqhkiG9w0BCRACCzFuoGwwXTELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEzARBgNVBAsTCkNsYXNzIDIgQ0ExHjAcBgNVBAMT FUdsb2JhbFNpZ24gQ2xhc3MgMiBDQQILAQAAAAAA9dVO4uowDQYJKoZIhvcNAQEBBQAEgYBQ TuT3sZAun1KFXF36Wi4jFBMIwuTnl1n4mWe8lGVbVYgkrWjFYQJeuyb4NGyWlDi4w08Qhu09 N7NgYkrOhfeZSsFl8Vz+qgDzJ52EZNwIvwal35xh2ERtg731VEc9BmL8AjAM/8vcm0VXN8jZ 4f6fjmre8eEtD6C/IZYEYHeDdgAAAAAAAA== --------------ms080708050205000306010607-- From owner-freebsd-ppc@FreeBSD.ORG Wed Jul 16 07:07:20 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7375537B401 for ; Wed, 16 Jul 2003 07:07:20 -0700 (PDT) Received: from bothawui.bothan.net (bothawui.bothan.net [66.92.184.160]) by mx1.FreeBSD.org (Postfix) with SMTP id D945D43F93 for ; Wed, 16 Jul 2003 07:07:19 -0700 (PDT) (envelope-from jtl-freebsd@bothan.net) Received: (qmail 15821 invoked from network); 16 Jul 2003 14:07:17 -0000 Received: from unknown (HELO bothan.net) (127.0.0.1) by localhost with SMTP; 16 Jul 2003 14:07:17 -0000 Date: Wed, 16 Jul 2003 16:07:40 +0200 X-Image-Url: jtl-freebsd@bothan.net Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Joshua LeVasseur To: freebsd-ppc@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: PowerPC system ISA limitations X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 14:07:20 -0000 According to the PowerPC programming environments manual, certain operations are to be avoided while virtual addressing is enabled. But to me, the wording in the respective locations of the manual is ambiguous. I was wondering if anyone knew more specifics regarding three situations: 1. The hashed page table: From section 7.6 of the v2.0 PEM (from IBM), "If page table search operations are performed automatically by the hardware, they are performed using physical addresses and as if the memory access attribute bit M=1 (memory coherency enforced in hardware). If the software performs the page table search operations, the accesses must be performed in real addressing mode (MSR[DR] = 0); this additionally guarantees that M=1." What is meant by software searches? A search performed by firmware, or the operating system kernel when the processor doesn't implement hardware searching? Or is this a generic page hash lookup by one's operating system kernel? If a generic page hash lookup by one's kernel, why is real mode necessary? If I use a BAT register to back the code and data used for searching the page hash, is that sufficient for leaving virtual addressing enabled? I have tested the situation where I use BAT registers while manipulating the page hash with virtual addressing enabled (a BAT register maps the page hash, another BAT for kernel code, and another BAT for kernel data). It executes correctly (or at least visibly). Perhaps side effects are implementation dependent (i.e. my processors were constructed such that they support searches with virtual addressing enabled) ... In section 7.6.3.2, the process for modifying a page table entry is described. Yet it doesn't mention whether or not the processor should be in real mode. Modification isn't the same as performing a search ... or is it? 2. Exception processing In section 6.2 of the v2.0 PEM, "Note: In some implementations, every instruction fetch when MSR[IR] = 1, and every data acess requiring address translation when MSR[DR] = 1, may modify SRR0 and SRR1." Is this just another way of saying that address translation may raise an exception, and thus store exception state? Or is this describing strange behavior, such as writing random data into these registers without raising an exception? If there is the chance of changing these registers without a corresponding exception, then an obvious use for rfi is lost: switching from virtual mode to physical mode while jumping to the physical mode instruction pointer. One can fill-out srr0 and srr1 while virtual addressing is enabled and handled by BAT registers (and external interrupts + decrementer exceptions are disabled), and then rfi. 3. Cache aliases In section 7.6.3 (of IBM's PEM v2.0) in regards to modifying the virtual address of a PTEG entry, "If the virtual address is being changed to a different address within the same hash class (primary or secondary), the following flow suffices: [psuedo code skipped] ... In this example, if the new address is not a cache synonym (alias) of the old address, care must be taken to also flush (or invalidate) from an on-chip cache any cache synonyms for the page. Thus, a temporary virtual address that is a cache synonym with the page whose PTE is being modified can be assigned and then used for the cache flushing (or invalidation)." This sounds like the manual describes a cache which uses virtual, or psuedo-virtual tags. I thought PowerPC uses physical cache tags. The implications of the paragraph are nasty though ... an OS may unmap a page, map the same physical page to a new address within the same PTEG much later, and then cause side effects due to invalid cache state. Perhaps the behavior is processor dependent? Or must every PowerPC kernel flush a page from the cache when unmapping the page? Thanks for any guidance, Josh From owner-freebsd-ppc@FreeBSD.ORG Wed Jul 16 07:34:34 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2657737B401 for ; Wed, 16 Jul 2003 07:34:34 -0700 (PDT) Received: from mail.jeamland.net (arlond.jeamland.net [202.45.126.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id F016C43F75 for ; Wed, 16 Jul 2003 07:34:32 -0700 (PDT) (envelope-from benno@FreeBSD.org) Received: from [10.1.1.131] (c211-28-93-127.rivrw5.nsw.optusnet.com.au [211.28.93.127]) by mail.jeamland.net (Postfix) with ESMTP id 45815357C8; Thu, 17 Jul 2003 00:34:30 +1000 (EST) From: Benno Rice To: Joshua LeVasseur In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Lk5sy5KT/NWoJBgXPfWm" Message-Id: <1058366069.782.12.camel@ratchet.jeamland.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 17 Jul 2003 00:34:29 +1000 cc: freebsd-ppc@freebsd.org Subject: Re: PowerPC system ISA limitations X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 14:34:34 -0000 --=-Lk5sy5KT/NWoJBgXPfWm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-07-17 at 00:07, Joshua LeVasseur wrote: > According to the PowerPC programming environments manual, certain=20 > operations are to be avoided while virtual addressing is enabled. But=20 > to me, the wording in the respective locations of the manual is=20 > ambiguous. I was wondering if anyone knew more specifics regarding=20 > three situations: >=20 > 1. The hashed page table: > From section 7.6 of the v2.0 PEM (from IBM), "If page table search=20 > operations are performed automatically by the hardware, they are=20 > performed using physical addresses and as if the memory access=20 > attribute bit M=3D1 (memory coherency enforced in hardware). If the=20 > software performs the page table search operations, the accesses must=20 > be performed in real addressing mode (MSR[DR] =3D 0); this additionally=20 > guarantees that M=3D1." >=20 > What is meant by software searches? A search performed by firmware, or=20 > the operating system kernel when the processor doesn't implement=20 > hardware searching? Or is this a generic page hash lookup by one's=20 > operating system kernel? If a generic page hash lookup by one's=20 > kernel, why is real mode necessary? If I use a BAT register to back=20 > the code and data used for searching the page hash, is that sufficient=20 > for leaving virtual addressing enabled? Hardware page table lookups are an optional feature in PowerPC, at least in the original spec (not Book E which is the 64-bit version and specifies a very different MMU). If the implementation doesn't provide hardware table lookup then the OS has to provide it by providing fault handlers for DTLB and ITLB misses. These handlers have to abide by the restrictions listed. > I have tested the situation where I use BAT registers while=20 > manipulating the page hash with virtual addressing enabled (a BAT=20 > register maps the page hash, another BAT for kernel code, and another=20 > BAT for kernel data). It executes correctly (or at least visibly). =20 > Perhaps side effects are implementation dependent (i.e. my processors=20 > were constructed such that they support searches with virtual=20 > addressing enabled) ... See above. > In section 7.6.3.2, the process for modifying a page table entry is=20 > described. Yet it doesn't mention whether or not the processor should=20 > be in real mode. Modification isn't the same as performing a search=20 > ... or is it? The kernel could have the page tables mapped in at a virtual address. > 2. Exception processing > In section 6.2 of the v2.0 PEM, "Note: In some implementations, every=20 > instruction fetch when MSR[IR] =3D 1, and every data acess requiring=20 > address translation when MSR[DR] =3D 1, may modify SRR0 and SRR1." >=20 > Is this just another way of saying that address translation may raise=20 > an exception, and thus store exception state? Or is this describing=20 > strange behavior, such as writing random data into these registers=20 > without raising an exception? If there is the chance of changing these=20 > registers without a corresponding exception, then an obvious use for=20 > rfi is lost: switching from virtual mode to physical mode while jumping=20 > to the physical mode instruction pointer. One can fill-out srr0 and=20 > srr1 while virtual addressing is enabled and handled by BAT registers=20 > (and external interrupts + decrementer exceptions are disabled), and=20 > then rfi. I think it just says what it says. In some implementations you can't rely on SRR0 and SRR1 being consistant when address translations are in effect. This means that if you're going to re-enable address translation in an exception handler, you really want to save SRR0 and SRR1 first, but then that's a good idea anyway since if you take another exception you're going to lose them. If you really want to do a virtual to physical jump, you might want to use sc instead. > 3. Cache aliases > In section 7.6.3 (of IBM's PEM v2.0) in regards to modifying the=20 > virtual address of a PTEG entry, "If the virtual address is being=20 > changed to a different address within the same hash class (primary or=20 > secondary), the following flow suffices: [psuedo code skipped] ... In=20 > this example, if the new address is not a cache synonym (alias) of the=20 > old address, care must be taken to also flush (or invalidate) from an=20 > on-chip cache any cache synonyms for the page. Thus, a temporary=20 > virtual address that is a cache synonym with the page whose PTE is=20 > being modified can be assigned and then used for the cache flushing (or=20 > invalidation)." >=20 > This sounds like the manual describes a cache which uses virtual, or=20 > psuedo-virtual tags. I thought PowerPC uses physical cache tags. >=20 > The implications of the paragraph are nasty though ... an OS may unmap=20 > a page, map the same physical page to a new address within the same=20 > PTEG much later, and then cause side effects due to invalid cache=20 > state. Perhaps the behavior is processor dependent? Or must every=20 > PowerPC kernel flush a page from the cache when unmapping the page? This one I'm not so sure on. I think the PowerPC spec may not specify what sort of cache is used, but I may be wrong. --=20 Benno Rice benno@FreeBSD.org --=-Lk5sy5KT/NWoJBgXPfWm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQA/FWJ1XjRwWofFmQkRAteuAJ4yPxKNC/1/jyocWy/K59i83AKgAQCeMto7 xUQTMNF5WiXAas9EINo0xmc= =we0u -----END PGP SIGNATURE----- --=-Lk5sy5KT/NWoJBgXPfWm-- From owner-freebsd-ppc@FreeBSD.ORG Thu Jul 17 14:54:27 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36D7C37B401 for ; Thu, 17 Jul 2003 14:54:27 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0696E43F93 for ; Thu, 17 Jul 2003 14:54:26 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h6HMMb6d014212 for ; Thu, 17 Jul 2003 18:22:38 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h6HLsSMM099170 for ppc@freebsd.org; Thu, 17 Jul 2003 14:54:28 -0700 (PDT) (envelope-from jmg) Date: Thu, 17 Jul 2003 14:54:28 -0700 From: John-Mark Gurney To: ppc@freebsd.org Message-ID: <20030717215428.GD35337@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: pam_chroot fails X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2003 21:54:27 -0000 Is anyone else seeing this? cc -O -pipe -I/usr/src/world/src/lib/libpam/modules/pam_chroot/../../../../contrib/openpam/include -I/usr/src/world/src/lib/libpam/modules/pam_chroot/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/world/src/lib/libpam/modules/pam_chroot/pam_chroot.c In file included from /usr/obj/powerpc/usr/src/world/src/sparc64/usr/include/sys/types.h:48, from /usr/obj/powerpc/usr/src/world/src/sparc64/usr/include/sys/param.h:67, from /usr/src/world/src/lib/libpam/modules/pam_chroot/pam_chroot.c:38: /usr/obj/powerpc/usr/src/world/src/sparc64/usr/include/machine/endian.h:55:1: "_BIG_ENDIAN" redefined :55:1: this is the location of the previous definition *** Error code 1 I got this a couple times, even after a cvs update. Failure in the same place both time. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."