_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
bjonnh has joined #litex
bjonnh has quit [Changing host]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
linear_cannon has quit [Read error: Connection reset by peer]
linear_cannon has joined #litex
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #litex
zjason` is now known as zjason
Prometheus6765 has joined #litex
<Prometheus6765> _florent_ Thank you. I am getting the following error while running https://github.com/sergachev/litex-template/blob/main/src/main.py :
<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.
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
<Prometheus6765> Sorry found out the mistake now I am getting ../include/generated/variables.mak: No such file or directory could somebody help
<ilia__s> it's worth showing a full output of the command you are running; maybe you are missing some basic dependencies
<Prometheus6765> I am running "python3 main.py"
<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
FabM has quit [Remote host closed the connection]
<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.
<tnt> Info : TAP xc7.tap does not have valid IDCODE (idcode=0x8e80126)
<tnt> Info : JTAG tap: auto0.tap tap/device found: 0x04740093 (mfg: 0x049 (Xilinx), part: 0x4740, ver: 0x0)
<tnt> Error: xc7.tap: IR capture error; saw 0x23 not 0x01
<trabucayre> tnt: zynqmp? seems idcode for a device where only PS tap is present
<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.
<tpb> Title: (_env) tnt@asuka ~/litex $ litex_server --jtag --jtag-config prog/openocd_zynqmp - Pastebin.com (at pastebin.com)
<tnt> it's better but still not working. Any attempt to read/access anything just times out.
<trabucayre> ok so everything must be correctly configured
<tnt> heh, if it was, it should be working, but it's not :)
<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 ... ).
<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.
<tpb> Title: (_env) tnt@asuka ~/litex $ litex_cli --identÿ¿ßï¿ï÷ýþÿßï÷ýþÿ¿ßïûýþ¿ß÷ûýþ¿ß - Pastebin.com (at pastebin.com)
<acathla> Anybody made a module in migen/LiteX to access SPI/QPI pseudo SRAM (Lyontek LY68L6400)?
<tnt> acathla: yes
<tnt> (it handles both the flash and the psram since they're on the same spi bus just with different chip selects)
<cr1901> .oO (I keep thinking... how does tnt do all this cool stuff :D?)
* tnt hasn't done much recently :(
<cr1901> Maybe, but everyone needs a break
<acathla> cr1901, I thought you made some cool stuffs too. It's time sharing of making cool stuffs
linear_cannon has quit [Read error: Connection reset by peer]
<acathla> Maybe I'll do cool stuff one day
linearcannon has joined #litex
<cr1901> acathla: I appreciate that. I've just been in a massive rut writing FPGA code for the past several months
<cr1901> Everything except the absolute basics takes a lot of out of me
<acathla> cr1901, I'm trying to do something usefull with FPGAs for years...
<tnt> didn't you work on xp2 support ?
linearcannon has quit [Read error: Connection reset by peer]
<cr1901> tnt: Yes, and then I took a long break :'D.
<cr1901> I don't feel good about it. I think doing the xo2 stuff was cool, but I haven't really _utilized_ it yet
linear_cannon has joined #litex
linear_cannon has quit [Read error: Connection reset by peer]
linear_cannon has joined #litex
linear_cannon has quit [Ping timeout: 250 seconds]
linear_cannon has joined #litex
<trabucayre> tnt: yep you have PL Tap, ARM dap & PS Tap... but PS is not PS :)
<_florent_> tnt: unfortunately I don't think JTAGBone has yet been tested with on Zynq with the chained ARM/PL taps...
<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"
<tnt> trabucayre: what do you mean PS is not PS ?
<tnt> _florent_: Mmm, does that change anything, I wold have expected openocd to "abstract" that aways.
<_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
<_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
<trabucayre> PS -> Processing System, and PS tap: a tap in jtag chain used to enable/configure ARM+PL
<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.
<tnt> (for 7 series)
<trabucayre> zynqmp chain is weird: there is an hidden tap: https://github.com/trabucayre/openFPGALoader/blob/master/src/xilinx.cpp#L103
<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.
<tnt> openocd sees the correct idcodes so presumably the opencd config for zynmps properly sets stuff up.
<tnt> but the IR has to be set for USER1-4 differently than on 7 series which is what I'm looking at now.
<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.
<trabucayre> I you select second tap (PL) it make sense the rest is the same as others serie7
<trabucayre> But I have never tried...
<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
<tnt> this is also what the openocd file does, create a single tap with IR len = 12
<trabucayre> In fact I have introduce a dummy tap with irlen=6. This allows to have same behaviour :)
<tnt> In anycase, none of this explains why litex loads 2-5 in IR instead of 0x20-0x23 for 7 series
<tnt> which is really what's I'm interested in at this point
<trabucayre> yep
<trabucayre> could you provides datasheet ?
<tpb> Title: RISC-V Hardware Design: Debug via BSCAN Chain - Edgeboard RISC-V Series - Pengcheng Xu's Place (at jsteward.moe)
<tnt> Looking at the config guide I found : https://i.imgur.com/klcGxHG.png which is yet another set of values ...
<tnt> Which is a mix of both lol .... 2,3,0x22,0x23 ...
<trabucayre> for artix, kintex I use 2 for USER1
<trabucayre> big mix :)
<tnt> Ok, gotta go, I'll pick this up later this evening.
ilia__s has quit [Ping timeout: 240 seconds]
<acathla> Someone has a simple documentation of what migen.genlib.misc.timeline() do?
<_florent_> acathla: This is a simple time/action sequencer, but not sure I would recommend using it that much since not very flexible
<_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
<acathla> _florent_, ok, thank you. I just wanted to understand already written code
<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.
<cr1901> _florent_: In the auto_tx_flush code, I feel like I'm missing something
<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
<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?
<tnt> trabucayre: btw, just adding {0x04740093, {"xilinx", "zynqmp", "xczu11eg", 6}}, make openfpga loader work with the xczu11eg
<cr1901> (In addition, valentyusb doesn't have an add_auto_tx_flush)
<tnt> cr1901: what's your target fpga btw ?
<cr1901> orangecrab
<cr1901> Or do you mean for the machxo2 work?
<tnt> no, I meant for your questions above.
<cr1901> orangecrab
<cr1901> r0.2
<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"
<tnt> ah yeah, same here.
<cr1901> Maybe someone should write a tutorial about how the streams work
* cr1901 is someone. In theory.
<_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).
<cr1901> Ahhhh fair.
<_florent_> otherwise regarding sink/source, in the LiteX codebase, sink/source are always seen from outside the module
<_florent_> at least that's what I'm trying to do
<cr1901> Meaning the autoflush is the tx fifo's sink
<cr1901> and the autoflush is the PHY's source
<_florent_> but I admit sink/source can then be confusing when describing the internal logic of the module
<cr1901> Are my above two messages correct?
<_florent_> the VideoFrameBuffer would make a nice stream tutorial/wiki, I should spent a bit of time writing it
<cr1901> My understanding is that if you have the autoflusher, even if the PHY is ready, the TX FIFO is throttled by "interval"
<_florent_> cr1901: I would say, the TX FIFO source is connected to Autoflush sink and Autoflush source connected to PHY source
<_florent_> TX-FIFO -> Autoflush -> PHY
<cr1901> Autoflush source connected to PHY source*?
<cr1901> You mean sink?
<_florent_> and when Autoflush is active, we accept data from TX-FIFO without retransmitting it to the PHY
<_florent_> yes sorry, to the UART's source, that is connected externally to the PHY's sink :)
<cr1901> ack
<cr1901> Wait... why do you connect a source to a source?
<cr1901> Yea see, this is why I get confused
<cr1901> >sink/source are always seen from outside the module
<cr1901> UART as a source makes sense if you're referring to it as the beginning of another pipeline from inside autoflush
<cr1901> from inside the autoflush module
<cr1901> But you just said sink/source are always seen from outside the module
<cr1901> _florent_: Sorry, this still isn't clear to me
* tnt still trying to debug JTAGBone
<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.
<cr1901> _florent_: Ignore my above q ("Wait... why do you connect a source to a source?")
<cr1901> wait, no... don't ignore it. I still don't get it T_T
* cr1901 wishes he could delete IRC msgs sometimes
<_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...
<_florent_> tnt: You could confirm this with a UARTBone + LiteScope observing the signals from the JTAG
<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.
<tnt> I just uncommented a bunhc of 'echo' in the openocd script and it prints tons of stuff like https://pastebin.com/L9pmZqQv
<tpb> Title: write overflow10 0x001 10 0x001 10 0x001 10 0x001 10 0x001 10 0x001 10 0x001 1 - Pastebin.com (at pastebin.com)
<_florent_> tnt: since we were speaking of sink/source, JTAG bone is transmitting valid/ready of of streams on bits 0 and 9:
<tnt> yeah looking at that now, but when issuing manual dr scan is almost like DR is not 10 bits.
<tpb> Title: > drscan uscale.tap 10 0 -endstate DRPAUSE0001> drscan uscale.tap 10 0 -ends - Pastebin.com (at pastebin.com)
<_florent_> indeed. I still think it could make sense to have some debug in place in the FPGA on the JTAG PHY
<_florent_> to split the issue in half
<_florent_> sorry I have to go
<cr1901> I feel like we've overloaded poor _florent_ today
<cr1901> _florent_: My questions can wait/they aren't important
<cr1901> I just wanted to ask while you were around :D!
Prometheus6765 has quit [Quit: Connection closed for inactivity]
<tnt> _florent_: actually looking at the logic in JTAGPHY, I don't see how this would work.
<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.
<tnt> (more than 10 because there are other taps on the chain).
<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.
ilia__s has joined #litex