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.

-- 
Len Sorensen

[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

-- 
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu