[Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Nardmann, Heiko]

Hi,

how far is support for SPARC Solaris as a guest operating system inside qemu? 
I have read something about PROLL but did not understand what it is for or or 
how to use it. Can anyone shed some light onto it?

-- 
Heiko Nardmann

Re: [Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Martin Bochnig]

Nardmann, Heiko wrote:

>how far is support for SPARC Solaris as a guest operating system inside qemu? 
>I have read something about PROLL but did not understand what it is for or or 
>how to use it. Can anyone shed some light onto it?
>  
>

A pity that you made me angry a while ago.

Otherwise I could tell you some IF's and WHY's.
As we're talking about guest code here, this is clearly "Blue Swirl"s
field, why don't you ask him directly?!

>PROLL but did not understand what it is for or or 
>how to use it. Can anyone shed some light onto it?
>  
>

And you are being paid by secunet?
How did you manage to gratuate in Technical CS??




I suggest you throw a quick look into the proll code.
Just as the OpenBoot Firmware on a real SPARC machine needs to "know"
the appropriate FCodes in order to be able to boot off some device, it
is with proll.
Besides that there may be lots of other tiny details who may prevent a
successful boot (location of bootblk).
I tried booting both Solaris 1.1.1 (SunOS 4.x) and several Solaris2.x
boot cd's w/o success.
One may be get more info when running qemu-system-sparc in "-nographic"
mode. I dod those tests on a Solaris11_x86 host.
You should start by reading and using BlueSwirl's latest proll updates -
posted to this ML on August 15th.


Martin Bochnig

Re: [Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Martin Bochnig]

Nardmann, Heiko wrote:

>how far is support for SPARC Solaris as a guest operating system inside qemu? 
>  
>

Latest public PROLL stuff has still the following problems:

>>From: "Blue Swirl" <blueswir1@hotmail.com>
>>To: renau@soe.ucsc.edu
>>Bcc: 
>>Date: Mon, 15 Aug 2005 17:42:56 +0200
>>
>>
>>Here's a translation: Boot sector "bootblk" gets loaded. It reads 8k from 
>>disk sd(0,2,0) (without partition code, mmh) at offset 8k. The contents is 
>>not what is expected, so it prints "bootblk: not a UFS file system.". After 
>>a couple of tries it gives up, prints "bootblk: can't find the boot 
>>program." and halts.
>>
>>Looks like a problem with obp_devopen. I'll make a new Proll image soon.
>>

>I have read something about PROLL but did not understand what it is for or or 
>how to use it. Can anyone shed some light onto it?
>  
>

It is the emulated system's main firmware.
x86 target for example uses a "BIOS".
The SPARC target needs "PROLL". Physical SPARC's use OpenBootProm.
The PPC target needs "Open Hack'Ware". Physical PPC's use either 
conventional "PREP" firmware, "OpenFirmware" CHRP or even 
"VirtualOpenFirmware" loaded through floppy.

Some time ago you mentioned that you are actually using real SPARC machines.
Shouldn't you be well aware of, what OBP is?

See http://people.redhat.com/zaitcev/linux/ :


    JavaStation and PROLL

My Krups

JavaStations come with two versions of PROM, 2.30 and 3.11. Linux works 
with 2.30 out of the box. In 3.11 Sun changed virtual memory layout and 
discarded an improtant interface (romvec). Thus 3.11 is not compatible 
with Linux.

My solution for the PROM 3.11 problem is *Proll*. Proll is a PROM 
replacement which takes over the machine instead of original PROM and 
presents a 2.x interface to Linux kernel. Documentation is not available 
yet but the code is easy to read as I hope. Current of Proll is *ID18*, 
which supports all SPARC based JavaStations. Download it from the 
following list.

    * proll_18.tar.gz
      <http://people.redhat.com/zaitcev/linux/proll_18.tar.gz>: Latest
      source code.
    * proll.version.h
      <http://people.redhat.com/zaitcev/linux/proll.version.h>: Change log.
    * proll.mrcoffee.ID18
      <http://people.redhat.com/zaitcev/linux/proll.mrcoffee.ID18>:
      Binary for JavaStation-1.
    * proll.krups.ID18
      <http://people.redhat.com/zaitcev/linux/proll.krups.ID18>: Binary
      for JavaStation-NC, good for network bootstrapping and for flash.
    * proll.krups-ser.ID18
      <http://people.redhat.com/zaitcev/linux/proll.krups-ser.ID18>:
      Binary for JavaStation-NC, same as above but with serial console.
    * proll.espresso.ID18
      <http://people.redhat.com/zaitcev/linux/proll.espresso.ID18>:
      Binary for JavaStation-E, now the same joint codebase as Krups.
    * proll.espresso-ser.ID18
      <http://people.redhat.com/zaitcev/linux/proll.espresso-ser.ID18>:
      Binary for JavaStation-E, same as above but with serial console.

