Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Sep 2014 11:55:52 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-sparc64@freebsd.org
Subject:   Re: PCI range checking under qemu-system-sparc64
Message-ID:  <2084808.1lxSgnvf69@ralph.baldwin.cx>
In-Reply-To: <53F73E6F.9080805@ilande.co.uk>
References:  <53F73E6F.9080805@ilande.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <Software, Yarrow> initialized
> kbd0 at kbdmux0
> nexus0: <Open Firmware Nexus device>
> nexus0: <builtin>: incomplete
> pcib0: <U2P UPA-PCI bridge> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2084808.1lxSgnvf69>