<somlo>
one of those should be `args.with_sdcard` (without the `spi` part)
<_florent_>
somlo: thanks, that's fixed
Skip has joined #litex
scanakci has quit [Quit: Connection closed for inactivity]
<somlo>
anybody successfully built a mor1kx based soc on a nexys4ddr recently?
<somlo>
and I mean *LiteX* soc, preferably from current upstream :)
<_florent_>
somlo: on my side i only tested it with lxsim recently, but could do the test tomorrow on the nexys4ddr
<_florent_>
somlo: is lxsim --cpu-type=mor1kx working?
<somlo>
_florent_: `lxsim` doesn't work directly, but `litex/litex/tools/litex_sim.py --cpu-type=mor1kx` gets me all the way to a bios prompt. I can't actually interact with it (nothing happens when I type stuff into it), but that's further than I get on the fpga
<somlo>
typing works when I use vexriscv instead of mor1kx, btw (in sim)
<_florent_>
ok, i'll do the test tomorrow
<CarlFK>
bunnie: kgugala_ can someone get me a netv2 bitstream with some easy to verify behavior so I can figure out if my pi loading system here is working?
<bunnie>
this has the production bitstream images, assuming you have the 35T version, use user-35.bit
<bunnie>
if you load it, the green LED near the TX port should flash
<CarlFK>
perfect
<bunnie>
this LED will flash even if there is no firmware to load, it's tied to a hardware counter that divides down the crystal directly.
<CarlFK>
bunnie: well... the led is already flashing. so .. about all this tells me is my attempts at loading kgugala_'s is failing. which I kinda guessed
<CarlFK>
do you have something handy that doesn't flash the led?
<bunnie>
the LED is already flashing?
<CarlFK>
yes. I'm guessing is was shipped that way
<bunnie>
oh right, because of the default bitstream already on the board
<bunnie>
ah yah here's a way
<bunnie>
on your board there is an ethernet connector
<bunnie>
just north of it, to the right of the "PROG" button
<bunnie>
there is a depopulated header that says "JTAG MODE" on it
<bunnie>
jam a pair of tweezers in that, and hit the PROG button
<CarlFK>
while it is powered?
<bunnie>
you should see the LEDs go to a sort of dim-orange state as the FPGA GPIOs all go into tri-state and stays in an unprogrammed state waiting for a JTAG bitstream
<CarlFK>
yes
<bunnie>
yah, you can do it while it's powered on
<bunnie>
punching the PROG button should make the FPGA latch the JTAG MODE pins and go into the wait-for-bitstream state
<tpb>
Title: GitHub - antmicro/netv2 at v4l2 (at github.com)
<bunnie>
unfortunately, i don't have a convenient setup to test PCI at the moment.
<CarlFK>
k
<bunnie>
one small gotcha -- you want to make sure you are specifying the correct bitstream loading mode if you're doing PCI. you have like...some 100ms or so...to respond to enumeration on boot. if you go with default bitstream generation options, the FPGA can take too long and it will fail to enumerate because of that delay
<bunnie>
the tolerance to this delay depends on the system
<bunnie>
so some people might see it, others might not
<bunnie>
but this was a driving factor behind the choice of the SPI part, to make sure it could support a config mode that can roughly meet that timing requirement
<CarlFK>
bunnie: oh right. also.. I forgot to flash while the linux box was at grub.
<CarlFK>
I was doing that, and ... at some point fogot I needed to do that :p
<CarlFK>
bunnie: for you todo list: pi 4.
<CarlFK>
openocd says "loaded file top.bit..." but it didn't make the led flash
<CarlFK>
so I'll stop using my pi 4. pi everywhere.
<bunnie>
yah the pi 4 probably has a different "timing coefficient" required in the .cfg file