Some SPARC32 Patches

[Olivier Danet]

Hello !

Here are a few patches for QEMU and OpenBIOS, about SPARC32, grouped 
into two
diffs:

OpenBIOS : http://temlib.org/pub/openbios_nn.diff
QEMU     : http://temlib.org/pub/qemu_nn.diff

Changes:

OpenBIOS
* SparcStation10/20 mode fix (drivers/iommu.c, drivers/sbus.c)

- TCX properties     (drivers/tcx.fs)
- next-property      (forth/device/property.fs)
- Keyboard property  (drivers/escc.c)

+ Memory allocation/deallocation (arch/sparc32/lib.c, 
arch/sparc32/ofmem_sparc32.c,
                                   libopenbios/ofmem_common.c, 
arch/sparc32/romvec.h)
+ a.out file loading (libopenbios/aout_load.c)
+ Dummy TICK counter (arch/sparc32/romvec.c)
+ Interrupt/Timer properties (include/drivers/drivers.h, 
forth/device/property.fs,
                               drivers/obio.c)

QEMU
- TCX Hardware acceleration : Blitter, Stippler, HW cursor 
(hw/display/tcx.c,
hw/sparc/sun4m.c)
- "!TC on DATA XFER" warning under NetBSD (hw/scsi/esp.c)
+ Timer Run/Stop bit correction (hw/timer/slavio_timer.c)

TCX emulation with acceleration seems good enough, although it is 
incomplete and
it is probably impossible to implement the 24bits mode accurately and 
efficiently in QEMU.

I will post each patch separately on the two mailing lists. TCX patches
should be synchronised : OpenBIOS cannot advertise an hardware cursor until
it is actually implemented.

One more thing.

After NetBSD and TCX acceleration, I tried NextSTEP, which needs the 
patches marked + above.
Alas, this is not enough to make it run.
Maybe it is because QEMU SCSI disk and ESP emulation are too fast.

Olivier

[Programmingkid]

On Jan 30, 2014, at 4:55 PM, Olivier Danet wrote:
> Hello !
>
> One more thing.
>
> After NetBSD and TCX acceleration, I tried NextSTEP, which needs the patches marked + above.
> Alas, this is not enough to make it run.
> Maybe it is because QEMU SCSI disk and ESP emulation are too fast.

Did the NeXtCube use Open Firmware?

[Lennart Sorensen]

On Thu, Jan 30, 2014 at 08:54:55PM -0500, Programmingkid wrote:
> On Jan 30, 2014, at 4:55 PM, Olivier Danet wrote:
> > Hello !
> >
> > One more thing.
> >
> > After NetBSD and TCX acceleration, I tried NextSTEP, which needs the patches marked + above.
> > Alas, this is not enough to make it run.
> > Maybe it is because QEMU SCSI disk and ESP emulation are too fast.
>
> Did the NeXtCube use Open Firmware?

Not likely.  It was m68k based.  It had something called the 'NeXT ROM
Monitor'.  See http://wiki.netbsd.org/ports/next68kfaq/ for example for
some info on that.

NeXTstep for the powerpc likely ran on open firmware machines, although
I don't know that for sure.

[Mark Cave-Ayland]

On 30/01/14 21:55, Olivier Danet wrote:
> Hello !
>
> Here are a few patches for QEMU and OpenBIOS, about SPARC32, grouped
> into two
> diffs:
>
> OpenBIOS : http://temlib.org/pub/openbios_nn.diff
> QEMU : http://temlib.org/pub/qemu_nn.diff
>
> Changes:
>
> OpenBIOS
> SparcStation10/20 mode fix (drivers/iommu.c, drivers/sbus.c)
> TCX properties (drivers/tcx.fs)
> next-property (forth/device/property.fs)
> Keyboard property (drivers/escc.c)
> Memory allocation/deallocation (arch/sparc32/lib.c,
>
> arch/sparc32/ofmem_sparc32.c,
> libopenbios/ofmem_common.c, arch/sparc32/romvec.h)
> a.out file loading (libopenbios/aout_load.c)
> Dummy TICK counter (arch/sparc32/romvec.c)
> Interrupt/Timer properties (include/drivers/drivers.h,
>
> forth/device/property.fs,
> drivers/obio.c)
>
> QEMU
> TCX Hardware acceleration : Blitter, Stippler, HW cursor
>
> (hw/display/tcx.c,
> hw/sparc/sun4m.c)
> "!TC on DATA XFER" warning under NetBSD (hw/scsi/esp.c)
> Timer Run/Stop bit correction (hw/timer/slavio_timer.c)
>
> TCX emulation with acceleration seems good enough, although it is
> incomplete and
> it is probably impossible to implement the 24bits mode accurately and
> efficiently in QEMU.
>
> I will post each patch separately on the two mailing lists. TCX patches
> should be synchronised : OpenBIOS cannot advertise an hardware cursor until
> it is actually implemented.
>
> One more thing.
>
> After NetBSD and TCX acceleration, I tried NextSTEP, which needs the
> patches marked + above.
> Alas, this is not enough to make it run.
> Maybe it is because QEMU SCSI disk and ESP emulation are too fast.
>
> Olivier

Hi Olivier,

These look great, and I can already see things that could potentially 
fix a few bug reports I've received off-list. Looking forward to 
receiving the unsquashed versions for review :)

ATB,

Mark.

[Artyom Tarasenko]

Salut Olivier,
> I tried NextSTEP, which needs the patches
> marked + above.
> Alas, this is not enough to make it run.
> Maybe it is because QEMU SCSI disk and ESP emulation are too fast.

I played with NextSTEP/sparc a few years ago and got the same impression.
I've managed to get it boot into a single user mode, but it was
unstable on disk operations. Just a simple
dd if=/dev/sd0a of=/dev/null was able to get it hanging. And I think
it was hanging in the kernel idle loop doing nothing.

If there were a Darwin/sparc ditribution, we could take a look, if
it's really a bug in NextSTEP or in qemu-system-sparc. But I couldn't
find such a distribution.

Artyom