Solaris 9 under OpenBIOS

Together with Mark Cave-Ayland fixed a bug in OpenBIOS preventing Solaris 9 boot in a single user mode on sun4m. As it turned out, Sun relied on some undocumented behavior while walking though a device tree: calling the "child" function with a null argument is expected to produce the same result as calling it with a pointer to the root node.

So, in the next OpenBIOS release, it should be possible to boot Solaris 9 just like the versions 5.7 and 8 with just '-s' switch instead of '-b'.
Unfortunately my schedule rarely fits the QEMU-Release schedule, so this fix probably won't make it into the upcoming QEMU 2.2. release because of the code freeze. But for those, who are starting their day with 'git pull' the release schedule doesn't matter. ;-)

Stay tuned...

Upstream QEMU can run NetBSD/sparc64

Mark did a good job fixing OpenBIOS properties and cmd646 emulation in QEMU, so NetBSD started to get up to the user space. Then I sent my patch for emulation of short load instructions upstream, so with all this patches applied qemu-system-sparc64 can successfully boot NetBSD 6.1.4 (and likely all the other sparc64 versions):

       
Updating motd.
Starting sshd.
postfix: rebuilding /etc/mail/aliases (missing /etc/mail/aliases.db)
Starting inetd.
Starting cron.
Sat Aug  9 11 11:18:59 CEST 2014

NetBSD/sparc64 (netbsd614) (console)

login: root
Aug  9 11:19:27 netbsd614 login: ROOT LOGIN (root) on tty console
Last login: Fri Jan  1 13:21:40 2010 on console
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 6.1.4 (GENERIC)

Welcome to NetBSD!

Terminal type is wsvt25.
We recommend that you create a non-root account and use su(1) for root access.
netbsd614#  ping 10.0.2.2
PING 10.0.2.2 (10.0.2.2): 48 data bytes
64 bytes from 10.0.2.2: icmp_seq=0 ttl=255 time=2.463 ms
64 bytes from 10.0.2.2: icmp_seq=1 ttl=255 time=1.994 ms

Have fun and please report the bugs to the qemu-devel@ mailing list.

Networking in Linux/sparc64 under qemu...

... is also possible. The bulit-in ne2k-pci network card doesn't work, but hey there is an even faster virtio-net alternative. At the OpenBIOS "ok" prompt, before the "boot" command in the previous post, type

cd /pci@1fe,0/pci1af4,1000
0 encode-int " interrupts" property
device-end

Will send this patch upstream as soon as we clarify whether "0" is allowed for the "interrupts" property.

Booting Linux/sparc64 on todays OpenBIOS

Historical day for everyone interested in the vanilla qemu-system-sparc64 emulator. For the first time it can boot Linux!

Although the patches I sent upstream are  fixing CPU and IOMMU, there is still one missing piece: cmd646 IDE. Luckily it's not a showstopper at all: qemu-sparc64 is a PCI machine, which means one could use the fast virtio instead! Now, this is the command line:

$  sparc64-softmmu/qemu-system-sparc64 -m 256 -nographic -prom-env 'auto-boot?=false' -kernel /path/to/kernel/image -drive file=/path/to/debian-disk,if=virtio,index=0 -append 'root=/dev/vda1 init=/bin/sh'

Some time ago, I used Forth to workaround missing qemu features  to get OBP working.
Now it's pretty similar: OpenBIOS doesn't have all the properties necessary for Linux to get the interrupt mapping.

So at the ok command prompt where you'd get after the command above, type:
 
cd /
1 encode-int " #interrupt-cells" property
cd /pci@1fe,0/ebus
000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+
ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property
000001ff encode-int ffffffff encode-int encode+ 00000003 encode-int encode+
" interrupt-map-mask" property

cd /pci@1fe,0/ebus@3/su
1 encode-int " interrupts" property
cd /pci@1fe,0/pci-ata@5
0 encode-int " interrupts" property

