From owner-freebsd-sparc64@freebsd.org Wed Sep 16 19:28:12 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 0BAFA9CE126 for ; Wed, 16 Sep 2015 19:28:12 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B73E51EFF; Wed, 16 Sep 2015 19:28:10 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [2.219.74.29] (helo=[192.168.1.86]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZcIN9-0007vN-Qi; Wed, 16 Sep 2015 20:28:07 +0100 Message-ID: <55F9C2B8.7030605@ilande.co.uk> Date: Wed, 16 Sep 2015 20:27:52 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Alexey Dokuchaev CC: Marius Strobl , "freebsd-sparc64@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> In-Reply-To: <20150916031030.GA6711@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2.219.74.29 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: No (on s16892447.onlinehome-server.info); Unknown failure 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: Wed, 16 Sep 2015 19:28:12 -0000 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: addr 0x1400002000-0x1400003fff on ebus0 > -eeprom0: cannot allocate resources > -device_attach: eeprom0 attach returned 6 > +eeprom0: model mk48t59 > ebus0: addr 0 (no driver attached) > -ebus0: 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: 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.