From owner-freebsd-sparc64@FreeBSD.ORG Thu Sep 4 15:56:02 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 33A8F2D6 for ; Thu, 4 Sep 2014 15:56:02 +0000 (UTC) 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 D0CB91CEA for ; Thu, 4 Sep 2014 15:56:01 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 54DE3B91C; Thu, 4 Sep 2014 11:56:00 -0400 (EDT) From: John Baldwin To: freebsd-sparc64@freebsd.org Subject: Re: PCI range checking under qemu-system-sparc64 Date: Thu, 04 Sep 2014 11:55:52 -0400 Message-ID: <2084808.1lxSgnvf69@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <53F73E6F.9080805@ilande.co.uk> References: <53F73E6F.9080805@ilande.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Sep 2014 11:56:00 -0400 (EDT) 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: Thu, 04 Sep 2014 15:56:02 -0000 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: Index: psycho.c =================================================================== --- psycho.c (revision 271098) +++ psycho.c (working copy) @@ -448,18 +448,12 @@ psycho_attach(device_t dev) i = OF_getprop_alloc(node, "ranges", sizeof(*range), (void **)&range); /* - * 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__); - /* * Find the addresses of the various bus spaces. * There should not be multiple ones of one kind. * The physical start addresses of the ranges are the configuration, * memory and I/O handles. */ - for (i = 0; i < PSYCHO_NRANGE; i++) { + for (; i >= 0; i--) { j = OFW_PCI_RANGE_CS(&range[i]); if (sc->sc_pci_bh[j] != 0) panic("%s: duplicate range for space %d", @@ -466,6 +460,18 @@ psycho_attach(device_t dev) __func__, j); sc->sc_pci_bh[j] = OFW_PCI_RANGE_PHYS(&range[i]); } + + /* + * Make sure that the expected ranges are present. The + * OFW_PCI_CS_MEM64 one is not currently used. + */ + if (sc->sc_pci_bh[OFW_PCI_CS_CONFIG] == 0) + panic("%s: missing CONFIG range", __func__); + if (sc->sc_pci_bh[OFW_PCI_CS_IO] == 0) + panic("%s: missing IO range", __func__); + if (sc->sc_pci_bh[OFW_PCI_CS_MEM32] == 0) + panic("%s: missing MEM32 range", __func__); + free(range, M_OFWPROP); /* Register the softc, this is needed for paired Psychos. */ -- John Baldwin From owner-freebsd-sparc64@FreeBSD.ORG Fri Sep 5 10:29:01 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 397818E9; Fri, 5 Sep 2014 10:29:01 +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 EC0BD1F44; Fri, 5 Sep 2014 10:28:59 +0000 (UTC) Received: from 4e56a41d.skybroadband.com ([78.86.164.29] 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 1XPqQI-0003MA-AY; Fri, 05 Sep 2014 11:07:19 +0100 Message-ID: <54098B49.7000307@ilande.co.uk> Date: Fri, 05 Sep 2014 11:07:05 +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: John Baldwin , freebsd-sparc64@freebsd.org References: <53F73E6F.9080805@ilande.co.uk> <2084808.1lxSgnvf69@ralph.baldwin.cx> In-Reply-To: <2084808.1lxSgnvf69@ralph.baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 78.86.164.29 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.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, 05 Sep 2014 10:29:01 -0000 On 04/09/14 16:55, 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: > > Index: psycho.c > =================================================================== > --- psycho.c (revision 271098) > +++ psycho.c (working copy) > @@ -448,18 +448,12 @@ psycho_attach(device_t dev) > > i = OF_getprop_alloc(node, "ranges", sizeof(*range), (void **)&range); > /* > - * 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__); > - /* > * Find the addresses of the various bus spaces. > * There should not be multiple ones of one kind. > * The physical start addresses of the ranges are the configuration, > * memory and I/O handles. > */ > - for (i = 0; i < PSYCHO_NRANGE; i++) { > + for (; i >= 0; i--) { > j = OFW_PCI_RANGE_CS(&range[i]); > if (sc->sc_pci_bh[j] != 0) > panic("%s: duplicate range for space %d", > @@ -466,6 +460,18 @@ psycho_attach(device_t dev) > __func__, j); > sc->sc_pci_bh[j] = OFW_PCI_RANGE_PHYS(&range[i]); > } > + > + /* > + * Make sure that the expected ranges are present. The > + * OFW_PCI_CS_MEM64 one is not currently used. > + */ > + if (sc->sc_pci_bh[OFW_PCI_CS_CONFIG] == 0) > + panic("%s: missing CONFIG range", __func__); > + if (sc->sc_pci_bh[OFW_PCI_CS_IO] == 0) > + panic("%s: missing IO range", __func__); > + if (sc->sc_pci_bh[OFW_PCI_CS_MEM32] == 0) > + panic("%s: missing MEM32 range", __func__); > + > free(range, M_OFWPROP); > > /* Register the softc, this is needed for paired Psychos. */ > Hi John, Thanks for the patch. Unfortunately testing is fairly difficult at the moment as I can't build a suitable test .iso to boot in QEMU as detailed in http://lists.freebsd.org/pipermail/freebsd-sparc64/2014-August/009474.html. Do you have any idea as to how to resolve the cross-build issue so I can create a valid .iso? Many thanks, Mark.