Re: [PATCH 0/8] ESCC2

[Artyom Tarasenko <atar4qemu@gmail.com>]

On Wed, Jun 17, 2020 at 10:24 AM Jasper Lowell <jasper.lowell@bt.com> wrote:
>
> I've been working on improving Solaris 10 emulation for the SPARC64
> Sun4u architecture with the goal of a working shell. Currently, Solaris
> 10 boots with a number of errors before displaying the prompt of an
> otherwise unresponsive installer shell. It's been mentioned that this
> problem may not be isolated to Solaris 10 but may affect derivatives of
> OpenSolaris including illumos.
>
> From what I can tell, Solaris 10 never attempts to use the 16550A UART
> for the serial console. The kernel will probe registers to identify the
> device but will not use it for receiving or transmitting. The kernel
> only prints to the console using the prom interface that OpenBIOS
> provides. It's difficult to ascertain what the problem is because there
> is no visibility into the kernel. The 16550A UART on the Ultra 5
> (Darwin), the machine that QEMU Sun4u is modelled against, is used for
> the keyboard/mouse (SuperIO) and is not traditionally used for the
> serial tty. Instead, the SAB 82532 ESCC2 is used to provide ttya and
> ttyb on this system. This patch exists to increment QEMU Sun4u towards
> being hardware faithful.

Nice, thanks for sharing!

> The SAB 82532 ESCC2 is complex because of the jungle of features that it
> provides. Linux and OpenBSD only use a small subset of features
> restricted to the ASYNC serial mode. The ASYNC serial mode is
> relatively simple to implement in isolation. I have made progress on a
> patch series that supports all serial modes, along with transitioning
> between them, but I have decided against submitting it. The serial
> controller appears to multiplex bit positions in registers across serial
> modes while preserving the bits themselves. This means that some 8-bit
> registers need to keep track of more than 8-bits of data and that the
> interpretation of the value the register holds depends on the selected
> serial mode. It's not ideal having a copy of each register for each
> serial mode because some bits are shared across some of the register
> modes. An added difficulty is that the manual doesn't document this
> behaviour well and its unclear what exactly happens when there is a
> transition in the selected serial mode. I've avoided depending on
> registers being uint8_t and have made use of macros so that the backend
> implementation of each register can be changed at a later date when
> supporting other serial modes. If I have the opportunity to test real
> hardware, or it becomes clear that HDLC/SDLC/BISYNC support is needed,
> I'll look at upstreaming the other changes that I have.
>
> I have written a bare-bones patch for OpenBIOS that adds this device to
> the device tree. With that applied, Solaris identifies and attaches the
> device successfully but does not interact with it further - similar to
> the 16550A UART. I did notice, however, that Solaris 10 entered an
> interrupt routine for this device when the network card was being
> configured. I couldn't manage to provoke this behaviour for the 16550A
> so this might be some small success. I strongly suspect that the
> interrupt is a spurious interrupt caused by misconfiguration of the
> devices in the firmware but I have not investigated this further.
>
> Solaris 10, judging from the OpenSolaris source code, determines
> stdin/stdout for the console by examining the stdin/stdout properties
> under /chosen in the device tree. Naturally, this is done with the prom
> interface. From what I can tell, to set these properties to the ESCC2
> node it's necessary to change stdin/stdout for OpenBIOS completely. This
> requires a device driver. I have made some progress on an OpenBIOS
> device driver for the ESCC2 but it's taking longer than expected to
> completely replace the 16550A and it's unlikely that I will have this
> finished soon. It's possible that Solaris 10 emulation for this platform
> will improve once that work is finished but it's unclear.

Actually we may consider adding another sparc64 machine: "ultra5", and
maybe deprecate "sun4u" machine once OpenBIOS supports escc2. (But
maybe keep it as it's as long as it's used by NetBSD regression tests)

> This is my first patch series for QEMU so it's possible that I've made
> mistakes in the contribution process - sorry in advance.

Congratulations on the first patch!  It's a very good start.

> Jasper Lowell (8):
>   hw/char/escc2: Add device
>   hw/char/escc2: Handle interrupt generation
>   hw/char/escc2: Add character device backend
>   hw/char/escc2: Add clock generation
>   hw/char/escc2: Add Receiver Reset (RRES) command
>   hw/char/escc2: Add RFRD command
>   hw/char/escc2: Add Transmit Frame (XF) command
>   hw/char/escc2: Add XRES command
>
>  hw/char/Kconfig         |    8 +
>  hw/char/Makefile.objs   |    1 +
>  hw/char/escc2.c         | 1135 +++++++++++++++++++++++++++++++++++++++
>  hw/char/trace-events    |    6 +
>  include/hw/char/escc2.h |   17 +
>  5 files changed, 1167 insertions(+)
>  create mode 100644 hw/char/escc2.c
>  create mode 100644 include/hw/char/escc2.h
>
> --
> 2.26.2
>


-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu