[PATCH for-6.2 0/2] escc: fixes for STATUS_TXEMPTY and SPEC_ALLSENT

[PATCH for-6.2 0/2] escc: fixes for STATUS_TXEMPTY and SPEC_ALLSENT

[Mark Cave-Ayland]

This is another attempt to fix booting 32-bit QEMU SPARC machines in
qemu-system-sparc using a real Sun PROM based upon further experiments and
re-reading of the ESCC datasheet from a previous patch posted at
https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg00324.html.

It appears that both the Sun PROM and OpenBSD with OpenBIOS fail to send an
explicit reset command as recommended in the ESCC datasheet, which causes
hangs during serial port enumeration since the introduction of the recent
ESCC reset changes.

The first patch always sets STATUS_TXEMPTY in R_STATUS on hardware reset
which wasn't documented in the "Reset" section(s) but is documented in the
"Transmit Interrupts and Transmit Buffer Empty Bit" section, whilst the
second patch updates SPEC_ALLSENT when writing to W_TXCTRL1.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>


Mark Cave-Ayland (2):
  escc: always set STATUS_TXEMPTY in R_STATUS on device reset
  escc: update the R_SPEC register SPEC_ALLSENT bit when writing to
    W_TXCTRL1

 hw/char/escc.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

-- 
2.20.1

[PATCH for-6.2 1/2] escc: always set STATUS_TXEMPTY in R_STATUS on device reset

[Mark Cave-Ayland]

The "Transmit Interrupts and Transmit Buffer Empty Bit" section of the ESCC
datasheet states the following about the STATUS_TXEMPTY bit: "After a hardware
reset (including a hardware reset by software), or a channel reset, this bit
is set to 1".

Update escc_reset() to set the STATUS_TXEMPTY bit in the R_STATUS register
on device reset as described which fixes a regression whereby the Sun PROM
checks this bit early on startup and gets stuck in an infinite loop if it is
not set.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
---
 hw/char/escc.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/hw/char/escc.c b/hw/char/escc.c
index 0fce4f6324..a7d9050c83 100644
--- a/hw/char/escc.c
+++ b/hw/char/escc.c
@@ -354,6 +354,17 @@ static void escc_reset(DeviceState *d)
             cs->rregs[j] = 0;
             cs->wregs[j] = 0;
         }
+
+        /*
+         * ...but there is an exception. The "Transmit Interrupts and Transmit
+         * Buffer Empty Bit" section on page 50 of the ESCC datasheet says of
+         * the STATUS_TXEMPTY bit in R_STATUS: "After a hardware reset
+         * (including a hardware reset by software), or a channel reset, this
+         * bit is set to 1". The Sun PROM checks this bit early on startup and
+         * gets stuck in an infinite loop if it is not set.
+         */
+        cs->rregs[R_STATUS] |= STATUS_TXEMPTY;
+
         escc_reset_chn(cs);
     }
 }
-- 
2.20.1

[PATCH for-6.2 2/2] escc: update the R_SPEC register SPEC_ALLSENT bit when writing to W_TXCTRL1

[Mark Cave-Ayland]

The ESCC datasheet states that SPEC_ALLSENT is always set in sync mode and set
in async mode once all characters have cleared the transmitter. Since writes to
SERIAL_DATA use a synchronous chardev API, the guest can never see the state when
transmission is in progress so it is possible to set SPEC_ALLSENT in the
R_SPEC register unconditionally.

This fixes a hang when using the Sun PROM as it attempts to enumerate the
onboard serial devices, and a similar hang in OpenBSD SPARC32 where in both cases
the boot process will not proceed until SPEC_ALLSENT has been set after writing
to W_TXCTRL1.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
---
 hw/char/escc.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/hw/char/escc.c b/hw/char/escc.c
