[qemu] SPI console TX indicator host-side pacing

[AlexJones0]

Description

A dependency of #27932. Provisioning flows use the SPI console with a TX-ready GPIO indicator pin, but QEMU will not necessarily handle IO events caused by communication with CharDevs in the expected order, which can lead to unintended SPI transactions.

Specifically, for very short SPI console transactions (<= 4 bytes), the TX ready pin may be asserted, with the host seeing this and then reading out the SPI packet header and payload. With a sufficiently small payload, the host may do all of these SPI reads before QEMU execution is handled back to the vCPU which can poll the CSb status / last read address to determine that it should deassert the GPIO pin (and this signal then needs to be propagated).

As such, for very short reads, the host might finish the SPI console transaction without QEMU ever having time to deassert the GPIO pin, leaving the host to think it can immediately start another transaction (and read out a junk frame). This can cause the CS / last read address to come out of sync, causing the SPI device to get stuck still thinking it is in the middle of a transaction and the host to read out junk frames.

To fix this, in OpenTitanLib we should introduce an optional check for the SPI console where we wait to explicitly see the TX ready inidicator GPIO deassertion after reading the header (before reading the payload), only when running in QEMU execution environments. This will ensure correct pacing even for small SPI transactions and will allow the SPI console to be used with the TX indicator pin in QEMU environments.