PCI range checking under qemu-system-sparc64

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Wed Sep 16 19:28:12 UTC 2015


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.



More information about the freebsd-sparc64 mailing list