cd /pci@1fe,0/pci1af4,1001
0 encode-int " interrupts" property
device-end
boot


The only magical constant above is actually "ffe29140" - the address of the root pci node in the OpenBIOS device hierarchy. Although it the same in all the recent builds, in theory it could be moved somewhere else one day. But I guess till that day OpenBIOS will have the missing properties... ;-)

Update:

Oh, and a few words to /path/to/kernel/image and /path/to/debian-disk:

I found no Linux/sparc64 distribution which has a built in virtio driver. This makes installing from a  CD/DVD image not possible. The solution is build your own kernel with the virtio driver compiled in and put it at /path/to/kernel/image.

As for the disk, the user space utilities from the sparc32 world can be used in the sparc64 world as is. So, you can install Debian (or your favorite sparc32 distribution) in the /path/to/debian-disk, using qemu-system-sparc (no 64 at the end), and then use it with qemu-system-sparc64 as described above.

If you know a Linux/sparc64 distribution with the virtio support, please let me know.

/Happy hacking

Qemu is going to boot Linux/sparc64

After considering it a bit, I thought, it's a good marketing strategy: the free QEMU version shall run the free OS - Linux. And if anyone is interested in running something else, feel free to ask me for a [paid] support. :-)

So, Linux is going to be the second OS which vanilla qemu-system-sparc64 would boot - HelenOS was the first one. But, unlike HelenOS, Linux will be fully functional, having not just a stdout, but a stdin as well. And a serial port support!

At the moment OpenBIOS has some missing features - it doesn't describe the interrupt mappings - and a regression - currently it can't even boot HelenOS from a command line. But both are not show-stoppers.

Once my patches are accepted I'll publish the OpenBIOS command to boot Linux (not because it's top secret, but due to the dependency to a certain version).

OpenBIOS strikes back

Mark did it! OpenBIOS svn.r1035 with two patches (escc and lance) can boot a sun4m Solaris. As soon as the patches are reviewed and committed I'll have to update the how-to. Booting Solaris is going to be much simpler. Congratulations the OpenBIOS Team!

Whose house?

I occurred to me that I'm sort of competing with Mark Cave-Ayland. While Mark makes a really good job to get a proprietary OS (Solaris 8) working with an Open Source firmware (OpenBIOS) under a 32 bit SPARC qemu machine, I'm trying to get a Open Source OS (OpenSolaris) working with a proprietary firmware (OBP) under a 64 bit SPARC qemu machine. Right now we are at about the same place - he is right after the disk detection, I'm a bit behind.

Who's gonna see the '#' first, what are your bets? What task do you think is easier?

But speaking seriously, if Mark makes it first I'll buy him a beer.

Round and round she goes, and where she stops nobody knows

After a while I got back to qemu. This time to the sparc64 port. It's interesting to see how the highlights of the sun4m story are repeating. With the difference that this time the way goes faster. The highlights of the last weekends:

• What? Not even a greeting message? I should give it up. hack, hack, hack
• Oh, wow, it gives a message "Button Power ON"! Too bad it hangs afterwards. hack, hack, hack
• Ha! got it up to the Forth bootstrapping, too bad I have no prompt. hack, hack, hack
• Yes! The Forth is with me, there finally is the "ok " prompt. Too bad it sees no devices. hack, hack, hack
• Woo-hoo, OBP sees a disk controller! Why doesn't it see the disks? hack, hack, hack
• Aha, there are my disks. Can I boot Solaris, please? Hrm, no. Can I boot anything? No?!? hack, hack
• Ok, now it's properly initialized. Well, properly enough to boot SILO, and yes, it's stuck at ufsboot just like the sparc32 version did.
• Ta-da! Finally I see something new:

SunOS Release 5.11 Version Natamar_0.4__b96 64-bit
Copyright 1983-2008 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.

