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:

  • 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 non-CCS? They must be compatible with SCSI-2, or even partially with SCSI-3.
Update 15.08.2010: The SunOS 4.1.4 can be successfully booted after my last patch.

6 comments:

Guillaume said...

Hello,

Even though SunOS 4.1.4 is not your main target, could you add a section about it in the HOWTO exposing the command line you have used to start this boot sequence ?

With the current qemu from the Git repo, if I execute :

$ sparc-softmmu/qemu-system-sparc -M SS-20 -m 256 -startdate "2009-12-13" -L . -bios ss20_v2.25_rom -nographic -cdrom sunos-4.1.4.iso

I have the following output :

ESP ERROR: esp_mem_writeb: Unhandled ESP command (a2)

Power-ON Reset

SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)


CPU_#0 TI, STP1021PGA(1.x) 1Mb External cache

CPU_#1 ******* NOT installed *******
CPU_#2 ******* NOT installed *******
CPU_#3 ******* NOT installed *******

<<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID = 00000008)



$$$$$ WARNING : No Keyboard Detected! $$$$$
MMU ICACHE_TLB bit pattern Test
Case 0000000f: I_TLB mis-matched exp=55555000 obs=00000000 xor= 55555000 entry # 0x00000000
Available Memory 0x10000000
Allocating SRMMU Context Table
Context Table allocated, Available Memory 0x0ffc0000
Setting SRMMU Context Register
Context Table allocated, Available Memory 0x0ffc0000
Setting SRMMU Context Table Pointer Register
RAMsize allocated, Available Memory 0x0ffb0000
Allocating SRMMU Level 1 Table
Level 1 Table allocated, Available Memory 0x0ffafc00
Mapping RAM @ 0xffef0000
RAM mapped, Available Memory 0x0ffafa00
Mapping ROM @ 0xffd00000
ROM mapped, Available Memory 0x0ffaf800
Mapping ROM @ 0x00000000
ROM mapped, Available Memory 0x0ffaf000
ttya initialized
Cpu #0 Data Access Error
ok

atar said...

It's described as Solaris 2.5.1-, as it is the same for all the Solaris versions before 2.6. So, if you use -hdb instead of -cdrom option, you'll have to boot with

ok boot disk1:d

Btw, do you by any chance have a hard drive image of 4.1.4? It may be more interesting than cdrom because unlike cdrom it can be configured not to use the obscure 7E1 serial mode. Also there were some other patches from sun, which may be crucial.

R. Stricklin said...

Artyom -

Your console output stops pretty much at the point where the SunOS 4 serial driver sets the high bit, which fouls up "normal" terminal emulators unless you have the "strip high bit" option set. I wonder if it is tickling a bug in the qemu display code? Or perhaps just these characters are not available in the display font you are using. I have not played with it myself so this is pure conjecture. It is worth noting that even though you can't easily interpret the display when this happens, input is unaffected, which fits with you being able to enter commands and have them executed.

I'd be curious to hear where you are able to go with this information (if anywhere). - bear@typewritten.org

atar said...

It's true, SunOS driver sets tty in 7E1 mode. But as I wrote above it's not a problem: NetBSD is totally fine with 7E1.

I guess the problem is the serial driver itself: it didn't support cts/rts till some patch.

The patch is of course not included in the original install cd, so SunOS currently can not be installed under qemu.

But if you have a SunOS hard drive image with all patches applied, we may have more luck.

Neozeed said...

Hmm I think this is where a frame buffer would help a lot.. ;)

I started trying to hack the existing sun buffere into a BW2, as I figure the BW2 is pretty much just a fixed resolution display that just exists as a bunch of memory in the memory map.... I'll have to dig a lot further though, as I'm too much of a noob... :|

Also a BW2 would allow us to install nextstep...

atar said...

Actually TCX which does emulate would have been enough for SunOS (but probably still not enough for the NEXTStep). It is a good question why ss5 OBP is not happy with TCX which qemu does emulate. Not sure that BW2 would improve the situation.Btw, BW2 had its own ROM on board, right? Do you have it?

And as I wrote this, I think that's that's the reason OBP doesn't work with TCX: we lack it's ROM.