earlgrey: Intermittent spihost corruption when clkdiv=0

@hcallahan-lowrisc is already working on this.

Since Jul 9, 2026.

The spihost1 peripheral on earlgrey a2 has been observed causing non-deterministic data corruption when there is an RX fifo overrun or a TX fifo underrun.

All testing done with clkdiv=0, QSPI, and fullcyc=1.

### **Scenario 1 (may require 100,000+ tries to reproduce)**

1. Wait for STATUS.READY \== 1 and STATUS.ACTIVE \== 0
2. Write an RXONLY command to the COMMAND register for a length larger than the FIFO size.
3. Wait for the RX FIFO to fill up
4. Drain the RX fifo
5. Observe that an extra repeat byte will appear in the output intermittently.

**Workaround**: Don't create commands that receive more than the FIFO size.

### **Scenario 2 (may require 100,000+ tries to reproduce)**

1. Wait for STATUS.READY \== 1
2. Write an RXONLY command to the COMMAND register with length equal to the FIFO SIZE
3. Drain the RX fifo partially
4. Wait for STATUS.READY \==1, and
5. Write another RXONLY command for the FIFO size.
6. Hiccup while draining the RX FIFO, such that it fills up and the second transfer has to stall waiting for space in the RX FIFO.
7. Observe that an extra repeat byte will appear in the output intermittently.

**Workaround**: Wait for STATUS.ACTIVE \== 0 and drain the FIFO before issuing another command. Unfortunately, this prevents us from getting 100% SPI bus utilization, as transfers can't be pipelined.

### **Scenario 3 (may require 100,000+ tries to reproduce, and can only be reproduced on \*some\* chips)**

1. Wait for STATUS.READY \== 1 and STATUS.ACTIVE \== 0
2. Write a TXONLY command to the COMMAND register (any length)
3. Fill up the TX FIFO with data
4. Wait for STATUS.READY \== 1 and STATUS.ACTIVE \== 0
5. Write an RXONLY command to the COMMAND register with a length shorter than RX FIFO size. (this part might not be necessary, but it is how I am recognizing the symbol slip)
6. Observe that intermittently an extra clock cycle (maybe a glitch?) is inserted on the bus, shifting the data by one symbol.

**Workaround:** Fill the FIFO before issuing the command. Unfortunately, this increases end-to-end latency and prevents us from getting 100% bus utilization.

Perhaps the stall signal has a multi-cycle waiver?