Date: Mon, 7 Sep 2015 22:31:52 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150907203152.GA70457@alchemy.franken.de> In-Reply-To: <20150906124859.GA14919@FreeBSD.org> References: <557B6116.70900@ilande.co.uk> <557C1162.3000106@FreeBSD.org> <557D82F8.50908@ilande.co.uk> <557DA6D5.4070800@FreeBSD.org> <557DCF54.7020606@ilande.co.uk> <A88F6A52-FA8A-4669-A2D6-23374F8E26BB@FreeBSD.org> <557DF887.20508@ilande.co.uk> <20150906110308.GA68829@FreeBSD.org> <55EC2E8D.4020803@ilande.co.uk> <20150906124859.GA14919@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <EEPROM/clock> addr 0x1400002000-0x1400003fff on ebus0 > eeprom0: cannot allocate resources > device_attach: eeprom0 attach returned 6 > ebus0: <fdthree> addr 0 (no driver attached) > ebus0: <su> 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: <PCI-EBus2 bridge> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150907203152.GA70457>