From owner-freebsd-sparc64@freebsd.org Tue Sep 15 22:15:30 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 86AEC9C2C4D for ; Tue, 15 Sep 2015 22:15:30 +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 42F29107F; Tue, 15 Sep 2015 22:15:29 +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 1ZbyVD-0003hL-PJ; Tue, 15 Sep 2015 23:15:20 +0100 Message-ID: <55F89861.1030107@ilande.co.uk> Date: Tue, 15 Sep 2015 23:14:57 +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 , Alexey Dokuchaev CC: "freebsd-sparc64@freebsd.org" References: <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> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> In-Reply-To: <20150913180126.GC7862@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: Tue, 15 Sep 2015 22:15:30 -0000 On 13/09/15 19:01, Marius Strobl wrote: > On Sun, Sep 13, 2015 at 10:39:41AM +0000, Alexey Dokuchaev wrote: >> On Sun, Sep 13, 2015 at 04:21:43AM +0200, Marius Strobl wrote: >>> 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. >> >> I've applied that patch, but it alone is not enough to allow the boot >> to proceed further in QEMU. :( >> > > Err, right, on a second look the bug I thought existed in ebus(4) > actually isn't there; its code I added as part of the conversion > to NEW_PCIB is just a bit unclean/unobvious but in fact does the > right thing, even if a child resource would map to SYS_RES_IOPORT. > > However, I noticed that the cause of failure likely is a bug in > the "ranges" property of the QEMU EBus bridge. The following is > an example from a T1-AC200 demonstrating how a correct setup > looks like: > ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at device 12.0 on pci1 > child_hi child_lo phys_hi phys_mid phys_lo size > 00000010 00000000 82016010 00000000 f0000000 01000000 > 00000014 00000000 82016014 00000000 f1000000 00800000 > > When mapping EBus child resources, their adresses are translated > to the address base specified by (phys_mid << 32) | phys_lo on > the parent side, based on the range the child resource falls > into (determined via child_hi, child_lo and size). For PCI-EBus- > bridges, the parent address range further must [1, p. 113 f.] > match the resources on the PCI side, i. e. the BARs. In the above > case that's 0xf0000000 determined by (phys_mid << 32) | phys_lo > and size 0x1000000 from the ranges property and mem 0xf0000000- > 0xf0ffffff from the first BAR (see dmesg snippet) for example. > > With QEMU we get (based on the dump from Mark and your dmesg): > ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at device 3.0 on pci0 > child_hi child_lo phys_hi phys_mid phys_lo size > 00000010 00000000 02001810 00000000 00000000 01000000 > 00000014 00000000 01001814 00000000 00000000 00004000 > > So here, the parent addresses don't match as for example > 0x00000000 determined by (phys_mid << 32) | phys_lo doesn't > match BAR 0, which is mem 0x3000000-0x3ffffff. Likewise for > the second BAR and range combo. Sizes are correct, though. > > Note that according to the dump from Mark, the BARs of the > PCI-EBus-bridge at least match its "assigned-addresses" > property. So it might be as simple as fixing phys_mid and > phys_lo in the device tree file shipping with OpenBIOS, iff > such a thing exists and the device tree isn't assembled > dynamically somehow. Aha - I bet that's it. I've tweaked OpenBIOS to update phys_mid the same as "assigned-addresses" and that now gives me the following for /pci/ebus: 0 > cd /pci/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 03 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 40 00 00 00 40 00 ok Properly formatted, ranges now looks like this: 00000010 00000000 02001810 00000000 03000000 01000000 00000014 00000000 01001814 00000000 00004000 00004000 ...and in my tests here it doesn't appear to regress any of my test images. As I still don't have a FreeBSD environment setup yet, I've uploaded the binary to http://www.ilande.co.uk/tmp/openbios-sparc64 - if someone with QEMU 2.4 could replace openbios-sparc64 with the downloaded version and post a boot log in -nographic mode then that would be great. BTW does the comment on D2791 mean that it has been superseded by a new patch that has been committed to trunk? ATB, Mark.