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... ;-)
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
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
12 comments:
what the hell is virtio and how do I run Solaris 10 on this?
http://wiki.libvirt.org/page/Virtio
Running Solaris 10 is more tricky - you'd have to heavily modify qemu to make it boot.
is it possible to install NetBSD sparc64 on qemu ?
I tried to start an install image and it dropped me to a Boot: prompt with the message Failed to load 'netbsd'.
Thanks
Can you please specify which version of qemu and openbios you were able to boot sparc64 linux kernel with, because i just can't figure out how to make it happen. Thanks!
Use qemu-1.4.0 or the current git version. Then you don't need that Forth spells. My patches are already included, so it will work just like that, out of the box. The only thing you need to take into account is the kernel image must not be compressed.
Well I tried on different versions, including 1.4.0 and kernel starts booting, but it freezes right on the start on "[ 0.000000] Remaping the kernel... done.". Is there some special kernel configuration to make it work?
Nevermind, i found solution, default memory size of qemu is too small, you need to add -m 256. Still thanks!
I managed to boot, but virtio disk i/o performance is very bad and it is show stopper. Is there any way how to improve it(besides the usual ways)?
That's strange. Please report the issue on the qemu-devel mailing list. Virtio is actually the best performance one can get...
And, btw, how bad is "very bad"? How did you measure and what numbers have you got?
Well by "very bad" I mostly mean it was unusable for normal operation(coping ~100M of data resulted in hour or so of waiting). While CPU performance was quite good, any disk or network operation resulted in long blocking wait.
I will try to figure out what was the problem, and report on list if I won't be able to find a solution.
Oh. That's very bad indeed. I can't reproduce it though:
sh-3.1# time dd if=/dev/zero of=/mnt/100M-file bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 12.238 seconds, 8.6 MB/s
real 0m12.356s
user 0m0.069s
sys 0m10.394s
sh-3.1# time cp /mnt/100M-file /mnt/100M-file-2
real 0m35.387s
user 0m3.603s
sys 0m29.209s
sh-3.1# uname -a
Linux (none) 3.3.2 #13 Sun May 13 18:42:12 CEST 2012 sparc64 GNU/Linux
Can you tell more about your setup? What is your command line, what is your guest, the file system type and the kernel?
Post a Comment