I am not good at documenting stuff, but Robb Dubinski wrote a nice 
HOWTO, located at http://www.tldp.org/HOWTO/JavaStation-HOWTO/index.html.

Jim Mintha has filesystem images at http://www.ultralinux.org/js. Those 
are snapshots of a live system originally based on Red Hat 5.2.

On JavaStation-E a hardware fix 
<http://people.redhat.com/zaitcev/notes/espresso_ide.txt> is needed to 
get IDE interrupts.

[Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Blue Swirl]

Hi,

Short answer: does not work yet.

Long answer: based on the recent tests, I'd say the problem is more in the 
Openprom implementation rather than Sparc v8 CPU or hardware emulation. It's 
much harder to know what are the problems when working with closed source.

If you want to help, I'd suggest that trying to get Linux 2.4 series or some 
BSDs boot would benefit also Solaris. Proll openprom.c is less than 1000 
lines long and it's no rocket science.

If bugs in V9 emulation were fixed, there could be some chances of booting 
recent Sparc64 kernels. Also a working prom with real OpenFirmware support 
is needed and that does not exist yet.

More testing is always helpful.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/

Re: [Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Martin Bochnig]

Hi,


> If bugs in V9 emulation were fixed, there could be some chances of 
> booting recent Sparc64 kernels. Also a working prom with real 
> OpenFirmware support is needed and that does not exist yet.
>

why isn't it possible to use some Sun-provided flash PROM-Update binary 
for SS5 or so?

 > It's much harder to know what are the problems when working with 
closed source.
Ok, OBP sources are closed, but isn't OpenSolaris.org of any help?
(I know, no support for any old 32bit platforms anymore, however.)

Re: [Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Blue Swirl]

>why isn't it possible to use some Sun-provided flash PROM-Update binary for 
>SS5 or so?

Now that would be interesting.  Running it could reveal some bugs in Qemu's 
HW implementation and especially where we have made some bogus shortcuts.  
For example, the boot sequence is not what a real Prom expects, execution 
starts from 0xffd00000 instead of zero (reset vector).  I guess in the real 
HW, after reset the prom occupies all of the address space, and one of the 
first things it does is to enable RAM.  Or prom lives near zero forever and 
RAM banks are higher.

Other issues: NVRAM contents are Qemu-specific.  Undocumented or secret I/O 
registers are not implemented. Maybe speed differences, bugs, unimplemented 
stuff.

>Ok, OBP sources are closed, but isn't OpenSolaris.org of any help?
>(I know, no support for any old 32bit platforms anymore, however.)

Probably not for exactly that reason.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: [Qemu-devel] Q: SPARC Solaris as guest operating system with qemu?

[Martin Bochnig]

Blue Swirl wrote:

>> why isn't it possible to use some Sun-provided flash PROM-Update 
>> binary for SS5 or so?
>
>
> Now that would be interesting.  Running it could reveal some bugs in 
> Qemu's HW implementation and especially where we have made some bogus 
> shortcuts.  For example, the boot sequence is not what a real Prom 
> expects, execution starts from 0xffd00000 instead of zero (reset 
> vector).  I guess in the real HW, after reset the prom occupies all of 
> the address space, and one of the first things it does is to enable 
> RAM.  Or prom lives near zero forever and RAM banks are higher.



To anyone who didn't already find it by himself:

http://www.sunshack.org/data/bootroms.html

(includes *SS 10* *sun-4m* *2.25* *Final* version released by Sun not 
EOL'd yet adds *>= 150 Mhz* Hypersparc support
Contributed by brian@tash.net )
<mailto:brian@tash.net>