• But wait, didn't I see it with OpenBIOS?!? Yes, I did. In fact all the 64 bit SPARC operating systems I tried so far go a little further with OpenBIOS.
• So, can OBP on qemu-system-sparc64 do anything the OpenBIOS can't?!? No?!? (because badly documented missing devices, probably necessary just for OBP, are badly hacked by me). I should give it up. :-)

And this is the progress so far. Hats off to the HelenOS team who managed to get their OS running under qemu. No other OS can work under qemu-system-sparc64 yet.

Does anyone have a Martux 0.2 image? It used to be available on the authors site, but seems to be gone, leaving just the check sum files. The file I'm looking for is

CD_sun4u_sparcv9__marTux_0.2__small_naked_demo_cd_bs2048b.iso.bz2 .

Sent a small patch to OpenBIOS

Now there is a few bytes of my code in the OpenBIOS project as well.
Switching perspectives is an interesting experience: while debugging qemu and seeing something what I don't understand immediately, the first thought is that some hw device is not properly emulated.
Debugging OpenBIOS I'm pretty much sure that hw emulation is fine.

Anyway, fixed one bug. Solaris still crashes on the boot,  but now it should be possible to switch off the mapping of the page 0x0.

In case you are wondering what this would be good for, there are 2 good reasons: a) being compliant to IEEE-1275 SPARC supplement, and more importantly b) ability to easy catch a null pointer dereferences.

The trivial rest of the Solaris boot exercise is left to Mark, Blue and other OpenBIOS developers. :-)

a couple of bugs in OpenBIOS

Found two bugs in OpenBIOS. I think I fixed one of them, but it can be checked only when the other one gets fixed. The other one is pretty deep in the Forth engine, don't want to mess with it. Once it will be fixed I'll get back to OpenBIOS.

going further with OpenBIOS

No, I was wrong about the 80 characters limit. Found the correct place where it crashed, but the reasoning was wrong. Something was corrupting the stack, so success after patching ufsboot was incidental.

back to OpenBIOS

Since SS-5 OBP works pretty well, I think it's a good time to get back to OpenBIOS: it's free (as in speech), and can support more than 256 MiBs RAM.  Theoretically Ross's SPARCStation-20 OBP supports up to 2 GiB RAM, but frankly speaking I think having a more or less hardware-precise SS-5 is enough.

The very first experience has shown that bootblk loads ufsboot successfully, but then it hangs. I'm feeling myself getting back few months in the past. Back then I was debugging pretty much similar routines in the bootblk, but the main job was done by Mitch Bradley. I sort of hoped I skipped the necessity to learn the gory details of the UFS filesystem. Ok, back to school. ;-) . My very first long shot:

