On Thu, May 7, 2020 at 4:29 PM <jasper.low...@bt.com> wrote: > > 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.
At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the 16550A UART. I think there were more such machines. I don't expect there is anything in the Solaris kernel which would prevent any serial device known to it to be used as a tty. > 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. Well, theoretically yes, but practically there is just one baudrate which can be specified in the OBP. I think it's perfectly safe to use max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer. Regards, Artyom > > On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote: > > On 05/02/2020 06:31, jasper.low...@bt.com 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. -- Regards, Artyom Tarasenko SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu