From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 20 08:27:06 2014 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA8E0D09; Wed, 20 Aug 2014 08:27:06 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 424983DC5; Wed, 20 Aug 2014 08:27:06 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7K8R0eb057639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2014 11:27:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7K8R0eb057639 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7K8R0bW057638; Wed, 20 Aug 2014 11:27:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Aug 2014 11:27:00 +0300 From: Konstantin Belousov To: sparc64@freebsd.org Subject: Re: svn commit: r270201 - in head/sys: powerpc/include sys Message-ID: <20140820082700.GY2737@kib.kiev.ua> References: <201408200802.s7K82cJ6059609@svn.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JViz224v3YRbOSfM" Content-Disposition: inline In-Reply-To: <201408200802.s7K82cJ6059609@svn.freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 08:27:06 -0000 --JViz224v3YRbOSfM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 20, 2014 at 08:02:38AM +0000, Konstantin Belousov wrote: > Author: kib > Date: Wed Aug 20 08:02:38 2014 > New Revision: 270201 > URL: http://svnweb.freebsd.org/changeset/base/270201 >=20 > Log: > Add arch-specific macro SFBUF_PHYS_DMAP(), which should translate the > physical address of the page to direct map address, in case > SFBUF_OPTIONAL_DIRECT_MAP returns true. The case of PowerPC AIM > 64bit, where the page physical address is identical to the direct map > address, is accidental. Real use of this interposer is for sparc64 machines which can use direct map due to usable cache implementation. Could someone with the machine identified as SPARC64V test the following patch ? Just booting multiuser should be enough. diff --git a/sys/sparc64/include/vmparam.h b/sys/sparc64/include/vmparam.h index 8e7d76c..c2f30c3 100644 --- a/sys/sparc64/include/vmparam.h +++ b/sys/sparc64/include/vmparam.h @@ -241,5 +241,8 @@ extern vm_offset_t vm_max_kernel_address; =20 #define SFBUF #define SFBUF_MAP +#define SFBUF_OPTIONAL_DIRECT_MAP dcache_color_ignore +#include +#define SFBUF_PHYS_DMAP(x) TLB_PHYS_TO_DIRECT(x) =20 #endif /* !_MACHINE_VMPARAM_H_ */ --JViz224v3YRbOSfM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT9FvUAAoJEJDCuSvBvK1BaJgP/1WPrITGayGgyrWUCQWI9buj HT8IbGzSrBs33EANdcxm68GKHU+0s8iEkd+SrlUTJvaqPc1oFiguZ3X/He/i0tBQ ShjYxW6lTQfeKR2Q1ueY7nN3pOXe5oSwOWkasSYkijHvTldswZzLiasuDghNMWff z+kOwzWK3lTyP4BDUv8YNxiqN5t575XG6eVTHpFQrrJIWwz+HToGwrzL3MVAraJK Vbod7N3q9Ek/Q0m4naNAq3EoB3l412uz11+BCbJW2wgWk6oVjAPHLc3p/eUVafdX xd9V7xaiTGpLFpdkIAjI8cOajoihBwwTa6XESzeCjiMSpda8ONJjTbS6+lwlzDt8 xfwCQf6/htRcfZFtGeRcibSz5cuchAjFWOQyfc0trVW1Bw+fpwgAlXlBkp2Gv7dy l6HUJJJiDq/njy6MI8HXC4L8LPkSmy3NmI4Z9vuMUMP+vKsm7BaXSFqMLoLlCR+5 vqhKCf5p7n2PTQ4ugbwxv/Rz94jk/FRImbxCNFF8gHG2Q8QCXFQqm72xfg3/MWOL FSUt++27ypy0IMb54ZsgDNkBn0p/XpNYvsdXbSNSnpNfyUX4FvIB2OBycLHlbMrr xIpZT48ui/Z8UMA1tSruooKNI3Y+QWuaByrEtuSpYeAd/y5da2fLmqEi8PtZ1OHp 8SJ+Vcy4hwOba2pskA1b =OODx -----END PGP SIGNATURE----- --JViz224v3YRbOSfM-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 22 13:18:59 2014 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8B8AC65 for ; Fri, 22 Aug 2014 13:18:58 +0000 (UTC) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A88DC3F3A for ; Fri, 22 Aug 2014 13:18:57 +0000 (UTC) Received: from 5d604c68.skybroadband.com ([93.96.76.104] helo=[192.168.1.81]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XKoQN-00069T-MC for freebsd-sparc64@freebsd.org; Fri, 22 Aug 2014 13:58:36 +0100 Message-ID: <53F73E6F.9080805@ilande.co.uk> Date: Fri, 22 Aug 2014 13:58:23 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 93.96.76.104 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Subject: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 13:18:59 -0000 Hi all, I'm currently working on a set of patches to enable FreeBSD to boot in -nographic mode under qemu-system-sparc64 and I've just come across the following error during boot: Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc00a0000. Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17 11:37:19 UTC 2014 root@snap.freebsd.org:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 134217728 (128 MB) avail memory = 106053632 (101 MB) cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU) random device not loaded; using insecure entropy random: initialized kbd0 at kbdmux0 nexus0: nexus0: : incomplete pcib0: mem 0x1fe00000000-0x1fe01ffffff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz panic: psycho_attach: unsupported number of ranges cpuid = 0 KDB: stack backtrace: #0 0xc085db60 at psycho_attach+0x780 #1 0xc0569dd8 at device_attach+0x518 #2 0xc056b4e8 at device_probe_and_attach+0x28 #3 0xc056b510 at bus_generic_attach+0x10 #4 0xc087704c at nexus_attach+0x58c #5 0xc0569dd8 at device_attach+0x518 #6 0xc056b4e8 at device_probe_and_attach+0x28 #7 0xc056b87c at bus_generic_new_pass+0x11c #8 0xc056aeb8 at bus_set_pass+0xf8 #9 0xc056af08 at root_bus_configure+0x8 #10 0xc086a9a4 at configure+0x4 #11 0xc04d4e3c at mi_startup+0x1dc #12 0xc00a0028 at btext+0x28 Uptime: 1s Having a look at the source it looks like we're being tripped by the following check in psycho.c: /* * Make sure that the expected ranges are present. The * OFW_PCI_CS_MEM64 one is not currently used though. */ if (i != PSYCHO_NRANGE) panic("%s: unsupported number of ranges", __func__); Now it seems that this occurs because OpenBIOS currently only supports 32-bit PCI memory space (and so doesn't generate the 64-bit PCI memory space entry withing the corresponding property). I could alter OpenBIOS to add a dummy 64-bit PCI memory space entry to the end of the ranges property, however this particular check does seem to be rather excessive and it is also slightly disingenuous to have OpenBIOS include a declaration for a memory space that it cannot use (plus it seems from the comment above that FreeBSD can't actually use it anyway?!). Does anyone know why this particular assertion was added and what it's actually trying to guard against? Many thanks, Mark. From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 22 15:22:19 2014 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD3A8399 for ; Fri, 22 Aug 2014 15:22:19 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7712C3EDC for ; Fri, 22 Aug 2014 15:22:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id C148638075 for ; Fri, 22 Aug 2014 10:14:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id ehdhwLG1EMCb for ; Fri, 22 Aug 2014 10:14:09 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 75B6C38063 for ; Fri, 22 Aug 2014 10:14:09 -0500 (CDT) Message-ID: <53F75E40.1010209@freebsd.org> Date: Fri, 22 Aug 2014 08:14:08 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org Subject: Re: PCI range checking under qemu-system-sparc64 References: <53F73E6F.9080805@ilande.co.uk> In-Reply-To: <53F73E6F.9080805@ilande.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:22:19 -0000 FYI, if you set kern.vty=vt, you get graphics with QEMU on sparc64. -Nathan On 08/22/14 05:58, Mark Cave-Ayland wrote: > Hi all, > > I'm currently working on a set of patches to enable FreeBSD to boot in > -nographic mode under qemu-system-sparc64 and I've just come across > the following error during boot: > > > Booting [/boot/kernel/kernel]... > jumping to kernel entry at 0xc00a0000. > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17 11:37:19 UTC 2014 > root@snap.freebsd.org:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC > sparc64 > gcc version 4.2.1 20070831 patched [FreeBSD] > real memory = 134217728 (128 MB) > avail memory = 106053632 (101 MB) > cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU) > random device not loaded; using insecure entropy > random: initialized > kbd0 at kbdmux0 > nexus0: > nexus0: : incomplete > pcib0: mem 0x1fe00000000-0x1fe01ffffff irq > 2032,2030,2031,2021 on nexus0 > pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz > panic: psycho_attach: unsupported number of ranges > cpuid = 0 > KDB: stack backtrace: > #0 0xc085db60 at psycho_attach+0x780 > #1 0xc0569dd8 at device_attach+0x518 > #2 0xc056b4e8 at device_probe_and_attach+0x28 > #3 0xc056b510 at bus_generic_attach+0x10 > #4 0xc087704c at nexus_attach+0x58c > #5 0xc0569dd8 at device_attach+0x518 > #6 0xc056b4e8 at device_probe_and_attach+0x28 > #7 0xc056b87c at bus_generic_new_pass+0x11c > #8 0xc056aeb8 at bus_set_pass+0xf8 > #9 0xc056af08 at root_bus_configure+0x8 > #10 0xc086a9a4 at configure+0x4 > #11 0xc04d4e3c at mi_startup+0x1dc > #12 0xc00a0028 at btext+0x28 > Uptime: 1s > > > Having a look at the source it looks like we're being tripped by the > following check in psycho.c: > > > /* > * Make sure that the expected ranges are present. The > * OFW_PCI_CS_MEM64 one is not currently used though. > */ > if (i != PSYCHO_NRANGE) > panic("%s: unsupported number of ranges", __func__); > > > Now it seems that this occurs because OpenBIOS currently only supports > 32-bit PCI memory space (and so doesn't generate the 64-bit PCI memory > space entry withing the corresponding property). > > I could alter OpenBIOS to add a dummy 64-bit PCI memory space entry to > the end of the ranges property, however this particular check does > seem to be rather excessive and it is also slightly disingenuous to > have OpenBIOS include a declaration for a memory space that it cannot > use (plus it seems from the comment above that FreeBSD can't actually > use it anyway?!). > > Does anyone know why this particular assertion was added and what it's > actually trying to guard against? > > > Many thanks, > > Mark. > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to > "freebsd-sparc64-unsubscribe@freebsd.org" > From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 22 18:52:47 2014 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFD8B8B7 for ; Fri, 22 Aug 2014 18:52:47 +0000 (UTC) Received: from mx.bsdtec.net (mx.bsdtec.net [174.34.171.65]) by mx1.freebsd.org (Postfix) with ESMTP id 90DCA36EA for ; Fri, 22 Aug 2014 18:52:47 +0000 (UTC) Received: from localhost (mx.bsdtec.net [172.16.32.2]) by mx.bsdtec.net (Postfix) with ESMTP id 671A7489875; Fri, 22 Aug 2014 18:46:36 +0000 (UTC) Received: from mx.bsdtec.net ([172.16.32.2]) by localhost (mx.bsdtec.net [172.16.32.2]) (amavisd-new, port 10032) with ESMTP id oujl6d9KDzso; Fri, 22 Aug 2014 18:46:35 +0000 (UTC) Received: from localhost (mx.bsdtec.net [172.16.32.2]) by mx.bsdtec.net (Postfix) with ESMTP id 5F62D4898C8; Fri, 22 Aug 2014 18:46:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at bsdtec.net Received: from mx.bsdtec.net ([172.16.32.2]) by localhost (mx.bsdtec.net [172.16.32.2]) (amavisd-new, port 10026) with ESMTP id mqdiePYXyv81; Fri, 22 Aug 2014 18:46:35 +0000 (UTC) Received: from [192.168.1.111] (bsdtec.plus.com [84.92.41.141]) by mx.bsdtec.net (Postfix) with ESMTPSA id 97080489875; Fri, 22 Aug 2014 18:46:34 +0000 (UTC) Message-ID: <1408733192.4056.5.camel@atlas.lerwick.hopto.org> Subject: Re: svn commit: r270201 - in head/sys: powerpc/include sys From: Craig Butler To: Konstantin Belousov Date: Fri, 22 Aug 2014 19:46:32 +0100 In-Reply-To: <20140820082700.GY2737@kib.kiev.ua> References: <201408200802.s7K82cJ6059609@svn.freebsd.org> <20140820082700.GY2737@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:52:47 -0000 On Wed, 2014-08-20 at 11:27 +0300, Konstantin Belousov wrote: > On Wed, Aug 20, 2014 at 08:02:38AM +0000, Konstantin Belousov wrote: > > Author: kib > > Date: Wed Aug 20 08:02:38 2014 > > New Revision: 270201 > > URL: http://svnweb.freebsd.org/changeset/base/270201 > > > > Log: > > Add arch-specific macro SFBUF_PHYS_DMAP(), which should translate the > > physical address of the page to direct map address, in case > > SFBUF_OPTIONAL_DIRECT_MAP returns true. The case of PowerPC AIM > > 64bit, where the page physical address is identical to the direct map > > address, is accidental. > Real use of this interposer is for sparc64 machines which can use direct > map due to usable cache implementation. > > Could someone with the machine identified as SPARC64V test the following > patch ? Just booting multiuser should be enough. > > diff --git a/sys/sparc64/include/vmparam.h b/sys/sparc64/include/vmparam.h > index 8e7d76c..c2f30c3 100644 > --- a/sys/sparc64/include/vmparam.h > +++ b/sys/sparc64/include/vmparam.h > @@ -241,5 +241,8 @@ extern vm_offset_t vm_max_kernel_address; > > #define SFBUF > #define SFBUF_MAP > +#define SFBUF_OPTIONAL_DIRECT_MAP dcache_color_ignore > +#include > +#define SFBUF_PHYS_DMAP(x) TLB_PHYS_TO_DIRECT(x) > > #endif /* !_MACHINE_VMPARAM_H_ */ What machines are identified as SPARC64V ?? our collection only identifies as sparc64. I think the sun4v code got sin binned, AFAIK the sun4u identifies as just plain sparc64. Regards Craig From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 22 19:01:49 2014 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 170F3B9A for ; Fri, 22 Aug 2014 19:01:49 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC039374D for ; Fri, 22 Aug 2014 19:01:48 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7MJ1fro038041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 22:01:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7MJ1fro038041 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7MJ1eci038039; Fri, 22 Aug 2014 22:01:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Aug 2014 22:01:40 +0300 From: Konstantin Belousov To: Craig Butler Subject: Re: svn commit: r270201 - in head/sys: powerpc/include sys Message-ID: <20140822190140.GQ2737@kib.kiev.ua> References: <201408200802.s7K82cJ6059609@svn.freebsd.org> <20140820082700.GY2737@kib.kiev.ua> <1408733192.4056.5.camel@atlas.lerwick.hopto.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fcn+O7u6afXSKWdN" Content-Disposition: inline In-Reply-To: <1408733192.4056.5.camel@atlas.lerwick.hopto.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:01:49 -0000 --Fcn+O7u6afXSKWdN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2014 at 07:46:32PM +0100, Craig Butler wrote: > On Wed, 2014-08-20 at 11:27 +0300, Konstantin Belousov wrote: > > On Wed, Aug 20, 2014 at 08:02:38AM +0000, Konstantin Belousov wrote: > > > Author: kib > > > Date: Wed Aug 20 08:02:38 2014 > > > New Revision: 270201 > > > URL: http://svnweb.freebsd.org/changeset/base/270201 > > >=20 > > > Log: > > > Add arch-specific macro SFBUF_PHYS_DMAP(), which should translate t= he > > > physical address of the page to direct map address, in case > > > SFBUF_OPTIONAL_DIRECT_MAP returns true. The case of PowerPC AIM > > > 64bit, where the page physical address is identical to the direct m= ap > > > address, is accidental. > > Real use of this interposer is for sparc64 machines which can use direct > > map due to usable cache implementation. > >=20 > > Could someone with the machine identified as SPARC64V test the following > > patch ? Just booting multiuser should be enough. > >=20 > > diff --git a/sys/sparc64/include/vmparam.h b/sys/sparc64/include/vmpara= m.h > > index 8e7d76c..c2f30c3 100644 > > --- a/sys/sparc64/include/vmparam.h > > +++ b/sys/sparc64/include/vmparam.h > > @@ -241,5 +241,8 @@ extern vm_offset_t vm_max_kernel_address; > > =20 > > #define SFBUF > > #define SFBUF_MAP > > +#define SFBUF_OPTIONAL_DIRECT_MAP dcache_color_ignore > > +#include > > +#define SFBUF_PHYS_DMAP(x) TLB_PHYS_TO_DIRECT(x) > > =20 > > #endif /* !_MACHINE_VMPARAM_H_ */ >=20 > What machines are identified as SPARC64V ?? our collection only > identifies as sparc64. SPARC64V are Zeus cores from Fujitsu. https://en.wikipedia.org/wiki/SPARC64_V FWIW, I find it strange that later cores are not marked as having the unaliasing tagging. >=20 > I think the sun4v code got sin binned, AFAIK the sun4u identifies as > just plain sparc64. sun4v is the platform name, not the CPU microarchitecture. I believe that Zeus are sun4u. --Fcn+O7u6afXSKWdN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT95OUAAoJEJDCuSvBvK1BWssP/0uNcVwe40ZjBzYO+iMGn8+j H7pyg6wDcD8HstRLIuc+vv3nuE5j0zne4nqVG3DNEjhn8h1FLZvCP35JAq1dyKI+ 7q95e8lbPGMjIdzQXSeOzFL9PApHqG288J/D3WpvyCymzZHDvgSIUKHs9AhidYdb ZJBxCKZvL8TPP/99SC5LxExGNVTP3NlzknTQWpUiUt3okGPyNpK/t5SN+qd0dBQF Cuq7eFFr3IenmDRjxMbvV2ZL2u6Dldi7K33spJQZpKUPpqPbIdA+0tdo9ryHPwRW fpwZeHnVeYrjPDFt1T3YSMXL8pWl7DBQcRDbs63jdmirNX9i1Vn4wB7SDkVKkOQJ HQlOEUeNS5BfG3OEdGyrXOFygUgxsjU3gVuOlacXZs8P+nfgQRyTZAoYmmGo82Js MwMJYTgQxBf54VWwxC2Ckb/Mm2xD2JVz419pmaT+3VXQM2YzF1aMRuHMtro6JNyA JggwFG5WptH7H6IUCLsoUVL+WfjQy1Fgp28QJ0O57cz+MyjNATcHZUn/kMJc/gBB caJbr/I3fYgG+ZQuaRAsbUdF4Xu7HofQwd+brB3wyL1PUg4W6hnH3CBiatGZmzjr MPApqkx14djxI2jcH2BGN9Wq3NLUUHGxs9yu1CbIpXqf1d8SVV6OEbpZQMzI/XQT 2o5KQcFEwfYqzIUan3CW =PQ/a -----END PGP SIGNATURE----- --Fcn+O7u6afXSKWdN-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 22 19:32:55 2014 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 757AEE20 for ; Fri, 22 Aug 2014 19:32:55 +0000 (UTC) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "darkthrone.kvedulv.de", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3822A3B0E for ; Fri, 22 Aug 2014 19:32:54 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id D7AA814F8; Fri, 22 Aug 2014 21:32:50 +0200 (CEST) Date: Fri, 22 Aug 2014 21:32:50 +0200 From: Michael Moll To: Konstantin Belousov Subject: Re: svn commit: r270201 - in head/sys: powerpc/include sys Message-ID: <20140822193250.GA14071@darkthrone.kvedulv.de> References: <201408200802.s7K82cJ6059609@svn.freebsd.org> <20140820082700.GY2737@kib.kiev.ua> <1408733192.4056.5.camel@atlas.lerwick.hopto.org> <20140822190140.GQ2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140822190140.GQ2737@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:32:55 -0000 Hi, On Fri, Aug 22, 2014 at 10:01:40PM +0300, Konstantin Belousov wrote: > > I think the sun4v code got sin binned, AFAIK the sun4u identifies as > > just plain sparc64. > sun4v is the platform name, not the CPU microarchitecture. I believe > that Zeus are sun4u. On Solaris e.g. a Primepower 450 with Zeus CPUs was sun4us. I don't know if later Fujitsu CPUs were also sun4us or together with SUN sun4u as the hardware was the same anyway. Regards -- Michael Moll From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 22 19:42:16 2014 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EB3C44E for ; Fri, 22 Aug 2014 19:42:16 +0000 (UTC) Received: from mx.bsdtec.net (mx.bsdtec.net [174.34.171.65]) by mx1.freebsd.org (Postfix) with ESMTP id 0DCB23C00 for ; Fri, 22 Aug 2014 19:42:16 +0000 (UTC) Received: from localhost (mx.bsdtec.net [172.16.32.2]) by mx.bsdtec.net (Postfix) with ESMTP id A822D489898; Fri, 22 Aug 2014 19:42:15 +0000 (UTC) Received: from mx.bsdtec.net ([172.16.32.2]) by localhost (mx.bsdtec.net [172.16.32.2]) (amavisd-new, port 10032) with ESMTP id lCORqM0Fuc-s; Fri, 22 Aug 2014 19:42:14 +0000 (UTC) Received: from localhost (mx.bsdtec.net [172.16.32.2]) by mx.bsdtec.net (Postfix) with ESMTP id 4F61F48989C; Fri, 22 Aug 2014 19:42:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at bsdtec.net Received: from mx.bsdtec.net ([172.16.32.2]) by localhost (mx.bsdtec.net [172.16.32.2]) (amavisd-new, port 10026) with ESMTP id rdYGDr9eBOZl; Fri, 22 Aug 2014 19:42:14 +0000 (UTC) Received: from [192.168.1.111] (bsdtec.plus.com [84.92.41.141]) by mx.bsdtec.net (Postfix) with ESMTPSA id 7B2A0489898; Fri, 22 Aug 2014 19:42:13 +0000 (UTC) Message-ID: <1408736531.4056.12.camel@atlas.lerwick.hopto.org> Subject: Re: svn commit: r270201 - in head/sys: powerpc/include sys From: Craig Butler To: Michael Moll Date: Fri, 22 Aug 2014 20:42:11 +0100 In-Reply-To: <20140822193250.GA14071@darkthrone.kvedulv.de> References: <201408200802.s7K82cJ6059609@svn.freebsd.org> <20140820082700.GY2737@kib.kiev.ua> <1408733192.4056.5.camel@atlas.lerwick.hopto.org> <20140822190140.GQ2737@kib.kiev.ua> <20140822193250.GA14071@darkthrone.kvedulv.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:42:16 -0000 On Fri, 2014-08-22 at 21:32 +0200, Michael Moll wrote: > Hi, > > On Fri, Aug 22, 2014 at 10:01:40PM +0300, Konstantin Belousov wrote: > > > I think the sun4v code got sin binned, AFAIK the sun4u identifies as > > > just plain sparc64. > > sun4v is the platform name, not the CPU microarchitecture. I believe > > that Zeus are sun4u. > > On Solaris e.g. a Primepower 450 with Zeus CPUs was sun4us. > I don't know if later Fujitsu CPUs were also sun4us or together with SUN > sun4u as the hardware was the same anyway. > > Regards Thanks Michael and Konstantin I just found your dmesg on the FreeBSD wiki and can see the SPARC64-V identifier. I learned something new. Regards Craig From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 23 11:41:34 2014 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 526B3BCD for ; Sat, 23 Aug 2014 11:41:34 +0000 (UTC) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12C593BC3 for ; Sat, 23 Aug 2014 11:41:33 +0000 (UTC) Received: from 5d604c68.skybroadband.com ([93.96.76.104] helo=[192.168.1.81]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XL9h7-0002Se-Na for sparc64@freebsd.org; Sat, 23 Aug 2014 12:41:24 +0100 Message-ID: <53F87DC9.9020800@ilande.co.uk> Date: Sat, 23 Aug 2014 12:40:57 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 93.96.76.104 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Subject: Trying to cross-build FreeBSD 10 release ISOs for sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 11:41:34 -0000 Hi all, Further to my earlier post, I figured it would probably make sense to setup my own FreeBSD build environment to work out what was happening but I can't seem to produce any valid ISOs for qemu-system-sparc64. The steps I took were as follows: 1) Created a new VM on a KVM amd64 host 2) Downloaded the latest FreeBSD 10 amd64 release ISO 3) Installed the basic system 4) Followed the instructions in the developers handbook to cross-build a kernel (TARGET=sparc64 TARGET_ARCH=sparc64) 5) Try and boot generated ISOs While the output ISOs are generated, they appear to be invalid (or at least OpenBIOS can't find a valid partition on them). Reviewing the logs, the entire build process seems to work all the way up to the point where the ISOs are generated which looks like this: root@freebsd:/usr/src/release # make -dx TARGET=sparc64 TARGET_ARCH=sparc64 cdrom sh /usr/src/release/sparc64/mkisoimages.sh -b FreeBSD_Install disc1.iso release Calculated size of `/tmp/bootfs.PjPBSKfi/bootfs.img': 524288 bytes, 4 inodes Extent size set to 8192 /tmp/bootfs.PjPBSKfi/bootfs.img: 0.5MB (1024 sectors) block size 8192, fragment size 1024 using 1 cylinder groups of 0.50MB, 64 blks, 64 inodes. super-block backups (for fsck -b #) at: 32, Populating `/tmp/bootfs.PjPBSKfi/bootfs.img' Image `/tmp/bootfs.PjPBSKfi/bootfs.img' complete 16+0 records in 16+0 records out 8192 bytes transferred in 0.000175 secs (46811633 bytes/sec) 1510+1 records in 1511+0 records out 495124480 bytes transferred in 35.611080 secs (13903664 bytes/sec) 1+1 records in 2+0 records out 655360 bytes transferred in 0.002090 secs (313572789 bytes/sec) 2+0 records in 2+0 records out 655360 bytes transferred in 0.001184 secs (553519748 bytes/sec) gpart: scheme 'VTOC8': Invalid argument gpart: No such geom: md0. gpart: No such geom: md0. Superficially it looks as if gpart can't understand the partitioning scheme used for sparc64 ISOs but does anyone else have any ideas as to why this isn't working? I should add that the FreeBSD 10 release sparc64 ISOs downloaded directly from freebsd.org appear to be fine and start to boot as intended. Many thanks, Mark. From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 23 13:09:55 2014 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEE597E2; Sat, 23 Aug 2014 13:09:55 +0000 (UTC) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "darkthrone.kvedulv.de", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F2C832C2; Sat, 23 Aug 2014 13:09:55 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id C47751691; Sat, 23 Aug 2014 15:09:50 +0200 (CEST) Date: Sat, 23 Aug 2014 15:09:50 +0200 From: Michael Moll To: Konstantin Belousov Subject: Re: svn commit: r270201 - in head/sys: powerpc/include sys Message-ID: <20140823130950.GA47512@darkthrone.kvedulv.de> References: <201408200802.s7K82cJ6059609@svn.freebsd.org> <20140820082700.GY2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140820082700.GY2737@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 13:09:55 -0000 Hi, On Wed, Aug 20, 2014 at 11:27:00AM +0300, Konstantin Belousov wrote: > Could someone with the machine identified as SPARC64V test the following > patch ? Just booting multiuser should be enough. > > diff --git a/sys/sparc64/include/vmparam.h b/sys/sparc64/include/vmparam.h > index 8e7d76c..c2f30c3 100644 > --- a/sys/sparc64/include/vmparam.h > +++ b/sys/sparc64/include/vmparam.h > @@ -241,5 +241,8 @@ extern vm_offset_t vm_max_kernel_address; > > #define SFBUF > #define SFBUF_MAP > +#define SFBUF_OPTIONAL_DIRECT_MAP dcache_color_ignore > +#include > +#define SFBUF_PHYS_DMAP(x) TLB_PHYS_TO_DIRECT(x) > > #endif /* !_MACHINE_VMPARAM_H_ */ Works for me. :) Regards -- Michael Moll