<swetland>
aaand TX is happy too. And etherbone is working now.
<jevinskie[m]>
:) that is a weird trick. What made you try that??
<swetland>
well the crc error register ticked up on almost every inbound packet, only a few surviving. made me think the clock was badly aligned
<swetland>
some of the fancier phys have a clock offset parameter but not this one
<swetland>
so by flipping the 0, 1 in the ddrout to 1,0, the clock shifts by half its cycle
<jevinskie[m]>
ah, but of course! nice :)
<swetland>
and it would appear that is sufficient to line up with the rx data reliably (flood pinged the device, dumping rx info in a little test program and it seemed to keep up ok w/ no errors)
<swetland>
big question is, can we parameterize this so I can avoid having local hacky patches -- question for _florent_ I suppose
* swetland
apologizes in advance for inflicting more workaround for more weirdly broken hardware on people...
<swetland>
upshot is litex_server/litex_cli is also happily chattering with the board via etherbone
<swetland>
hmm. both these etherbone docs mention FEC for UDP but neither specifies an implementation
<jevinskie[m]>
I haven't seen it implemented/used
<swetland>
I guess most of the time on modern switched ethernet on a local link without heavy congestion the chances of dropped or corrupt packets are pretty low
<shorne_>
hello, is there still any effort/will to get litex SoC's into qemu?
<shorne_>
I am working on adding some stuff for openRISC, and thinking maybe also it would not be too hard to get the litex devices in
<shorne_>
I guess the concern before was that litex soc's could be reconfigured and change and qemu want's their hardware definitions to be static. But I think the board configs are more stable now
<swetland>
shorne_: I've been adding a few peripherals for a RV32 target in qemu. haven't tried pushing them upstream yet
<swetland>
have chatted a bit with _florent_ and mithro about stable CSR/IRQ base addresses. Not sure if there's agreement on exactly how to approach that yet
<swetland>
for now I have a local patch that keeps CSRs on my fpga target from moving around unexpectedly
<jevinskie[m]>
Can’t qemu parse DTS? I wonder if that’s a path forward
<swetland>
ugh.
<swetland>
If you want to pitch that to the Qemu people you'll need to find someone who doesn't hate DTS to do it, which rules me out. ^^
<swetland>
I gather even trying to get them to agree on "having a runtime configuration language" to set things up has failed multiple times in the past...
<jevinskie[m]>
Oh, that’s disappointing. I come from Apple-dom and as a hobbies Zephyr user so devicetree is natural to me :P
<swetland>
I consider it a really horrific piece of technical debt foisted off on us from open firmware
<swetland>
string matching is error prone and clunky. the data payload typing is basically all by convention, not any actual reliably parsed type indicators, etc, etc
<swetland>
every time I'm forced to deal with it, the results are entire afternoons wasted debugging shit that would have Just Worked if we were still using board files
<swetland>
so, no, not a fan
<shorne_>
jevinskie[m]: well, qemu can also generate dts, so as long as the qemu target stays the same and the CSRs inside the decive don't move around it should be ok
<shorne_>
The goal would be able to have a kernel that can boot on both qemu and litex, so we can test litex software/drivers
<swetland>
yeah from the standpoint of "can I run the same kernel on qemu-litex and some-fpga-litex", both can provide you with DTS and then at least as long as the specific registers within a CSR bank don't move around, you should be okay
<shorne_>
yeah, thats my thought, so the issue of litex changing memory maps is not really an issue with qemu
<swetland>
and I think that's desirable anyway since code is going to upstream linux, zephyr, etc -- needlessly breaking existing drivers by rearranging CSRs within a bank or bits within individual registers feels counterproductive
<shorne_>
as of now, we have litemmc, liteeth, liteuart upstream in the kernel, so as long as those don't change I think we can build a qemu hw/
<tpb>
Title: #litex on 2022-05-19 — irc logs at libera.irclog.whitequark.org (at libera.irclog.whitequark.org)
<cr1901>
I didn't see it in the scrollback
<shorne_>
shenki: wow, just got the mail, didn't realize you did a separate implementation, it looks more clean, ill have to review
<shorne_>
I am working on an openrisc virt board now, it was kind of on my todo for fun projects
<shorne_>
but as I was doing it I was wondering why we can't do a litex board, now that qemu can jsut generated the DTS for the kernel
<swetland>
I've got a very simple litex machine model I've been using, mostly with the aim of being as close a match to the litex setup I have on a ECP5 fpga board
<swetland>
shenki: thanks for the cc!
<_florent_>
not really able to contribute, but that's great to see the qemu efforts! Good support would be really nice and would complement the verilator simulations + tests on hardware.
<_florent_>
cr1901: sorry, forgot to answer, litevideo and opentitan are no longer installed with LiteX no; litevideo can still be used but is no longer maintained (would need to be fully re-written) and for Video Out we now have a simple core directly integrated in LiteX; opentitan was install for ibex, but we switched to the ibex repo directly.
<swetland>
_florent_: opinions on clock skew hackery for liteeth/phy/rmii.py ?
<swetland>
I was getting 90+% crc errors on rx on the muselab board w/ waveshare module
<swetland>
the cheesy trick of swapping 0 and 1 here fixes rx for me: self.specials += DDROutput(0, 1, clock_pads.ref_clk, ClockSignal("eth_tx"))
<swetland>
(all the hardware I try to use with litex appears to be cursed in some way)
<_florent_>
swetland: lol, hoping we won't have to put workaround everywhere for all the combinations of cursed hardware you are using :)
<_florent_>
I would need to have a closer look, I never had trouble with the current setting, but I should have a closer look to see if it's optimal or not
<_florent_>
we could eventually add a parameter to configure the clk phase.
<swetland>
well the good news is I'm running out of Litex peripherals to discover bad interactions with! Though I haven't fully put spiflash and sdcard through their paces yet...
<_florent_>
swetland: OK, I have to add a LAN8720A RMII module to one project in a couple of days. While doing so, I'll look at the LAN8720A/DP83848 datasheets
FabM has quit [Quit: Leaving]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex
linearcannon has joined #litex
linear_cannon has quit [Ping timeout: 248 seconds]
linear_cannon has joined #litex
linearcannon has quit [Ping timeout: 260 seconds]
<swetland>
_florent_: Thanks! I've got a batch of LAN8720A RMII pmods arriving from JLCPCB next week so it'll be interesting to see if they work as-is or need trickery.