Round and round she goes, and where she stops nobody knows

After a while I got back to qemu. This time to the sparc64 port. It's interesting to see how the highlights of the sun4m story are repeating. With the difference that this time the way goes faster. The highlights of the last weekends:

• What? Not even a greeting message? I should give it up. hack, hack, hack
• Oh, wow, it gives a message "Button Power ON"! Too bad it hangs afterwards. hack, hack, hack
• Ha! got it up to the Forth bootstrapping, too bad I have no prompt. hack, hack, hack
• Yes! The Forth is with me, there finally is the "ok " prompt. Too bad it sees no devices. hack, hack, hack
• Woo-hoo, OBP sees a disk controller! Why doesn't it see the disks? hack, hack, hack
• Aha, there are my disks. Can I boot Solaris, please? Hrm, no. Can I boot anything? No?!? hack, hack
• Ok, now it's properly initialized. Well, properly enough to boot SILO, and yes, it's stuck at ufsboot just like the sparc32 version did.
• Ta-da! Finally I see something new:

SunOS Release 5.11 Version Natamar_0.4__b96 64-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.

• But wait, didn't I see it with OpenBIOS?!? Yes, I did. In fact all the 64 bit SPARC operating systems I tried so far go a little further with OpenBIOS.
• So, can OBP on qemu-system-sparc64 do anything the OpenBIOS can't?!? No?!? (because badly documented missing devices, probably necessary just for OBP, are badly hacked by me). I should give it up. :-)

And this is the progress so far. Hats off to the HelenOS team who managed to get their OS running under qemu. No other OS can work under qemu-system-sparc64 yet.

Does anyone have a Martux 0.2 image? It used to be available on the authors site, but seems to be gone, leaving just the check sum files. The file I'm looking for is

CD_sun4u_sparcv9__marTux_0.2__small_naked_demo_cd_bs2048b.iso.bz2 .

Sent a small patch to OpenBIOS

Now there is a few bytes of my code in the OpenBIOS project as well.
Switching perspectives is an interesting experience: while debugging qemu and seeing something what I don't understand immediately, the first thought is that some hw device is not properly emulated.
Debugging OpenBIOS I'm pretty much sure that hw emulation is fine.

Anyway, fixed one bug. Solaris still crashes on the boot,  but now it should be possible to switch off the mapping of the page 0x0.

In case you are wondering what this would be good for, there are 2 good reasons: a) being compliant to IEEE-1275 SPARC supplement, and more importantly b) ability to easy catch a null pointer dereferences.

The trivial rest of the Solaris boot exercise is left to Mark, Blue and other OpenBIOS developers. :-)

Bug in all Solaris versions after 5.7?!?

Tried to clean up some patches for submitting upstream, and it turned out that one of the hacks is needed because of a Solaris bug! I'm really astonished.
The init routine of the network card driver in Solaris 2.6 has this piece of code:

call      ddi_get_parent

ld        [%l0 + 0xc], %o0

call      ddi_get_driver_private

nop

add       %o0, 0x4, %g2

st        %g2, [%l0 + 0x720]

That's how it looks in Solaris 9:

call      ddi_get_parent

ld        [%l0 + 0x10], %o0

call      ddi_get_driver_private

nop

add       %o0, 0x10, %g2

st        %g2, [%l0 + 0x728]

Adding 0x10 to the base of dma registers, makes a pointer to a nowhere.

Yes, qemu is not precise, and doesn't emulate memory aliasing (Blue Swirl had a patch for it), but hey, Solaris works on sun4m only due to a coincidence!

So, all the Solaris versions from 5.7 to 9 can be booted in qemu by hot patching in kadb (booting kadb is already described in the how-to).

That's how I patched Solaris 9 for booting under qemu:

kadb[0]: le#leinit:b	set a deferred breakpoint
kadb[0]: :c	continue execution
...
kadb[0]: leinit+0x654?i	check that we are at the correct place
add       %o0, 0x10, %g2
kadb[0]: leinit+0x654/X
leinit+0x654:   84022010
kadb[0]: leinit+0x654/W 84022004
leinit+0x654:   0x84022010    =   0x84022004	patch
kadb[0]: leinit:d	delete the breakpoint
kadb[0]: :c	continue

Once again I can only recommend  reading the PANIC! UNIX System Crash Dump Analysis Handbook to understand the basics before patching anything.

Did java 5+ ever work on 32 bit SPARC machines?

Basically the question should sound "Did java 5_ ever work on 32 bit SPARC machines?", because for the plus part I already know the answer. Up to now it didn't.

Here goes the story:

Fixed the "Solaris Y2K10" bug

Got back to Solaris/qemu Y2K10 bug. The name turned out to be misleading because a) it's not a Solaris bug and b) it's not a Y2K10 bug.

The reason for the bug was someone mixing hexadecimal and decimal values. Gonna check if there are more such places and send the trivial fix later.

Submitted SunOS 4.1.4 & Solaris 2.2 fix upstream

Sent upstream the serial port patch. The patch allows booting SunOS 4.1.4 and Solaris 2.2.

Booting Solaris 2.2 is more tricky than SunOS 4.1.4, since it doesn't support SPARCStation-5. It has to be started in SS-20 emulation.

Will update the how-to shortly.

Going deeper into NetBSD problem

It looks like the documentation on the NCR89C100 chip (aka esp) is wrong or incomplete. Actually nothing new. Earlier I found that timer is definitely described wrong. But at least timer is described correctly in the Sun4m architecture manual, and for the scsi part the only source is the NCR document.

