PCI range checking under qemu-system-sparc64

Marius Strobl marius at alchemy.franken.de
Wed Sep 16 21:19:25 UTC 2015

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.


More information about the freebsd-sparc64 mailing list