From owner-freebsd-sparc64@freebsd.org Sun Sep 13 10:39:41 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 1BE409CD4C8 for ; Sun, 13 Sep 2015 10:39:41 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0C11E1E82; Sun, 13 Sep 2015 10:39:41 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 0AD301BE4; Sun, 13 Sep 2015 10:39:41 +0000 (UTC) Date: Sun, 13 Sep 2015 10:39:41 +0000 From: Alexey Dokuchaev To: Marius Strobl Cc: Mark Cave-Ayland , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150913103940.GA60101@FreeBSD.org> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150913022143.GA7862@alchemy.franken.de> User-Agent: Mutt/1.5.23 (2014-03-12) 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 10:39:41 -0000 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. :( As Mark had mentioned, I will try to get some debug info and share it if I find anything interesting. ./danfe