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 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.