Carey Schug provided me his spare 2.5.1 and 2.6 Solaris install disks, so I can extend my playground. Solaris 2.6 fails exactly the same way as 9 (bootblk: can't find the boot program). The 2.5.1 version fails differently:
(Can't deduct msgbuf from physical memory list) Program terminated
The problem is known with real SS-10 / SS-20 machines, and solution supposed to be moving SIMMs from one slot to another one. Not sure, that it would work with virtual SIMMs as well...
But, anyway this is a rare case when more bugs/error messages is better. Thanks, Carey!
Saturday, September 12, 2009
Sunday, September 6, 2009
The "Wh": SunOS 4.1.4 under qemu-system-sparc
Ha! OBP already has shown one advantage: it can boot SunOS 4.1.4 (aka Solaris 1.1.2)!
Well, almost. It has problems with the serial console after booting. It is possible to give commands, but I see only the first 2 bytes of response:
SPARCstation 20 (1 X 390Z50), No Keyboard
ROM Rev. 2.25, 64 MB memory installed, Serial #0.
Ethernet address 52:54:0:12:34:56, Host ID: 72000000.
ok boot disk2:d
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@2,0:d File and args:
root on /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@2,0:d fstype 4.2
Boot: vmunix
Size: 868352+2319136+75288 bytes
SuperSPARC: PAC ENABLED
SunOS Release 4.1.4 (MUNIX) #2: Fri Oct 14 11:09:07 PDT 1994
Copyright (c) 1983-1993, Sun Microsystems, Inc.
cpu = SUNW,SPARCstation-20
mod0 = TI,TMS390Z50 (mid = 8)
mem = 65084K (0x3f8f000)
avail mem = 60309504
Ethernet address = 52:54:0:12:34:56
espdma0 at SBus slot f 0x400000
esp0 at SBus slot f 0x800000 pri 4 (onboard)
sd2: non-CCS device found at target 2 lun 0 on esp0
sd2 at esp0 target 2 lun 0
sd2:
sd2: Vendor 'QEMU', product 'QEMU', (unknown capacity)
sd3: non-CCS device found at target 0 lun 0 on esp0
sd3 at esp0 target 0 lun 0
sd3:
ledma0 at SBus slot f 0x400010
le0 at SBus slot f 0xc00000 pri 6 (onboard)
bpp_attach unit 0: register check failed!
zs0 at obio 0x100000 pri 12 (onboard)
zs1 at obio 0x0 pri 12 (onboard)
fdc: no RQM - stat 0xc0
fdc: no RQM - stat 0xc0
SUNW,fdtwo0 at obio 0x700000 pri 11 (onboard)
rd0: using preloaded munixfs
WARNING: preposterous time in file system -- CHECK AND RESET THE DATE!
root on rd0a fstype 4.2
swap on ns0b fstype spec size 58616K
dump on ns0b fstype spec size 58604K
What would you like to do?
1 - install SunOS mini-root
2 - exit to single user shell
Enter a 1 or 2: 2
you may restart this script by typing
# reboot
The things marked with light gray is what I don't see, but what is there on a real SS-20. Thanks, Carey for spending the time to find this out!
But the things are there: if I answer "2" I obviously get into the miniroot and when I type "reboot" afterwards the machine successfully reboots.
So, it is a success, but with open issues:
Well, almost. It has problems with the serial console after booting. It is possible to give commands, but I see only the first 2 bytes of response:
SPARCstation 20 (1 X 390Z50), No Keyboard
ROM Rev. 2.25, 64 MB memory installed, Serial #0.
Ethernet address 52:54:0:12:34:56, Host ID: 72000000.
ok boot disk2:d
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@2,0:d File and args:
root on /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@2,0:d fstype 4.2
Boot: vmunix
Size: 868352+2319136+75288 bytes
SuperSPARC: PAC ENABLED
SunOS Release 4.1.4 (MUNIX) #2: Fri Oct 14 11:09:07 PDT 1994
Copyright (c) 1983-1993, Sun Microsystems, Inc.
cpu = SUNW,SPARCstation-20
mod0 = TI,TMS390Z50 (mid = 8)
mem = 65084K (0x3f8f000)
avail mem = 60309504
Ethernet address = 52:54:0:12:34:56
espdma0 at SBus slot f 0x400000
esp0 at SBus slot f 0x800000 pri 4 (onboard)
sd2: non-CCS device found at target 2 lun 0 on esp0
sd2 at esp0 target 2 lun 0
sd2:
sd2: Vendor 'QEMU', product 'QEMU', (unknown capacity)
sd3: non-CCS device found at target 0 lun 0 on esp0
sd3 at esp0 target 0 lun 0
sd3:
ledma0 at SBus slot f 0x400010
le0 at SBus slot f 0xc00000 pri 6 (onboard)
bpp_attach unit 0: register check failed!
zs0 at obio 0x100000 pri 12 (onboard)
zs1 at obio 0x0 pri 12 (onboard)
fdc: no RQM - stat 0xc0
fdc: no RQM - stat 0xc0
SUNW,fdtwo0 at obio 0x700000 pri 11 (onboard)
rd0: using preloaded munixfs
WARNING: preposterous time in file system -- CHECK AND RESET THE DATE!
root on rd0a fstype 4.2
swap on ns0b fstype spec size 58616K
dump on ns0b fstype spec size 58604K
What would you like to do?
1 - install SunOS mini-root
2 - exit to single user shell
Enter a 1 or 2: 2
you may restart this script by typing
# reboot
The things marked with light gray is what I don't see, but what is there on a real SS-20. Thanks, Carey for spending the time to find this out!
But the things are there: if I answer "2" I obviously get into the miniroot and when I type "reboot" afterwards the machine successfully reboots.
So, it is a success, but with open issues:
What is wrong with the serial console? I tested the mode 9600E1 (which is used by SunOS 4.1.4) under NetBSD and it looks totally fine there. Also I tried to switch parity off under SunOS, and it made no difference. Why SCSI devices are detected as
Saturday, September 5, 2009
Yes, I did it! OBP is functional under qemu!
Wrote another hack, and now I can use OBP under qemu! Woo-hoo! All in all it took just 7 weekends. :)
The bad news is that.... It doesn't do much better than OpenBIOS. I can boot Linux, and NetBSD (this one is more complex, as OBP checks disklabel, and NetBSD miniroots don't have it), but booting Solaris 9 gives...
...the very error message as under OpenBIOS:
bootblk: can't find the boot program
I still think it is a progress: OBP has a debugger, while OpenBIOS doesn't. If nothing else helps I can step through the boot loader.
And anyway the effort wasn't useless: I found one bug in CPU, and three in scsi layer.
The bad news is that.... It doesn't do much better than OpenBIOS. I can boot Linux, and NetBSD (this one is more complex, as OBP checks disklabel, and NetBSD miniroots don't have it), but booting Solaris 9 gives...
...the very error message as under OpenBIOS:
bootblk: can't find the boot program
I still think it is a progress: OBP has a debugger, while OpenBIOS doesn't. If nothing else helps I can step through the boot loader.
And anyway the effort wasn't useless: I found one bug in CPU, and three in scsi layer.
Third bug in SCSI layer (esp) fixed
Up to now "select without attention" was handled the same way as "select with attention". According to NCR53C9X documentation, select without ATN sends the CDB (Command Descriptor Block) directly, whereas select with ATN sends one message phase byte followed by 6, 10, or 12 command phase bytes. This one byte was shifting CDB and producing invalid commands. After fixing this bug scsi probe looks like this:
ok probe-scsi
Target 0
Unit 0 Disk
Target 2
Unit 0 Removable Read Only device
ok
It still doesn't show all the target properties, but it doesn't matter. The next stop is booting.
ok probe-scsi
Target 0
Unit 0 Disk
Target 2
Unit 0 Removable Read Only device
ok
It still doesn't show all the target properties, but it doesn't matter. The next stop is booting.
Labels:
esp,
qemu,
SCSI,
Select Without Attention
Subscribe to:
Posts (Atom)
