<daveshah>
I thought all modules are addressed at once, so there can only be one command/clock delay for all of them?
<dkozel>
0x82000004
<xobs>
That seems super high, and we probably need input from florent on this one.
<dkozel>
0x82000000 is the CSR base
<dkozel>
memory_region,csr,0x82000000,65536,io
<xobs>
Yeah, but on the system I'm testing, it's: `memory_region,csr,0x00000000,131072,io`
<xobs>
And he mentioned that the biggest aperture he's seen is 512 MB, but in order to be at that address it would need a 2 GB aperture.
<dkozel>
right, this seems like a reasonable error then
<dkozel>
I don't see an immediate way to reduce the CSR address or remap the CSR portion to a separate region
<xobs>
And I'm not familiar with this at all, which is why I think florent is the best person to give us input.
<dkozel>
Thanks for adding the code! I'll have a read through to see how you've done it and try some standalone Rust utils
<xobs>
I admit, the bridge innards are pretty hairy, mostly because they support having the connection go away and come back.
<dkozel>
Yep, I'm more than happy to wait. I'm going to get the DMA transfers wrapped into GNU Radio today, don't need the wishbone utils to get going on that
<xobs>
It was designed to debug Fomus over USB where you're resetting the connection a lot. Or via SPI where you're reflashing the board.
<dkozel>
I'm hoping one day to get partial reconfig working so the PCIe portion can be put into some idle state and various DSP components hanging off the wishbone bus can be reconfigured without taking down the system
<xobs>
But overall it works well. And now we have binaries for 16 platforms! :D
<xobs>
Including s390x for some reason...
<dkozel>
very likely because someone could
<xobs>
Might as well, right?
<xobs>
I'll have to get 64-bit wishbone support at some point...
<xobs>
Oh right, that's why I removed 32-bit darwin support. Because it's now a tier 3 in Rust. Because Apple removed 32-bit darwin support.
<dkozel>
look to the future, add 128bit support
<zyp>
xobs, at some point I'd have to ask for your help to look into why litescope doesn't work properly via wishbone-tool (but does via litex_server)
<zyp>
oh, and also, wishbone-tool doesn't seem to want to open my uart at 3Mbaud, litex_server does
<xobs>
zyp: my guess is that it's using "logical" registers. when was the last time you tried?
<tpb>
Title: wishbone-tool: first pass at support for multiword read and write · litex-hub/wishbone-utils@56ed52f · GitHub (at github.com)
<zyp>
I only got into this stuff recently, so my previous build of wishbone-tool was certainly not that old
<xobs>
One big difference is that `wishbone-tool` doesn't have streaming support, it only does single-word operations.
<zyp>
but actually it seems to work now
<xobs>
It may be that litescope requires streamed writes. I haven't looked.
<xobs>
Oh. Well okay then.
<xobs>
I did convert a bunch of `write()` calls into `write_all()` calls, so perhaps that fixed it.
<zyp>
I do believe the only change between the version I ran now and the previous one was the config fix from yesterday, so I'm not sure why it suddenly works now
<xobs>
You can set the environment variable `RUST_LOG=debug` to get more information.
<xobs>
But it looks like it's trying to peek or poke, and the other side isn't responding.
<_florent_>
xobs, dkozel: sorry i was away
<_florent_>
xobs: so from what i undertand, you managed to get wishbone tool working on the setup?
<xobs>
_florent_: that's correct, it was able to read and write memory, and I could run it as a wishbone server instead of running `litex_server`, and the two test scripts could work with it as a drop-in replacement.
<_florent_>
dkozel: so you have to substract 0x82000000 when doing the read/write on the host
<_florent_>
xobs: ok nice!
<_florent_>
xobs: BTW, for the issue you had, one of the DMA register is only 24-bit, i planned to used the scratch register for testing, but it was not present in this design so used this one
<dkozel>
Works!
<xobs>
_florent_: that's fine, I figured it out in the end!
<dkozel>
thanks xobs and _florent_
<zyp>
xobs, actually it seems to be sometimes working, sometimes failing, here's a failed run followed by a succeeding run: https://paste.jvnv.net/view/ncKEl
<xobs>
zyp: do you have something else that's opening that serial port by any chance? maybe your OS is trying to treat it like a modem?
anuejn_ is now known as anuejn
<zyp>
no, I don't, and I haven't had any problems using litex_server with the same setup
m4ssi has joined #litex
<zyp>
is the wishbone serial protocol documented anywhere?
<xobs>
Not that I'm aware of.
<_florent_>
daveshah: indeed, i was wrong in my reasoning for the cmd/clk delay for each module. I'll think about what we could do to improve the write leveling in your case.
<tpb>
Title: ZCU104: get ddram_64 working · Issue #49 · litex-hub/litex-boards · GitHub (at github.com)
<zyp>
xobs, the failing peek is for polling analyzer_storage_done
<zyp>
I started digging into it now, and it can seem like after the peek fails, the client retries, reads a 1 erroneously, and then dumps an empty buffer since the analyzer didn't finish yet
<zyp>
and it also looks like this might actually be a problem with my usb uart
<xobs>
one difference I can think of is that wishbone-tool is faster.
<zyp>
and I have no idea why that packet gets stalled, that shouldn't happen
<xobs>
you can use `-s random-test --random-range [base-of-ram]` to write random values to RAM to test your UART integrity.
<zyp>
no errors for 16000 iterations, but also no usb packets larger than ten bytes
<zyp>
that STALL handshake is a pretty red flag, that shouldn't happen, and I assume it is because it chokes on too much data or something
<zyp>
which it also shouldn't, because it's not too much data
<xobs>
Right, and it's doing a read followed by a write, so nagle won't get involved.
<zyp>
but that'd explain the random behavior, since it depends on how the host are putting stuff into the packets
<xobs>
I have a theory.
<xobs>
Try this.
<xobs>
Actually, hmm... Yes, the problem is probably due to the lack of flow control. I'm not sure what else can be done aside from lowering the timeout so it retries again.
<xobs>
I can force a flush in between, but that will just slow it down.
<xobs>
It will just mask the underlying problem.
<zyp>
I'm looking at the source for the usb-uart now to see if I can spot anything
<zyp>
(I'm using the uart port of a blackmagic probe, because the ftdi adapters I've got got so much latency that dumping the litescope buffer gets super slow)
<tpb>
Title: Travis CI - Test and Deploy with Confidence (at travis-ci.com)
<xobs>
Could people please give v0.6.13 a try? It adds pcie support as well as the high-speed serial fixes for zyp.
spacekookie_ has joined #litex
spacekookie has quit [Ping timeout: 272 seconds]
rohitksingh has quit [Ping timeout: 244 seconds]
spacekookie_ is now known as spacekookie
<scanakci>
What is the minimum frequency that LiteDRAM operates? I am using very recent version of LiteX (20 commits behind) and notice some problems. If I synthesize SoC below 125 MhZ (genesys board), the SoC prints nonsense characters (something is going wrong with UART?) rather than BIOS terminal. With 125MhZ, I actually get the BIOS terminal and type commands. However, memory tests fail for 125MhZ. There are lots of time
<scanakci>
violations and most probably they are the problems. 50 MhZ was working fine before, I am curious if recent version has some limitations/constraints that I am not aware of :).
<daveshah>
It varies, on Artix-7 and ECP5 problems tend to be below 55MHz
<daveshah>
On the ECP5 it seems to vary between batches of FPGA or DRAM....
<zyp>
if you get nonsense characters, it sounds like the baudrate is not calculated correctly
<scanakci>
I actually did not specify baudrate. I will tweak it and see what changes
<daveshah>
are you rebuilding the software after changing frequency?