| *** tpb has joined #litex | 00:00 | |
| *** HoloIRCUser has quit IRC | 02:41 | |
| *** scanakci has quit IRC | 02:43 | |
| xobs | dkozel: If you have easy access to that, I could get started shortly. | 02:47 |
|---|---|---|
| xobs | (It would be helpful to have a compiler on the machine as well) | 02:47 |
| xobs | (And, unfortunately, root access) | 02:47 |
| *** gregdavill has quit IRC | 02:51 | |
| *** scanakci has joined #litex | 03:17 | |
| *** CarlFK has quit IRC | 03:48 | |
| *** CarlFK has joined #litex | 03:53 | |
| *** Degi has quit IRC | 03:54 | |
| *** Degi has joined #litex | 03:56 | |
| *** CarlFK has quit IRC | 04:11 | |
| *** CarlFK has joined #litex | 04:58 | |
| *** HoloIRCUser has joined #litex | 06:39 | |
| *** HoloIRCUser1 has joined #litex | 06:40 | |
| *** HoloIRCUser has quit IRC | 06:43 | |
| *** CarlFK has quit IRC | 06:50 | |
| *** HoloIRCUser has joined #litex | 06:57 | |
| *** HoloIRCUser1 has quit IRC | 07:01 | |
| _florent_ | xobs: i prepared the setup, i'm sending you the info to connect to it | 07:07 |
| *** CarlFK has joined #litex | 07:16 | |
| *** CarlFK has quit IRC | 08:10 | |
| *** CarlFK has joined #litex | 08:43 | |
| *** synaption[m] has quit IRC | 08:56 | |
| *** john_k[m] has quit IRC | 08:56 | |
| *** bunnie has quit IRC | 08:56 | |
| *** abeljj[m] has quit IRC | 08:56 | |
| *** disasm[m] has quit IRC | 08:56 | |
| *** david-sawatzke[m has quit IRC | 08:56 | |
| *** sajattack[m] has quit IRC | 08:56 | |
| *** xobs has quit IRC | 08:56 | |
| *** david-sawatzke[m has joined #litex | 09:12 | |
| *** CarlFK has quit IRC | 09:14 | |
| *** CarlFK has joined #litex | 09:24 | |
| *** sajattack[m] has joined #litex | 09:51 | |
| *** john_k[m] has joined #litex | 09:51 | |
| *** xobs has joined #litex | 09:51 | |
| *** synaption[m] has joined #litex | 09:51 | |
| *** abeljj[m] has joined #litex | 09:51 | |
| *** disasm[m] has joined #litex | 09:51 | |
| *** bunnie has joined #litex | 09:51 | |
| dkozel | xobs: I'll test the wishbone tool right now. | 10:14 |
| xobs | dkozel: For some reason, the top few bits don't seem to be set: | 10:15 |
| xobs | sudo ./target/debug/wishbone-tool --pcie-bar /sys/bus/pci/devices/0000\:02\:00.0/resource0 --csr-csv ~/pcie_sdi/csr.csv pcie_dma0_writer_table_value -> 0xx03ffffff (after writing 0xffffffff there) | 10:16 |
| dkozel | permission error without sudo, segfault with. Might be using the wrong pci resource. checking | 10:18 |
| xobs | Oh, it works fine if I put wishbone-tool into server mode and use the litex tests to read and write those regiseters. | 10:22 |
| xobs | Ah, it's because it's a register that spans two physical registers. That's why I wasn't able to properly write it with the command line. | 10:22 |
| xobs | Okay, good. | 10:22 |
| dkozel | I'm using the right pci device | 10:22 |
| dkozel | dmesg: litepcie 0000:03:00.0: enabling device (0000 -> 0002) | 10:22 |
| xobs | what's your command line? | 10:23 |
| dkozel | sudo ./target/debug/wishbone-tool --pcie-bar /sys/bus/pci/devices/0000\:03\:00.0/resource0 --csr-csv ~/src/litepcie_aller_test/soc_pciesoc_aller/csr.csv ctrl_scratch | 10:23 |
| xobs | That should be it, yeah. What address is `ctrl_scratch` according to your csr.csv? | 10:24 |
| daveshah | _florent_: to avoid polluting the issue comments, how would individual delays to the command/clock work for https://github.com/enjoy-digital/litedram/pull/190#issuecomment-621339178 ? | 10:24 |
| tpb | Title: WIP: Implement cmd_latency calibration by jedrzejboczar · Pull Request #190 · enjoy-digital/litedram · GitHub (at github.com) | 10:24 |
| daveshah | I thought all modules are addressed at once, so there can only be one command/clock delay for all of them? | 10:25 |
| dkozel | 0x82000004 | 10:25 |
| xobs | That seems super high, and we probably need input from florent on this one. | 10:26 |
| dkozel | 0x82000000 is the CSR base | 10:26 |
| dkozel | memory_region,csr,0x82000000,65536,io | 10:27 |
| xobs | Yeah, but on the system I'm testing, it's: `memory_region,csr,0x00000000,131072,io` | 10:27 |
| 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. | 10:28 |
| dkozel | right, this seems like a reasonable error then | 10:28 |
| dkozel | I don't see an immediate way to reduce the CSR address or remap the CSR portion to a separate region | 10:31 |
| xobs | And I'm not familiar with this at all, which is why I think florent is the best person to give us input. | 10:32 |
| 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 | 10:32 |
| xobs | I admit, the bridge innards are pretty hairy, mostly because they support having the connection go away and come back. | 10:32 |
| 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 | 10:32 |
| 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. | 10:33 |
| 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 | 10:33 |
| xobs | But overall it works well. And now we have binaries for 16 platforms! :D | 10:34 |
| xobs | Including s390x for some reason... | 10:34 |
| dkozel | very likely because someone could | 10:34 |
| xobs | Might as well, right? | 10:37 |
| xobs | I'll have to get 64-bit wishbone support at some point... | 10:38 |
| 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. | 10:47 |
| dkozel | look to the future, add 128bit support | 10:48 |
| 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) | 10:58 |
| zyp | oh, and also, wishbone-tool doesn't seem to want to open my uart at 3Mbaud, litex_server does | 10:59 |
| xobs | zyp: my guess is that it's using "logical" registers. when was the last time you tried? | 10:59 |
| zyp | a week ago or so | 10:59 |
| xobs | It used to be that it didn't work due to not supporting multi-word reads and writes, but tom keddie added support for that here: https://github.com/litex-hub/wishbone-utils/commit/56ed52ff6fa19dff701690c74921c15dc214fb73 | 11:03 |
| tpb | Title: wishbone-tool: first pass at support for multiword read and write · litex-hub/wishbone-utils@56ed52f · GitHub (at github.com) | 11:03 |
| zyp | I only got into this stuff recently, so my previous build of wishbone-tool was certainly not that old | 11:04 |
| xobs | One big difference is that `wishbone-tool` doesn't have streaming support, it only does single-word operations. | 11:05 |
| zyp | but actually it seems to work now | 11:05 |
| xobs | It may be that litescope requires streamed writes. I haven't looked. | 11:05 |
| xobs | Oh. Well okay then. | 11:05 |
| xobs | I did convert a bunch of `write()` calls into `write_all()` calls, so perhaps that fixed it. | 11:06 |
| 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 | 11:07 |
| xobs | I discovered clippy. | 11:08 |
| xobs | https://github.com/litex-hub/wishbone-utils/commit/49d32ed97652567875eff30c7af5e87a98caaf8c#diff-1d22e5dac94f01fd2bd9fbd0f39fb055R176 is the fix that probably has the most impact. | 11:08 |
| tpb | Title: wishbone-tool: fix most clippy warnings · litex-hub/wishbone-utils@49d32ed · GitHub (at github.com) | 11:08 |
| zyp | hmm, actually now it only works once | 11:09 |
| zyp | https://paste.jvnv.net/view/ISeQo | 11:10 |
| tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 11:10 |
| xobs | You can set the environment variable `RUST_LOG=debug` to get more information. | 11:11 |
| xobs | But it looks like it's trying to peek or poke, and the other side isn't responding. | 11:11 |
| _florent_ | xobs, dkozel: sorry i was away | 11:13 |
| _florent_ | xobs: so from what i undertand, you managed to get wishbone tool working on the setup? | 11:13 |
| 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. | 11:14 |
| _florent_ | dkozel: in your design there is an address translation happening: https://github.com/enjoy-digital/netv2/blob/master/netv2.py#L180 | 11:15 |
| tpb | Title: netv2/netv2.py at master · enjoy-digital/netv2 · GitHub (at github.com) | 11:15 |
| _florent_ | dkozel: so you have to substract 0x82000000 when doing the read/write on the host | 11:16 |
| _florent_ | xobs: ok nice! | 11:16 |
| _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 | 11:17 |
| dkozel | Works! | 11:17 |
| xobs | _florent_: that's fine, I figured it out in the end! | 11:18 |
| dkozel | thanks xobs and _florent_ | 11:18 |
| 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 | 11:25 |
| tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 11:25 |
| 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? | 11:25 |
| *** anuejn_ is now known as anuejn | 11:26 | |
| zyp | no, I don't, and I haven't had any problems using litex_server with the same setup | 11:26 |
| *** m4ssi has joined #litex | 11:30 | |
| zyp | is the wishbone serial protocol documented anywhere? | 11:34 |
| xobs | Not that I'm aware of. | 11:37 |
| _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. | 11:37 |
| xobs | zyp: but the client implementation for litex_server is at https://github.com/enjoy-digital/litex/blob/master/litex/tools/remote/comm_uart.py and my guess is that I'll need to implement multi-word writes in order for it to work reliably. | 11:38 |
| tpb | Title: litex/comm_uart.py at master · enjoy-digital/litex · GitHub (at github.com) | 11:38 |
| xobs | Oh, except now that I look at that, it's actually just doing single-word writes as well. | 11:38 |
| xobs | florent, do you see the link that zyp posted? what is that address it's writing? could that be the device missing a packet? | 11:39 |
| _florent_ | daveshah: the write leveling results are generally more linear (ex: https://github.com/litex-hub/litex-boards/issues/49#issuecomment-604297096), in your case there is a jump between m3 and m4 | 11:39 |
| tpb | Title: ZCU104: get ddram_64 working · Issue #49 · litex-hub/litex-boards · GitHub (at github.com) | 11:39 |
| zyp | xobs, the failing peek is for polling analyzer_storage_done | 11:40 |
| 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 | 11:41 |
| zyp | and it also looks like this might actually be a problem with my usb uart | 11:42 |
| xobs | one difference I can think of is that wishbone-tool is faster. | 11:42 |
| zyp | https://bin.jvnv.net/file/GtKiI.png <- as far as I can tell, these are the pokes happening right before the peek | 11:44 |
| zyp | and I have no idea why that packet gets stalled, that shouldn't happen | 11:44 |
| xobs | you can use `-s random-test --random-range [base-of-ram]` to write random values to RAM to test your UART integrity. | 11:44 |
| zyp | no errors for 16000 iterations, but also no usb packets larger than ten bytes | 11:51 |
| 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 | 11:52 |
| zyp | which it also shouldn't, because it's not too much data | 11:52 |
| xobs | Right, and it's doing a read followed by a write, so nagle won't get involved. | 11:53 |
| zyp | but that'd explain the random behavior, since it depends on how the host are putting stuff into the packets | 11:53 |
| xobs | I have a theory. | 11:54 |
| xobs | Try this. | 11:54 |
| 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. | 11:58 |
| xobs | I can force a flush in between, but that will just slow it down. | 11:58 |
| xobs | It will just mask the underlying problem. | 11:58 |
| zyp | I'm looking at the source for the usb-uart now to see if I can spot anything | 11:59 |
| 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) | 12:01 |
| xobs | You can try this, which will space out the writes and slow it down slightly: https://gist.github.com/xobs/36058c2a3ecc10b55674a2ca028c551b | 12:02 |
| tpb | Title: Add a flush to wishbone-tool uart · GitHub (at gist.github.com) | 12:02 |
| xobs | Actually, I see a flush in the litex code. | 12:03 |
| xobs | So let me commit that. | 12:03 |
| xobs | Can you try the latest wishbone-tool and see if that fixes it for you? | 12:05 |
| *** CarlFK has quit IRC | 12:06 | |
| zyp | sure | 12:06 |
| zyp | I also found that cat /dev/zero > /dev/… produces the same STALL handshakes, so there's an obvious issue with large packets there | 12:07 |
| xobs | https://en.wikipedia.org/wiki/Nagle's_algorithm | 12:08 |
| tpb | Title: Nagle's algorithm - Wikipedia (at en.wikipedia.org) | 12:08 |
| zyp | that seems to be a working workaround | 12:11 |
| zyp | while we're at it, is it possible to get the serial port set to 3Mbaud? currently it's giving the following error: | 12:15 |
| zyp | ERROR [wishbone_tool::bridge::uart] unable to reconfigure serial port Invalid argument -- connection may not work | 12:15 |
| zyp | (litex_server manages to open it in 3Mbaud, so it should be possible) | 12:16 |
| xobs | zyp: you're initializing it with --baud 3000000? | 12:35 |
| zyp | yes | 12:36 |
| xobs | https://github.com/dcuddeback/serial-rs/issues/37 | 12:37 |
| tpb | Title: Higher baud rates for macOS · Issue #37 · dcuddeback/serial-rs · GitHub (at github.com) | 12:37 |
| zyp | ah, right | 12:37 |
| zyp | I second that request then :) | 12:37 |
| zyp | or I could take a look at implementing it myself, it's just that I don't know rust :) | 12:38 |
| xobs | I'm just a bit concerned since there has been no activity since 2018. | 12:39 |
| zyp | oh, right, that was a ticket on the serial lib | 12:39 |
| xobs | I'll look into switching to `serialport-rs`. But I'll need help testing it. | 12:41 |
| xobs | There, can you try that? | 12:54 |
| *** CarlFK has joined #litex | 12:54 | |
| zyp | yeah, sure, I just spent some time digging into the usb-uart, apparently I'm not the first to see the issue (https://github.com/blacksphere/blackmagic/issues/538) | 13:01 |
| tpb | Title: BMP serial interface ignores write (PC->device) bigger 16 byte. · Issue #538 · blacksphere/blackmagic · GitHub (at github.com) | 13:01 |
| zyp | thanks, works fine at 3Mbaud now | 13:08 |
| xobs | Except it broke every other build :P https://travis-ci.com/github/litex-hub/wishbone-utils/builds/162974114 | 13:13 |
| tpb | Title: Travis CI - Test and Deploy with Confidence (at travis-ci.com) | 13:13 |
| zyp | ha | 13:14 |
| xobs | I probably just need to switch to musl everywhere. | 13:22 |
| xobs | There, now everything is green: https://travis-ci.com/github/litex-hub/wishbone-utils/builds/163000017 | 14:07 |
| tpb | Title: Travis CI - Test and Deploy with Confidence (at travis-ci.com) | 14:07 |
| xobs | Could people please give v0.6.13 a try? It adds pcie support as well as the high-speed serial fixes for zyp. | 14:15 |
| *** spacekookie_ has joined #litex | 15:24 | |
| *** spacekookie has quit IRC | 15:27 | |
| *** rohitksingh has quit IRC | 15:50 | |
| *** spacekookie_ is now known as spacekookie | 15:53 | |
| 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 | 17:18 |
| 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 :). | 17:18 |
| daveshah | It varies, on Artix-7 and ECP5 problems tend to be below 55MHz | 17:19 |
| daveshah | On the ECP5 it seems to vary between batches of FPGA or DRAM.... | 17:19 |
| zyp | if you get nonsense characters, it sounds like the baudrate is not calculated correctly | 17:24 |
| scanakci | I actually did not specify baudrate. I will tweak it and see what changes | 17:30 |
| daveshah | are you rebuilding the software after changing frequency? | 17:30 |
| scanakci | yes I am | 17:32 |
| _florent_ | scanakci: are you testing with the default genesys2 target with Vexriscv? (https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/genesys2.py), if not, could you do a test? if it's failing, i could have a look | 18:12 |
| tpb | Title: litex-boards/genesys2.py at master · litex-hub/litex-boards · GitHub (at github.com) | 18:12 |
| *** HoloIRCUser has quit IRC | 18:37 | |
| *** HoloIRCUser has joined #litex | 18:37 | |
| *** lambda has quit IRC | 19:47 | |
| *** lambda has joined #litex | 20:05 | |
| *** m4ssi has quit IRC | 20:36 | |
| *** HoloIRCUser1 has joined #litex | 20:51 | |
| *** HoloIRCUser has quit IRC | 20:51 | |
| *** zyp has quit IRC | 20:53 | |
| *** shuffle2 has quit IRC | 20:53 | |
| *** Finde has quit IRC | 20:53 | |
| *** tnt has quit IRC | 20:53 | |
| *** Xark has quit IRC | 20:53 | |
| *** zyp has joined #litex | 20:53 | |
| *** shuffle2 has joined #litex | 20:53 | |
| *** Xark has joined #litex | 20:53 | |
| *** Finde has joined #litex | 20:54 | |
| *** Xark has quit IRC | 20:54 | |
| *** Xark has joined #litex | 20:54 | |
| *** tnt has joined #litex | 20:58 | |
| *** CarlFK has quit IRC | 21:41 | |
| *** CarlFK has joined #litex | 22:02 | |
| futarisIRCcloud | https://twitter.com/Claude1079/status/1255438834042654726?s=19 | 23:13 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
