Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

Just thought I'd chime in with an update.

We are currently emulating a 16550A UART. The guest sees this as the SU
device, referring to the SuperIO port (a pair of 16550A UARTs). On the
Ultra 5, the machine that Sun4u is modelled against, SuperIO was used
for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya default)
and a DB9 (ttyb default) with a SAB82532 ESSC2.

Using tracing, I've looked through how the 16550A UART is touched and
it looks like Solaris 10 has no issues identifying the device. I've
matched register accesses with driver code in OpenSolaris and I'm
pretty sure the device is attached successfully. Also, if you boot
Solaris 10 with debugging output, you can see that the device gets
labelled as su0. The only time Solaris is capable of writing to the
console is when OpenBIOS is used as a proxy.

Rather than Solaris deciding against using SuperIO as a tty, I don't
think there was ever any support for doing so (at least on SPARC
machines). This could be an explanation for why the system appears to
be trucking along just fine despite a seemingly frozen console - there
is no console. I don't think the frozen console is the fault of broken
interrupt routing as the 16550A UART is never programmed to generate
them.

I've started work on emulating the SAB 82532 ESSC2 but it's
unfortunately way more complex than than the 16550A. For instance, it's
possible to configure different baudrates for receiving and
transmitting. QEMU's chardev interface doesn't appear to handle that.
QEMUSerialSetParams has a single speed value that is passed to
cfsetispeed and cfsetospeed. The chip also has support for stick parity
, which aren't valid options right now either. If I'm wrong on either
of those points please correct me. Unless there is an alternative,
changes to the interface may need to be made if adding this device is
to be considered.


Jasper Lowell.


