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

Open Firmware for qemu-system-ppc -M prep

I'm glad to announce the result of some weekends of work: a new firmware which is not just open, but is also powerful (it runs on Power CPUs), free (the individual files are licensed under MIT and BSD licenses) and of course legendary - it's based on the original PReP firmware from Mitch Bradley's FirmWorks company.

That's how it happened: Mitch licensed the files from the original PReP firmware under the MIT license, I adjusted them to the current OFW tree and added some build files. Then I gathered a small firmware for QEMU PReP machine which used a Cirrus Logic graphics adapter (need a one line change in QEMU code to enable it). Then I added a driver for QEMU "standard" VGA Adapter (also known as Bochs Graphic Adapter) and this night Mitch has committed it together with my atapi fixes as svn.3738 here:

http://code.coreboot.org/p/openfirmware/source/tree/HEAD/

What's in the tree? The original 1994-2000 stuff landed in the /cpu/ppc/prep directory. The build files for generic PReP firmware on top of the generic PPC firmware are in the /cpu/ppc/prep/build folder. And QEMU-specific stuff is in /cpu/ppc/prep/qemu folder. For those who don't want to compile it, but would like to try it straight away I've built two binaries: qprepofw-vga-svn-3738.rom which uses QEMU in graphics mode, and qprepofw-serial-svn-3738.rom for serial console (in the current QEMU version I found no way for guest to see if qemu-system-ppc -M prep is launched with an additional -nographic option).

How to use it:

qemu-system-ppc -M prep  -bios qprepofw-vga-svn-3738.rom  -cpu 603 -hda /path/hdd-image -fda /path/floppy -cdrom path/cd

or

qemu-system-ppc -M prep -bios qprepofw-serial-svn-3738.rom  -cpu 603 -hda /path/hdd-image -fda /path/floppy -cdrom path/cd -nographic

And then

boot disk

or

boot cdrom

or

boot floppy

The advantages over OpenHackWare (default QEMU firmware for PReP target) and OpenBIOS:

• can boot from floppies and cdrom images. It's possible to boot for instance NetBSD-6.1.3-prep.iso. Of Course, It Runs NetBSD!™
• supports QEMU's -vga std, -vga cirrus graphic adapters and serial console
• is written in Forth (OpenHackWare is not), has command history, Forth syntax highlighting and code completion.
• uses the original layout for NVRAM

The drawbacks:

• doesn't detect the amount of RAM present and the screen resolution. For now I've just hard-coded 128MiB and 1024x768. Is a trivial thing to support once QEMU chooses the way this information is passed to the firmware (OHW and OpenBIOS use different mechanisms, there are patches which are removing the former one and adding the later, but they are not in upstream yet)
• can't boot from Apple Partition Boot Code. The original RS/6000 firmware was probably not able to do it either, but OpenBIOS can do it and maybe it's a nice feature for testing (not sure if it is important yet: on one hand there are more PPC distributions for Macs, on the other hand, Macs had slightly different hardware and firmware than PReP machines)

So, digital archaeologists,  have fun and please report if you could do with OHW something which OFW can't.

Stay tuned...

Playing with Open Firmware

Made a couple of small improvements in Open Firmware and sent the patches to Mitch Bradley. One fix is probably not relevant for the most of users: it has to do with handling fdisk/MBR partitions on CDs. Another one may be more interesting for those who use CD/DVD drives on OLPC.
I was hoping to do something useful, but it turned out OLPC don't have a built-in cdrom drive. Still there can be one or two users who have external drives and would like to boot from them.

I didn't realize till recent times that as a part of his work on the OLPC Project, Mitch released the original Open Firmware base for ARM, MIPS, PPC and x86 machines. It has some advantages over OpenBIOS: Forth syntax highlighting,  word completion, more comfortable debugging and an emulator of Power CPUs to simplify cross-platform building.

It is distributed  under MIT Open-Source License, which may be more suitable than GPL for some projects.

May the Forth be with you. :-)

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.

IOMMU support in upstream qemu-system-sparc64

I didn't write about SPARC emulation lately because I didn't work on it. But Mark Cave-Ayland is still working hard, so there is a lot of new stuff. The sun4m emulation has a new graphic adapter: cg3. Also the old adapter (tcx) supports acceleration.

And now, something really cool for the sun4u emulation. As of today git master has a working IOMMU support in qemu-system-sparc64! This means that you don't need to follow all the steps in
Debian/sparc64 Wheezy under QEMU How-To. Just insert your image into -cdrom and voilà!
Well done, Mark!

Now, while using an IDE drive simplifies the installation process a lot, using virtio still makes sense. Quick performance test:

root@debian-wheezy:~#  dd if=/dev/vdb of=/dev/null bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1.56761 s, 66.9 MB/s

root@debian-wheezy:~#  dd if=/dev/sda of=/dev/null bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 9.59107 s, 10.9 MB/s


Yes, IDE is slower, as the emulated kernel has to do more work, but still, the performance is pretty much ok.


Also, not every OS running on sun4u machines has support for virtio. From an undisclosed source I know that Mark is working on booting NetBSD/sparc64 under vanilla QEMU. Stay tuned. ;-)

800km (500 mi) from San Francisco to Los Angeles

Took my bicycle overseas to ride from San Francisco to Los Angeles. We did it in 7 days. Was a great trip! Not writing the whole story here, just a couple of pictures.

The bike arrived