[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/8] ESCC2
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH 0/8] ESCC2 |
Date: |
Wed, 17 Jun 2020 15:33:57 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
Cc'ing chardev maintainers and Laurent.
On 6/17/20 10:23 AM, Jasper Lowell 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.
>
> 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.
>
> This is my first patch series for QEMU so it's possible that I've made
> mistakes in the contribution process - sorry in advance.
>
> 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
>
- [PATCH 0/8] ESCC2, Jasper Lowell, 2020/06/17
- [PATCH 1/8] hw/char/escc2: Add device, Jasper Lowell, 2020/06/17
- [PATCH 2/8] hw/char/escc2: Handle interrupt generation, Jasper Lowell, 2020/06/17
- [PATCH 3/8] hw/char/escc2: Add character device backend, Jasper Lowell, 2020/06/17
- [PATCH 5/8] hw/char/escc2: Add Receiver Reset (RRES) command, Jasper Lowell, 2020/06/17
- [PATCH 4/8] hw/char/escc2: Add clock generation, Jasper Lowell, 2020/06/17
- [PATCH 6/8] hw/char/escc2: Add RFRD command, Jasper Lowell, 2020/06/17
- [PATCH 7/8] hw/char/escc2: Add Transmit Frame (XF) command, Jasper Lowell, 2020/06/17
- [PATCH 8/8] hw/char/escc2: Add XRES command, Jasper Lowell, 2020/06/17
- Re: [PATCH 0/8] ESCC2, no-reply, 2020/06/17
- Re: [PATCH 0/8] ESCC2,
Philippe Mathieu-Daudé <=
- Re: [PATCH 0/8] ESCC2, Artyom Tarasenko, 2020/06/17