SX framebuffer emulation

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

1993 reached

The time machine is working! Well, I had to fix another bug to do it. This time in DMA again. The Solaris 2.3/sparc can be installed under qemu!

Submitted the patch upstream. After it gets accepted, it should be possible to use Solaris 2.5.1- instructions from the how-to to install Solaris 2.3. I wonder if the patch also improves the situation with NetBSD 5.x stability. Feel free to report.

Trying to reach 1993

Trying to boot yet older Solaris/SunOS version: Solaris 2.3. According to the Wikipedia, it's the first one which supported SPARCStation-5. You may wanna ask "what is about SunOS 4.1.4 (Solaris 1.1.2), it can be booted, and it must be the older?". No, it's not. Looks like Solaris 2.x and SunOS 4.x were developed independently: 1.1.2 was released in November 1994, and 2.3 was released in November 1993. Is a bit misleading. But explains why 2.3 has problems with the esp scsi controller while 1.1.2 doesn't. And the both systems are so old that the kadb debugger can't set deferred breakpoints. Anyway, the current status of Solaris 2.3:

ok boot disk1:d -vs
Boot device: /iommu/sbus/espdma@5,8400000/esp@5,8800000/sd@1,0:d  File and args: -vs
Size: 719688+166144+108728 Bytes
SunOS Release 5.3 Version Generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1993, Sun Microsystems, Inc.
vac: enabled in write through mode
cpu0: FMI,MB86907 (mid 0 impl 0x0 ver 0x4 clock 1075 MHz)
mem = 65536K (0x4000000)
avail mem = 58142720
Ethernet address = 52:54:0:12:34:56
root nexus = SUNW,SPARCstation-5
iommu0 at root: obio 0x10000000
sbus0 at iommu0: obio 0x10001000
espdma0 at sbus0: SBus slot 5 0x8400000
esp0 at espdma0: SBus slot 5 0x8800000 sparc ipl 4
        polled command timeout
esp:            State=CLEARING Last State=CLEARING
esp:            Latched stat=0x97 intr=0x8 fifo 0x0
esp:            last msg out: NO-OP; last msg in: COMMAND COMPLETE
esp:            DMA csr=0xa4240030
esp:            addr=fc00300a dmacnt=8000 last=fc003008 last_cnt=30
esp:            Cmd dump for Target 1 Lun 0:
esp:            cdblen=6, cdb=[ 0x12 0x0 0x0 0x0 0x30 0x0 ]; Status=0x0
esp:            pkt_state=0x1f pkt_flags=0xb pkt_statistics=0x0
esp:            cmd_flags=0x1422 cmd_timeout=60

sent the SunOS 4.1.4 patch upstream

Sent the SunOS 4.1.4 patch upstream. If it gets accepted, it should be possible to get up to "The Wh" using Solaris 2.5.1- instructions from the how-to.

Found another bug in qemu which I can't fix. Hoped that others can do it, so posted it to the mailing list, but got no responses. Actually the bug may be related to the SunOS fix I just sent: maybe SunOS tries to access a non-connected address not because it's buggy, but because qemu translates the address wrong.

If no-one from the mailing list answers I'll have to dig it further.

SunOS 4.1.4 again

Got back to SunOS 4.1.4 (aka Solaris 1.1.2). Thanks to Carey Sсhug, I had a chance to test in on a hard drive image. While serial port driver still has problems, the system is alive in the background and using qemu port forwarding  I was able to login via telnet:

SunOS UNIX (sol112)

login: root
SunOS Release 4.1.4 (GENERIC) #2: Fri Oct 14 11:09:47 PDT 1994
sol112#

FPU bugs

Found more bugs. This time in FPU. One was very promptly fixed by Blue Swirl (the mysterious qemu-sparc maintainer). Another one is more tricky. qemu goes astray and doesn't stop at breakpoint, so it's gonna be hard to find out what exactly is going on.

sent another qemu patch upstream

The -m 256 option should be not necessary anymore. The minimal RAM amount for the emulated SPARCStation-5 is now 32 MiB. So OBP should understand now the memory sizes of 32, 64, 96, 128, 160,192, 224 and 256 MiB. When not specified, the default value of 128 MiB is taken.

