sparc64: fledgling QEMU support

[Mark Cave-Ayland]

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: 00000000-0000-0000-0000-000000000000
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 0000000000100000 for type 0000000000000001...
switching to new context: entry point 0x100000 stack 0x00000000ffe8aa09
>> 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@0x1000000+6248@0x13b8798+3261984@0x1800000+932320@0x1b1c620
symbols @ 0xffc5a300 119 start=0x1000000

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
der...@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 c0000000-dfffffff
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 0x1111 (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-ffffffff 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 ffffffffffffffed
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.

[Mark Kettenis]

> Date: Tue, 09 Sep 2014 19:20:09 +0100
> From: Mark Cave-Ayland <mark.cav...@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 ffffffffffffffed
WARNING: bad date in battery clock -- CHECK AND RESET THE DATE!

spam.

Cheers,

Mark

[Brad Smith]

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

> unix-gettod:interpret: exception -13 caught
> interpret h# 01c099fc unix-gettod failed with error ffffffffffffffed
> 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 systems.

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.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Bryan Steele]

> 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 drivers implementing
the virtual protocols (..vnet(4)/vdsk(4)). Does QEMU support this?

Could the PCI virtio stuff be adapted to non-x86 architectures?

-Bryan.

[Miod Vallat]

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

[Mark Kettenis]

> Date: Tue, 9 Sep 2014 19:07:30 +0000
> From: Miod Vallat <mi...@online.fr>

Ah, but as Brad noticed, it's a 8029 instead of a 8129, which we don't
include in our sparc64 kernels.

[Mark Cave-Ayland]

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

[Mark Cave-Ayland]

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.

[Miod Vallat]

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

[Mark Cave-Ayland]

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.

[Mark Cave-Ayland]

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.

[Stefan Fritsch]

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

[Stuart Henderson]

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.

[Mark Kettenis]

> From: Stefan Fritsch <s...@sfritsch.de>
> Date: Tue, 09 Sep 2014 22:41:53 +0200

Sounds like faithful emulation to me ;).

[Mike Larkin]

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

[Stuart Henderson]

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.

[John Long]

Fantastic! Will be great for quick jobs without banshee fan wail and roasted
office space in the long summers.

Thank you.

/jl