Re: [PATCH 0/8] ESCC2
On Wed, Jun 17, 2020 at 10:24 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. 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
Re: [PATCH 0/8] ESCC2
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 >
Re: [PATCH 0/8] ESCC2
Patchew URL: https://patchew.org/QEMU/20200617082402.242631-1-jasper.low...@bt.com/ Hi, This series failed the asan build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash export ARCH=x86_64 make docker-image-fedora V=1 NETWORK=1 time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 === TEST SCRIPT END === GEN docs/interop/qemu-qmp-ref.html GEN docs/interop/qemu-qmp-ref.txt GEN docs/interop/qemu-qmp-ref.7 /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) CC qga/commands.o CC qga/guest-agent-command-state.o CC qga/main.o --- AR libvhost-user.a GEN docs/interop/qemu-ga-ref.html GEN docs/interop/qemu-ga-ref.txt /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) GEN docs/interop/qemu-ga-ref.7 LINKqemu-ga LINKqemu-keymap /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) LINKivshmem-client /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) LINKivshmem-server /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) LINKqemu-nbd AS pc-bios/optionrom/multiboot.o /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) AS pc-bios/optionrom/linuxboot.o CC pc-bios/optionrom/linuxboot_dma.o /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) AS pc-bios/optionrom/kvmvapic.o AS pc-bios/optionrom/pvh.o LINKqemu-storage-daemon CC pc-bios/optionrom/pvh_main.o LINKqemu-img /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) BUILD pc-bios/optionrom/multiboot.img /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) BUILD pc-bios/optionrom/linuxboot.img BUILD pc-bios/optionrom/linuxboot_dma.img LINKqemu-io BUILD pc-bios/optionrom/kvmvapic.img BUILD pc-bios/optionrom/multiboot.raw BUILD pc-bios/optionrom/linuxboot.raw /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of ` BUILD pc-bios/optionrom/linuxboot_dma.raw __interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) LINKqemu-edid BUILD pc-bios/optionrom/kvmvapic.raw SIGNpc-bios/optionrom/multiboot.bin SIGNpc-bios/optionrom/linuxboot.bin /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by definition from /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors.cpp.o) SIGNpc-bios/optionrom/linuxboot_dma.bin LINKfsdev/virtfs-proxy-helper SIGNpc-bios/optionrom/kvmvapic.bin LINKscsi/qemu-pr-helper LINKqemu-bridge-helper LINKvirtiofsd /usr/bin/ld: /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a(asan_interceptors_vfork.S.o): warning: common of `__interception::real_vfork' overridden by
[PATCH 0/8] ESCC2
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 -- 2.26.2