index a7d9050c83..8755d8d34f 100644
--- a/hw/char/escc.c
+++ b/hw/char/escc.c
@@ -586,6 +586,20 @@ static void escc_mem_write(void *opaque, hwaddr addr,
             s->wregs[s->reg] = val;
             break;
         case W_TXCTRL1:
+            s->wregs[s->reg] = val;
+            /*
+             * The ESCC datasheet states that SPEC_ALLSENT is always set in
+             * sync mode, and set in async mode when all characters have
+             * cleared the transmitter. Since writes to SERIAL_DATA use the
+             * blocking qemu_chr_fe_write_all() function to write each
+             * character, the guest can never see the state when async data
+             * is in the process of being transmitted so we can set this bit
+             * unconditionally regardless of the state of the W_TXCTRL1 mode
+             * bits.
+             */
+            s->rregs[R_SPEC] |= SPEC_ALLSENT;
+            escc_update_parameters(s);
+            break;
         case W_TXCTRL2:
             s->wregs[s->reg] = val;
             escc_update_parameters(s);
-- 
2.20.1

Re: [PATCH for-6.2 2/2] escc: update the R_SPEC register SPEC_ALLSENT bit when writing to W_TXCTRL1

[Philippe Mathieu-Daudé]

On 11/18/21 19:18, Mark Cave-Ayland wrote:
> The ESCC datasheet states that SPEC_ALLSENT is always set in sync mode and set
> in async mode once all characters have cleared the transmitter. Since writes to
> SERIAL_DATA use a synchronous chardev API, the guest can never see the state when
> transmission is in progress so it is possible to set SPEC_ALLSENT in the
> R_SPEC register unconditionally.
> 
> This fixes a hang when using the Sun PROM as it attempts to enumerate the
> onboard serial devices, and a similar hang in OpenBSD SPARC32 where in both cases
> the boot process will not proceed until SPEC_ALLSENT has been set after writing
> to W_TXCTRL1.
> 
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> ---
>  hw/char/escc.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Re: [PATCH for-6.2 0/2] escc: fixes for STATUS_TXEMPTY and SPEC_ALLSENT

[Peter Maydell]

On Thu, 18 Nov 2021 at 18:18, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
>
> This is another attempt to fix booting 32-bit QEMU SPARC machines in
> qemu-system-sparc using a real Sun PROM based upon further experiments and
> re-reading of the ESCC datasheet from a previous patch posted at
> https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg00324.html.
>
> It appears that both the Sun PROM and OpenBSD with OpenBIOS fail to send an
> explicit reset command as recommended in the ESCC datasheet, which causes
> hangs during serial port enumeration since the introduction of the recent
> ESCC reset changes.
>
> The first patch always sets STATUS_TXEMPTY in R_STATUS on hardware reset
> which wasn't documented in the "Reset" section(s) but is documented in the
> "Transmit Interrupts and Transmit Buffer Empty Bit" section, whilst the
> second patch updates SPEC_ALLSENT when writing to W_TXCTRL1.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

Series
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Re: [PATCH for-6.2 0/2] escc: fixes for STATUS_TXEMPTY and SPEC_ALLSENT

[Mark Cave-Ayland]

On 18/11/2021 18:23, Peter Maydell wrote:

> On Thu, 18 Nov 2021 at 18:18, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>>
>> This is another attempt to fix booting 32-bit QEMU SPARC machines in
>> qemu-system-sparc using a real Sun PROM based upon further experiments and
>> re-reading of the ESCC datasheet from a previous patch posted at
>> https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg00324.html.
>>
>> It appears that both the Sun PROM and OpenBSD with OpenBIOS fail to send an
>> explicit reset command as recommended in the ESCC datasheet, which causes
>> hangs during serial port enumeration since the introduction of the recent
>> ESCC reset changes.
>>
>> The first patch always sets STATUS_TXEMPTY in R_STATUS on hardware reset
>> which wasn't documented in the "Reset" section(s) but is documented in the
>> "Transmit Interrupts and Transmit Buffer Empty Bit" section, whilst the
>> second patch updates SPEC_ALLSENT when writing to W_TXCTRL1.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> 
> Series
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

Thanks Peter. I've added this to my qemu-sparc queue and will send a PR shortly with 
both yours and Philippe's R-B tags.


ATB,

Mark.