The subunits of the real machine are much more integrated than described. DVMA works differently compared to qemu, the expected interrupts are not triggered, and "Select with(out) attention" commands work differently too. At least in the mode NetBSD uses.

Starting to wonder why qemu is capable to boot anything at all. Looking at all this errors makes me feel like getting lost 100 meters away from the home. Or even in my own basement. Have to experiment further.

Bug in NetBSD 1.6 - 3.1 emulation

Was going to write that I couldn't imagine what did the NetBSD guys smoke during 5 years between the versions 1.6 and 3.1 inclusively. The NCR 53c9x SCSI chip (known as "esp" in SPARC and PPC machines) was not so uncommon back then. How could they introduce an instability and didn't notice it ?!?

The code from NetBSD 1.5.3:

NCRDMA_SETUP(sc, &sc->sc_cmdp, &sc->sc_cmdlen, 0, &dmasize);
//...
NCRCMD(sc, NCRCMD_SELATN | NCRCMD_DMA);
NCRDMA_GO(sc);

The code from NetBSD 1.6-3.1:

NCRCMD(sc, NCRCMD_SELATN | NCRCMD_DMA);
NCRDMA_SETUP(sc, &sc->sc_cmdp, &sc->sc_cmdlen, 0, &dmasize);
NCRDMA_GO(sc);

The code from NetBSD 4:

NCRDMA_SETUP(sc, &sc->sc_cmdp, &sc->sc_cmdlen, 0, &dmasize);
//...
NCRCMD(sc, NCRCMD_SELATN | NCRCMD_DMA);
NCRDMA_GO(sc);

See the difference? In the versions 1.6-3.1 the command is executed before the DMA is set up, so the SCSI controller may not get the command using DMA.

And then I googled for the expected bug reports and found none. Why could it work on the real hardware? Maybe some latency: if the latency of a SCSI controller was larger than a DMA controller, it might work? Maybe concurrency: if some other driver (for instance Ethernet) prepared DMA for itself, the SCSI driver could steal it? Maybe DMA didn't work for these versions at all and after the first attempt they switched to the PIO mode.

TME strikes back!

A great news for everyone who's interested in the 64-bit SPARC emulation (sun4u)!

After a nearly 3 years long pause Matt Fredette released the new version of TME - The Machine Emulator. Matt has skipped the sun4m emulation, which I think makes sense, because meanwhile qemu emulates sun4m pretty well (and fast!). Therefore the current list of the supported platforms is sun2, sun3, sun4c and sun4u. The only sun4u machine which tme can emulate is Ultra 1, so don't hold your breath for OpenSolaris support just yet.

But at least it can boot NetBSD 5. Also it uses the original OBP (not OpenBIOS) which implies that the emulation is pretty close to the hardware. It also seems to emulate cg6 graphic adapter which is much more powerful than qemu's tcx. Less powerful than Bob's cg14, but it's not yet included in the official git master anyway.

As for the OpenSolaris: it doesn't support the Ultra-1 and Ultra-2 machines. But! You can give a spin to Martux, the hacked OpenSolaris distribution which does have a support for the early Ultras.

Fixed the slavio timer bug properly

Fixed the timer bug found last week more correctly. Will submit the patch later.

Gosh, it is hot over here. Today is something like 38C (~100F) . The cpu in my head is refusing to send any patches and fix any further bugs till the temperature drops.

Fixed another bug in the slavio timer emulation

Trying to get NeXTStep/sparc to boot without any success, I got back to the old bug which seemed to be related: some versions of OBP hang at boot waiting for the timer interrupts.

Somehow I got poisoned by the motto of the qemu developers: OBP doesn't work because the initial set-up is wrong. On the real hardware no one would expect BIOS to work if the machine doesn't pass the power-on self test (POST). But then I it came to me that exactly this motto prevented other people to get OBP working under qemu-system-sparc.

So, I went on and asked Mitch, if he thought whether his creation - OBP - was buggy and relied on the [probably missing] POST initialization. Mitch said that he's pretty much sure that the OBP would do the right thing in this case, so I took another look at the qemu timer code, and fixed the bug.

The bug turned out to be unrelated to the NeXTStep boot problem. On the other hand the fix provides the alternatives to SPARCStation-5 emulation. Now it's possible to get SPARCStation-10 firmware to work, which gives 512m to the guest.

Here come some boot logs with the OBP from SPARCStation-10 and LX.

Yet another bug in IRQ emulation

Trying to find out why NetBSD versions 1.6-3.1 do not boot, I found a bug in IRQ processing. After fixing it these versions still don't boot, :) but fail more gracefully.
Looks like there is another couple of bugs to go...

Solaris 2.2 / sparc

Still in 1993. Moved from November to May: Using the cg14 implementation from Bob I was able to boot Solaris 2.2 on emulated SPARCstation-20. It was not possible before cause Solaris 2.2 is not compatible with SS-5. I wonder what are the oldest Solaris/SunOS versions which can be booted on SS-20? Solaris 2.0 is not: it supported only sun4c. SunOS 4.1.2 can not boot either: according to the Wikipedia it supports sun4m, but none of the SPARCstations.

So the versions left untested are Solaris 2.1 and SunOS 4.1.{0-1}. Have no idea about SunOS 4.0.

Will post some screenshots later.

Another week another SCSI bug

Fixed Solaris 2.6+ boot which I accidentally broke last week. It's not that my Solaris 2.3 dma/irq fix was wrong, but the fix unleashed a counterpart interrupts handling bug in esp controller.

Too bad that no one reported it earlier. I wouldn't have to hack till midnight now. ;-) And thanks to VooDoo_UzH_ for reporting it.

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.