As OFMEM memory ranges don't provide an explicit upper limit, we must manually
check that CIF claim calls lie within a valid maxmimum range if attempting to
allocate a specific address. Since the claim method provides a 1:1 mapping between
physical and virtual addresses, the valid maximum address is therefore equivalent
to the machine RAM size.
This fixes booting yaboot 1.3.17 which implements a top-down search using claim to
find the next free memory region to locate its heap. Without this fix we blindly
accept a claim for physical addresses far above the available RAM which fails
silently when we try to use the mapping later.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
libopenbios/ofmem_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libopenbios/ofmem_common.c b/libopenbios/ofmem_common.c
index 217bd9b..fc19d27 100644
--- a/libopenbios/ofmem_common.c
+++ b/libopenbios/ofmem_common.c
@@ -623,7 +623,7 @@ ucell ofmem_claim( ucell addr, ucell size, ucell align )
virt = phys = 0;
if( !align ) {
if( is_free(addr, size, ofmem->virt_range) &&
- is_free(addr, size, ofmem->phys_range) ) {
+ is_free(addr, size, ofmem->phys_range) && addr < get_ram_size() ) {
ofmem_claim_phys_( addr, size, 0, 0, 0, 0 );
ofmem_claim_virt_( addr, size, 0, 0, 0, 0 );
virt = phys = addr;
--
2.11.0
On 13/02/18 13:15, Weidemann, Maik (M-SO) wrote:
Hi Maik,
> Hello,
>
> I try do emulate / virtualize a very old Sun Workstation Ultra 2 with a SunOs 5.8 with KVM/qemu.
> As host system I use a Ubuntu 17.10 with the qemu packages from http://ppa.launchpad.net/jacob/virtualisation/ubuntu.
> The qemu Version is:
> QEMU emulator version 2.11.0(Debian 1:2.11+dfsg-1ubuntu1~ppa0)
>
> I tried to start a virtual machine with the default bios (Version: 1.1.git20161120-2). But I get this error message:
> # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw
> OpenBIOS for Sparc64
> set_property: NULL phandle
> set_property: NULL phandle
> Unhandled Exception 0x0000000000000030
> PC = 0x00000000ffd0f6b8 NPC = 0x00000000ffd0f6bc
> Stopping execution
Yes, unfortunately that combination of QEMU/OpenBIOS won't work because
at the moment there is no way to pass the device tree from QEMU to
OpenBIOS and so the two must generally be kept in sync. Hopefully this
requirement will be something that can be relaxed in time.
> I see that was some new commits at the git repository, so I clone the repo an build a new openbios-file (https://www.openbios.org/OpenBIOS#Building_OpenBIOS) an start the vm with this new bios. But I get also a error message:
> # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios openbios-builtin.elf
> Unhandled Exception 0x0000000000000030
> PC = 0x00000000ffd21368 NPC = 0x00000000ffd2136c
> Stopping execution
Something definitely looks wrong there - for 2.11 have you tried
grabbing the relevant OpenBIOS binary direct from git? It's available as
a direct download from
https://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/openbios-sparc64;h=a4a3b8….
> Is it even possible to emulate a Sun Sparc Ultra 2 with a SunOs 5.8 (64bit)?
> SunOS satnw014 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-2
The default sun4u model emulates an Ultra 5, so assuming your image
contains enough drivers then in theory you should be able to at least
boot into the kernel and get somewhere close to userspace.
To the best of my knowledge the main outstanding feature missing from
the SPARC64 emulation preventing it from booting SunOS is the MMU IE bit
which is required to program PCI devices. I suspect this will still be
the case for SunOS 5.8.
There has been a lot of work done over the past couple of releases to
fix up all the PCI bridge issues so I would hope that getting
qemu-system-sparc64 to boot Solaris 64-bit is now within reach, so watch
this space :)
ATB,
Mark.
Hello,
I try do emulate / virtualize a very old Sun Workstation Ultra 2 with a SunOs 5.8 with KVM/qemu.
As host system I use a Ubuntu 17.10 with the qemu packages from http://ppa.launchpad.net/jacob/virtualisation/ubuntu.
The qemu Version is:
QEMU emulator version 2.11.0(Debian 1:2.11+dfsg-1ubuntu1~ppa0)
I tried to start a virtual machine with the default bios (Version: 1.1.git20161120-2). But I get this error message:
# qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw
OpenBIOS for Sparc64
set_property: NULL phandle
set_property: NULL phandle
Unhandled Exception 0x0000000000000030
PC = 0x00000000ffd0f6b8 NPC = 0x00000000ffd0f6bc
Stopping execution
I see that was some new commits at the git repository, so I clone the repo an build a new openbios-file (https://www.openbios.org/OpenBIOS#Building_OpenBIOS) an start the vm with this new bios. But I get also a error message:
# qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios openbios-builtin.elf
Unhandled Exception 0x0000000000000030
PC = 0x00000000ffd21368 NPC = 0x00000000ffd2136c
Stopping execution
Is it even possible to emulate a Sun Sparc Ultra 2 with a SunOs 5.8 (64bit)?
SunOS satnw014 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-2
Best regards
Maik
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/ <https://opensource.apple.com/tarballs/BootX/>
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
There are few other useful debugging tech- niques. Setting "auto-boot?" to false will cause the system to enter the OpenFirmware User In- terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause BootX to drop back into the OpenFirmware User Interface. This can be used as a break point. The "dumpl" word will dump some memory, by en- tering the address, then the length, then "dumpl". By calling printf in BootX immediately before En- ter(), the address can be easily determined, and the variable can then be examined and altered from OpenFirmware. Finally typing the "go" command will resume BootX’s execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends some info to the screen, seemingly via open firware, while displaying the “Apple Logo” boot graphic. The info show some of the boot process and what stage it’s loading” loading mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I might be able to do that?