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

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

Hiding the boot device from an OS

Suspecting a bug in SCSI subsystem, I was wondering how to prevent an OS from detecting the device it's booting from. At first it sounds weird, but it's possible for most of OS/distributions in the SPARC (and probably PPC) world, because they

• boot  init scripts from a RAM disk
• use IEEE 1275 device tree to find out available devices *

*) with exception of  Linux. At least the Linux uniform IDE driver tries to detect a hardware by probing.

For FreeBSD, NetBSD, OpenBSD and Solaris it's possible to hide the boot device from the OS install CD with the following commands:

ok cd scsi " unknown" name device-end
ok boot /unknown/sd@6,0:f

Use the Forth, Luke!

Back and Forth. But mostly Forth.

Debugged the OBP boot comparing the cases where it crashes on RAM detection and on SX framebuffer detection. Now I have the path, which initializes almost everything not stepping into routines where it hangs. Currently two qemu hacks are needed: upper SIMM-FCode hack and timer stop & go hack. The rest is simple:

: t1
root-device ffd60d80 execute ffd61340 execute " banner-name" attribute device-end
" cpu-devices+" do-drop-in ( * ffd61450 * )
ffd61e70 execute ( * ffd61ea0 * )
ffd5edb0 execute ffd52a30 execute + +
ffd62930 execute 3drop 2drop ( * ffd62990 *)
ffd65610 execute drop ffd65970 execute ( * ffd659a0 * )
true (is) standalone? ffd65f20 execute ffd65f30 execute ! ffd65f40 execute ffd65f50 execute ! ( * ffd66370 * )
sunmon-compat? ffd60490 execute or 0= ffd66240 execute ( * ffd66a60 *)
ffd68920 execute ( * ffd68940 * )
ffd68dd0 execute ( * ffd68e40 *)
enable-interrupts ( * ffd6b210 * )
"/sbus" find-device scsi-initiator-id xdrint " scsi-initiator-id"
attribute device-end ( * ffd6b780 * )
ffd6e9a0 execute ffd6f160 execute "/sbus" find-device scsi-initiator-id xdrint " scsi-initiator-id" attribute device-end
ffd6f160 execute dup root-device " clock-frequency" integer-attribute device-end
2 / "/sbus" find-device " clock-frequency" integer-attribute device-end
ffd60a00 execute ( * nvram rc * )
;
showstack
t1
setenv fcode-debug? true
" probe-" do-drop-in f probe-slot " probe+" do-drop-in

May the Forth be with you

Learning Forth. It is actually a very powerful language.

Don't know if the One Laptop Per Child initiative will give something to children, but it certainly brings something to me: very good Forth lessons.

There are also some useful documentation from Sun (meanwhile Oracle).