One of the things that is different about ot_uart (as compared to the old upstream ibex_uart) is that it does not use a regular clock pulse to check when to transmit from the tx buffer, instead it will just always transmit immediately when the buffer is written.
Alistair reckons that the way ibex_uart does it currently is more accurate to real hardware. This may be true, I'm not sure.
The main concern that Alistair has[1] is that this change might break Tock[2], and so we need a thorough test of a tock app that interacts a lot with the UART before he will accept this change.
For now, I will try to upstream the other UART changes without the clock change, and we can close this issue once we have either:
- tested and upstreamed that change later
- decided that we don't actually need this change, and the clocked version of the UART is acceptable for our needs
[1] https://lists.nongnu.org/archive/html/qemu-riscv/2026-04/msg00522.html
[2] https://tockos.org/
One of the things that is different about ot_uart (as compared to the old upstream ibex_uart) is that it does not use a regular clock pulse to check when to transmit from the tx buffer, instead it will just always transmit immediately when the buffer is written.
Alistair reckons that the way ibex_uart does it currently is more accurate to real hardware. This may be true, I'm not sure.
The main concern that Alistair has[1] is that this change might break Tock[2], and so we need a thorough test of a tock app that interacts a lot with the UART before he will accept this change.
For now, I will try to upstream the other UART changes without the clock change, and we can close this issue once we have either:
[1] https://lists.nongnu.org/archive/html/qemu-riscv/2026-04/msg00522.html
[2] https://tockos.org/