futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mibus has joined #litex
mibus has quit [Client Quit]
Melkhior has joined #litex
Dolu has joined #litex
Melkhior has quit [Quit: Ping timeout (120 seconds)]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #litex
<joseng>
_florent_ Tested now with l2_size=0, that also disables the reversing of the data order (and the flag "l2_reverse" which is by default True does not do anything with cache size 0)
<joseng>
Is it recommended to have no l2 cache at all? Or can the cache somehow be disabled for the DMA readers and writers?
<_florent_>
joseng: the LiteDRAMDMAReader/Writer are directly connected to the DRAM controller, so there is no caching. But if for your test you are writing/checking data from the CPU, you'll have to be sure the L2 cache is flushed before doings reads from the CPU, or disable the L2 cache as you just did.
<_florent_>
The L2 cache improve performance and allow more efficient accesses to the DRAM, but you should indeed probably disable it for now (but with a potential reversing of the data as you seen, that we could try to avoid).
Dolu_ has joined #litex
Dolu has quit [Read error: Connection reset by peer]
captain_morgan has quit [Read error: Connection reset by peer]
captain_morgan0 has joined #litex
tmbinc has quit [Ping timeout: 256 seconds]
tmbinc has joined #litex
Dolu_ has quit [Remote host closed the connection]
ambro718 has joined #litex
<somlo>
_florent_: got litescope working with the actual fpga board \o/
<somlo>
thanks again for the handholding! :)
Melkhior has joined #litex
<Melkhior>
Hello,
<Melkhior>
I'm trying to get the sdcard work in SPI mode in the LiteX BIOS on my HW, and so far no luck.
<Melkhior>
The 'native' mode works beautifully - LiteX loads the kernel and root filesystem very fast, and everything is fine.
<Melkhior>
However if I use SPI mode instead, the BIOS hangs on 'Booting from boot.json...', though sometimes after some minutes I get "Booting from boot.bin..." (and occasionally after that "SDCard boot failed./No boot medium found").
<Melkhior>
Any suggestion what could cause the SPI mode to fail? Or how I could try to figure out the problem?
<Melkhior>
Thanks in advance!
Melkhior has quit [Quit: Ping timeout (120 seconds)]
<_florent_>
it's not very fast (5 to 10min to boot linux), but if this is useful for you, happy to help you setting this up
<Melkhior>
_florent_ Thanks for the advice. I triple-checked the signals (all 4 of them :-) ) that I based on the arty design. I guess they're OK as it seems the "init" part is always successful, at least that the impression I got from tracking the state of the FSM in the SPI-based controllers I've tried with my design (and with one btistream - that I can't
<Melkhior>
regenerate for unknown reasons - I was able to read blocks from the card... early in the process so I didn't think of saving it!).
<Melkhior>
I also tried lowering/raising the frequency (thanks for confirming I had the right file, it felt strange to change C code rather than HDL) - 25 MHz, 20MHz, 5MHz, 400KHz, all hangs the same way. Meanwhile, 'native' mode always just works!
<Melkhior>
I wish I could just use litesdcard in my design, I've managed to generate some verilog, but the interface is too complicated for my limited HW skills at this stage. I can't figure out to _not_ have a local ClockDomain & PLLs (so I can use my own 48, 50 or 100 MHz clock directly), how to expose the CSR (can I just do
<Melkhior>
"bus_pads.cmd_arg.eq(self.sdcore.cmd_argument.storage)" and expose them to the outside world ?), or how to talk to the source/sink...
<Melkhior>
The only difference between 'working' and 'non-working' is using "sdcard" or "spisdcard" in "make.py", which the board defines like this:
Melkhior has quit [Quit: Ping timeout (120 seconds)]
Melkhior has joined #litex
kgugala has quit [Remote host closed the connection]
<_florent_>
Melkhior: the pinout seems fine, only thing I can see is the un-required PULLUP on the clk pin
<_florent_>
for now exporting LiteSDCard will indeed not be very easy since there are no generator (as it's the case for LiteDRAM, LiteEth, etc...)
<Melkhior>
tried with and without, doesn't make any difference that I can see ; I'll remove it again
<Melkhior>
(the pullup on clk)
<_florent_>
maybe try with other SDCard is you have others
<Melkhior>
I tried some designs with alternate cards, same result; unrotunately they are all class-10 UHS1 - I can't find anything older/slower at home... and older/slower cards are as expensive as large, fast ones :-(
<Melkhior>
Anyway thanks for all the help - and for LiteX, quite impressive how it works if you don't deliberately cripple it by using an older, slower mode of operation :-)
<_florent_>
Melkhior: BTW, why aren't you able to use the native mode in your application?
<Melkhior>
I can use native mode, but I haven't found a controller that I could integrate with my own design (non-LiteX):-( Everything is either SPI-only (and reasonably easy to use) or a Wishbone-with-DMA-and-all-the-goodies that I can't figure out how to use. I'm trying to interface with another bus, good ol' IEEE 1496-1993, obsoleted in 2000:-)
<_florent_>
Melkhior: thanks re LiteX, that's really interesting to see what you already manage to do with it (and also the extension you implemented for VexRiscv)
<_florent_>
ok for your implementation, I remember we discussed this by mail
<_florent_>
For LiteSDCard, we could eventually work on a core generate together if you want to integrate it as a verilog core in your VHDL design
<_florent_>
If you want to contribute an initial implementation, I'll be happy to review it and help you getting it working
<_florent_>
For examples of generators, you can look at LiteDRAM:
<Melkhior>
yep, decided to have a got at it:-) turns out the interface with the SBus worked first time, and I can get some crypto on it :-)
<Melkhior>
Trying to get the sdcard to work turns out to be the big problem - and I was sort of expecting it to be 'standard' enough to be the easiest part... silly me :-)