From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 22 13:18:59 2014 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8B8AC65 for ; Fri, 22 Aug 2014 13:18:58 +0000 (UTC) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A88DC3F3A for ; Fri, 22 Aug 2014 13:18:57 +0000 (UTC) Received: from 5d604c68.skybroadband.com ([93.96.76.104] helo=[192.168.1.81]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XKoQN-00069T-MC for freebsd-sparc64@freebsd.org; Fri, 22 Aug 2014 13:58:36 +0100 Message-ID: <53F73E6F.9080805@ilande.co.uk> Date: Fri, 22 Aug 2014 13:58:23 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 93.96.76.104 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Subject: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) 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: Fri, 22 Aug 2014 13:18:59 -0000 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? Many thanks, Mark.