Re: sparc64: fledgling QEMU support
Fantastic! Will be great for quick jobs without banshee fan wail and roasted office space in the long summers. Thank you. /jl
Re: sparc64: fledgling QEMU support
Date: Tue, 09 Sep 2014 19:20:09 +0100 From: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Hi all, Following up from my posts at the beginning of the summer, I'm pleased to announce that as of today, qemu-system-sparc64 built from QEMU git master will successfully install OpenBSD from an .iso and boot back into it in serial mode with its default sun4u emulation: ... There are still some issues with the device tree to work out; in particular NVRAM and networking (I'd guess that the OpenBSD sparc64 kernel doesn't contain the Realtek device driver so at some point I'll need to create a virtual hme device) but it's good enough to install/boot an OS on different hardware for testing - what could be more fun than that? Sweet. The RealTek 8129 should be supported by the rl(4) driver, and is AFAICT included in the RAMDISK kernel. Not sure why it doesn't attach. If it is easy to hook up QEMU's e1000 hardware emulation to the emulated sparc64 hardware, that should be supported as well on the OpenBSD side. OpenBSD expects the device tree node for the PS/2 keyboard to be named 8042. That's how it is named on the Ultra AXi boards. The NVRAM is supposed to be described by a node named eeprom under ebus. proper emulation of this device will get rid of the unix-gettod:interpret: exception -13 caught interpret h# 01c099fc unix-gettod failed with error ffed WARNING: bad date in battery clock -- CHECK AND RESET THE DATE! spam. Cheers, Mark
Re: sparc64: fledgling QEMU support
On 09/09/14 2:20 PM, Mark Cave-Ayland wrote: Hi all, Following up from my posts at the beginning of the summer, I'm pleased to announce that as of today, qemu-system-sparc64 built from QEMU git master will successfully install OpenBSD from an .iso and boot back into it in serial mode with its default sun4u emulation: $ ./qemu-system-sparc64 -cdrom install55.iso -boot d -nographic OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: ---- Welcome to OpenBIOS v1.1 built on Aug 26 2014 12:48 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 4829 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.3 .. Jumping to entry point 0010 for type 0001... switching to new context: entry point 0x10 stack 0xffe8aa09 OpenBSD BOOT 1.6 Trying bsd... open /pci@1fe,0/pci-ata@5/ide1@2200/cdrom@0:f/etc/random.seed: No such file or directory Booting /pci@1fe,0/pci-ata@5/ide1@2200/cdrom@0:f/bsd 3901336@0x100+6248@0x13b8798+3261984@0x180+932320@0x1b1c620 symbols @ 0xffc5a300 119 start=0x100 Unexpected client interface exception: -1 console is /pci@1fe,0/ebus@3/su Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5 (RAMDISK) #153: Tue Mar 4 15:12:10 MST 2014 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK real mem = 134217728 (128MB) avail mem = 122011648 (116MB) mainbus0 at root: OpenBiosTeam,OpenBIOS cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 100 MHz cpu0: physical 256K instruction (64 b/l), 16K data (32 b/l), 256K external (64 b/l) psycho0 at mainbus0: SUNW,sabre, impl 0, version 0, ign 7c0 psycho0: bus range 0-2, PCI bus 0 psycho0: dvma map c000-dfff pci0 at psycho0 ppb0 at pci0 dev 1 function 0 Sun Simba rev 0x11 pci1 at ppb0 bus 1 ppb1 at pci0 dev 1 function 1 Sun Simba rev 0x11 pci2 at ppb1 bus 2 unknown vendor 0x1234 product 0x (class display subclass VGA, rev 0x00) at pci0 dev 2 function 0 not configured ebus0 at pci0 dev 3 function 0 Sun PCIO EBus2 rev 0x01 fdthree at ebus0 addr 0- not configured com0 at ebus0 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo com0: console kb_ps2 at ebus0 addr 60-67 not configured Realtek 8029 rev 0x00 at pci0 dev 4 function 0 not configured pciide0 at pci0 dev 5 function 0 CMD Technology PCI0646 rev 0x07: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7d4 for native-PCI interrupt pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 2.1. ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 prtc0 at mainbus0 softraid0 at root scsibus1 at softraid0: 256 targets bootpath: /pci@1fe,0/pci-ata@5,0/ide1@2200,0/cdrom@0,0:f root on rd0a swap on rd0b dump on rd0b unix-gettod:interpret: exception -13 caught interpret h# 01c099fc unix-gettod failed with error ffed WARNING: bad date in battery clock -- CHECK AND RESET THE DATE! erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/sparc64 5.5 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? I At any prompt except password prompts you can escape to a shell by typing '!'. Default answers are shown in []'s and are selected by pressing RETURN. You can exit this program at any time by pressing Control-C, but this can leave your system in an inconsistent state. Terminal type? [sun] System hostname? (short form, e.g. 'foo') openbsd Available network interfaces are: vlan0. Which network interface do you wish to configure? (or 'done') [vlan0] done DNS domain name? (e.g. 'bar.com') [my.domain] DNS nameservers? (IP address list or 'none') [none] Password for root account? (will not echo) Password for root account? (again) Start sshd(8) by default? [yes] Start ntpd(8) by default? [no] Do you expect to run the X Window System? [no] Setup a user? (enter a lower-case loginname, or 'no') [no] ... etc. There are still some issues with the device tree to work out; in particular NVRAM and networking (I'd guess that the OpenBSD sparc64 kernel doesn't contain the Realtek device driver so at some point I'll need to create a virtual hme device) but it's good enough to install/boot an OS on different hardware for testing - what could be more fun than that? The Realtek hardware in that dmesg is an NE2000 PCI adapter which the sparc64 kernel config indeed does not have a driver for at the very moment, although it could be added. Having a QEMU driver for the Happy Meal MAC would provide the best level of compatibility with other OS's as that is what comes with a lot of Sun
Re: sparc64: fledgling QEMU support
On Tue, Sep 09, 2014 at 07:20:09PM +0100, Mark Cave-Ayland wrote: Hi all, Following up from my posts at the beginning of the summer, I'm pleased to announce that as of today, qemu-system-sparc64 built from QEMU git master will successfully install OpenBSD from an .iso and boot back into it in serial mode with its default sun4u emulation: $ ./qemu-system-sparc64 -cdrom install55.iso -boot d -nographic OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: ---- Welcome to OpenBIOS v1.1 built on Aug 26 2014 12:48 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 4829 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.3 .. Jumping to entry point 0010 for type 0001... switching to new context: entry point 0x10 stack 0xffe8aa09 OpenBSD BOOT 1.6 Trying bsd... open /pci@1fe,0/pci-ata@5/ide1@2200/cdrom@0:f/etc/random.seed: No such file or directory Booting /pci@1fe,0/pci-ata@5/ide1@2200/cdrom@0:f/bsd 3901336@0x100+6248@0x13b8798+3261984@0x180+932320@0x1b1c620 symbols @ 0xffc5a300 119 start=0x100 Unexpected client interface exception: -1 console is /pci@1fe,0/ebus@3/su Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5 (RAMDISK) #153: Tue Mar 4 15:12:10 MST 2014 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK real mem = 134217728 (128MB) avail mem = 122011648 (116MB) mainbus0 at root: OpenBiosTeam,OpenBIOS cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 100 MHz cpu0: physical 256K instruction (64 b/l), 16K data (32 b/l), 256K external (64 b/l) psycho0 at mainbus0: SUNW,sabre, impl 0, version 0, ign 7c0 psycho0: bus range 0-2, PCI bus 0 psycho0: dvma map c000-dfff pci0 at psycho0 ppb0 at pci0 dev 1 function 0 Sun Simba rev 0x11 pci1 at ppb0 bus 1 ppb1 at pci0 dev 1 function 1 Sun Simba rev 0x11 pci2 at ppb1 bus 2 unknown vendor 0x1234 product 0x (class display subclass VGA, rev 0x00) at pci0 dev 2 function 0 not configured ebus0 at pci0 dev 3 function 0 Sun PCIO EBus2 rev 0x01 fdthree at ebus0 addr 0- not configured com0 at ebus0 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo com0: console kb_ps2 at ebus0 addr 60-67 not configured Realtek 8029 rev 0x00 at pci0 dev 4 function 0 not configured pciide0 at pci0 dev 5 function 0 CMD Technology PCI0646 rev 0x07: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7d4 for native-PCI interrupt pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 2.1. ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 prtc0 at mainbus0 softraid0 at root scsibus1 at softraid0: 256 targets bootpath: /pci@1fe,0/pci-ata@5,0/ide1@2200,0/cdrom@0,0:f root on rd0a swap on rd0b dump on rd0b unix-gettod:interpret: exception -13 caught interpret h# 01c099fc unix-gettod failed with error ffed WARNING: bad date in battery clock -- CHECK AND RESET THE DATE! erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/sparc64 5.5 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? I At any prompt except password prompts you can escape to a shell by typing '!'. Default answers are shown in []'s and are selected by pressing RETURN. You can exit this program at any time by pressing Control-C, but this can leave your system in an inconsistent state. Terminal type? [sun] System hostname? (short form, e.g. 'foo') openbsd Available network interfaces are: vlan0. Which network interface do you wish to configure? (or 'done') [vlan0] done DNS domain name? (e.g. 'bar.com') [my.domain] DNS nameservers? (IP address list or 'none') [none] Password for root account? (will not echo) Password for root account? (again) Start sshd(8) by default? [yes] Start ntpd(8) by default? [no] Do you expect to run the X Window System? [no] Setup a user? (enter a lower-case loginname, or 'no') [no] ... etc. There are still some issues with the device tree to work out; in particular NVRAM and networking (I'd guess that the OpenBSD sparc64 kernel doesn't contain the Realtek device driver so at some point I'll need to create a virtual hme device) but it's good enough to install/boot an OS on different hardware for testing - what could be more fun than that? ATB, Mark. Neat! :-) It seems the GENERIC sparc64 kernel already has PCMCIA/CardBus ne(4), so adding 'ne* at pci?' might just work. OpenBSD/sparc64 already supports sun4v LDOMS, so there's
Re: sparc64: fledgling QEMU support
The RealTek 8129 should be supported by the rl(4) driver, and is AFAICT included in the RAMDISK kernel. Not sure why it doesn't attach. If it is easy to hook up QEMU's e1000 hardware emulation to the emulated sparc64 hardware, that should be supported as well on the OpenBSD side. Nothing a pcidump -vx dump from qemu wouldn't help diagnosing.
Re: sparc64: fledgling QEMU support
On 09/09/14 19:54, Mark Kettenis wrote: Sweet. The RealTek 8129 should be supported by the rl(4) driver, and is AFAICT included in the RAMDISK kernel. Not sure why it doesn't attach. If it is easy to hook up QEMU's e1000 hardware emulation to the emulated sparc64 hardware, that should be supported as well on the OpenBSD side. OpenBSD expects the device tree node for the PS/2 keyboard to be named 8042. That's how it is named on the Ultra AXi boards. Thanks for the information. I've had some interest from the NetBSD folk too and it seems that they don't build 8042 support into their default sparc64 kernel, so it looks like I'd have to switch over to su serial ports instead like the real thing (the QEMU sun4u model is fairly close to an Ultra 5). My aim is to try and provide an environment that mostly just works for as many OSs as possible. The NVRAM is supposed to be described by a node named eeprom under ebus. proper emulation of this device will get rid of the unix-gettod:interpret: exception -13 caught interpret h# 01c099fc unix-gettod failed with error ffed WARNING: bad date in battery clock -- CHECK AND RESET THE DATE! spam. Brilliant - very useful. The one issue I am aware of is that currently the NVRAM chap is wired up as ioport rather than MMIO so that will need to change. I believe Artyom posted some patches for this a year or so ago, however they will likely need a bit of work to get them suitable for upstream QEMU. ATB, Mark.
Re: sparc64: fledgling QEMU support
On 09/09/14 19:57, Brad Smith wrote: The Realtek hardware in that dmesg is an NE2000 PCI adapter which the sparc64 kernel config indeed does not have a driver for at the very moment, although it could be added. Having a QEMU driver for the Happy Meal MAC would provide the best level of compatibility with other OS's as that is what comes with a lot of Sun systems. Agreed. Once I've sorted out the NVRAM issues in theory QEMU should be able to run some older 64-bit Solaris 9-10 kernels, and I suspect I'll need to implement a virtual hme device in order for that to work. It seems like people on this list have quite a bit of SPARC experience, so would it be okay to ask questions about hme drivers on this list? Or would somewhere else be more appropriate? But for OpenBSD and sparc64 there are other options that could be used from QEMU's perspective such as the e1000 [em(4)], i82551 / i82559er [fxp(4)] and rtl8139 [re(4)] drivers that should work well. Interesting. Longer term the aim of the QEMU project is to move the hardwired machine types into pluggable devices, e.g. you can build a whole machine on the command line from multiple -device parameters or preload the default machine types such as sun4u using instructions from a file. So while this is not practical now without source hacks, it is likely to become possible in the future. ATB, Mark.
Re: sparc64: fledgling QEMU support
Interesting. Longer term the aim of the QEMU project is to move the hardwired machine types into pluggable devices, e.g. you can build a whole machine on the command line from multiple -device parameters or preload the default machine types such as sun4u using instructions from a file. So while this is not practical now without source hacks, it is likely to become possible in the future. Do not expect any support for the fanciest device combinations. While most sparc64 systems will probably be able to cope with whatever five-feet sheeps you can build, sparc32 qemu will happily attempt to emulate systems which make no sense, physically, and dismissing reports that BSD does not run on such artificial setups is annoying, to say the least.
Re: sparc64: fledgling QEMU support
On 09/09/14 20:04, Bryan Steele wrote: Neat! :-) It seems the GENERIC sparc64 kernel already has PCMCIA/CardBus ne(4), so adding 'ne* at pci?' might just work. OpenBSD/sparc64 already supports sun4v LDOMS, so there's drivers implementing the virtual protocols (..vnet(4)/vdsk(4)). Does QEMU support this? Could the PCI virtio stuff be adapted to non-x86 architectures? QEMU already has a virtio PCI device that can be plugged into qemu-system-sparc64 (see Artyom's blog at http://tyom.blogspot.co.uk/2013/03/debiansparc64-wheezy-under-qemu-how-to.html for an example of how to do this with Linux). This could be an amusing project; in theory it would be possible to work on an x86 laptop to test/debug big-endian virtio support with the help of QEMU's virtual hardware. You can do this by plugging in a standard virtual cdrom/hd along with an additional virtio hd/nic, booting from the standard devices and then testing the drivers accessing the extra devices as required. I should probably add that there may still be some CPU bugs lying around, and also you'd need a power source since as I don't believe the UIIi processor has any power-saving instructions (or at least QEMU doesn't emulate them) which causes qemu-system-sparc64 to take a lot of CPU... ATB, Mark.
Re: sparc64: fledgling QEMU support
On 09/09/14 21:26, Miod Vallat wrote: Interesting. Longer term the aim of the QEMU project is to move the hardwired machine types into pluggable devices, e.g. you can build a whole machine on the command line from multiple -device parameters or preload the default machine types such as sun4u using instructions from a file. So while this is not practical now without source hacks, it is likely to become possible in the future. Do not expect any support for the fanciest device combinations. While most sparc64 systems will probably be able to cope with whatever five-feet sheeps you can build, sparc32 qemu will happily attempt to emulate systems which make no sense, physically, and dismissing reports that BSD does not run on such artificial setups is annoying, to say the least. Oh sure. It was more to make a point that at some point the QEMU machine will become ultimately more flexible, which I see as something useful for development rather than production use. As I mentioned in one of my earlier emails, my aim is to get the basic sun4u Ultra 5 machine good enough to be able to run the main Linux/*BSD/Solaris OSs out of the box so the final choices of hardware for the virtual device model will be quite limited. ATB, Mark.
Re: sparc64: fledgling QEMU support
On Tuesday 09 September 2014 21:27:37, Mark Cave-Ayland wrote: Could the PCI virtio stuff be adapted to non-x86 architectures? QEMU already has a virtio PCI device that can be plugged into qemu-system-sparc64 (see Artyom's blog at http://tyom.blogspot.co.uk/2013/03/debiansparc64-wheezy-under-qemu-h ow-to.html for an example of how to do this with Linux). This could be an amusing project; in theory it would be possible to work on an x86 laptop to test/debug big-endian virtio support with the help of QEMU's virtual hardware. You can do this by plugging in a standard virtual cdrom/hd along with an additional virtio hd/nic, booting from the standard devices and then testing the drivers accessing the extra devices as required. From the openbsd side, virtio should work with sparc. But since nobody has tested it on big endian so far, there will be bugs. And it needs to be enabled in the config, of course. If you look at generic PCI network adapters, I would recommend trying e1000 if possible. Last time I tried it (on x86), qemu's rtl8139 emulation did not work with openbsd's driver, and I think there were some problems with the ne2k emulation, too. Or maybe ne2k just had terrible performance. Cheers, Stefan
Re: sparc64: fledgling QEMU support
On 2014/09/09 21:18, Mark Cave-Ayland wrote: On 09/09/14 19:57, Brad Smith wrote: The Realtek hardware in that dmesg is an NE2000 PCI adapter which the sparc64 kernel config indeed does not have a driver for at the very moment, although it could be added. Having a QEMU driver for the Happy Meal MAC would provide the best level of compatibility with other OS's as that is what comes with a lot of Sun systems. Agreed. Once I've sorted out the NVRAM issues in theory QEMU should be able to run some older 64-bit Solaris 9-10 kernels, and I suspect I'll need to implement a virtual hme device in order for that to work. In terms of real Solaris, one of the machine types it runs on is the netra x1 which has a Davicom DM9102, which is a dec 21140 tulip clone using the dc(4) driver on OpenBSD. As far as NICs go, this might not be too horrendous to emulate - at least, Microsoft managed to emulate a 21140 in Virtual Server, and numerous NIC vendors made clones of it.
Re: sparc64: fledgling QEMU support
From: Stefan Fritsch s...@sfritsch.de Date: Tue, 09 Sep 2014 22:41:53 +0200 On Tuesday 09 September 2014 21:27:37, Mark Cave-Ayland wrote: Could the PCI virtio stuff be adapted to non-x86 architectures? QEMU already has a virtio PCI device that can be plugged into qemu-system-sparc64 (see Artyom's blog at http://tyom.blogspot.co.uk/2013/03/debiansparc64-wheezy-under-qemu-h ow-to.html for an example of how to do this with Linux). This could be an amusing project; in theory it would be possible to work on an x86 laptop to test/debug big-endian virtio support with the help of QEMU's virtual hardware. You can do this by plugging in a standard virtual cdrom/hd along with an additional virtio hd/nic, booting from the standard devices and then testing the drivers accessing the extra devices as required. From the openbsd side, virtio should work with sparc. But since nobody has tested it on big endian so far, there will be bugs. And it needs to be enabled in the config, of course. If you look at generic PCI network adapters, I would recommend trying e1000 if possible. Last time I tried it (on x86), qemu's rtl8139 emulation did not work with openbsd's driver, and I think there were some problems with the ne2k emulation, too. Or maybe ne2k just had terrible performance. Sounds like faithful emulation to me ;).
Re: sparc64: fledgling QEMU support
On Tue, Sep 09, 2014 at 10:56:59PM +0200, Mark Kettenis wrote: From: Stefan Fritsch s...@sfritsch.de Date: Tue, 09 Sep 2014 22:41:53 +0200 On Tuesday 09 September 2014 21:27:37, Mark Cave-Ayland wrote: Could the PCI virtio stuff be adapted to non-x86 architectures? QEMU already has a virtio PCI device that can be plugged into qemu-system-sparc64 (see Artyom's blog at http://tyom.blogspot.co.uk/2013/03/debiansparc64-wheezy-under-qemu-h ow-to.html for an example of how to do this with Linux). This could be an amusing project; in theory it would be possible to work on an x86 laptop to test/debug big-endian virtio support with the help of QEMU's virtual hardware. You can do this by plugging in a standard virtual cdrom/hd along with an additional virtio hd/nic, booting from the standard devices and then testing the drivers accessing the extra devices as required. From the openbsd side, virtio should work with sparc. But since nobody has tested it on big endian so far, there will be bugs. And it needs to be enabled in the config, of course. If you look at generic PCI network adapters, I would recommend trying e1000 if possible. Last time I tried it (on x86), qemu's rtl8139 emulation did not work with openbsd's driver, and I think there were some problems with the ne2k emulation, too. Or maybe ne2k just had terrible performance. Sounds like faithful emulation to me ;). IIRC there were problems with the rl(4)/re(4) watchdog timer not being implemented in qemu (or implemented in a way that is incompatible with OpenBSD), which caused a stream of watchdog timeouts. I've switched to em(4) since about a year ago so I don't know if this is still a problem. -ml
Re: sparc64: fledgling QEMU support
On 2014/09/09 14:05, Mike Larkin wrote: IIRC there were problems with the rl(4)/re(4) watchdog timer not being implemented in qemu (or implemented in a way that is incompatible with OpenBSD), which caused a stream of watchdog timeouts. I've switched to em(4) since about a year ago so I don't know if this is still a problem. That was re(4), fixed some time ago (I believe it was in this commit http://git.qemu.org/?p=qemu.git;a=commit;h=05447803d034fc634c8372091c031578043dd80d) but it took ages to trickle over to various downstreams/distros.
