Bob Breuer implemented the cgfourteen framebuffer for SS-20. This is the great news for those who wait for NeXTStep/sparc emulation under qemu!
With one hack that I used last year for booting Solaris 2.5.1, it's possible to boot the early Solaris versions (2.3-2.5.1) with a color graphics. There is still a problem with y2k10 bug with Solaris 2.4-2.5.1 under qemu.
sparc-softmmu/qemu-system-sparc -M SS-20 -bios /path/to/ss20_v2.22.3.bin -hdb /path/to/Solaris23.iso -m 64 -cpu "TI SuperSparc 50"
sparc-softmmu/qemu-system-sparc -M SS-20 -bios /path/to/ss20_v2.22.3.bin -hdb /path/to/Solaris251.iso -m 64 -cpu "Ross RT620" -startdate "2009-09-05"
Right now it sometimes complains about
zs3: ring buffer overflow
when you do something with the mouse. But this issue is not SX/cg14 related.
Also some OBP versions are not happy with the DBRI emulation. Under these versions instead of booting directly, detection of the DBRI has to be switched off:
ok setenv sbus-probe-list f
ok reset
The bad boot screen looks like this:
The problem here is the sbus slot e. It should be either "Nothing there" or some devices. Empty string is an error.
The good boot screen looks like this:
It's even possible to get rid of the "Wrong packet length" error message, via disabling the network boot on debug. But the message is harmless.
With one hack that I used last year for booting Solaris 2.5.1, it's possible to boot the early Solaris versions (2.3-2.5.1) with a color graphics. There is still a problem with y2k10 bug with Solaris 2.4-2.5.1 under qemu.
sparc-softmmu/qemu-system-sparc -M SS-20 -bios /path/to/ss20_v2.22.3.bin -hdb /path/to/Solaris23.iso -m 64 -cpu "TI SuperSparc 50"
sparc-softmmu/qemu-system-sparc -M SS-20 -bios /path/to/ss20_v2.22.3.bin -hdb /path/to/Solaris251.iso -m 64 -cpu "Ross RT620" -startdate "2009-09-05"
Right now it sometimes complains about
zs3: ring buffer overflow
when you do something with the mouse. But this issue is not SX/cg14 related.
Also some OBP versions are not happy with the DBRI emulation. Under these versions instead of booting directly, detection of the DBRI has to be switched off:
ok setenv sbus-probe-list f
ok reset
The bad boot screen looks like this:
Setting NVRAM parameters to default values. Setting diag-switch? NVRAM parameter to true Probing /obio at 2,0 cgfourteen Probing /iommu@f,e0000000/sbus@f,e0001000 at f,0 espdma esp sd st ledma le SUNW,bpp Probing /iommu@f,e0000000/sbus@f,e0001000 at e,0 Probing /iommu@f,e0000000/sbus@f,e0001000 at 0,0 Nothing there Probing /iommu@f,e0000000/sbus@f,e0001000 at 1,0 Nothing there Probing /iommu@f,e0000000/sbus@f,e0001000 at 2,0 Nothing there Probing /iommu@f,e0000000/sbus@f,e0001000 at 3,0 Nothing there SPARCstation 20 (1 X 390Z50) ROM Rev. 2.25R hyperSPARC, 64 MB memory installed, Serial #0. Ethernet address 52:54:0:12:34:56, Host ID: 72000000. Power-On SelfTest FAILED ... Replace MBUS0 Module ... |
The problem here is the sbus slot e. It should be either "Nothing there" or some devices. Empty string is an error.
The good boot screen looks like this:
Probing Memory Bank #7 8 Megabytes of VRAM Probing /obio at 2,0 cgfourteen Probing /iommu@f,e0000000/sbus@f,e0001000 at f,0 espdma esp sd st ledma le SUNW,bpp SPARCstation 20 (1 X 390Z50) ROM Rev. 2.22, 64 MB memory installed, Serial #0. Ethernet address 52:54:0:12:34:56, Host ID: 72000000. Boot device: /iommu/sbus/ledma@f,400010/le@f,c00000 File and args: Internal loopback test -- Wrong packet length; expected 36, observed 64 Can't open boot device Type help for more information ok |
It's even possible to get rid of the "Wrong packet length" error message, via disabling the network boot on debug. But the message is harmless.
12 comments:
Wow..!
I'm going to have to download the latest GIT sources and build this.... !!!!!!!!!!
Alas, it's not in git yet. You'll have to apply the patch manually.
And alas again, NeXTStep can't be boot yet. Maybe you'll have more luck than me though. I haven't try to debug yet.
yeah it doesn't fully boot... then again for me, all the solaris stuff doesn't fully boot on the SS-20 either.. very weird.
Are you sure you are using the latest git? My fix for SS-20 boot was included at Saturday night (CET). What error do you get? I know it's hard to type, so a screenshot would be enough. I need to see the first error though, so if the things resets afterwards the timing can be tricky.
can we have screenshots?
What screenshots? Are you asking me or Neozeed?
Let me get it from GIT again.... it didn't crash it just hung....
Oh. I forgot to mention something, sorry. The DBRI emulartion in the SX patch is incomplete. Before booting you have to
ok setenv sbus-probe-list f
ok reset
That is very nice - congrats!
just one question: has anybody managed to get openwindows to run with this?
[in my case I could get solaris 2.4 to boot, but the display freezes just after
the "Starting Openwindows" message appears on the console. The machine does not seem to be locked, though - actually, if I type any key at all I see on the debug output the kind of ram access that I would expect for a scroll: that is quite a lot of read/write cycles for enter, and way less for any other key]
No, I haven't managed it either. Actually I even haven't managed to make Debian use cg14. But Bob says there is a new version which is at least Linux-compatible. As soon as he publishes it, we can test again.
Does this patch supporting Booting Solaris 7 on the OpenBIOS for SPARC32 yet? I have someone interested in me doing a QEMU virtual machine that can run the CLI version of Solaris 7, not single user mode, but server mode with no GUI.
I want to help out the QEMU community and test out to see if different versions of Solaris will boot under QEMU using SPARC emulation.
It's working pretty good. There are also patches from Mark which implement a cg3 frame buffer.
But actually for a CLI version you don't need any frame buffers at all.
Also Solaris 7 might even work with OpenBIOS - which would make it running easier than ever.
Post a Comment