_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
Dolu has quit [Ping timeout: 256 seconds]
lf_ has quit [Ping timeout: 260 seconds]
lf has joined #litex
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #litex
peepsalot has joined #litex
peeps[zen] has quit [Ping timeout: 256 seconds]
sthornington has quit [Ping timeout: 245 seconds]
Bertl is now known as Bertl_zZ
_whitelogger has joined #litex
Nic30 has joined #litex
Nic30 has quit [Remote host closed the connection]
Dolu has joined #litex
leons has quit [Quit: Bridge terminating on SIGTERM]
CarlFK[m] has quit [Quit: Bridge terminating on SIGTERM]
apolkosnik[m] has quit [Quit: Bridge terminating on SIGTERM]
xobs has quit [Quit: Bridge terminating on SIGTERM]
powergraphic has quit [Quit: Bridge terminating on SIGTERM]
promach3 has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
disasm[m] has quit [Quit: Bridge terminating on SIGTERM]
leons has joined #litex
CarlFK[m] has joined #litex
xobs has joined #litex
promach3 has joined #litex
sajattack[m] has joined #litex
DerFetzer[m] has joined #litex
powergraphic has joined #litex
disasm[m] has joined #litex
mibus[m] has joined #litex
abeljj[m] has joined #litex
apolkosnik[m] has joined #litex
<_florent_> iTitou: the CSRStorages need to be part of the Module to be collected (self.A, self.B, self.C instead of A, B, C)
Bertl_zZ is now known as Bertl
sthornington has joined #litex
<sthornington> Anyone with a ulx3s that can quickly test if the B1 button still works to rst and reload firmware?
sthornington has quit [Remote host closed the connection]
sthornington has joined #litex
sthornington has quit [Ping timeout: 272 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
<iTitou> _florent_: Thx !
<somlo> _florent_: is there any scenario in which the LiteSDCard gateware would be used with a non-removable card? I'm assuming No, but maybe I'm missing something
<somlo> also, any scenario where one would want to use GPIO for things like card-detect, instead of the built-in gateware functionality ?
<somlo> I'm also guessing No to this one, but with somewhat less confidence :)
<somlo> Asking because the current Linux driver checks for all of these as part of its card-detect method, and I'd like to simply remove all that dead code (on the assumption it's really *dead*)
<Finde> not in direct answer but in that theme, I seem to remember that Xilinx's vc707 board doesn't even have a CD pin
<somlo> Finde: IIRC digging through the LiteSDCard gateware sources yesterday the CSR bit dedicated to card-detect is hard-coded to "present" in that case
<somlo> whatever that is (0 I believe)
<Finde> yeah that's what we had to do for our sd device
<somlo> although in that case detecting eject and re-insert from e.g. Linux will end up being lots and lots of fun
<Finde> we just assumed it would never be unplugged...
<Finde> bit hard to give any guarantees there
<somlo> maybe that's where GPIO could come into play in some shape of form? I'm really not a hardware guy, althoug I'm trying hard to keep up ;)
<Finde> oh like to flick a separate switch after you insert kind of thing?
<Finde> seems reasonable yeah
<somlo> so you'd specify that in some DT cell in your mmc node, in which case I should probably *NOT* remove that code, as it's *NOT* dead :)
<Finde> makes sense to me
<somlo> In its current form, the driver does some trickery w.r.t. inserting a set-bus-width command into the command stream driven by the generic mmc layers *once* at the "right time" in "the beginning"
<somlo> and the "we're done with this part" flag stays set across an eject/reinsert cycle, so the card is never properly re-initialized after being ejected once
<somlo> so I'm trying to hook into the "get_cd" mmc driver method to reset that "we still need to set the bus width" flag
<somlo> so if the card is not removable, there's no problem; If we can rely on the CSR card-detect flag, we're OK; if there isn't a card-detect pin, we punt and make it GPIO's problem to signal us when the card is in/out of its slot (best effort)
<somlo> Finde: thanks for the brainstorm, I think it all starts making sense now ;)
<somlo> _florent_, Finde: https://github.com/litex-hub/linux/commit/2a99b5a0285edfb0d44f2745737feaacfb3fca14 (latest commit in the litex-rocket-rebase branch)
<Finde> at the very least your description sounds right to me
<somlo> I'm not a huge fan of how the set_bus_width is done, but given that, the fix I put in works. I'm going to look at the overall driver some more for additional clean-up opportunities :)
<somlo> as it turns out, the trellisboard's built-in sdcard reader doesn't have a card-detect pin either
<somlo> gateware hard-codes a "present" bit in the CSR card-detect register
indy has quit [Max SendQ exceeded]
indy has joined #litex
x56 has quit [Quit: Ծ-Ծ]
x56 has joined #litex