From owner-freebsd-sparc64@freebsd.org Sun Sep 13 17:36:54 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36456A037E4 for ; Sun, 13 Sep 2015 17:36:54 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) 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 C10DC1A3A; Sun, 13 Sep 2015 17:36:52 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZbBCi-0001Lw-0J; Sun, 13 Sep 2015 18:36:43 +0100 Message-ID: <55F5B41F.7060903@ilande.co.uk> Date: Sun, 13 Sep 2015 18:36:31 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <557D82F8.50908@ilande.co.uk> <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> In-Reply-To: <20150913022143.GA7862@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: 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: No (on s16892447.onlinehome-server.info); Unknown failure X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 17:36:54 -0000 On 13/09/15 03:21, Marius Strobl wrote: >>> That's already unusual; real PCI-EBus-bridges have two memory >>> BARs (although children may use I/O ports which are translated >>> to memory resources upstream) rather than an I/O port and a >>> memory one. However, the above actually should also work code- >>> wise, iff the resource types are encoded correctly in the ranges >>> table. >> >> While the QEMU PCI-ebus properties don't necessarily reflect a real >> ultra2 > > You probably mean Ultra5/10 here; Ultra2 are SBus- rather than PCI- > based. Still, the machine QEMU emualtes only looks similar to a > real Ultra5/10 from a 10 km distance ... Ooops, yes. >> , they should be consistent in terms of ranges as several patches >> along those lines were required to enable NetBSD and OpenBSD to boot >> under qemu-system-sparc64. For reference I've included the properties >> from OpenBIOS below: >> >> >> 0 > cd /pci/ ok >> 0 > .properties >> name "pci" >> reg 000001fe 00000000 00000000 02000000 >> vendor-id 108e >> device-id a000 >> revision-id 0 >> class-code 60000 >> min-grant 0 >> max-latency 0 >> devsel-speed 0 >> fast-back-to-back >> 66mhz-capable >> subsystem-vendor-id 1af4 >> subsystem-id 1100 >> cache-line-size 0 >> device_type "pci" >> model "SUNW,sabre" >> compatible {"pci108e,a000", "pciclass,0"} >> #address-cells 3 >> #size-cells 2 >> #interrupt-cells 1 >> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 00 00 00 >> 00 00 00 00 10 00 00 00 00 01 ff 00 10 00 00 00 00 00 00 10 00 00 00 >> virtual-dma -- 8 : c0 00 00 00 20 00 00 00 >> #virtual-dma-size-cells 1 >> #virtual-dma-addr-cells 1 >> no-streaming-cache >> interrupts -- 10 : 00 00 07 f0 00 00 07 ee 00 00 07 ef 00 >> 00 07 e5 >> upa-portid 1f >> bus-range -- 8 : 00 00 00 00 00 00 00 02 >> available -- 28 : 02 00 00 00 00 00 00 00 04 04 00 00 00 >> 00 00 00 0b fc 00 00 01 00 00 00 00 00 00 00 00 00 83 80 00 00 00 00 00 >> 00 7c 80 >> interrupt-map -- 30 : 00 00 20 00 00 00 00 00 00 00 00 00 00 >> 00 00 01 ff e2 b7 40 00 00 00 10 00 00 28 00 00 00 00 00 00 00 00 00 00 >> 00 00 01 ff e2 b7 40 00 00 00 14 >> interrupt-map-mask -- 10 : 00 00 f8 00 00 00 00 00 00 00 00 00 00 >> 00 00 07 >> ok >> 0 > cd ebus ok >> 0 > .properties >> name "ebus" >> vendor-id 108e >> device-id 1000 >> revision-id 1 >> class-code 68000 >> min-grant 0 >> max-latency 0 >> devsel-speed 0 >> fast-back-to-back >> 66mhz-capable >> subsystem-vendor-id 1af4 >> subsystem-id 1100 >> cache-line-size a00 >> model "ebus" >> compatible {"pci108e,1000", "pciclass,068000"} >> #address-cells 2 >> #size-cells 1 >> #interrupt-cells 1 >> assigned-addresses -- 28 : 02 00 18 10 00 00 00 00 03 00 00 00 00 >> 00 00 00 01 00 00 00 01 00 18 14 00 00 00 00 00 00 40 00 00 00 00 00 00 >> 00 40 00 >> reg 00001800 00000000 00000000 00000000 00000000 >> 02001810 00000000 00000000 00000000 01000000 >> 01001814 00000000 00000000 00000000 00004000 >> interrupt-map -- 14 : 00 00 00 14 00 00 03 f8 00 00 00 01 ff >> e1 b9 48 00 00 00 2b >> interrupt-map-mask -- c : 00 00 01 ff ff ff ff ff 00 00 00 03 >> ranges -- 30 : 00 00 00 10 00 00 00 00 02 00 18 10 00 >> 00 00 00 00 00 00 00 01 00 00 00 00 00 00 14 00 00 00 00 01 00 18 14 00 >> 00 00 00 00 00 00 00 00 00 40 00 >> ok >> 0 > cd su ok >> 0 > .properties >> name "su" >> device_type "serial" >> reg 00000014 000003f8 00000008 >> interrupts 1 >> ok >> > > Okay, so the address of "su" actually is mapped to the I/O port space > at the EBus bridge. Again that doesn't match any real machine but at > least is consistent with the BAR setup QEMU employs on the PCI side. Yes. It's to do with the way that OpenBIOS expects to access ioport X at base + X which doesn't sit too well with the PCI-EBus bridge; at least it would require some terrific special case hacks to get this working correctly. >> I wonder if the problem is the same as that in >> https://reviews.freebsd.org/D2791 which is that some assumptions about >> the device tree are hard-coded rather than being read and/or calculated >> from the PROM properties? >> > > The first generations of PCI-based sun4u machines don't adhere to > the IEEE 1754-1994 bus binding specifications (on the other hand, > I only ever got draft versions of these so I've no idea whether > they went final). E450 are worst in that regard, closely followed > by Ultra30. To that matter, even the interpretation of the ranges > property for the PCI-ISA-bridges found in PCI-Express-based sun4u > machines still doesn't follow the relevant bus binding document. > Thus, assuming the behavior of real hardware built by Fujitsu and > Sun - which includes distrusting knowingly incorrect OFW properties > in quite a few occasions - in sparc64 bus code rather than basing > it on the OFW standards generally is sane. > That said, later device-tree-related code in FreeBSD/sparc64 is > rather generic and has quite a few heuristics, which made things > work out-of-the box on several models we didn't have access to > ourselves. Actually, in some cases FreeBSD performed even better > than Linux, Net- and OpenBSD did in that regard, i. e. while these > latter needed changes, FreeBSD required none. This also is why - > apparently - the FreeBSD kernel manages to attach the 16550 of > QEMU as low-level console device, although the BAR layout of the > PCI-EBus-bridge doesn't match any real hardware. Whilst working with other OSs, what tends to happen is that the basic kernel output gets sent via prom_printf() or similar which means that you see the output fine until you switch to userspace and your console driver kicks in. Now that may not be the case for FreeBSD but that's why I'm keen to get the ebus device attach working first to eliminate this as a possibility. > However, looking at ebus(4), I've spotted a bug in the conversion > to NEW_PCIB. Interested parties might want to give the attached > patch a try. That bug definitely can lead to the problem seen with > QEMU, I'm not sure it's the only one in that regard, though; I'm > fairly certain in this case there's no problem with interpreting > the device-tree involved, given that the same code is used for > ISA busses which - at least in reality - unlike EBus ones use > I/O port instead of memory space for the resources of devices > such as UARTs etc. There could be other spots not prepared for > EBus devices suddenly requesting SYS_RES_IOPORT, too, though. Thank you! I'm the process of clearing out space to set everything up so I would hope to be in place to start looking at this again in a couple of weeks. ATB, Mark.