From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 9 18:32:21 2015 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 775C5F61 for ; Tue, 9 Jun 2015 18:32:21 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [66.135.54.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA291C53 for ; Tue, 9 Jun 2015 18:32:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 23A8256088; Tue, 9 Jun 2015 13:32:20 -0500 (CDT) Date: Tue, 9 Jun 2015 13:32:20 -0500 From: Mark Linimon To: Daniel Rudy Cc: "freebsd-sparc64@freebsd.org" Subject: Re: Sun Fire T1000 Message-ID: <20150609183219.GA13202@lonesome.com> References: <1432801667.8486.YahooMailBasic@web184303.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432801667.8486.YahooMailBasic@web184303.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:32:21 -0000 I don't know if someone replied to this earlier or not, if so, apologies. These do not boot under sparc64. The sun4v port was intended to support them but was never completed. It would be a fairly time-consuming effort for someone. mcl From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 10 06:22:02 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 458B145A for ; Wed, 10 Jun 2015 06:22:02 +0000 (UTC) (envelope-from fddi@gmx.it) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA5FF17A9 for ; Wed, 10 Jun 2015 06:22:01 +0000 (UTC) (envelope-from fddi@gmx.it) Received: from [10.0.0.40] ([71.202.183.78]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lbujs-1ZRlB047ds-00jMex; Wed, 10 Jun 2015 08:16:27 +0200 Message-ID: <5577D636.8000701@gmx.it> Date: Tue, 09 Jun 2015 23:16:22 -0700 From: fddi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mark Linimon , Daniel Rudy CC: "freebsd-sparc64@freebsd.org" Subject: Re: Sun Fire T1000 References: <1432801667.8486.YahooMailBasic@web184303.mail.ne1.yahoo.com> <20150609183219.GA13202@lonesome.com> In-Reply-To: <20150609183219.GA13202@lonesome.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:vnoAORj+tv0Az4rg3kue/FxKrmHbMU432EJyI5WkyGEznKo1jpr AhKMIpjErK36gI+Kto2zgaxiM9fauc2zkwqCfAoDZPvcFyCrJKXEsxg0MORkrycQR5a3DZr WrZNg7TTPo6Py04x483eIOos+LuEof091nzZa1tP52DEM6Ul3sO2l19DJkuh9tSfbRlZnbC veyFTx918aO9UsmsbK/kA== X-UI-Out-Filterresults: notjunk:1;V01:K0:0Xmp6rSKJus=:Q8jt3pLNFlDf6tDiOi1TLf nRkVtsMmCxTQKWqTrcERrKXYIrpRrv75AC+V7QQSjhPpVnJIDuS5npqDPgaIhF4ElfP6ZfC22 R826K8iSM63KQI/JpFzelL272I52PoIab9JZcio/hovf419D611lv1K6hfmddrYhzqPJViiX+ gUgypjRU+HWO6iwu1NuhYmTyPxwaTysHb+j+YPVXKdYdldWNixAjzMtHYfwlKVTJi5To2U4tV TlBc7C5O2Mqx+jhAC5AAhyrifagHhaox4KFeHTLppmEkMXsF91TaUybspYsFC42hYsxoF0NiX jdy0xsygoGQi/M5OzDF183MuRwRLYpCNRGsaIU5pD4De5digr0CAUm7e2svQXLcoZvRxdc+0M VXclmwJW4RUKOTyV/vIEAsH+2lORDCecWmu2ARLlFh9zfg6hy0tuRkTIAQv7ESKz7eWwzvuvu nSfSuHPz/HopW8zoPCrTHRowokpMI3od6Ej39mjQwgZWW2SzyoBy7SnZEgsAQq8rAejA3pZQs Jpjj3LlfvpobyqHZRXV05cO1E5hue8QfxDYqLr4nNYfn94eH99RKHqZEIcRelt2sLEWAipt7T kjxNNSVzohqeRK4kpLQirQCcGpNOLxrGq1yyJP0iXJz0EDdGn8PM94MflXEFKixvQ/ET2dSGV L/BbvQUqwkVtDQEH1JJ1fut0H+FfkEkw+GSTro4PfDOiEL8H++dvxZQn4VYLNqTuJIgo= X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 06:22:02 -0000 On 09/06/15 11:32, Mark Linimon wrote: > I don't know if someone replied to this earlier or not, if so, apologies. > > These do not boot under sparc64. The sun4v port was intended to support > them but was never completed. It would be a fairly time-consuming effort > for someone. > > mcl > _______________________________________________ > 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" I think OpenBSD has support for it, if one wants to run a BSD style OS on those machines. Rick From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 11 03:11:27 2015 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AA26A75 for ; Thu, 11 Jun 2015 03:11:27 +0000 (UTC) (envelope-from t05976e0028-ecae75002-b3af625ff9904dea8df58793674e3f47@bounce.twitter.com) Received: from spring-chicken-bg.twitter.com (spring-chicken-bg.twitter.com [199.16.156.172]) (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 C93E41CEB for ; Thu, 11 Jun 2015 03:11:26 +0000 (UTC) (envelope-from t05976e0028-ecae75002-b3af625ff9904dea8df58793674e3f47@bounce.twitter.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=dkim-201406; t=1433992283; bh=NWuQ+3KiWLxV9H94ym6tcP4GAnqAgwIvLx4KdcOiWZg=; h=Date:From:To:Subject:MIME-Version:Content-Type:Feedback-ID: Message-ID; b=LjYpheJbaunNiNBK46XlFgwxXV88uVKBCGiRK6DjdUnLL6ie+jCIA/wjg5+YLYhOo l/Co5PsXpP1qUt71FhCIQYZy25SOEjCFzd97jWmsMiPtV5PEqccY3tRnY6VnHwa59u 3ccXBDsIrMLbGmzGOLsRIbLKFZ4wIVbAxt+OmyA9UYqDFm84jk78083hpYibo94LmQ 1c2Pa5m2feV3H8FiCIXximkbiek+4Z3O/iUX6xXDAmUvNzUeHpLmrqxAqxPZXciuqM 5fV3sGgBN7qzr5VeF4nbPaJDdZgGRkJAHSabXsXzjZmgxRem6mjPaPKOT/VaTbC4FP 4typq/+3/vgQQ== X-MSFBL: ZnJlZWJzZC1zcGFyYzY0QGh1Yi5mcmVlYnNkLm9yZ0BhdGxhLWFxai0yMy1zcjEt RXZlcnl0aGluZy4xOTJARXZlcnl0aGluZ0BmcmVlYnNkLXNwYXJjNjRcQGh1Yi5m cmVlYnNkLm9yZ1xAdXNiIyMyNFxAMjQ0XEAzMzE4MzI3NDkxXEAwXEA0YTY4OTc4 ZGZmNjViN2VlZGY0YmRmOWMwYzExZjQ0MDU3MDdhYzhl Date: Thu, 11 Jun 2015 03:11:23 +0000 From: Twitter To: Cijos Dianthus Subject: Confirm your Twitter account, Cijos Dianthus MIME-Version: 1.0 Feedback-ID: 0040162518f58f41d1f0:16481b2a2bd9895cc9f3f73eb2597daffdce:none:twitterESP Message-ID: <45.96.40539.B5CF8755@twitter.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 03:11:27 -0000 Cijos Dianthus, Confirm your email address to complete your Twitter account. It's easy - just click on the button below. Click on the link below or copy and paste it into a browser: https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Faccount%2Fconfirm_user_email%2F3318327491%2F93H39-D3CCF-143399%3Ft%3D1%26cn%3DZW1haWxfY29uZmlybV9pbml0%26sig%3D66f0389e6af45751bc46f223b42469bed34f606a%26al%3D1%26iid%3Db3af625ff9904dea8df58793674e3f47%26ac%3D1%26autoactions%3D1433992283%26uid%3D3318327491%26nid%3D244%2B308&t=1&cn=ZW1haWxfY29uZmlybV9pbml0&sig=28a7e0760db245ab279b78bdb039e3fad80fabdd&iid=b3af625ff9904dea8df58793674e3f47&uid=3318327491&nid=244+308 From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 12 13:20:47 2015 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 514A653D for ; Fri, 12 Jun 2015 13:20:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29E7314EE for ; Fri, 12 Jun 2015 13:20:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [137.122.64.8]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 38130B939 for ; Fri, 12 Jun 2015 09:20:45 -0400 (EDT) Message-ID: <557ADCAB.9020409@FreeBSD.org> Date: Fri, 12 Jun 2015 09:20:43 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.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> <2084808.1lxSgnvf69@ralph.baldwin.cx> In-Reply-To: <2084808.1lxSgnvf69@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Jun 2015 09:20:45 -0400 (EDT) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:20:47 -0000 On 9/4/14 11:55 AM, John Baldwin wrote: > On Friday, August 22, 2014 01:58:23 PM 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? > > I suspect it was added out of an abundance of caution based on whatever real > hardware it has run on. You can try this (untested) change: FYI, I was able to test my earlier patch and have posted an updated patch for review. In my case the system appears to hang before it goes into single user mode both in graphics mode and with -nographic. https://reviews.freebsd.org/D2791 -- John Baldwin From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 12 23:10:56 2015 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDDCAA88; Fri, 12 Jun 2015 23:10:56 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) 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 7B00B77E; Fri, 12 Jun 2015 23:10:54 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from 5ec26862.skybroadband.com ([94.194.104.98] helo=[192.168.1.87]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1Z3Xhv-0001y3-1g; Fri, 12 Jun 2015 23:45:52 +0100 Message-ID: <557B6116.70900@ilande.co.uk> Date: Fri, 12 Jun 2015 23:45:42 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: John Baldwin , freebsd-sparc64@freebsd.org References: <53F73E6F.9080805@ilande.co.uk> <2084808.1lxSgnvf69@ralph.baldwin.cx> <557ADCAB.9020409@FreeBSD.org> In-Reply-To: <557ADCAB.9020409@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 94.194.104.98 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: Re: 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.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 23:10:56 -0000 On 12/06/15 14:20, John Baldwin wrote: > On 9/4/14 11:55 AM, John Baldwin wrote: >> On Friday, August 22, 2014 01:58:23 PM 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? >> >> I suspect it was added out of an abundance of caution based on whatever real >> hardware it has run on. You can try this (untested) change: > > FYI, I was able to test my earlier patch and have posted an updated patch for > review. In my case the system appears to hang before it goes into single user > mode both in graphics mode and with -nographic. > > https://reviews.freebsd.org/D2791 Hi John, Thanks for the patch. As I could never cross-compile a SPARC64 kernel on a local FreeBSD VM, I wasn't able to test your patch at the time. However if it gets merged then I'll try and find some time to start digging again with a suitable ISO. Many thanks, Mark. From owner-freebsd-sparc64@FreeBSD.ORG Sat Jun 13 11:17:57 2015 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54DC8DC9 for ; Sat, 13 Jun 2015 11:17:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12EC1F6A for ; Sat, 13 Jun 2015 11:17:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [137.122.64.66]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0BAD6B926; Sat, 13 Jun 2015 07:17:55 -0400 (EDT) Message-ID: <557C1162.3000106@FreeBSD.org> Date: Sat, 13 Jun 2015 07:17:54 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mark Cave-Ayland , freebsd-sparc64@freebsd.org Subject: Re: PCI range checking under qemu-system-sparc64 References: <53F73E6F.9080805@ilande.co.uk> <2084808.1lxSgnvf69@ralph.baldwin.cx> <557ADCAB.9020409@FreeBSD.org> <557B6116.70900@ilande.co.uk> In-Reply-To: <557B6116.70900@ilande.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 13 Jun 2015 07:17:55 -0400 (EDT) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 11:17:57 -0000 On 6/12/15 6:45 PM, Mark Cave-Ayland wrote: > On 12/06/15 14:20, John Baldwin wrote: >> On 9/4/14 11:55 AM, John Baldwin wrote: >>> On Friday, August 22, 2014 01:58:23 PM 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? >>> >>> I suspect it was added out of an abundance of caution based on whatever real >>> hardware it has run on. You can try this (untested) change: >> >> FYI, I was able to test my earlier patch and have posted an updated patch for >> review. In my case the system appears to hang before it goes into single user >> mode both in graphics mode and with -nographic. >> >> https://reviews.freebsd.org/D2791 > > Hi John, > > Thanks for the patch. As I could never cross-compile a SPARC64 kernel on > a local FreeBSD VM, I wasn't able to test your patch at the time. > However if it gets merged then I'll try and find some time to start > digging again with a suitable ISO. FYI, the steps I took to build a new ISO in an amd64 host were the following: - download an existing HEAD snap ISO - untar that to a directory named foo/tree - use 'make TARGET=sparc64 buildkernel' to build a test kernel - 'make TARGET=sparc64 installkernel DESTDIR=foo/tree' - 'sh /usr/src/release/sparc64/mkisoimages.sh -b "test" sparc64.iso foo/tree' I was then able to boot sparc64.iso. -- John Baldwin