Etherbone issues

[redmercury]

I am trying to get etherbone working with my butterstick, but it seems that litex_term and wishbone-tool are both failing to read the uart correctly when using --uart-name=crossover. All that is read is a constant spew of 0xa resulting in pages of newlines. I have verified in wireshark using the etherbone dissector that the port read for the uart_xover_rxempty is returning 0 constantly and that the port read for uart_xover_rxtx is constantly reading 0xa.

When I use uartbone instead of etherbone, the reads are correct and the bios terminal is displayed correctly, so I can discount the crossover uart as being the issue.

I'm pretty new to LiteX so I did some digging in LiteEthEtherboneWishboneMaster and compared it to Stream2Wishbone (for uartbone) and they do seem a little divergent in their manipulation of the wishbone bus, but I'm not yet well educated in LiteX's stream logic or wishbone itself to diagnose what the issue might be - it feels like the bus read should latch the data instead of assuming it is always valid after the wishbone ack, but like I said I'm pretty new to this.

I attempted to use litex_sim with etherbone to narrow things down, but the tap0 device created by sim.py is bound to 192.168.1.100 by default and litex_server fails to sucessfully read the initial packet (error is "assert packet.pr == 1").

Any ideas what might be going on?

Thanks!

[redmercury]

I just tried this with the 2023.12 release and it worked, so it seems to be a recent regression.

[m-byte]

@redmercury I noticed similar behavior. Did you by any chance also try 2024.04? Would be helpful for limiting the search.

Btw: It's not constant 0x0a for me, there are other characters in between from time to time (especially right after start when one would expect the buffer to be full... But most of the time it reads as 0x0a.

[redmercury]

@m-byte I just tried 2024.04 and it worked for me. I can't see a way of bisecting by date with litex_setup.py though :(

[AndrewD]

litex_setup.py just checks out litex and related trees at different points.

So you can use git bisect in the litex directory. Occasionally you need to move other repositories to a different commit to sync with litex dependencies, but these change less frequently.

Additionally anything that touches etherbone is usually mentioned in the commit message.

There was some refactoring to support hybrid etherbone a few months ago: maybe the issue you are having is a side effect of this?

[AndrewD]

If you use litescope: does this also have problems?

[m-byte]

Since uartbone is not affected, I would assume that this is something in liteeth, so I would start looking there. You can use the release tags to limit your search. E.g. run git log 2024.04..HEAD (might have to add ' around 2024.04) inside your liteeth directory.

[m-byte]

@AndrewD I believe hybrid etherbone should have already been part of 2024.04

[m-byte]

@m-byte I just tried 2024.04 and it worked for me. I can't see a way of bisecting by date with litex_setup.py though :(

Reading through the git diff since 2024.04 in liteeth, it seems like the only somewhat relevant things that changed since then would have been the wishbone interface and the mac interface. My understanding is that etherbone is not using the wishbone interface, so unlikely to be the culprit. The MAC interface was seemingly changed to one where RX and TX are split.

Since this starts with the first commit in liteeth since 2024.04, you might want to try the most recent litex with liteeth 2024.04 (git checkout 2024.04) if that breaks things, it's not liteeth. If things still work, try going through the commits returned by git log 2024.04...master. Either go through them one-by-one or do some sort of binary search to speed the process up.

[m-byte]

So it seems like liteeth is not the issue. With everything at master and only litex itself at 2024.04 with 14a6403 and aac828b cherry picked, crossover uart works at expected. Litex at 14a6403 and aac828b, things already don't work. So it must have been some commit in litex between the tag and 14a6403. I'll do some more digging...

[m-byte]

Seems like a47dde6 (or rather af3d2a2 / #1999) is the source of this.

[AndrewD]

class Wishbone2CSR is generating this new re signal, so i guess etherbone is not using this interface?

Edited: i was thinking of a different issue!

[m-byte]

@redmercury Found it, it was a bug in the etherbone code.