Date: Wed, 16 Sep 2015 23:19:15 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Alexey Dokuchaev <danfe@FreeBSD.org>, "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150916211914.GD18789@alchemy.franken.de> In-Reply-To: <55F9C2B8.7030605@ilande.co.uk> References: <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> <55F9C2B8.7030605@ilande.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 16, 2015 at 08:27:52PM +0100, Mark Cave-Ayland wrote: > 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 Speaking of APB emulation, QEMU apparently cares about adding two APBs to the Sabre but there's nothing beneath them, i. e. all PCI devices hang off directly from the host-PCI-bridge. This cannot be in reality, hardware-wise. The QEMU topology shouldn't pose a problem for FreeBSD but I think some x11 part at least one point in time had the assumption the if there are APBs (aka Simbas), all PCI devices sit underneath them. Anyway, I'm mainly puzzled as to why that topology was chosen in QEMU. If there's a problem with emulating an entire PCI hierarchy, i. e. devices behind PCI-PCI- bridges, why not emulate a Hummingbird and get rid of the APBs altogether in the frist place? > 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. The next lines should be probe messages of the devices on the ATA controller, i. e. something like: cd0 at ata3 bus 0 scbus1 target 1 lun 0 cd0: <TEAC CD-224E 1.7A> Removable CD-ROM SCSI device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ada0 at ata3 bus 0 scbus1 target 0 lun 0 ada0: <ST340016A 3.10> ATA-5 device ada0: Serial Number 3HS2QXLQ ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytes) ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 And then finally some "Trying to mount root from <...>" line. Which suggest that the next thing to investigate is the CMD646 emulation. Is there a particular reason why QEMU emulates a CMD646U rather than a plain CMD646 as found in the real sun4u machines of the USIIe/i era? Alexey, does building the port with CDROM_DMA disabled make a difference? I've also a gut feeling that interrupts are not working, otherwise there should be some timeout message if detection of ATA devices fails and finally a panic due to there being no source for mounting root (assuming the kernel doesn't hang before the enumeration of storage devices). Alexey, could you please try to drop into the debugger (apparently, ctrl-a b should bring you there with QEMU if you have compiled DDB into the kernel) and issue a `show intrcnt` (besides a backtrace)? Btw., is there a way to netboot with qemu-system-sparc64? It would help enormously not to build ISO images for testing but apparently at least `boot net:dhcp` isn't implemented in QEMU/OpenBIOS. > 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? Unlikely; "Initialized" means just that, the SA stuff has been set up. Also, given that IP isn't used at that point IPsec simply isn't either. Unblocking the random device in turn comes later, i. e. at least after storage devices have been probed. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150916211914.GD18789>