martinraison has quit [Remote host closed the connection]
_franck_6 has joined #litex
_franck_ has quit [Ping timeout: 246 seconds]
_franck_6 is now known as _franck_
martinraison has joined #litex
martinraison has quit [Remote host closed the connection]
martinraison has joined #litex
shenki has quit [Ping timeout: 272 seconds]
shenki has joined #litex
martinraison has quit [Remote host closed the connection]
martinraison has joined #litex
martinraison has quit [Remote host closed the connection]
martinraison has joined #litex
Dolu has joined #litex
martinraison has quit [Remote host closed the connection]
martinraison has joined #litex
martinraison has quit [Ping timeout: 240 seconds]
martinraison has joined #litex
<shorne>
somlo: fixing up the drivers should not be too hard
feldim2425_ has joined #litex
feldim2425 has quit [Ping timeout: 260 seconds]
feldim2425_ is now known as feldim2425
<somlo>
shorne: I took a first pass at doing that in litex-hub/linux (litex-rebase branch); for now they SHOULD compile on 8-bit CSR and 32-bit CPU (as that's the target they were written for originally);
<somlo>
I have (some hacked version of) shenki's liteETH driver and (spi-)sdcard drivers tested on my setup (64-bit rocket, 32-bit csr data width)
martinraison has quit [Remote host closed the connection]
martinraison has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
martinraison has quit [Remote host closed the connection]
martinraison has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
martinraison has quit [Remote host closed the connection]
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 - https://znc.in]
feldim2425 has joined #litex
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex
<somlo>
_florent_: do you have (nexys4ddr) bitstream and a kernel (def)config file you could send me to debug this?
<somlo>
must be some really stupid and small/subtle change in the include/linux/litex.h accessors
<somlo>
one thing I could do is try 8-bit csr data width with rocket (I know how to build the bitstream for that :)
<somlo>
I'll try that and see what happens, BRB
<somlo>
the other thing is that I dropped the liteUART version I had in litex-rocket-rebase in favor of the one that went upstream
<somlo>
not sure that has anything to do with it, but it's the only other change I can think of that might be related
<_florent_>
somlo: yes I can test and prepare things on the nexys4ddr to help working together on this
<_florent_>
somlo: I did a test with only the UART in the .dts and the issue was also there, that's indeed possible it's related to it
_franck_ has quit [Ping timeout: 264 seconds]
<somlo>
_florent_: so, can you copy the drivers/tty/serial/liteuart.c from litex-rocket-rebase over the one upstream (in litex-rebase) and see if that works?
_franck_ has joined #litex
<somlo>
If yes, we can diff them and see what broke
<somlo>
hopefully the Kconfig options are the same...
<somlo>
*option names, I mean
<somlo>
so if the litex.h accessors work for 8-bit csr-data-width on rocket, I'd presume they're fine on vexriscv as well, which would leave the liteUART driver. I'm waiting for both the bitstream and kernel for 8-bit CSR rocket to build, will report back once I know if it works
<somlo>
(might have to take a 40-minute car trip that overlaps with it all, so it might be an hour before I get back with any results)
martinraison has joined #litex
martinraison has quit [Remote host closed the connection]
FFY00 has quit [Remote host closed the connection]
martinraison has joined #litex
FFY00 has joined #litex
<somlo>
_florent_: also, ignoring the 'rocket-rebase' branch, proper-upstream should have 8-bit CSR support and liteUART
<somlo>
so I wonder if *that* works (before any of my changes are applied at all)
<_florent_>
somlo: ok thanks. I try to the test with upstream and also liteuart before leaving the office
<somlo>
it'd have to be a simplified design with no ethernet/sdcard/etc
<somlo>
_florent_: oh yeah, sorry, forgot it's much later where you are ;)
<_florent_>
the features can be present in the bitstream, just that it will not be used by Linux
<somlo>
oh, that's good then
<somlo>
_florent_: I don't use liteUART directly from linux -- I use sbi, which traps into machine-mode and causes bbl to handle console i/o
<somlo>
that said, with 8-bit CSRs linux boots, but ethernet doesn't work
<somlo>
so I might have screwed up the accessors. I'll do some debugging and post a v6 of the patch to lkml later today (hopefully) after I figure it out
<somlo>
assume it's the accessors and that i messed it up, until further notice :)
FFY00 has quit [Ping timeout: 268 seconds]
<somlo>
and, btw, thanks for catching that!
FFY00 has joined #litex
Bertl is now known as Bertl_oO
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex
martinraison has quit [Remote host closed the connection]
<_florent_>
somlo: in fact the behavior is similar with upstream Linux 5.11-rc1, I'll try to understand tomorrow
FFY00 has quit [Quit: dd if=/dev/urandom of=/dev/sda]
FFY00 has joined #litex
lkcl has quit [Ping timeout: 268 seconds]
lkcl has joined #litex
<somlo>
_florent_: then we have *two* problems ;) I broke 8-bit CSR accessors between litex-rocket-rebase -> litex-rebase, AND upstream LiteUART is being weird...
<somlo>
_florent_: so, it turns out I did *not* break accessors for 8-bit CSRs. In my previous test, I accidentally kept using the 32-bit-CSR kernel on my 8-bit-CSR bitstream :D
<somlo>
with the actual 8-bit-CSR kernel on the 8-bit-CSR bitstream (nexys4ddr, rocket+litex) I can get LiteETH working fine in linux (which means the accessors are OK)
<_florent_>
somlo: ah ok, good
<somlo>
I'm getting cmd-51 dma timeouts, cmd-1 command timeouts, and subsequent cmd-51 data xfer timeouts with liteSDCard, but I don't think that's specifically related to CSRs
<_florent_>
somlo: for now I kept 8-bit CSR to only change one thing at a time, but I'll probably switch Linux-on-LiteX-Vexriscv to 32-bit once the other issues are solved
<somlo>
so liteSDCard (the linux driver) works on 32-bit CSRs, and not so well on 8-bit (bios is fine on either)
<_florent_>
somlo: interesting, I think that's the issue I had
<somlo>
hmmm, need to troubleshoot the linux driver on the 8-bit CSR setup, see if I can find the problem
<somlo>
but the good news is that the for-upstream CSR patches are OK; we need to find why the LiteSDCard driver hates us on 8-bit subregisters, and why upstream liteUART hates us on vexriscv
<somlo>
I think per shorne it seems OK on mor1k
<_florent_>
somlo: exactly, not sure it's worth spending too much time on the 8-bit CSR support for LiteSDCard
<_florent_>
I'll investigate on upstream linux/Vexriscv
<_florent_>
regarding LiteEth, are you using the polling or IRQ mode?
<somlo>
_florent_: IRQ mode
<somlo>
looking at the liteuart driver in upstream vs. litex-rocket-rebase, the .c file has quite a few changes. From the outside (Kconfig), it's only that LITEUART_NR_PORTS was renamed to LITEUART_MAX_PORTS
<somlo>
and `port->type` is hardcoded to '1' rather than adding a special PORT_LITEUART value to serial_core.h
<somlo>
but I'm not set up to test it on this end (litex+rocket doesn't use it)
<somlo>
the litex-rocket-rebase version has its own accessors defined internally (using iowrite32/ioread32)
<somlo>
and since each CSR is 8 bit, and alignment is 4 bytes regardless of subregister size, the register offsets don't change across the 8-vs-32-bit csr data width
<somlo>
so this one should work the same on both 8- and 32-bit CSRs
<somlo>
I don't think the breakage is in the CSR accessors, rather something else in the changes since the old version we still have in litex-rocket-rebase
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
SpaceCoaster has joined #litex
martinraison has joined #litex
martinraison has quit [Ping timeout: 264 seconds]
<somlo>
_florent_: final conclusion for today: on nexys4ddr / litex+rocket, both litex-rocket-rebase ("old" kernel) and litex-rebase ("new" kernel) behave the same: working liteeth, litesdcard works on 32-bit CSR width, breaks on 8-bit CSR width
<somlo>
liteUART driver accessors appear to have the same behavior in both kernels (I'm not set up to test easily) -- so the breakage must be elswhere in the diff between the litex-rocket and current upstream
<somlo>
more digging into litesdcard tomorrow :)
<somlo>
I *am* getting data xfer timeouts even on 32-bit CSRs, but it generally works and high-level data integrity is preserved after xfers are retried
<somlo>
hoping to find an actual bug by troubleshooting on 8-bit CSRs, one that would help fix behavior on 32-bit CSRs as well (one can dream, right?) :)