[OpenBIOS] Qemu/OpenBIOS 64-bit

[Mark Cave-Ayland]

On 28/12/13 00:54, Tarl Neustaedter wrote:

> On 2013-Dec-27, 19:08 , Nick Couchman wrote:

>> [root at qemu-openbios-dev ~]# /opt/qemu/bin/qemu-system-sparc64 -cdrom
>> /mnt/iso/Solaris/sol-10-u9-ga-sparc-dvd.iso -boot d -nographic -m 2048
>> OpenBIOS for Sparc64
>> Configuration device id QEMU version 1 machine id 0
>> kernel cmdline
>> CPUs: 1 x SUNW,UltraSPARC-IIi
>> UUID: 00000000-0000-0000-0000-000000000000
>> Welcome to OpenBIOS v1.1 built on Dec 27 2013 23:00
>> Type 'help' for detailed information
>> Trying cdrom:f...
>> Not a bootable ELF image
>> Not a bootable a.out image
>>
>> Loading FCode image...
>> Loaded 7420 bytes
>> entry point is 0x4000
>> Ignoring failed claim for va 1000000 memsz a8cb6!
>> Ignoring failed claim for va 1402000 memsz 4b4a8!
>> Ignoring failed claim for va 1800000 memsz 61b48!
>
> Those are a problem. My recollection is that it's loading Solaris
> (genunix) in at 100.0000. Failing those claims means something is busted
> with the memory model.

(Disclaimer: it's probably been at least a year since I last looked at 
this in detail)

I seem to remember that the memory regions in question are remapped to 
two different physical addresses by the bootloader at two different 
points during boot; the remapping is allowed to happen but OFMEM drops a 
warning onto the serial console as at the time I wasn't sure if this was 
a valid thing to do or not.

>> Jumping to entry point 00000000010071d8 for type 0000000000000001...
>> switching to new context: entry point 0x10071d8 stack 0x00000000ffe86a01
>> warning:interpret: exception -13 caught
>
> That's a problem. No idea what an exception -13 means. I'm surprised it
> was able to continue after that.

 From memory I think this is the chunk of Forth code in the Solaris 
kernel that sets up something on HME hardware (which QEMU currently does 
not emulate).

>> SunOS Release 5.10 Version Generic_142909-17 64-bit
>> Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights
>> reserved.
>> spacex@:interpret: exception -13 caught
>
> spacex@ is an forth operation to do a 64-bit load from an arbitrary
> address space. Most of them are used to access physical memory, for
> things like manipulating MMUs, although there are a few for dealing with
> some of the IO devices. This sounds like somewhere QEMUs machine model
> doesn't directly match what Solaris 5.10 thinks it should.

I'm fairly sure this error occurs because spacex@ isn't yet implemented 
in OpenBIOS. It wouldn't be too difficult to add it though.

>> could not find debugger-vocabulary-hook>threads:interpret: exception
>> -13 caught
>> (Can't load tod module) EXIT
>
> That looks like Solaris is trying to panic, and something had trashed
> the forth vocabulary. Debugger-vocabulary-hook is a defer word in
> openboot which is invoked on enter-forth, I suspect the >threads is from
> Solaris' forthdebug module.

Again I think the fault here is that the 
debugger-vocabulary-hook>threads defer doesn't exist in OpenBIOS at the 
moment. But also the RTC hardware isn't currently mapped correctly in 
QEMU - it's currently mapped as ioport rather than MMIO IIRC. Artyom had 
some patches to fix this but I never managed to apply them (and the 
corresponding QEMU changes).


ATB,

Mark.