*** tpb <[email protected]> has joined #litex | 00:00 | |
*** cr1901 <cr1901!~cr1901@2601:8d:8600:911:cf1:8507:720a:c17> has quit IRC (Remote host closed the connection) | 01:37 | |
*** cr1901 <cr1901!~cr1901@2601:8d:8600:911:cf1:8507:720a:c17> has joined #litex | 01:38 | |
*** linear_cannon <[email protected]> has quit IRC (Read error: Connection reset by peer) | 02:01 | |
*** linear_cannon <[email protected]> has joined #litex | 02:01 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 02:40 | |
*** TMM_ <[email protected]> has joined #litex | 02:40 | |
*** Degi <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 03:01 | |
*** Degi <[email protected]> has joined #litex | 03:02 | |
*** zjason` is now known as zjason | 07:49 | |
*** Prometheus6765 <[email protected]> has joined #litex | 07:59 | |
Prometheus6765 | _florent_ Thank you. I am getting the following error while running https://github.com/sergachev/litex-template/blob/main/src/main.py : | 08:00 |
---|---|---|
Prometheus6765 | subprocess.CalledProcessError: Command '['make', '-C', '/home/karthikeyan/sims/litex-template/src/build/software/firmware', '-f', '/home/karthikeyan/sims/litex-template/src/src/firmware/Makefile']' returned non-zero exit status 2. | 08:00 |
*** FabM <[email protected]> has joined #litex | 08:02 | |
Prometheus6765 | Sorry found out the mistake now I am getting ../include/generated/variables.mak: No such file or directory could somebody help | 08:42 |
ilia__s | it's worth showing a full output of the command you are running; maybe you are missing some basic dependencies | 09:42 |
Prometheus6765 | I am running "python3 main.py" | 10:12 |
ilia__s | it does rely on relative paths (I should fix that it seems), so run as I proposed - python src/main.py from repo root | 11:37 |
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Remote host closed the connection) | 11:45 | |
tnt | Anyone got experience with JTAGBone ? Jut got a Digilent HS-3 instad of my Xilinx Platform cable to try and use it. I have self.add_jtagbone() in the target. And trying litex_server --jtag but that doesn't seem to be enough. | 12:17 |
tnt | Info : TAP xc7.tap does not have valid IDCODE (idcode=0x8e80126) | 12:18 |
tnt | Info : JTAG tap: auto0.tap tap/device found: 0x04740093 (mfg: 0x049 (Xilinx), part: 0x4740, ver: 0x0) | 12:18 |
tnt | Error: xc7.tap: IR capture error; saw 0x23 not 0x01 | 12:18 |
trabucayre | tnt: zynqmp? seems idcode for a device where only PS tap is present | 12:48 |
tnt | trabucayre: yeah, I grabbed https://raw.githubusercontent.com/openocd-org/openocd/master/tcl/target/xilinx_zynqmp.cfg and used that instead of xc7 one now. | 12:50 |
tnt | https://pastebin.com/6T7KunDx | 12:50 |
tpb | Title: (_env) tnt@asuka ~/litex $ litex_server --jtag --jtag-config prog/openocd_zynqmp - Pastebin.com (at pastebin.com) | 12:50 |
tnt | it's better but still not working. Any attempt to read/access anything just times out. | 12:51 |
trabucayre | ok so everything must be correctly configured | 12:54 |
tnt | heh, if it was, it should be working, but it's not :) | 13:08 |
tnt | Ok, so progress ... the xilinx_zynqmp.cfg stupidely used chipname.tap for the CPU ad chipname.ps for the logic ... (which makes no-sense, PS is 'Programmable System', that's the ARM core. PL is the logic ... ). | 13:20 |
tnt | Anyway, I changed it so that chipname.tap is the PL tap and now, I get a response. It's garbage but at least there is a reponse. | 13:21 |
tnt | https://pastebin.com/G3KTXKpE | 13:21 |
tpb | Title: (_env) tnt@asuka ~/litex $ litex_cli --identÿ¿ßï¿ï÷ýþÿßï÷ýþÿ¿ßïûýþ¿ß÷ûýþ¿ß - Pastebin.com (at pastebin.com) | 13:21 |
acathla | Anybody made a module in migen/LiteX to access SPI/QPI pseudo SRAM (Lyontek LY68L6400)? | 13:44 |
acathla | tnt, does that part https://github.com/smunaut/ice40-playground/blob/master/projects/riscv_doom/rtl/top.v#L311-L366 handle access to that chip? | 13:45 |
tnt | acathla: yes | 13:46 |
tnt | (it handles both the flash and the psram since they're on the same spi bus just with different chip selects) | 13:47 |
cr1901 | .oO (I keep thinking... how does tnt do all this cool stuff :D?) | 13:47 |
* tnt hasn't done much recently :( | 13:48 | |
cr1901 | Maybe, but everyone needs a break | 13:48 |
acathla | cr1901, I thought you made some cool stuffs too. It's time sharing of making cool stuffs | 13:51 |
*** linear_cannon <[email protected]> has quit IRC (Read error: Connection reset by peer) | 13:51 | |
acathla | Maybe I'll do cool stuff one day | 13:51 |
*** linearcannon <[email protected]> has joined #litex | 13:51 | |
cr1901 | acathla: I appreciate that. I've just been in a massive rut writing FPGA code for the past several months | 13:53 |
cr1901 | Everything except the absolute basics takes a lot of out of me | 13:54 |
acathla | cr1901, I'm trying to do something usefull with FPGAs for years... | 13:55 |
tnt | didn't you work on xp2 support ? | 13:55 |
*** linearcannon <[email protected]> has quit IRC (Read error: Connection reset by peer) | 13:56 | |
cr1901 | tnt: Yes, and then I took a long break :'D. | 13:58 |
cr1901 | I don't feel good about it. I think doing the xo2 stuff was cool, but I haven't really _utilized_ it yet | 13:58 |
*** linear_cannon <[email protected]> has joined #litex | 13:59 | |
*** linear_cannon <[email protected]> has quit IRC (Read error: Connection reset by peer) | 14:01 | |
*** linear_cannon <[email protected]> has joined #litex | 14:03 | |
*** linear_cannon <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 14:11 | |
*** linear_cannon <[email protected]> has joined #litex | 14:13 | |
trabucayre | tnt: yep you have PL Tap, ARM dap & PS Tap... but PS is not PS :) | 15:07 |
_florent_ | tnt: unfortunately I don't think JTAGBone has yet been tested with on Zynq with the chained ARM/PL taps... | 15:14 |
Prometheus6765 | Thanks ilia__s. I was able to get https://github.com/sergachev/litex-template/blob/main/src/main.py to run but it shows "Memory initialization failed" | 15:21 |
tnt | trabucayre: what do you mean PS is not PS ? | 15:24 |
tnt | _florent_: Mmm, does that change anything, I wold have expected openocd to "abstract" that aways. | 15:24 |
_florent_ | tnt: the LiteX Server / Gateware part will be similar yes, but I'm just not the sure OpenOCD part has been tested with this configuration | 15:29 |
_florent_ | tnt: So the issue will most probably be in the .cfg file or here: https://github.com/enjoy-digital/litex/blob/master/litex/build/openocd.py#L42-L160 | 15:30 |
_florent_ | tnt: and most probably here: https://github.com/enjoy-digital/litex/blob/master/litex/build/openocd.py#L42-L54 or https://github.com/enjoy-digital/litex/blob/master/litex/build/openocd.py#L156 | 15:32 |
trabucayre | PS -> Processing System, and PS tap: a tap in jtag chain used to enable/configure ARM+PL | 15:32 |
tnt | I'm a bit lost why to select between chain 1-4 the irscan is set to '1 + chain' while what I read in the doc indicates it shouldbe 0x20-0x23. | 16:03 |
tnt | (for 7 series) | 16:04 |
trabucayre | zynqmp chain is weird: there is an hidden tap: https://github.com/trabucayre/openFPGALoader/blob/master/src/xilinx.cpp#L103 | 16:07 |
tnt | yeah, I'm looking at it right now. But to know what to change I have to understand the supposedely working code for 7 series. | 16:08 |
tnt | openocd sees the correct idcodes so presumably the opencd config for zynmps properly sets stuff up. | 16:11 |
tnt | but the IR has to be set for USER1-4 differently than on 7 series which is what I'm looking at now. | 16:11 |
tnt | But AFAICT the old code sets IR to 2,3,4,5 for USER1-4 ... but I'd have expected 0x20,0x21,0x22,0x23 respectively. | 16:12 |
trabucayre | I you select second tap (PL) it make sense the rest is the same as others serie7 | 16:15 |
trabucayre | But I have never tried... | 16:15 |
tnt | no, from what I read, you have to treat the PS+PL tap as a single one with IR=12 because you need a specific 12 bit value loaded to go to USER1-4 | 16:19 |
tnt | this is also what the openocd file does, create a single tap with IR len = 12 | 16:19 |
tnt | https://jsteward.moe/images/zujtag-nahitafu.png | 16:20 |
trabucayre | In fact I have introduce a dummy tap with irlen=6. This allows to have same behaviour :) | 16:21 |
tnt | In anycase, none of this explains why litex loads 2-5 in IR instead of 0x20-0x23 for 7 series | 16:22 |
tnt | which is really what's I'm interested in at this point | 16:22 |
trabucayre | yep | 16:22 |
trabucayre | could you provides datasheet ? | 16:24 |
tnt | I read that here : https://jsteward.moe/risc-v-hardware-design-part-b-edgeboard-series.html | 16:25 |
tpb | Title: RISC-V Hardware Design: Debug via BSCAN Chain - Edgeboard RISC-V Series - Pengcheng Xu's Place (at jsteward.moe) | 16:25 |
tnt | Looking at the config guide I found : https://i.imgur.com/klcGxHG.png which is yet another set of values ... | 16:26 |
tnt | Which is a mix of both lol .... 2,3,0x22,0x23 ... | 16:26 |
trabucayre | for artix, kintex I use 2 for USER1 | 16:27 |
trabucayre | big mix :) | 16:27 |
tnt | Ok, gotta go, I'll pick this up later this evening. | 16:28 |
*** ilia__s <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 17:32 | |
acathla | Someone has a simple documentation of what migen.genlib.misc.timeline() do? | 17:40 |
acathla | https://github.com/m-labs/migen/blob/master/migen/genlib/misc.py#L48-L73 | 17:41 |
_florent_ | acathla: This is a simple time/action sequencer, but not sure I would recommend using it that much since not very flexible | 18:10 |
_florent_ | acathla: The HyperRAM core was for example using it, but I had to switch to a proper FSM to allow more flexibility, ex: https://github.com/litex-hub/litehyperbus/commit/02033b1df6ef3518dae0a54a1a196183d9059981 | 18:12 |
acathla | _florent_, ok, thank you. I just wanted to understand already written code | 18:15 |
tnt | Somehwat annoyingly I can't find the equivalent of "7-series configuration guide" for the zyn mpsocs :/ There is one for "Ultrascale" but that doesn't cover the zynq usp. | 18:31 |
cr1901 | _florent_: In the auto_tx_flush code, I feel like I'm missing something | 19:31 |
cr1901 | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L289-L290 On these two lines, you connect the tx_fifo and the PHY to the flushing stream from both ends | 19:32 |
cr1901 | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L295-L297 How are you able to override the control signal connections down here when you connected both ends? | 19:33 |
tnt | trabucayre: btw, just adding {0x04740093, {"xilinx", "zynqmp", "xczu11eg", 6}}, make openfpga loader work with the xczu11eg | 20:10 |
cr1901 | (In addition, valentyusb doesn't have an add_auto_tx_flush) | 20:24 |
tnt | cr1901: what's your target fpga btw ? | 20:25 |
cr1901 | orangecrab | 20:25 |
cr1901 | Or do you mean for the machxo2 work? | 20:25 |
tnt | no, I meant for your questions above. | 20:26 |
cr1901 | orangecrab | 20:26 |
cr1901 | r0.2 | 20:26 |
cr1901 | Basically, my confusion boils down to "I don't know how the LiteX streams work and I often get confused by the terms source and sink because those terms depend on your POV" | 20:27 |
tnt | ah yeah, same here. | 20:28 |
cr1901 | Maybe someone should write a tutorial about how the streams work | 20:29 |
* cr1901 is someone. In theory. | 20:29 | |
_florent_ | cr1901: in the auto_tx_flush I'm probably using the fact that the last assignment done is the one effectively done (similar to this behavior in verilog/vhdl). | 20:57 |
cr1901 | Ahhhh fair. | 20:59 |
_florent_ | otherwise regarding sink/source, in the LiteX codebase, sink/source are always seen from outside the module | 21:00 |
_florent_ | at least that's what I'm trying to do | 21:00 |
cr1901 | Meaning the autoflush is the tx fifo's sink | 21:01 |
cr1901 | and the autoflush is the PHY's source | 21:01 |
_florent_ | but I admit sink/source can then be confusing when describing the internal logic of the module | 21:02 |
cr1901 | Are my above two messages correct? | 21:02 |
_florent_ | the VideoFrameBuffer would make a nice stream tutorial/wiki, I should spent a bit of time writing it | 21:03 |
cr1901 | My understanding is that if you have the autoflusher, even if the PHY is ready, the TX FIFO is throttled by "interval" | 21:05 |
_florent_ | cr1901: I would say, the TX FIFO source is connected to Autoflush sink and Autoflush source connected to PHY source | 21:05 |
_florent_ | TX-FIFO -> Autoflush -> PHY | 21:05 |
cr1901 | Autoflush source connected to PHY source*? | 21:06 |
cr1901 | You mean sink? | 21:06 |
_florent_ | and when Autoflush is active, we accept data from TX-FIFO without retransmitting it to the PHY | 21:06 |
_florent_ | yes sorry, to the UART's source, that is connected externally to the PHY's sink :) | 21:07 |
cr1901 | ack | 21:07 |
cr1901 | Wait... why do you connect a source to a source? | 21:07 |
cr1901 | Yea see, this is why I get confused | 21:09 |
cr1901 | >sink/source are always seen from outside the module | 21:10 |
cr1901 | UART as a source makes sense if you're referring to it as the beginning of another pipeline from inside autoflush | 21:10 |
cr1901 | from inside the autoflush module | 21:10 |
cr1901 | But you just said sink/source are always seen from outside the module | 21:10 |
cr1901 | _florent_: Sorry, this still isn't clear to me | 21:12 |
* tnt still trying to debug JTAGBone | 21:13 | |
tnt | Now I get all 0x00 for some reasons. Thing is if I set a wrong value in IR, it times out. Observing the data at he "CommUART" level, I actually see the right number of bytes in response to commands. | 21:14 |
cr1901 | _florent_: Ignore my above q ("Wait... why do you connect a source to a source?") | 21:19 |
cr1901 | wait, no... don't ignore it. I still don't get it T_T | 21:20 |
* cr1901 wishes he could delete IRC msgs sometimes | 21:20 | |
_florent_ | tnt: from what you describe, it's like the FPGA receive the commands correctly so Host -> FPGA path is working and the FPGA -> Host path is "almost" working: sending the right number of data but stuck at 0... | 21:24 |
_florent_ | tnt: You could confirm this with a UARTBone + LiteScope observing the signals from the JTAG | 21:25 |
tnt | _florent_: huh, no I think the number of bytes on the CommUART must be an artefact just because it expects 4 bytes so it only reeads 4. | 21:25 |
tnt | I just uncommented a bunhc of 'echo' in the openocd script and it prints tons of stuff like https://pastebin.com/L9pmZqQv | 21:26 |
tpb | Title: write overflow10 0x001 10 0x001 10 0x001 10 0x001 10 0x001 10 0x001 10 0x001 1 - Pastebin.com (at pastebin.com) | 21:26 |
_florent_ | tnt: since we were speaking of sink/source, JTAG bone is transmitting valid/ready of of streams on bits 0 and 9: | 21:28 |
_florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/build/openocd.py#L60-L69 | 21:29 |
tnt | yeah looking at that now, but when issuing manual dr scan is almost like DR is not 10 bits. | 21:30 |
tnt | https://pastebin.com/8v0w1SSS | 21:31 |
tpb | Title: > drscan uscale.tap 10 0 -endstate DRPAUSE0001> drscan uscale.tap 10 0 -ends - Pastebin.com (at pastebin.com) | 21:31 |
_florent_ | indeed. I still think it could make sense to have some debug in place in the FPGA on the JTAG PHY | 21:33 |
_florent_ | to split the issue in half | 21:33 |
_florent_ | sorry I have to go | 21:33 |
cr1901 | I feel like we've overloaded poor _florent_ today | 21:34 |
cr1901 | _florent_: My questions can wait/they aren't important | 21:34 |
cr1901 | I just wanted to ask while you were around :D! | 21:34 |
*** Prometheus6765 <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 22:05 | |
tnt | _florent_: actually looking at the logic in JTAGPHY, I don't see how this would work. | 22:33 |
tnt | There will be more SHIFTs than 10 because the total DR length is more than 10. So the "hardcoded" "JTAG Xfer FSM" can't work. | 22:34 |
tnt | (more than 10 because there are other taps on the chain). | 22:34 |
tnt | DR really needs to be implemented as a 10 length shift register that's only loaded/interpreted at the right time rather than relying on counting the shifts. | 22:35 |
*** ilia__s <[email protected]> has joined #litex | 23:19 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!