futarisIRCcloud has quit [Quit: Connection closed for inactivity]
CarlFK has joined #litex
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #litex
<john_k[m]>
_florent_: I've got my CLE-215 setup and ready to flash but I'm trying to figure out the correct pinout for my FTDI 232 cable - can you point me in the right direction?
<john_k[m]>
ah, I had it right the first time - it just read garbage for the ID code in that one instance
nrossi has quit [Ping timeout: 260 seconds]
nrossi has joined #litex
sajattack[m] has quit [Ping timeout: 260 seconds]
sajattack[m] has joined #litex
<_florent_>
somlo: thanks the the PR, strange this was not happening on my side, probably related to a different GCC.
<_florent_>
benh: somlo made a batch of Trellisboards and i got mine from him, maybe he has an unused one to sell
<_florent_>
benh: otherwise, the Versa ECP5 5G is also a nice board, the FPGA is smaller (45F), but you have DDR3/Ethernet which is nice for Microwatt/Linux dev
<benh>
ah Treillis doesn't have DDR3 & Etherner ? ok
<benh>
Versa is about $500 AUD... I'll wait a bit. Not much more expensive than an Arty 100T mind you.. maybe I can get sponsored by IBM (my former employer :)
<_florent_>
Trellisboard has 32-bit/1GB DDR3 and 1GBps ethernet, but it's not possible to purchase it
_whitelogger has joined #litex
<john_k[m]>
_florent_: after you flash the CLE-215 with --load, how did you reset the device to get it to re-enumerate over PCIe?
<_florent_>
john_k[m]: you just need to reboot the Host
<john_k[m]>
ah ok
<john_k[m]>
also, which kernel version were you compiling against for the module? I'm having issues with 5.6.11
<_florent_>
john_k[m]: but i had a strange behaviour with Acorn + Nest that was reloading the bitstream from flash on reboot that i haven't investigated yet
<_florent_>
to workaround that, i was flashing the board with --flash
<john_k[m]>
hrm ok, thanks
<_florent_>
i'm compiling it on Ubuntu 18.04, i would have to check for the exact kernel version
<john_k[m]>
I can look it up
<john_k[m]>
--flash isn't working for me, says "Error: Unknown flash device (ID 0x00ffffff)"
<john_k[m]>
did you run into anything like that?
<john_k[m]>
18.04 uses kernel 5.3
<_florent_>
no, flash was working
<_florent_>
you can still use --load
<_florent_>
there is a led chaser on the 4 leds
<john_k[m]>
that is running
<john_k[m]>
lspci still shows "03:00.0 Processing accelerators: Squirrels Research Labs Acorn CLE-215+"
<_florent_>
if it's there after rebooting, then you are using the right bitstream
<_florent_>
when you are doing the --load, do you see the led chaser?
<john_k[m]>
before I reboot, you mean?
<_florent_>
yes
<_florent_>
just to be sure the bistream is loaded correctly
<john_k[m]>
hrm, any good way to go back to design in the flash without powering the machine off?
<john_k[m]>
yes chaser starts right after I use --load
<john_k[m]>
rebooting causes default bitstream to load, as you observed
<john_k[m]>
will try a different CLE-215 in the morning to check on the flash thing
<john_k[m]>
my goal is to make a dedicated CLE-215 sample project
<john_k[m]>
since there seems to be additional interest in this board now
<awordnot>
i wasn't aware of the CLE-215. other than these potential flashing issues are there any known pitfalls compared to something like a NiteFury?
<john_k[m]>
it is a commercial application of NiteFury
<_florent_>
john_k[m]: ok, so you will need to get the flash working
<john_k[m]>
I'm not aware of any other pitfalls, but I'm just getting started
<awordnot>
cool
<john_k[m]>
I'm also trying with an Acorn Nest, maybe I'll try it in a native mPCIe slot, to see if that has something to do with the bitstream reloading
<_florent_>
john_k[m]: i'll also probably create a project with this board to demonstrate how to create PCIe processing accelerators
<john_k[m]>
ah, nice
<john_k[m]>
I need to go to bed now, but if there is any other gotchas or tricks you can think of, please let me know
<_florent_>
john_k[m]: good idea to test without the Nest, i was also suspecting it to cause this behaviour but haven't tested
<john_k[m]>
and I'll look into it more in the morning
<awordnot>
is it possible the CLE-215 has some additional circuitry to reset the FPGA bitstream on PCIe reset or initial poweron? not really sure how that works
<_florent_>
john_k[m]: ok sure, i'll try to do some tests today
<john_k[m]>
it's likely how the Nest has it's PCIe bridges and embedded controller configured
<john_k[m]>
it's possible they wanted the devices to reset on reboot to make cryptocurrency mining support easier?
CarlFK has quit [Quit: Leaving.]
futarisIRCcloud has joined #litex
CarlFK has joined #litex
<zyp>
_florent_, I don't presume you've used the edge clock bridge in ecp5 to split a ddr3 memory across both left and right side banks?
<daveshah>
but I'm not sure if it is in exactly the same way
<daveshah>
I know it uses an edge clock bridge though
<zyp>
ah, I should check the schematics
<zyp>
yes, it got the address bus on right side and data bus on left side
scanakci has quit [Quit: Connection closed for inactivity]
Skip has joined #litex
<Skip>
Has anyone run LiteX on a rev C pano logic device? The BIOS Memtest fails here. It works fine on a Rev B. Unfortunately I only have one Rev C and I've never used SDRAM on it before so it could be an hardware issue.
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex
scanakci has joined #litex
<john_k[m]>
I have a rev C but have not tried since they got DDR working on rev B - I was never able to make it work on rev C
<Skip>
I would think it would "just work" as far as I know it's exactly the same design with just different FPGA and SPI chips stuffed, but that's just an assumption.
<Skip>
Thanks for the response!
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex
FFY00 has quit [Read error: Connection reset by peer]
<CarlFK>
bunnie: im trying to get it working on a pi. I patched debian's version, it built, but http://paste.ubuntu.com/p/jzkJm2562D/ Error: no device found
<CarlFK>
tumbleweed had to make a few changes as the source drifted
_whitelogger has joined #litex
<bunnie>
usually it doesn't report the odd jtag errors in the beginning but if the FPGA seems to be alive it could be some other weirdness in openocd...
sconklin has quit [Remote host closed the connection]
<john_k[m]>
anyone seen where the the ID code for a Xilinx Artix-7 sometimes has a higher bit set? ie I see 0x13636093 instead of 0x03636093
<john_k[m]>
hrm I guess per UG470, that's the version
<john_k[m]>
_florent_: how many CLE-215+ have you tested? 2 of the 3 I've tried so far have ID CODE 0x13636093
<_florent_>
john_k[m]: i only tested one
<john_k[m]>
ah, ok
<_florent_>
john_k[m]: you could try to lower the clock frequency in the openocd config file
<john_k[m]>
looks like I'll have some small PRs incoming
<_florent_>
you could also try to use VivadoProgrammer to load the bistream
<john_k[m]>
the bitstreams load fine in the end, it's just not in the list of supported chips
<john_k[m]>
and I have to look into the flash side of things as well, got a flash device with ID 0x00918d0d which isn't supported yet
<john_k[m]>
hrm, I think something is being wonky in my environment, --load just worked fine with no complaints on a fresh terminal :\
<CarlFK>
bunnie: what sort of diagnostics are ther for netv2, like generate a test pattern
<bunnie>
the simplest thing to do is to pass through a video
<john_k[m]>
_florent_: a diagnostic when you have a chance - does your CLE-215+ sticker on the bottom have a QR code or a printed serial number?
<bunnie>
if that works a lot of things are correct
<bunnie>
also talking to the firmware over the serial port is a good sign that many things are working
<_florent_>
john_k[m]: i could look tomorrow, but i remember seeing a QR code yes
<CarlFK>
is there a .. what is top.bit called? bitstream? anyway, where can I get a known working one?
<john_k[m]>
my 'working' unit is the same, the other two I've tried have white serial # stickers near the non-PCIe end with printed serial numbers
<john_k[m]>
* my 'working' unit is the same (QR code), the other two I've tried have white serial # stickers near the non-PCIe end with printed serial numbers
<john_k[m]>
lowering jtag freq to 5MHz seems to be an improvement
<john_k[m]>
* lowering jtag freq to 5MHz seems to be an improvement stability-wise