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.
Monday, May 31, 2010
Saturday, May 29, 2010
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
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
Saturday, May 22, 2010
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.
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.
Saturday, May 15, 2010
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
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
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
esp: cmd_flags=0x1422 cmd_timeout=60
Saturday, May 8, 2010
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.
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.
Subscribe to:
Posts (Atom)