Date: Wed, 16 Sep 2015 20:27:52 +0100 From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: Marius Strobl <marius@alchemy.franken.de>, "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <55F9C2B8.7030605@ilande.co.uk> In-Reply-To: <20150916031030.GA6711@FreeBSD.org> References: <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> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/09/15 04:10, Alexey Dokuchaev wrote: > On Tue, Sep 15, 2015 at 11:14:57PM +0100, Mark Cave-Ayland wrote: >> 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: >> >> [...] >> 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. > > Log is identical to the one I posted earlier (modulo the build timestamps), > except this part: > > eeprom0: <EEPROM/clock> addr 0x1400002000-0x1400003fff on ebus0 > -eeprom0: cannot allocate resources > -device_attach: eeprom0 attach returned 6 > +eeprom0: model mk48t59 > ebus0: <fdthree> addr 0 (no driver attached) > -ebus0: <su> addr 0x14000003f8-0x14000003ff irq 43 (no driver attached) > +uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 > +uart0: console (9600,n,8,1) > ebus0: <kb_ps2> addr 0x1400000060-0x1400000067 (no driver attached) Well this is definitely progress - at least the ebus attach is now sorted :) I've sent the patch upstream (see http://www.openfirmware.info/pipermail/openbios/2015-September/008802.html) and will commit it soon if there are no objections. Next I'll see if I can get the 8042 part of the device tree correct in order to attach the PS/2 keyboard driver. > Kernel still hangs at the same place. Hmmm. Thinking back to when I was getting NetBSD/OpenBSD to work under QEMU then first things I would look at are: - Missing UPA/APB diagnostic register implementation from QEMU - Use of an ASI unimplemented/buggy in QEMU - Incorrect interrupt mapping/bug in APB emulation Is it possible to force entry into the kernel debugger on boot and get a backtrace during the hang to see what is happening? Also how does the boot log compare with a complete boot log - often looking at what the next line is on a complete boot log gives a hint as where things are going wrong. If you boot in normal (graphic) mode is there any output that appears there but not in -nographic mode? I also see that the output stops after "IPsec: Initialized Security Association Processing." appears on the console. Maybe the crypto uses paths that aren't well tested in QEMU or we are waiting for entrophy? Does disabling the IPsec module in the kernel help? >> BTW does the comment on D2791 mean that it has been superseded by a new >> patch that has been committed to trunk? > > Yes, it was committed as part of r287726. Because commit log did not have > reference to D2791, it had to be closed/abandoned by hand. Great! Thank you both for your help so far :) ATB, Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55F9C2B8.7030605>