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