Bus Fault with Xilinx UART Lite #45302
Assignees
Labels
Comments
yashi
added a commit
to yashi/zephyr
that referenced
this issue
May 12, 2022
Xilinx AXI UART Lite v2.0[1] has the following clause for both RX and TX
FIFO respectively:
When a read request is issued to an empty FIFO, a bus error (SLVERR) is
generated and the result is undefined.
When a write request is issued while the FIFO is full, a bus
error (SLVERR) is generated and the data is not written into the FIFO.
To protect this, we have:
xlnx_uartlite_read_status(dev) & STAT_REG_RX_FIFO_VALID_DATA, and
xlnx_uartlite_read_status(dev) & STAT_REG_TX_FIFO_FULL
but these are not enough for multi-threaded apps. Consider two threads
calling poll_out(), it is always possible for a thread to be swapped out
right after reading the status register, the other thread fill the TX FIFO,
and the original thread is swapped back to write more data to the FIFO
because previously read status doesn't indicate the FIFO is full.
To close this race condition, this commit uses a spinlock for each FIFO.
This ensures that only one thread accesses the FIFO even for SMP cases.
This closes zephyrproject-rtos#45302.
[1] https://docs.xilinx.com/v/u/en-US/pg142-axi-uartlite
Signed-off-by: Yasushi SHOJI <[email protected]>
nashif
pushed a commit
that referenced
this issue
May 12, 2022
Xilinx AXI UART Lite v2.0[1] has the following clause for both RX and TX
FIFO respectively:
When a read request is issued to an empty FIFO, a bus error (SLVERR) is
generated and the result is undefined.
When a write request is issued while the FIFO is full, a bus
error (SLVERR) is generated and the data is not written into the FIFO.
To protect this, we have:
xlnx_uartlite_read_status(dev) & STAT_REG_RX_FIFO_VALID_DATA, and
xlnx_uartlite_read_status(dev) & STAT_REG_TX_FIFO_FULL
but these are not enough for multi-threaded apps. Consider two threads
calling poll_out(), it is always possible for a thread to be swapped out
right after reading the status register, the other thread fill the TX FIFO,
and the original thread is swapped back to write more data to the FIFO
because previously read status doesn't indicate the FIFO is full.
To close this race condition, this commit uses a spinlock for each FIFO.
This ensures that only one thread accesses the FIFO even for SMP cases.
This closes #45302.
[1] https://docs.xilinx.com/v/u/en-US/pg142-axi-uartlite
Signed-off-by: Yasushi SHOJI <[email protected]>
laxiLang
pushed a commit
to laxiLang/zephyr
that referenced
this issue
May 30, 2022
Xilinx AXI UART Lite v2.0[1] has the following clause for both RX and TX
FIFO respectively:
When a read request is issued to an empty FIFO, a bus error (SLVERR) is
generated and the result is undefined.
When a write request is issued while the FIFO is full, a bus
error (SLVERR) is generated and the data is not written into the FIFO.
To protect this, we have:
xlnx_uartlite_read_status(dev) & STAT_REG_RX_FIFO_VALID_DATA, and
xlnx_uartlite_read_status(dev) & STAT_REG_TX_FIFO_FULL
but these are not enough for multi-threaded apps. Consider two threads
calling poll_out(), it is always possible for a thread to be swapped out
right after reading the status register, the other thread fill the TX FIFO,
and the original thread is swapped back to write more data to the FIFO
because previously read status doesn't indicate the FIFO is full.
To close this race condition, this commit uses a spinlock for each FIFO.
This ensures that only one thread accesses the FIFO even for SMP cases.
This closes zephyrproject-rtos#45302.
[1] https://docs.xilinx.com/v/u/en-US/pg142-axi-uartlite
Signed-off-by: Yasushi SHOJI <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Xilinx AXI UART Lite v2.0 has the following clause for both RX and TX FIFO (emphasis mine):
To avoid this we have
xlnx_uartlite_read_status(dev) & STAT_REG_RX_FIFO_VALID_DATAandxlnx_uartlite_read_status(dev) & STAT_REG_TX_FIFO_FULLbut this is not enough for multi-threaded app.Consider this:
Two apps might be not enough but the running
samples/philosophersgenerates the error messages below.To Reproduce
rm -rf build && west build -b arty_a7_arm_designstart_m3 zephyr/samples/philosophers -- -DDEBUG_PRINTF=1 -DCONFIG_LOG=ywest flashExpected behavior
samples/philosophersruns without a bus error.Impact
showstopper for apps with high uart usage
Logs and console output
Environment (please complete the following information):
Additional context
It's easier to disable the whole interrupt by
irq_lock() / irq_unlock()while inpoll_outandpoll_in, or more precisely right before callingxlnx_uartlite_read_status()to afterxlnx_uartlite_write_tx_fifo(dev, c);. But that might be too long for the system interrupts to be disabled, especially with a slow baud rate.Should we disable the scheduler instead?
Or does it make sense to do something like:
The text was updated successfully, but these errors were encountered: