PCI range checking under qemu-system-sparc64
mark.cave-ayland at ilande.co.uk
Fri Aug 22 13:18:59 UTC 2014
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:
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 at snap.freebsd.org:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC
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
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
Does anyone know why this particular assertion was added and what it's
actually trying to guard against?
More information about the freebsd-sparc64