$ strings sun4m/ufsboot
...
 ['] find-device catch if 2drop true else current-device device-end then swap l!
...

Trying to find out whether this sentence works I found out that OpenBIOS doesn't support input lines longer than 80 characters! It would be interesting to find out whether it's just a console limitation, or the API too. If it's an API limitation it may be exactly the bug that prevents Solaris from booting.

Another observing:

0 > " /openprom" ['] find-device  ok
3 > . . . -29a594 9 -264cec  ok

• "ok" is not a prompt, but a response. I don't think it's important.
• It operates with signed hexadecimals. This looks pretty weird. Here comes the same question again: is this just a console representation, or another API bug.

Gonna check it with OpenBIOS developers.

Spurious interrupts

Previously qemu dropped interrupts on disabling them. The real hardware doesn't do it. Which means, that lots of interrupts were dropped, including the spurious ones. But the real ones were dropped too, that's why the system timer was ticking so slow.

The question is where the spurious  IRQs are coming from: it's not only the ESP which produces them, under Solaris 8 & 9 there are lots of complains about spurious timer interrupts, and they both seem to crash due to a buffer overflow during processing of a (possibly spurious) LE interrupt.

NetBSD 1.3.3 boot doesn't crash with my wrong irq patch. The patch makes qemu drop interrupts, including the spurious ones.

All in all it looked like there is one global problem with interrupts processing. Until now. But now it looks like there is not one source of spurious interrupts, but many.

• esp doesn't seem to produce spurious interrupts under Solaris while reading.
• I've found a bug in the slavio timer which produces spurious interrupts.
• NetBSD may be crashing due to another issue: I don't have a disk which I could boot under OBP. It is possible that OpenBIOS is not compatible with the older NetBSD versions. Update: This is the reason for NetBSD crashing, Michael Kostylev confirmed it.

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.

Open Boot vs. OpenBIOS

While being a great Open Source fan, I still think it would be better to use a real machine's firmware to ensure the emulation is complete. Once we are sure the virtual hardware is working properly there will be no need to run POST. It doesn't even have to be implemented.

Otherwise there are chances that Firmware would perfectly function on a virtual hardware, but it would have nothing to do with the real hardware. There are always some features which are documented too fuzzy or not documented at all.

So I'm going to give it a shot with the real firmware. Btw it is called OBP - Open Boot Prom.

The first results are not very fruitful: the RAM is not detected, and there are no sbus devices (=> no booting from SCSI yet). But at least OBP has the command "power-off" (which OpenBIOS doesn't), and the command is even perfectly working:

$ qemu-system-sparc -M SS-20 -L . -bios ss20_v2.25_rom -nographic -hda hda.img
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 *******

<<<>>> 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 0x08000000
Allocating SRMMU Context Table
Context Table allocated, Available Memory 0x07fc0000
Setting SRMMU Context Register
Context Table allocated, Available Memory 0x07fc0000
Setting SRMMU Context Table Pointer Register
RAMsize allocated, Available Memory 0x07fb0000
Allocating SRMMU Level 1 Table
Level 1 Table allocated, Available Memory 0x07fafc00
Mapping RAM @ 0xffef0000
RAM mapped, Available Memory 0x07fafa00
Mapping ROM @ 0xffd00000
ROM mapped, Available Memory 0x07faf800
Mapping ROM @ 0x00000000
ROM mapped, Available Memory 0x07faf000
ttya initialized
Cpu #0 TI,TMS390Z55
Cpu #1 Nothing there
Cpu #2 Nothing there
Cpu #3 Nothing there
Probing Memory Bank #0 Nothing there
Probing Memory Bank #1 Nothing there
Probing Memory Bank #2 Nothing there
Probing Memory Bank #3 Data Access Error
ok show-devs
/TI,TMS390Z55@f,f8fffffc
/SUNW,sx@f,80000000
/eccmemctl@f,0
/virtual-memory@0,0
/memory
/obio
/iommu@f,e0000000
/openprom
/aliases
/options
/packages
/obio/power@0,a01000
/obio/auxio@0,800000
/obio/SUNW,fdtwo@0,700000
/obio/interrupt@0,400000
/obio/counter@0,300000
/obio/eeprom@0,200000
/obio/zs@0,0
/obio/zs@0,100000
/iommu@f,e0000000/sbus@f,e0001000
/packages/obp-tftp
/packages/deblocker
/packages/disk-label

ok show-sbus
SBus slot f
SBus slot e
SBus slot 0
SBus slot 1
SBus slot 2
SBus slot 3
ok power-off

$

Looks like the OpenBIOS doesn't recognize Solaris boot sector:


Configuration device id QEMU version 1 machine id 32
UUID: 00000000-0000-0000-0000-000000000000
CPUs: 1 x FMI,MB86904
Welcome to OpenBIOS v1.0 built on Jul 5 2009 17:37
Type 'help' for detailed information

[sparc] Booting file 'cdrom' with parameters ''
Trying cdrom (/iommu/sbus/espdma/esp/sd@2,0)
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Trying cdrom:d (/iommu/sbus/espdma/esp/sd@2,0:d)
Not a bootable ELF image
Not a Linux kernel image
Loading a.out image...
Loaded 7680 bytes
entry point is 0x4000
Jumping to entry point...
bootblk: can't find the boot program
halt, power off