On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote:
> On 05/02/2020 06:31, address@hidden wrote:
> 
> > I'm currently working towards emulating Solaris 10 on sun4u.
> > 
> >  
> > 
> > The Solaris 10 ISO image I am attempting to boot is the one from
> > the Oracle
> > 
> > download page at
> > https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> > 
> > Image: sol-10-u11-ga-sparc-dvd.iso
> > 
> > MD5:   53e8b066f7f250ce2fd2cef063f8072b
> > 
> >  
> > 
> > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> > 
> >  
> > 
> > The command I am using to run QEMU is:
> > 
> > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
> > 
> >  
> > 
> > ```
> > 
> > CPUs: 1 x SUNW,UltraSPARC-IIi
> > 
> > UUID: 00000000-0000-0000-0000-000000000000
> > 
> > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> > 
> >   Type 'help' for detailed information
> > 
> > Trying cdrom:f...
> > 
> > Not a bootable ELF image
> > 
> > Not a bootable a.out image
> > 
> >  
> > 
> > Loading FCode image...
> > 
> > Loaded 7420 bytes
> > 
> > entry point is 0x4000
> > 
> > Evaluating FCode...
> > 
> > Evaluating FCode...
> > 
> > Ignoring failed claim for va 1000000 memsz af6d6!
> > 
> > Ignoring failed claim for va 1402000 memsz 4dcc8!
> > 
> > Ignoring failed claim for va 1800000 memsz 510c8!
> > 
> > SunOS Release 5.10 Version Generic_147147-26 64-bit
> > 
> > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
> > reserved.
> > 
> > could not find debugger-vocabulary-hook>threads:interpret:
> > exception -13 caught
> > 
> > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> > 
> > \ All rights reserved.
> > 
> > \
> > 
> > \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> > 
> >  
> > 
> > hex
> > 
> >  
> > 
> > only forth also definitions
> > 
> > vocabulary kdbg-words
> > 
> > also kdbg-words definitions
> > 
> >  
> > 
> > defer p@
> > 
> > defer p!
> > 
> > ['] x@ is p@
> > 
> > ['] x! is p!
> > 
> >  
> > 
> > 8 constant ptrsize
> > 
> >  
> > 
> > d# 32 constant nbitsminor
> > 
> > h# ffffffff constant maxmin
> > 
> > \
> > 
> > \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> > 
> > \ Use is subject to license terms.
> > 
> > \
> > 
> >  
> > 
> > \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> > 
> >  
> > 
> > h# 7ff constant v9bias
> > 
> > h# unix-tte:interpret: exception -13 caught
> > 
> > interpret ' unix-tte is va>tte-data failed with error
> > ffffffffffffffed
> > 
> > WARNING: consconfig: cannot find driver for screen device /pci@1fe,
> > 0/pci@1,1/QEMU,VGA@2
> > 
> > Configuring devices.
> > 
> > WARNING: Interrupt not seen after set_features
> > 
> > Using RPC Bootparams for network configuration information.
> > 
> > Attempting to configure interface hme0...
> > 
> > WARNING: Power off requested from power button or SC, powering down
> > the system!
> > 
> > Skipped interface hme0
> > 
> > svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount
> > -a failed: one or
> > more file systems failed to mount
> > 
> > Serial console, reverting to text install
> > 
> > Beginning system identification...
> > 
> > Searching for configuration file(s)...
> > 
> > Search complete.
> > 
> > Discovering additional network configuration...
> > 
> > ```
> > 
> >  
> > 
> > The installation menu is shown after but the console is
> > unresponsive.
> > 
> >  
> > 
> > After some debugging, it looks like the QEMU front-end is correctly
> > filling
> > 
> > the serial receive buffer with characters, and then starts dropping
> > them once
> > 
> > the number of characters in the buffer reach the interrupt level.
> > The interrupt
> > 
> > level happens to be 1 when booting Solaris 10. This looks like
> > normal behaviour
> > 
> > to me.
> > 
> >  
> > 
> > I started looking at why the serial receive buffer might not be
> > consumed and
> > 
> > considered that interrupts might not be being raised correctly. I
> > ran with
> > 
> > tracing and there were no interrupts for IRQ 0x2b like there are
> > when using
> > 
> > OpenBSD. When inspecting the registers of the serial device it
> > looks like the
> > 
> > Interrupt Enable Register is set to zero.
> > 
> >  
> > 
> > If Solaris 10 was using the device is polling mode, it should be
> > reading the RBR
> > 
> > or at least the LSR. When tracing serial_ioport_read and
> > serial_ioport_write,
> > 
> > once the menu is hit, I don't see any read or writes to the serial
> > device
> > 
> > registers despite me trying to send characters and use the menu.
> > 
> >  
> > 
> > The driver Solaris 10 is using for the device appears to be
> > similar/same as
> > 
> > /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at
> > https://github.com/nxmirrors/onnv.
> > 
> >  
> > 
> > ```
> > 
> > asy->asy_hwtype = ASY16550AF;
> > 
> > OUTB(FIFOR, 0x00); /* clear fifo register */
> > 
> > asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
> > 
> >  
> > 
> > /* set/Enable FIFO */
> > 
> > OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> > 
> > (asy->asy_trig_level & 0xff));
> > 
> >  
> > 
> > if ((INB(ISR) & 0xc0) == 0xc0)
> > 
> >     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> > 
> > else {
> > 
> >     asy->asy_hwtype = ASY8250;
> > 
> >     OUTB(FIFOR, 0x00); /* NO FIFOs */
> > 
> >     asy->asy_trig_level = 0;
> > 
> > }
> > 
> > ```
> > 
> >  
> > 
> > From what I can tell when tracing serial_ioport_write and
> > serial_ioport_read,
> > 
> > Solaris 10 correctly identifies the serial device and successfully
> > attaches it.
> > 
> > In the asyattach function (OpenSolaris driver), interrupts are
> > disabled by zeroing the
> > 
> > Interrupt Enable Register. From what I'm reading in OpenSolaris
> > source code, interrupts
> > 
> > are reenabled when the device is "opened". This seems like
> > consistent and
> > 
> > correct behaviour though I'm not sure why the device is not being
> > opened to be
> > 
> > used by the serial console.
> > 
> >  
> > 
> > Is this an issue anyone else has tried to debug?
> > 
> > Are there any leads that I can follow up on for why the serial
> > console becomes
> > unresponsive
> > 
> > on Solaris 10?
> 
> It has been a while since I've looked at booting Solaris >= 10 but
> certainly the
> messages above about set_features and the frozen console suggest that
> something is
> going amiss with interrupt routing, although since Linux and NetBSD
> were fine the
> last time I ran my OpenBIOS release tests then Solaris must be doing
> something
> different here.
> 
> Note that the serial interrupts are routed from the ebus into sabre
> so the first
> thing to check would be that the end-to-end routing from device to
> CPU looks correct
> when using Solaris.
> 
> 
> ATB,
> 
> Mark.