On 28/12/13 00:54, Tarl Neustaedter wrote:
On 2013-Dec-27, 19:08 , Nick Couchman wrote:
[root@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
CPUs: 1 x SUNW,UltraSPARC-IIi
Welcome to OpenBIOS v1.1 built on Dec 27 2013 23:00
Type 'help' for detailed information
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.
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
5.10 Version Generic_142909-17 64-bit
Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights
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
(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).