From owner-freebsd-sparc64@freebsd.org Mon Sep 7 20:32:02 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 6DAB99CCF00 for ; Mon, 7 Sep 2015 20:32:02 +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 DA98418F8; Mon, 7 Sep 2015 20:32:01 +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 t87KVqv2070598 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Sep 2015 22:31:52 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t87KVq4Z070597; Mon, 7 Sep 2015 22:31:52 +0200 (CEST) (envelope-from marius) Date: Mon, 7 Sep 2015 22:31:52 +0200 From: Marius Strobl To: Alexey Dokuchaev Cc: Mark Cave-Ayland , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150907203152.GA70457@alchemy.franken.de> References: <557B6116.70900@ilande.co.uk> <557C1162.3000106@FreeBSD.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150906124859.GA14919@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]); Mon, 07 Sep 2015 22:31:52 +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: Mon, 07 Sep 2015 20:32:02 -0000 On Sun, Sep 06, 2015 at 12:48:59PM +0000, Alexey Dokuchaev wrote: > On Sun, Sep 06, 2015 at 01:16:13PM +0100, Mark Cave-Ayland wrote: > > On 06/09/15 12:03, Alexey Dokuchaev wrote: > > > Mark did you have any success with getting the boot process further? > > > > Not really - due to changes with my job and involvment in GSoC this year > > then my QEMU SPARC64 work hasn't really progressed much :( > > > > I don't have my FreeBSD environment setup right now (due to OS upgrade) > > but can you post the console output for the boot as far as it gets with > > the current version of the patch applied? > > Last few lines: > > [...] > eeprom0: addr 0x1400002000-0x1400003fff on ebus0 > eeprom0: cannot allocate resources > device_attach: eeprom0 attach returned 6 > ebus0: addr 0 (no driver attached) > ebus0: addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) This suggests that there's something wrong with the emulation of the PCI-EBus-bridge (child space maps to a region not covered by the BARs, child space not covered by the mapping, wrong resource type in the ranges table or something like that), causing the allocation of child resources to fail as in the eeprom(4) case above. Such a problem would also explain why uart(4) doesn't try to attach to 'su' albeit it should: uart_bus_probe() already allocates the resource, failing silently if that doesn't work and, thus, causing uart_bus_attach() never to be called. > Full log available here: > > http://193.124.210.26/head-r287497-sparc64-qemu.log > > ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at device 3.0 on pci0 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. Marius