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
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
Patchew URL: https://patchew.org/QEMU/20200617082402.242631-1-jasper.lowell@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
LINK qemu-ga
LINK qemu-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)
LINK ivshmem-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)
LINK ivshmem-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)
LINK qemu-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
LINK qemu-storage-daemon
CC pc-bios/optionrom/pvh_main.o
LINK qemu-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
LINK qemu-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)
LINK qemu-edid
BUILD pc-bios/optionrom/kvmvapic.raw
SIGN pc-bios/optionrom/multiboot.bin
SIGN pc-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)
SIGN pc-bios/optionrom/linuxboot_dma.bin
LINK fsdev/virtfs-proxy-helper
SIGN pc-bios/optionrom/kvmvapic.bin
LINK scsi/qemu-pr-helper
LINK qemu-bridge-helper
LINK virtiofsd
/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)
/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)
/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)
LINK vhost-user-input
BUILD pc-bios/optionrom/pvh.img
BUILD pc-bios/optionrom/pvh.raw
SIGN pc-bios/optionrom/pvh.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)
/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 x86_64-softmmu/hmp-commands.h
GEN x86_64-softmmu/hmp-commands-info.h
GEN x86_64-softmmu/config-devices.h
---
CC x86_64-softmmu/hw/scsi/virtio-scsi.o
CC x86_64-softmmu/hw/scsi/virtio-scsi-dataplane.o
CC x86_64-softmmu/hw/scsi/vhost-scsi-common.o
/tmp/qemu-test/src/migration/ram.c:919:45: error: implicit conversion from 'unsigned long' to 'double' changes value from 18446744073709551615 to 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion]
xbzrle_counters.encoding_rate = UINT64_MAX;
~ ^~~~~~~~~~
/usr/include/stdint.h:130:23: note: expanded from macro 'UINT64_MAX'
---
18446744073709551615UL
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [/tmp/qemu-test/src/rules.mak:69: migration/ram.o] Error 1
make[1]: *** Waiting for unfinished jobs....
/tmp/qemu-test/src/fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven );
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
/tmp/qemu-test/src/fpu/softfloat.c:3423:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
absZ0 &= ~ ( ( (uint64_t) ( absZ1<<1 ) == 0 ) & roundNearestEven );
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
/tmp/qemu-test/src/fpu/softfloat.c:3483:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
absZ0 &= ~(((uint64_t)(absZ1<<1) == 0) & roundNearestEven);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
/tmp/qemu-test/src/fpu/softfloat.c:3606:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
zSig &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven );
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
/tmp/qemu-test/src/fpu/softfloat.c:3760:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
zSig &= ~ ( ( ( roundBits ^ 0x200 ) == 0 ) & roundNearestEven );
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
/tmp/qemu-test/src/fpu/softfloat.c:3987:21: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven );
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
/tmp/qemu-test/src/fpu/softfloat.c:4003:22: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
zSig0 &= ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven );
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
/tmp/qemu-test/src/fpu/softfloat.c:4273:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
zSig1 &= ~ ( ( zSig2 + zSig2 == 0 ) & roundNearestEven );
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!
8 errors generated.
make[1]: *** [/tmp/qemu-test/src/rules.mak:69: fpu/softfloat.o] Error 1
make: *** [Makefile:527: x86_64-softmmu/all] Error 2
Traceback (most recent call last):
File "./tests/docker/docker.py", line 669, in <module>
sys.exit(main())
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=8d05dab6690f47fa9c4a223cb750d7b8', '-u', '1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=x86_64-softmmu', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-ijl9vbi1/src/docker-src.2020-06-17-04.49.55.30222:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-debug']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=8d05dab6690f47fa9c4a223cb750d7b8
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-ijl9vbi1/src'
make: *** [docker-run-test-debug@fedora] Error 2
real 4m7.449s
user 0m8.702s
The full log is available at
http://patchew.org/logs/20200617082402.242631-1-jasper.lowell@bt.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.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
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 >
© 2016 - 2024 Red Hat, Inc.