On Wed, Jun 17, 2020 at 10:24 AM Jasper Lowell <jasper.low...@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
