qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1262081] Re: qemu-system-sparc in qemu 1.7.0 fails


From: Artyom Tarasenko
Subject: Re: [Qemu-devel] [Bug 1262081] Re: qemu-system-sparc in qemu 1.7.0 fails to boot with Sun ROM
Date: Sat, 28 Dec 2013 11:00:13 +0100

On Tue, Dec 24, 2013 at 3:22 PM, Mark Cave-Ayland
<address@hidden> wrote:
> On 23/12/13 21:00, Peter Bartoli wrote:
>
>>> I currently have patches for a CG3 framebuffer pending that will enable
>>> you to boot Solaris into graphics mode, which I hope will be applied
>>> soon.
>>
>>
>> That is AWESOME news.  Really, I'm hoping to just have a text-based
>> console like on my SS5 with the old familiar Sun logo and to start
>
>
> ..X?
>
>
>>> Also Artyom's blog is quite out of date with respect to OpenBIOS -
>>> OpenBIOS has been able to boot my test Solaris 8 image for over 2 years
>>> now so you may find that you can get by without the proprietary Sun ROM
>>> (and avoid having to manually type a boot command into OBP every time
>>> you restart). Unfortunately the OpenBIOS binaries for 1.7 also have a
>>> bug that breaks booting from hard disks (CDROMs are fine), but the
>>> updated binaries should be merged into git in time for the next 1.7.x
>>> release.
>>
>>
>> Again, great news.  I'm running Solaris 2.5.1 ... any clue if OpenBIOS
>> might work for me?
>
>
> No idea - I don't have many Solaris images for testing at all, so just try
> it and see. Although you need to wait for the fixed binaries to hit the QEMU
> 1.7/master git repo to fix another outstanding SPARC boot bug.
>
>
>> If I may, do you know why qemu-system-sparc w/ OBP ignores the following
>> prom-env options?
>>
>>     -prom-env 'boot-device=disk1' -prom-env 'auto-boot?=true'
>
>
> That's because the boot parameters are passed to the PROM via a QEMU custom
> FW interface (which OBP has no knowledge of) rather than by having QEMU
> emulate the NVRAM in exactly the same way as real hardware.

Actually QEMU does set variables in NVRAM (hw/sparc/sun4m.c:151), and
afaik uses the layout of open-sourced OBP. The problem is that earlier
versions of OBP seemed to have a different layout, or maybe just a
magic constant is missing somewhere.

Artyom

-- 
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]