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
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?
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.
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
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.