ot_uart: Add break interrupt and add opt-in mocking of break oversampling
#212
+102
−22
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AlexJones0
force-pushed
the
uart_break
branch
2 times, most recently
from
30aa1d4 to
3c22ba3
Compare
rivos-eblot
requested changes
Oct 3, 2025
AlexJones0
force-pushed
the
uart_break
branch
2 times, most recently
from
4581889 to
3ca69fd
Compare
jwnrt
reviewed
Oct 3, 2025
rivos-eblot
approved these changes
Oct 3, 2025
rivos-eblot
requested changes
Oct 3, 2025
This commit hooks up the QEMU UART RX break event to the `ot_uart` so that the break receive triggers an interrupt. This completely ignores the configured `CTRL.RXBLVL` as we have no notion for "how long" break is being held for. Breaks can be sent to a given CharDev via the QEMU monitor. With the goal of mocking the UART oversampling `VAL` register enough that it can support differentiation between break conditions and not (essentially treating the UART RX like a GPIO strap), we implement logic for outputting either 0x0 or 0xFFFF depending on whether we are "in a break" or not. That is, the `VAL` register will report 16 samples equivalent to the last UART bit received (which is 0 when in a break, and 1 for a stop bit on any valid transmission). We make the assumption here that break is being "held", rather than just being a transient event. This logic is enabled through an `oversample-break` property to make it an opt-in behaviour. To better support flows that use break as a GPIO signal that can be continually asserted, add an additional property that treats incoming break events as a "toggle", such that one break event will cause the UART to enter break until another event tells it to exit break. This is again an opt-in property intended for testing edge-case software that uses UART Break in this way. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
Separate out the UART documentation from the Earlgrey and Darjeeling machine documentation files into its own seperate documentation file (like the `spi_device.md`) and describe in more detail sending break conditions via the QEMU monitor and using the properties to mock break conditions in the oversampled `VAL` register for SW edge cases. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
rivos-eblot
approved these changes
Oct 3, 2025
jwnrt
approved these changes
Oct 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR hooks up the QEMU UART RX break event to the
ot_uartso that the break receive triggers an interrupt. This completely ignores the configuredCTRL.RXBLVLas we have no notion for "how long" break is being held for. Breaks can be sent to a given CharDev via the QEMU monitor.With the goal of mocking the UART oversampling
VALregister enough that it can support differentiation between break conditions and not (essentially treating the UART RX like a GPIO strap, as Earlgrey's ROM_EXT Rescue 1.0 protocol unfortunately does), we implement logic for outputting either0x0or0xFFFFdepending on whether we are "in a break" or not. That is, theVALregister will report 16 samples equivalent to the last UART bit received (which is 0 when in a break, and 1 for a stop bit on any valid transmission). We make the assumption here that break is being "held", rather than just being a transient event. This logic is enabled through anoversample-breakproperty to make it an opt-in behaviour.To better support the ROM_EXT flows that use break like a strapping, add an additional property that treats incoming break events as a "toggle", such that one break event will cause the UART to enter break until another event tells it to exit break. This is similarly an opt-in property intended for testing edge-case software like ROM_EXT that uses UART Break in this way.