jwnrt
commented
9 months ago Here's a minimal-ish repro of a bug with the system loopback that we found during testing:
uart_loopback.c (expand)
```c
// Copyright lowRISC contributors.
// Licensed under the Apache License, Version 2.0, see LICENSE for details.
// SPDX-License-Identifier: Apache-2.0
#include "sw/device/lib/arch/device.h"
#include "sw/device/lib/base/mmio.h"
#include "sw/device/lib/dif/dif_uart.h"
#include "sw/device/lib/runtime/hart.h"
#include "sw/device/lib/testing/test_framework/check.h"
#include "sw/device/lib/testing/test_framework/ottf_main.h"
#include "hw/top_earlgrey/sw/autogen/top_earlgrey.h"
#include "uart_regs.h"
OTTF_DEFINE_TEST_CONFIG();
bool test_main(void) {
dif_uart_t uart;
CHECK_DIF_OK(dif_uart_init(
mmio_region_from_addr(TOP_EARLGREY_UART1_BASE_ADDR), &uart));
CHECK_DIF_OK(dif_uart_configure(
&uart, (dif_uart_config_t){
.baudrate = (uint32_t)kUartBaudrate,
.clk_freq_hz = (uint32_t)kClockFreqPeripheralHz,
.parity_enable = kDifToggleDisabled,
.parity = kDifUartParityEven,
.tx_enable = kDifToggleEnabled,
.rx_enable = kDifToggleEnabled,
}));
// Check the `RXLVL` before the loopback is enabled.
size_t available = 0;
CHECK_DIF_OK(dif_uart_rx_bytes_available(&uart, &available));
LOG_INFO("%d bytes available before setting loopback", available);
// Set the `SLPBK` (System loopback) bit to enabled.
uint32_t reg = mmio_region_read32(uart.base_addr, UART_CTRL_REG_OFFSET);
reg = bitfield_bit32_write(reg, UART_CTRL_SLPBK_BIT, true);
mmio_region_write32(uart.base_addr, UART_CTRL_REG_OFFSET, reg);
// Alternatively:
// CHECK_DIF_OK(
// dif_uart_loopback_set(&uart, kDifUartLoopbackSystem, kDifToggleEnabled));
// Check the `RXLVL` immediately after the loopback is enabled.
CHECK_DIF_OK(dif_uart_rx_bytes_available(&uart, &available));
LOG_INFO("%d bytes available immediately after setting loopback", available);
// Delay by some amount and check the `RXLVL` again.
busy_spin_micros(10);
CHECK_DIF_OK(dif_uart_rx_bytes_available(&uart, &available));
LOG_INFO("%d bytes available some delay after setting loopback", available);
uint8_t byte;
CHECK_DIF_OK(dif_uart_byte_receive_polled(&uart, &byte));
LOG_INFO("byte in fifo: %02x", byte);
return true;
}
```
Running this in the fpga_cw310_sival_rom_ext execution environment reliably triggers the bug. It does not trigger as often (if at all) with the test_rom or with UART0.
Here's the output:
I00001 ottf_main.c:154] Running sw/device/tests/uart_smoketest.c
I00002 uart_smoketest.c:34] 0 bytes available before setting loopback
I00003 uart_smoketest.c:40] 0 bytes available immediately after setting loopback
I00004 uart_smoketest.c:44] 1 bytes available some delay after setting loopback
I00005 uart_smoketest.c:48] byte in fifo: f0
I00006 ottf_main.c:109] Finished sw/device/tests/uart_smoketest.c
I00007 status.c:28] PASS!The code is initializing UART1 and printing the RXLVL register field which starts at 0.
The system loopback is then enabled, and the RXLVL is printed again as still 0.
After some delay, there is suddenly a byte in the FIFO. In this run it was f0 but we've seen 80 and ff too.
The bug can also be triggered by modifying the normal smoketest to use UART1 and running it in the fpga_cw310_sival_rom_ext environment. That test is meant to loop through:
'S', 'm', 'o', 'k', 'e', ' ', 't', 'e', 's', 't', '!'but instead we see:
'M', 0xff, 'm', 'o', 'k', 'e', ' ', 't', 'e', 's', 't', '!'It's as if the S is shifted across by a few bits to make an M and then we get some corrupted 0xff byte afterwards.
rswarbrick
alees24
Test point name
chip_sw_uart_system_loopback
Host side component
Rust
OpenTitanTool infrastructure implemented
Yes
Silicon Validation (SiVal)
Yes
Emulation Targets
Contact person
@rswarbrick
Checklist
Please fill out this checklist as items are completed. Link to PRs and issues as appropriate.