<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>
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.
<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
<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
<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
<_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.