Date: Fri, 05 Sep 2014 11:07:05 +0100 From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> To: John Baldwin <jhb@freebsd.org>, freebsd-sparc64@freebsd.org Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <54098B49.7000307@ilande.co.uk> In-Reply-To: <2084808.1lxSgnvf69@ralph.baldwin.cx> References: <53F73E6F.9080805@ilande.co.uk> <2084808.1lxSgnvf69@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <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. */ > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54098B49.7000307>