The support of RAM size <256MiB is important for SunOS 4.1.4 (aka Solaris 1.1.2) because its installer crashes under qemu when started with "-m 256" option.

Will update the how-to shortly.

a couple of bugs in OpenBIOS

Found two bugs in OpenBIOS. I think I fixed one of them, but it can be checked only when the other one gets fixed. The other one is pretty deep in the Forth engine, don't want to mess with it. Once it will be fixed I'll get back to OpenBIOS.

The ultimate way of starting qemu under Windows

Being on vacation I gave a shot on building and launching qemu under Windows. Of course I was stumbled on getting the message

chardev: backend "stdio" not found
qemu: could not open serial device 'mon:stdio': No such file or directory

when running with  -nographic option. The option is necessary for launching qemu with SPARCstation-5's OBP, as it doesn't support qemu's TCX graphic card.

I googled, but found only that many people have stumbled over this problem before with no luck of solving it. And then I was so desperate that I read the qemu manual page. And you know what? The solution is described there! Instead of using console for standard I/O, it's possible to redirect it to a port, and telnet there:

sparc-softmmu/qemu-system-sparc -nographic  -serial mon:telnet::4444,server,nowait -bios ../sparc/ss5.bin -hdd ../sparc/solaris-disk

And then just telnet to localhost:4444.
Now I have Solaris/sparc running on my Windows laptop. ;-)

Moreover I think the option -serial mon:telnet::4444,server,nowait is pretty useful for Unix hosts too. When stated with it you have ability to get into qemu console by pressing Ctrl-A c,  and hence eject/insert virtual CD-ROMs, plugging unplugging disks and so on.

Update:  the above method works if qemu is  compiled under cygwin. With plain msys/MinGW, it has to be started with
-monitor file:bob.txt -bios ..\ss5.bin -m 256 -M SS-5 -serial mon:telnet:127.0.0.1:4444,server,nowait
options. Thanks, Neozeed.

saving energy while working with qemu

As you know qemu always tends to use 100% of cpu. Qemu console is not available with -nographic option, so saving vm is not possible.

The good news is UNIX (and of course Linux) has a standard mechanism for freezing and unfreezing processes:

$ kill -STOP
(from another shell)

will stop  the process. It will still reside in the  memory (RAM or swap).
To continue process, from the shell where it was started, type

$ fg

There will be no echo, but the command will execute.
If there is an echo, the tty is probably messed up. It can be restored again with

$ stty -brkint -icrnl ixoff -imaxbel iutf8 -isig -icanon -iexten -echo

going further with OpenBIOS

No, I was wrong about the 80 characters limit. Found the correct place where it crashed, but the reasoning was wrong. Something was corrupting the stack, so success after patching ufsboot was incidental.

back to OpenBIOS

Since SS-5 OBP works pretty well, I think it's a good time to get back to OpenBIOS: it's free (as in speech), and can support more than 256 MiBs RAM.  Theoretically Ross's SPARCStation-20 OBP supports up to 2 GiB RAM, but frankly speaking I think having a more or less hardware-precise SS-5 is enough.

The very first experience has shown that bootblk loads ufsboot successfully, but then it hangs. I'm feeling myself getting back few months in the past. Back then I was debugging pretty much similar routines in the bootblk, but the main job was done by Mitch Bradley. I sort of hoped I skipped the necessity to learn the gory details of the UFS filesystem. Ok, back to school. ;-) . My very first long shot:

