PCI range checking under qemu-system-sparc64

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Fri Sep 5 10:29:01 UTC 2014


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 at 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.



More information about the freebsd-sparc64 mailing list