<sajattack[m]>
I guess the litepcie kernel driver for linux-vexriscv would be different than the one for the litex-boards? Because it has more CSRs? Is that my issue?
<sajattack[m]>
and how do I pass the --driver down to litex-boards from way up in linux-vexriscv
<sajattack[m]>
hmm
<sajattack[m]>
how do I turn a csr.csv or csr.json to a csr.h
<sajattack[m]>
ahhh I think I might be onto something
<sajattack[m]>
I think I got it now, but I need a tool to send the linux bitstream over pcie uart
<sajattack[m]>
I don't think litex_term does that yet?
<sajattack[m]>
I wish the litepcie driver made a tty
<sajattack[m]>
or litex_term supported pcie
<sajattack[m]>
brb, rewriting litex_term in rust for litepcie xD
<sajattack[m]>
I already rewrote litepcie_util uart_test, now I just need the actual upload code
<_florent_>
sajattack[m]: LitePCIe hasn't really been tested/integrated with Linux-on-LiteX-VexRiscv so that's indeed possible some adaptations will be required.
<sajattack[m]>
on it boss :P
<_florent_>
To load the Linux images, you could use litex_server in pcie mode and then litex_term in bridge mode
<sajattack[m]>
how hard would it be to ioctl in python?
<sajattack[m]>
ahh
<sajattack[m]>
I tried litex_server in pcie mode and got some errors
<_florent_>
but this could also be interested to use the LitePCIe MMAP interface and just let the CPU directly access the Host's memory to load the binaries
<sajattack[m]>
yeah that would be smarter
<sajattack[m]>
let me try the litex_server again to show you
<tpb>
Title: Issue 40785: `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails with EINVAL); relies on compatibility behavior no longer permitted by [some] Unix OSes - Python tracker (at bugs.python.org)
<sajattack[m]>
aha
<_florent_>
instead of 0, can you try passing a valid length
<sajattack[m]>
what length is it then?
<_florent_>
the size of the BAR0, let me check
<sajattack[m]>
ok so like sys.stat or whatever
<_florent_>
The default side for BAR0 is 1MB in LitePCIe
<_florent_>
I'm still with Python3.6 and it's probably has to be updated for Python 3.7+
<_florent_>
for litex_server over PCIe, maybe first try litex_cli --regs
<_florent_>
also, on the PCIe designs where I'm using LitePCIe, the idea is to reduce BAR0 size and just expose the CSR to it to allow the Host to control the board
<sajattack[m]>
seems the libera bridge is a bit glitchy with long messages
<sajattack[m]>
I was showing a couple lines of the bios output, upload at 6%
yosys-questions has quit [Quit: Client closed]
<sajattack[m]>
the linux image would fit in spi flash if we had a driver for it
<pftbest>
_florent_: Hello. I noticed that etherbone stops working when sys_clk is < 20MHz both on ecp5 and xilinx. Is there some easy way to fix this? Or I should switch to uartbone?
<sajattack[m]>
did it default to 115200 baud maybe?
<sajattack[m]>
that would be silly but I bet that's why it's so slow
<sajattack[m]>
(talking to myself, not pftbest)
<zyp>
pftbest, < 20 MHz or < 31.25 MHz? does it work at e.g. 25 MHz?
<pftbest>
it works at 20, but fails at 10
<pftbest>
I also tried 16 and it didn't work
<pftbest>
Why 31.25? is it some special ratio?
<zyp>
I would guess there's an overrun or underrun somewhere when it becomes too slow to keep up
<zyp>
31.25 is 1Gb/s divided by a 32b wide stream
<pftbest>
As I understand GMII frequency is 125MHz
<pftbest>
BTW the ping works, but connecting from litex_server fails
<zyp>
ping is handled in the 125 MHz domain
<pftbest>
Maybe I can increase some fifo length?
<zyp>
IIRC etherbone got a 32b wide UDP stream heading over into the sys domain
<zyp>
perhaps
<zyp>
or you could put etherbone itself in a faster domain and cdc the memory bus
<pftbest>
zyp: I added it at random and it helped, but I don't understand why :(
<pftbest>
need to undo it and confirm again
<_florent_>
pftbest: with the current architecture, the minimum working freq will be 31.25MHz (125/4). If it works below, it's just luck (or effect of the internal buffering for small packets, but won't work for large packets)
<zyp>
yeah, and the more buffering you add, the larger packets it'll work for
<_florent_>
pftbest: there is no assert in the integration code, but I could eventually add one
<pftbest>
_florent_: ok, I see
<_florent_>
but even with working with increased depth, I would not recommend using this, it will cause you troubles later when you'll have long forget about this :)
<pftbest>
I just need to check some signals using litescope @ 10MHz
<pftbest>
and I don't like uartbone because it's slow
<zyp>
you know you can run litescope slower than the sys domain?
<pftbest>
But it seems there is no way around it
<pftbest>
zyp: I know, but I need sys itself to be slow
<zyp>
in that case I suggest putting etherbone in a faster domain
<pftbest>
zyp: Sorry, I don't know how to put some module in another clock domain. If I knew I wouldn't be running sys at 10MHz
<zyp>
putting a module in another clock domain is the easy part, you just wrap the instance in a ClockDomainsRenamer
<zyp>
the slightly harder part is adding CDC to the signals
<pftbest>
zyp: But what about CSR and Wishbone bus
<pftbest>
As I understand they will not just work as is
pftbest has quit [Remote host closed the connection]
<_florent_>
just create a specific clock_domain for your 10MHz logic and use it for LiteScope
pftbest has joined #litex
<pftbest>
_florent_: in my case changing the clock domain for litescope wont help. I am trying to enable DLL-off mode for DDR3 memory and run it at low frequency.
<pftbest>
I don't know how to move whole litedram to another clock domain, so I'm just trying to run whole "sys" slower, so I can probe the signals
<Melkhior>
Hello; for my design I have a bunch of set_input_delay/set_ouput_delay to deal with the unmatched length of traces on a parallel bus. So far I had hard-coded the path to the XDC file in vivado.py, but now i need some adaptability
<Melkhior>
Is there a way to add some extra constrain file to Litex ? (so XDC for Vivado)
<Melkhior>
Or to specify the input/output delay per-pins ?
<Melkhior>
TIA
<_florent_>
Melkhior: you should be able to pass the extra constraints with platform.add_platform_command("...")
<_florent_>
Otherwise, for your parallel bus, if you want to have the best possible delays, make sure to use IO registers (will automatically be the case with SDRInput/Output)
<Melkhior>
_florent_: I tried duplicating the file line-by-line with add_platform_command, but it complains about my parallel signal with a 'KeyError'
<Melkhior>
File "/home/dolbeau/LITEX/litex/litex/build/generic_platform.py", line 409, in resolve_signals
<Melkhior>
In the XDC, each signal of the group is specified independently (e.g. : et_input_delay -clock SBUS_3V3_CLK -min 0.838 [get_ports {SBUS_3V3_D[1]}] )
<Melkhior>
Not sure if it's related - but the other signals before are fine
<Melkhior>
So I'm guessing the bracket is an issue
<Melkhior>
nothing serious (I can just add a list of extra files in the platform.toolchain and specify that in my platform), just wondering what the 'proper' way was, if any
<Melkhior>
Also trying to make usable by third-parties, so the fewer patches to Litex the better :-)
<Melkhior>
As for the delay, the bus is just 25 MHz (technically, anything between 16.67 and 25), so the Artix-7 has no problem with timings
<Melkhior>
(those timings constraints are probably overkill... didn't know better so I did everything by-the-book ... ISBN 9781461229421 to be accurate ;-) )
<pftbest>
Melkhior: try to escape the braces with the double, for example instead of "{SBUS_3V3_D[1]}" use "{{SBUS_3V3_D[1]}}"
<Melkhior>
already done :-)
<Melkhior>
sorry I copy / pasted from the source file, not the exact line I feed to the tool :-(
<Melkhior>
_florent_: just realized I had a typo, I was only replacing *some* curly braces :-(
<Melkhior>
Trying again
<Melkhior>
Hehe, always ask an expert; with all the curly braces properly duplicated, it seems to work
<sajattack[m]>
Any ideas why my PCIe UART xover serial boot keeps getting stuck at 99%
<Melkhior>
thanks !
<_florent_>
sajattack[m]: is if with litex_term or your own code?
<sajattack[m]>
Any ideas why my PCIe UART xover serial boot keeps getting stuck at 99%
<sajattack[m]>
Oops
<sajattack[m]>
It's with litex_term
<sajattack[m]>
And a modified litex_server using address 0 instead of 0xf0000000
<sajattack[m]>
I also tried wishbone-tool at zyp's suggestion but it didn't work and I found an issue mentioning they don't support the upload protocol yet
<sajattack[m]>
it just sits at 99 until I spam enter about 10 times and then it crc errors
<Melkhior>
<sajattack[m]: congrats! nice to have 1 GiB for Litex :-) Presumably the FPGA is big enough for several cores, to justify the memory :-)
<sajattack[m]>
yes
<Melkhior>
BTW, if you don't have a 'better' way than serial to load the binaries, the 'C' extension will save a lot of space in Buildroot and is fine in VexRiscv
<sajattack[m]>
better to have motivation to develop an improved pcie loader :)
<Melkhior>
(better == microsd for non-memory-based root, == ethernet for memory-based root)
<Melkhior>
hehe, yes PCIe would be 'better'
<sajattack[m]>
well it is pcie at the moment
<sajattack[m]>
it's just slow as balls uart pcie
<sajattack[m]>
rather than dma pcie
<Melkhior>
4 KiB is small though, you can get more than that - I was getting 20+ KiB/s with an old BeagleBone White as the data source
<Melkhior>
Oh, OK, thought it would be a 'regular' uart
<sajattack[m]>
I don't understand the logs very well
<sajattack[m]>
ok I will try 8 core next
<Melkhior>
depends on your use case I guess, I recompiled a bunch of stuff (to test the B and K extension I had added) so more cores were better
<Melkhior>
2 or 4 has been tested a lot ... 8 might be much less charted territory
<sajattack[m]>
I don't really have a use case
<sajattack[m]>
I'm just goofing around
FabM has quit [Quit: Leaving]
yosys-questions has quit [Ping timeout: 256 seconds]
<_florent_>
sajattack[m]: congrats :)
<sajattack[m]>
thanks
<_florent_>
sajattack[m]: the upload is still very slow
<sajattack[m]>
it was all your hard work :P
<sajattack[m]>
yes
<_florent_>
have you finally changed litex_term parameters?
<sajattack[m]>
I changed the sfl_outstanding
<sajattack[m]>
should I change the other one too?
<_florent_>
ok, since you'll have to pay the PCIe latency for each frame, maybe you could to increase it now that you got a first version working
<_florent_>
have you also increased the delay?
<sajattack[m]>
ok
<sajattack[m]>
I haven't yet
<_florent_>
BTW, I want to add an auto-calibration for these parameters but haven't had time yet
<sajattack[m]>
should I increase the payload length too?
<_florent_>
not yet
<sajattack[m]>
1e-4 a good delay?
<_florent_>
you can try it and then increase sfl_outstanding to 2, 4, 8, etc...
<_florent_>
when increasing sfl_outstanding fails, try to increase the delay
<_florent_>
I think you should be able to get almost equivalent speed than with USB FIFOs (400-500KB/s)
<_florent_>
BTW once you have something you are happy with, would you mind filling an issue to summarize the changes you made? This way I'll make sure to address the issues
<sajattack[m]>
sure
<_florent_>
thanks
<sajattack[m]>
any sfl_outstanding greater than 0 causes it to get stuck at 99
<_florent_>
ok, I'll try to do some tests
<sajattack[m]>
my best results are 0-delay, 0-outstanding, 255 payload
<sajattack[m]>
still only 8KB/s though
<sajattack[m]>
I'll try using a non-hipster kernel
<sajattack[m]>
maybe some of my tickless bullshit is breaking it
<jevinskie[m]>
_florent_: Sorry about the noise, I ran the BIST again on the arty to get the logs for you and it passed fine. My brain and workstation were cluttered yesterday trying to clean up my diffs against upstream so I must have mixed something up.
<jevinskie[m]>
I managed to get BIST to pass on the arty at 200 MHz sys_clk for a peppy 1600 MT/s at CL 8 for about 1850 MB/s read!
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Ping timeout: 240 seconds]
yosys-questions has quit [Quit: Client closed]
pftbest has joined #litex
pftbest has quit [Ping timeout: 252 seconds]
pftbest has joined #litex
<_florent_>
jevinskie[m]: nice! So we still have some margin at 800MT/s (which is already > to the specified 667MT/s :) )
lkcl has quit [Quit: BNC by #bnc4you]
bjonnh has joined #litex
<bjonnh>
I'm considering buying a board to start playing with FPGA and DSPs for audio
<bjonnh>
(I want a fully open workflow if possible)
<bjonnh>
or is that overkiil
lkcl has joined #litex
Martoni42 has quit [Ping timeout: 252 seconds]
<jevinskie[m]>
You might want a non-zynq part so you don’t have the additional complexity of the hard processors
<sajattack[m]>
<jevinskie[m]> "sajattack: do you happen to be..." <- nope, I'm using acorn_cle_215
<bjonnh>
can't you just ignoret he arm part?
yosys-questions has joined #litex
<jevinskie[m]>
bjonnh: I’m not familiar with Xilinx personally but read that you have to boot the arm to load the PL bitstream (while altera SoCs can be configured to boot only the fpga side)
peepsalot has quit [Read error: Connection reset by peer]
<sajattack[m]>
I made an 8 core rv32gc with 8 fpus and when I try to lxterm into it my pc reboots 😂
<sajattack[m]>
oh I also gave it l2 cache
<sajattack[m]>
but I don't think that matters
<sajattack[m]>
I think maybe it was just a bad flash
peepsalot has joined #litex
<sajattack[m]>
Hmm, reflashed, still not happy
<sajattack[m]>
Maybe I'll go down to 4 fpus
<jevinskie[m]>
Need a pcie firewall :P
<tpw_rules>
i have not ben having much luck with cle-215
<tpw_rules>
it's inconsistent and unstable
<tpw_rules>
no pcie weirdness, but it only works on some syntheses