$ strings sun4m/ufsboot
...
 ['] find-device catch if 2drop true else current-device device-end then swap l!
...

Trying to find out whether this sentence works I found out that OpenBIOS doesn't support input lines longer than 80 characters! It would be interesting to find out whether it's just a console limitation, or the API too. If it's an API limitation it may be exactly the bug that prevents Solaris from booting.

Another observing:

0 > " /openprom" ['] find-device  ok
3 > . . . -29a594 9 -264cec  ok

• "ok" is not a prompt, but a response. I don't think it's important.
• It operates with signed hexadecimals. This looks pretty weird. Here comes the same question again: is this just a console representation, or another API bug.

Gonna check it with OpenBIOS developers.

SSH ciphers on emulated sparcs

Running X-applications on an emulated sparc over two ssh tunnels seemed quite slow, so I experimented a bit with different ciphers. Of course when you are connected from localhost to the very same localhost, a risk that a third party can sniff you connection is pretty low. So, obviously the most performing cipher would have been "no cipher". Unfortunately the ssh  bundled with Solaris 9 doesn't have this feature. I found an article where a few different ciphers where compared and wondered whether an emulated sparc cpu is closer to a real sparc or to the host cpu (in my case x86-64). It seems to be that the emulated system is acting rather like a host: arcfour is just a little bit more performant than blowfish:

cipher	throughput
3des	1.1MiB/s
aes128-cbc	1.89 MiB/s
blowfish	2.15MiB/s
arcfour	2.63MiB/s

Theoretical limit (dd if=/dev/zero of=junk bs=1024k count=100): 20.8MiB/s.
Yes, 2.63MiB/s is pretty lame. But hey, on the real hardware you'd get even less.

For now I'm adding

Host 10.0.2.*
  Ciphers arcfour

to my ~/.ssh/config

Tunneling qemu guest back and forth

Using the virtual guests sooner or later you need to have a way to transfer data between guest and host. If you just need to transfer files, it's relatively easy. There is a good document describing many possible ways of doing it in the qemu Puppy project.

But sometimes you want to pretend your virtual guest is a real machine: you want to log in into it, have multiple sessions, start GUI programs and so on. The easiest way to achieve it is use an ssh tunnel. This method is actually neither Solaris, nor qemu specific: you can do the same for exposing machines from your intranet to the outer world. How it works:

You start a ssh daemon (sshd) on your guest and on your host (or any other machine which will work as a representative for the guest). Then on your guest you say:

ssh -R 10022:localhost:22 hostuser@10.0.2.2

This opens a tunnel. If someone has an access to the host's port 10022 she can also login to your guest. So beware that your guest is exposed to the outer world after this point.

Now you can log in into your guest from the host using
ssh -X -p10022 guestuser@localhost
or from anywhere where your host is reachable using
ssh -X -p10022 guestuser@

The -X option is used to turn on X11 forwarding. From the sessions started like this you can run GUI applications.

It's also possible to transfer data via sftp:
sftp -o "port=10022" guestuser@localhost

Testing needed

While I'm busy with rewriting my Solaris 7 hack (which is also needed for Solaris 8 and 9), I'm looking for some help: I'd like to expore the y2k10 problem under qemu. Carey couldn't reproduce the problem on a real SPARCStation, so it may be a qemu nvram bug.
Currently needed /etc/system hack seems to be also nvram-related.

So, what I'm asking for:
boot Solaris 2.0 - 2.5.1 image with qemu option -rtc base=<dateTtime> where dateTtime is a string like  "2006-06-22T16:01:21". Try different dates and times. I.e:

./qemu-system-sparc -M SS-5 -m 256 -rtc base=2009-12-22T16:01:21
 -L  -bios ss5.bin -nographic  -hdb Solaris2.5.1.iso

...

ok boot disk1:d -vs 

Currently it looks like the system doesn't come up if the day of month is >20. 

At least for years 2009 and 2010.

The question is: do year, month, hours and seconds also play a role?

I.e. is it possible to boot when day is 22, with any year?
Is it not possible to boot when day is 22 and year is 2010 with any
month, hour and minutes settings?

Waiting for your feedback (you can write in English, German or Russian).

sneak preview screenshots

I haven't posted any images in my blog yet, so it may be the time to fix it:

That's how the installation of Solaris 2.5.1 looks like

Solaris 2.6 and Solaris 7 are not very different. Up to 2.6 you can already make such screenshots yourself using the vanilla qemu (git/master). Sneak preview starts here:

Solaris 7 installation under qemu

For some reason, Solaris 9 looks not that nice:

For all the installations I used a 'PC console' terminal type. Maybe it's not recommended anymore? That's how it looked at the end:

Solaris 9 installation under qemu

And yes, instead of pressing Return to reboot the qemu machine, I still had to do the following:

!
echo set scsi_options=0x58 >> /a/etc/system
halt

So, I've achieved the goal I set 7 moths ago. Solaris 9/SPARC will work under qemu.

who is here?

How many people are reading my blog? I see ~ 30 page impressions daily, but I don't know how many of them are unique. Also it's possible that people read only the how-to, and not the rest. How many of you are actually reading this? Just leave a comment. If you do it anonymously, then please sign your message somehow, so  I can distinguish you (if there is more than one of  you :). It would be also interesting to know why are you reading this.

I see that this week there were suddenly two banner clicks! Who has clicked? I'd like to thank this people. Was there an interesting banner?

The question to the people who didn't click: are you annoyed by the ads here? I think about switching the banners off: after all 2 clicks within half a year is not a top business solution. Actually I'm also considering switching off this blog. Doesn't seem to be the right way for getting rich and famous.

Things I did for qemu/sparc weren't a rocket science. When I started a half year ago I didn't know neither the sparc assembly language, nor SPARCstation architecture, nor forth, nor qemu, nor git. Which means that I fixed all of this bugs just because I cared to fix them. Any other person who'd care would have fixed them too. Nobody else did, so probably no one actually needs emulating Solaris/sparc? Does any of you miss emulation of some other architecture/OS?

another week, another qemu bug again

Fixed one more CPU bug. Really surprised that it didn't affect Linux and Solaris versions prior 2.6. I'd expect that lots of multi-threaded code relying on mutex should have been affected...

Lucky fix

It turned out that my last dma fixes had a nice side-effect: Solaris 8 and 9 don't complain about spurious timer interrupts anymore. I'm really surprised they don't because I'm absolutely sure there is at least one bug in the system timer. Funny enough fixing the timer bug without dma, covered 98% of spurious interrupt complains, whereas fixing dma removes 100% of them. After all it's possible that both documents describing the timer in two mutual exclusive ways describe it correctly. There are just multiple variants of the timer chip.

With the Solaris 7 hack, Solaris 8 & 9 can boot in a single user mode, regardless the timer fix. Will update the status in the how-to shortly.

booting from a hdd image

For some reason during a HDD boot, SCSI disk driver (sd) is loaded before SCSI controller's (esp) . So the system can find no disks and exits causing kernel panic:

Cannot assemble drivers for root /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0:a
Cannot mount root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0:a fstype ufs
panic: vfs_mountroot: cannot mount root

A workaround: add the following line to /etc/system in the HDD image:
set scsi_options=0x58

Updated the Solaris/sparc under qemu how-to.

yet another dma bug

Fixed another bug in qemu sparc32 dma. This one seems to be only relevant for Linux guests though.

another week, another qemu bug

There are very few qemu/sparc modules out there which I haven't had to touch. Since I've started I founded/fixed bugs in: irq, esp, cpu, esp, esp, cpu, scsi-disk, cpu,  scsi-disk, fdd, tcx, mmu, slavio, mmu. Today this list is extended with (sparc32_)dma.

Fixed a bug in dma which produced spurious interrupts and incomplete reads/writes. Will submit the patch later on this week.

Spurious interrupts

Previously qemu dropped interrupts on disabling them. The real hardware doesn't do it. Which means, that lots of interrupts were dropped, including the spurious ones. But the real ones were dropped too, that's why the system timer was ticking so slow.

The question is where the spurious  IRQs are coming from: it's not only the ESP which produces them, under Solaris 8 & 9 there are lots of complains about spurious timer interrupts, and they both seem to crash due to a buffer overflow during processing of a (possibly spurious) LE interrupt.

NetBSD 1.3.3 boot doesn't crash with my wrong irq patch. The patch makes qemu drop interrupts, including the spurious ones.

All in all it looked like there is one global problem with interrupts processing. Until now. But now it looks like there is not one source of spurious interrupts, but many.

• esp doesn't seem to produce spurious interrupts under Solaris while reading.
• I've found a bug in the slavio timer which produces spurious interrupts.
• NetBSD may be crashing due to another issue: I don't have a disk which I could boot under OBP. It is possible that OpenBIOS is not compatible with the older NetBSD versions. Update: This is the reason for NetBSD crashing, Michael Kostylev confirmed it.