From owner-freebsd-sparc64@freebsd.org Sun Sep 13 18:01:31 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 A54B9A03523 for ; Sun, 13 Sep 2015 18:01:31 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5FC1778; Sun, 13 Sep 2015 18:01:30 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8DI1QhR011243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Sep 2015 20:01:26 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8DI1QEU011242; Sun, 13 Sep 2015 20:01:26 +0200 (CEST) (envelope-from marius) Date: Sun, 13 Sep 2015 20:01:26 +0200 From: Marius Strobl To: Alexey Dokuchaev Cc: "freebsd-sparc64@freebsd.org" , Mark Cave-Ayland Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150913180126.GC7862@alchemy.franken.de> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150913103940.GA60101@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 13 Sep 2015 20:01:26 +0200 (CEST) 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 18:01:31 -0000 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. Marius 1: Peripheral Component Interconnect Input Output Controller, Part No.: 802-7837-01, Sun Microelectronics, March 1997