07:25 <msh> should jtagbone work OK with litescope? with litex_cli --regs I can see analyzer_trigger_done getting set, but analyzer_storage_done never gets set. doesn't _seem_ like it would be transport related, but uartbone worked OK in a similar setup before

09:13 <msh> tried uartbone in the same design now, and it works. guess maybe jtagbone is OK at slow rates or something

09:16 <tnt> In theory both are equivalent ... does jtagbone work for you for other stuff ?

09:17 <tnt> And TBH you're better off with uartbone. It's usually faster than jtagbone if you set a baudrate of like 1M or 2Mbaud.

09:28 <msh> jtagbone worked fine for litex_cli --regs, haven't used it for much else (I'm just integrating a generated litescope .v into another design)

09:28 <msh> will use uartbone, just the target board doesn't currently have any spare pins brought out. but can sort that out

15:40 <nickoe> msh I think the jtagbone is sorta slow

17:37 <nickoe> Is it possible to have multiple "endpoints" for the serial console?

17:53 <minute> hey, i am bringing up a new kintex-7 board with KSZ9031RNX eth phy, and i have a weird problem, it looks like all the nybbles in rx packages are doubled

17:54 <minute> example: 555555555555555555555555555555dd333333330000000000001100cc00008833666622bb00bb116688dddd006600000000000000000022aa33ffffeeff0088000000000000000000000000ee0000883366ffffeeff6622bb00bb11ffff220000

17:54 <minute> 000000000000000000000000000000000000000000000000001100668800008833ffff004400cc00000000000000000000000000000000000000005500110000000000000000005500ccdd11001100cc00008833666622bb00bb113399bbdd9955

17:54 <minute> ee22

17:54 <minute> any ideas?

17:54 <minute> (this is from the output of turning on eth/udp debug in litex bios)

17:55 <zyp> DDR vs SDR mismatch?

17:55 <minute> something with RX_DV/RX_CLK perhaps? this used to work on the last rev of the board, and this part wasn't changed, weirdly

17:56 <zyp> or perhaps something is running at double the clock rate it's supposed to

17:56 <minute> mhmm

18:21 <minute> each nybble is received twice and the nybbles are swapped... if i unscramble that in a script, it's a valid packet

18:27 <minute> another q, don't i have to set the phy mdio address anywhere?!

18:53 <zyp> probably defaults to 0, if mdio is even used

19:15 <_florent_> Ohh, I just saw that Intel PathFinder is in fact using LiteX under the hood: https://twitter.com/enjoy_digital/status/1570128793834258432

19:16 <_florent_> gsomlo: For the Rocket support they are advertising, they are probably just reusing your work :)

19:53 <somlo> _florent_: heh... why re-build the wheel when there's a nice, round one already there ;)

19:56 <somlo> BTW, made it a whole lot further with Fedora this time around (with LiteX support built into their "distro" kernel). Still crashes, but well *after* switching root from initrd to /dev/mmcblk0p2); https://imgur.com/a/8pvwQEp , https://imgur.com/a/FpnCFDb and https://imgur.com/a/lmCgog3

19:56 <tpb> Title: Imgur: The magic of the Internet (at imgur.com)

19:56 <somlo> I'll post a full log of serial at some point soon, before I start hunting for what exactly causes the crash

19:56 <somlo> but we're getting closer to world domination ;)

20:05 <minute> zyp: could this be a mismatch of 100mbit vs 1000? i.e. if the phy is in 10/100 mode it would clock the data as SDR and liteeth would sample at DDR, right? how can liteeth detect the link mode?

20:12 <zyp> minute, possible, IIRC it should detect the link mode from status bits on the data lines when idle

20:13 <minute> oh hmm, i didn't know this was possible. there's no MDIO happening at all, right?

20:29 <minute> i'm not sure if liteeth rgmii even supports switching to 100/10mbit? because it would need to switch the clock down to 25mhz or 2.5mhz

20:30 <minute> and s7rgmii.py has: tx_clk_freq = 125e6 and: rx_clk_freq = 125e6

20:49 <zyp> would it? I was of the impression that it's running the same clock and just repeating symbols

20:51 <zyp> hmm, no I guess RGMII is different from RMII in that regard

20:52 <zyp> RGMII is source synchronous, so in 100Mb/s mode it'll give you a 25MHz clock and SDR data

20:53 <zyp> so if your receiver believes it's still in 1Gb/s mode, it'll be clocked by the 25MHz RXCLK, but capture DDR data

21:25 <minute> exactly

21:26 <minute> possibly the cable i used was bad quality or old and downgraded to 100mbit this time, and liteeth doesn't know about this

21:26 <minute> i'll check link status via mido read tomorrow

21:34 <zyp> no lights on the switch showing speed?