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: Peter Bartoli
Subject: Re: [Qemu-devel] [Bug 1262081] Re: qemu-system-sparc in qemu 1.7.0 fails to boot with Sun ROM
Date: Tue, 24 Dec 2013 12:40:18 -0800

On Dec 24, 2013, at 6:22 AM, 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?

Sorry, yes ... to be able to start X on demand now and again would be awesome.

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

Standing by and looking forward to it!

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

Makes sense; thanks for clarifying!

-peter


reply via email to

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