<fkokosinski>
green and so on, so they don't really match. Did it use to be like this when you worked on it, or maybe some recen change to one of the litex cores caused this behavior?
<tpb>
Title: GitHub - enjoy-digital/netv2: NeTV2 SoC based on LiteX (at github.com)
<somlo>
_florent_: oooh, embed the mmc-slot thing *within* litespi0
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<somlo>
now I need to figure out what "unsupported mode bits 4" and "can't change chip-select polarity" actually means, but this is way better than the sound of crickets I was experiencing before :D
<_florent_>
somlo: ok good :)
<_florent_>
somlo: i'm also going to do some tests on the nexys4ddr with Linux-on-LiteX-Vexriscv
<somlo>
_florent_: and (obviously) thanks for getting me unstuck w.r.t. the DT entry! I'll pick this back up later in the afternoon (got some $DAYJOB stuff I kinda have to take care of first) :)
<fkokosinski>
_florent_ ping
fkokosinski has quit [Quit: Connection closed]
<mithro>
somlo: Is Rocket verilog of systemverilog?
<somlo>
mithro: litex-data-cpu-rocket/... is Verilog (upstream Rocket sources are Chisel)
<mithro>
somlo: Thanks, I think I was getting it confused with Ariane
<somlo>
I thought Ariane was also Verilog (not *System*), but don't quote me on that :)
CarlFK has joined #litex
<somlo>
_florent_: is the `reg = <x>` value of `mmc-slot@x` relative to that of the enveloping `spi@yyy`, or is it absolute (i.e., x == yyy)?
<Finde>
ariane is sv fwiw
tucanae47_ has joined #litex
tucanae47 has quit [Ping timeout: 246 seconds]
tucanae47_ is now known as tucanae47
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 265 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
<somlo>
_florent_: after some RTFMing, it appears nested nodes' `reg` properties are relative to their parents', so if litespi starts at 0x12004800, and the mmc-slot nested inside should also start at 0x12004800, the latter really *does* need to have `reg = <0>`, i.e. start at parent node's offset
<somlo>
at least one fewer things to confuse me :)
<mithro>
_florent_: I'm a bit confused about how the build at https://travis-ci.com/github/enjoy-digital/litex/jobs/315546886 succeeded, given it downloaded a Linux binary on Mac? Is the compiler never actually used as part of the setup.py test command?
<tpb>
Title: Travis CI - Test and Deploy with Confidence (at travis-ci.com)
<somlo>
if this means how many actual `cs` pins there are in the `spisdcard` pads, it's 1 on every set of pads on all platforms in litex[-boards] I could find, not sure why they'd have used 2 for the example...
<somlo>
if that makes sense to you, I'll add that to my kernel patch set as part of the litespi driver upgrade
<zyp>
what's the general opinion on wishbone-tool vs litex_server.py?
<zyp>
I'm having some problems getting litescope to work via wishbone-tool - works fine via litex_server.py
<_florent_>
somlo: yes cases where we use 2 or more cs pins are rare, it's only useful on boards where multiple chips are using the same SPI lines
<_florent_>
somlo: i've not been able to test the SDCard in SPI mode with Linux-on-LiteX-Vexriscv, but will do some testing tomorrow
<_florent_>
zyp: litex_server is probably slower and has less features than wishbone-tool, but that's what i'd recommend at first for LiteScope if you don't need specific features from wishbone tool. I've only used wishbone-tool for the specific cases that were not possible with litex_server (ex UART in Crossover mode over Etherbone) and it was working great, but i haven't tested personally LiteScope with it.
<zyp>
yeah, I tested the crossover mode earlier, and then I figured I'd keep using it, and found stuff weren't working properly
<zyp>
but I haven't looked too hard into how it's failing yet, so I don't have enough info to properly report it yet
<zyp>
I'm also looking forward until ethernet works more stable on the colorlight board, I guess it'll be a lot faster to dump the litescope buffer over etherbone rather than the uart bridge :)