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.