<levi>
Argh. I've got my LiteEth ethernet to the point where mdio works, gigabit link is established, but the other end just racks up its fcs error counter when I try to send anything. I assume something is wrong with the RGMII interface somehow, but it's difficult to see what it is.
CarlFK has joined #litex
<davidc__>
levi: can you put your PHY in a loopback mode?
<levi>
Hmm, yeah; looks like there's a bit for that in the MII Control Register.
<levi>
I've done that and it doesn't seem to have registered any particular errors. I've currently only got the bios loaded, so I can read and write mdio registers and attempt to netboot.
<levi>
I need a NIC that'll let me see bad frames to see how these are getting mangled.
<levi>
Woo, one of them *does* have such a setting. And the packets don't seem too mangled after all.
<levi>
Not so much mangled as truncated; and receive seems to work, at least enough for the ARP response to be understood.
<levi>
Maybe this is actually a software issue?
sajattack[m] has joined #litex
<sajattack[m]>
oh that's what [m] means in a username, matrix bridge, TIL
<sajattack>
/exit
<sajattack>
oops
sajattack has quit [Quit: leaving]
<sajattack[m]>
I love irssi and all but I think I'll hang out over here instead, sorry for offtopic
m4ssi has joined #litex
_whitelogger_ has joined #litex
rohitksingh_ has quit [Remote host closed the connection]
<_florent_>
levi: can you tell us which FPGA you are using?
<_florent_>
this will disable hardware PREAMBLE/CRC and will make the software manage it. (so if you have a CRC error on the RX, the software will still see it)
<_florent_>
and activate the debug traces in the software:
<_florent_>
now be sure to be able to capture malformed frame on your computer (ie avoid any switch, router, etc...)
<_florent_>
and you should now be able to see packet on the two side: the BIOS will show the TX/RX packets and you should be able to compare with what you have one your computer
<levi>
It's a Spartan 6, XC6SLX45, hooked up to a Broadcom 5482 dual-PHY, although I've only got the first one hooked hooked up to LiteEth now.
<levi>
I did figure out how to get debug tracing turned on in microudp, and I've got my NIC on my Linux+wireshark setup configured to give me malformed packets.
<levi>
So, it appears that I'm receiving just fine via LiteEth, so the hardware preamble/CRC works on that path. And the preamble seems to work on the tx side, and probably the crc would too but for some reason all the received frames in Wireshark stop (i.e. turn to all 00s) after 42 bytes.
<levi>
That's enough for the useful fields of the initial ARP to get received, so a response is sent and the netboot code sends the first UDP packet; it's truncated right at 42 bytes though which is just to the end of the UDP header. The debug printout on the console shows that the tx buffer was fully filled out, though.
<_florent_>
What frequency are you using on the CPU? i remember @daveshah and @gsomlo has issue with low frequencies (50/60MHz) and 1Gbps Ethernet
<daveshah>
Yes, I found it was 55MHz minimum for working 1Gbps TFTP
<levi>
I sent the board some 512 byte pings while it was attempting netboot to see if it would rx the entire payload, and it does print out the whole thing on the console.
<levi>
It's just tx that's not working.
<levi>
It's currently at 50MHz; I'll have to look at the timing report to see if I can crank it faster.
<daveshah>
Yes, 50MHz doesn't work afaik
<daveshah>
I think it was the Tx that was broken for me too
<levi>
Odd.
<daveshah>
I think it is some kind of underflow in liteeth
<daveshah>
But I never spent much time looking in detail
<tpb>
Title: Netboot issues with 1Gbps and low CPU frequency (<55MHz) · Issue #30 · enjoy-digital/liteeth · GitHub (at github.com)
<levi>
The timing report suggests I could maybe do 100MHz, but I'll try the tx FIFO first. I really appreciate the help!
<levi>
This board also doesn't bother with pin-strap configuring of the Phy, so it took me a while to figure out how to get it to decide it could do better than half-duplex 10BaseT.
<levi>
256 didn't seem to help; trying with a faster sysclk this time.
<levi>
Well, ethernet tx works now! Unfortunately something broke the SDRAM with the clock increase.
<_florent_>
OK thanks for the feedback, what frequency are you using now?
<_florent_>
i'm going to do some tests to see if i understand
<levi>
100MHz. I think I just need to adjust the SDRAM clocks to maintain the same relationship as they had at 50MHz?
<_florent_>
yes but DDR is not easy to get working correctly on Spartan6
<_florent_>
(mainly due to the PHY in LiteDRAM that should be refreshed)
<_florent_>
i'm going to do some tests with the Versa ECP5 / 1Gbps Ethernet and 50MHz clock to see if i reproduce and then investigate
<Xiretza>
hey, what exactly does the standalone liteeth core do? README says the frontend is etherbone (which is wishbone over UDP as far as I can tell), but then `gen.py --core` takes either "wishbone" or "udp". My goal is to somehow end up with a memory-mapped peripheral in my traditional SoC I can use for arbitrary ethernet, can liteeth help me with that?
<levi>
"wishbone" is what you want for a CPU-managed core, assuming the CPU has a wishbone interface as well.
<Xiretza>
I can make that happen, how does the wishbone interface work then? is it basically just two fifos for RX and TX? any specs?
<levi>
It's a fully-documented spec, yeah.
<levi>
_florent_: I doubled the clocks on the RAM and it came right back, so I appear to be in business now! Thanks for your help!
<_florent_>
Xiretza: sorry, the Etherbone frontend is not yet integrated in the generator, for now you can the generator can create a MAC+PHY (to be used with a CPU) or hardware IP/UDP stack and expose UDP ports
<_florent_>
Etherbone can be already be used when integrated with LiteX
<Xiretza>
levi: do you mean wishbone itself or liteeth's interface? I have the wishbone spec, I'm just not sure how liteeth's logical interface works.
<_florent_>
You can then create a Wishbone Master on the SoC bus and do the access with your computer
<_florent_>
can you explain a bit more your usecase? "My goal is to somehow end up with a memory-mapped peripheral in my traditional SoC I can use for arbitrary ethernet, can liteeth help me with that?"
<_florent_>
levi: great if you got it working (i will still investigate the issue with the slow CPU clock)
<levi>
Well it passes the SDRAM bootup memtest; I'm not sure how thorough that is. And ethernet tx/rx seem to be working; I haven't got the tftp boot server up yet though. That'll be a task for tomorrow!
<Xiretza>
_florent_: I'm building a RISC-V core and peripherals in VHDL as part of my end-of-school project, and since the Arty A7 board I'm using also has an ethernet PHY, I'd love to integrate it as well. Having to do all the MII interfacing myself would be annoying, so something that does that (but not necessarily a full UDP stack) would be nice to have.
<_florent_>
levi: if it passes memtest, it should be fine
<_florent_>
Xiretza: ok, then you probably want to use the generator to generate a core that integrate the PHY + MAC + SRAM + Wishbone interfaces
<_florent_>
you will then just have to connect it as a Wishbone Slave of your system and access it the same way it's done in the LiteX BIOS
<Xiretza>
_florent_: yeah, that seems like the best course of action - my question now is about the wishbone interface `--core wishbone` exposes though, is the LiteX BIOS the reference implementation?
<levi>
OK, I lied; I got the tftp server running and booted the firmware! Now I'm off to sleep though. Thanks again. :)
<_florent_>
Xiretza: yes, you can use the software from the BIOS as a reference to use the generated core
xobs has quit [Quit: killed]
nrossi has quit [Quit: killed]
bunnie[m] has quit [Quit: killed]
sajattack[m] has quit [Quit: killed]
<Xiretza>
levi: maybe I'm misunderstanding, but the wishbone specification doesn't tell me how to interface with an ethernet MAC, right? that's what a "wishbone datasheet" (WB spec section 2.1) is for, which I can't find for liteeth.
<_florent_>
Xiretza: indeed, there are no current documentation for that, except the current software:
freemint has quit [Remote host closed the connection]
freemint has joined #litex
CarlFK has joined #litex
freemint has quit [Ping timeout: 256 seconds]
rohitksingh has joined #litex
freemint has joined #litex
freemint has quit [Remote host closed the connection]
freemint has joined #litex
m4ssi has quit [Remote host closed the connection]
freemint has quit [Ping timeout: 256 seconds]
<somlo>
_florent_: got rocket/litex going at 40MHz on the trellisboard, with ethernet :)
<somlo>
so I can confirm it works
freemint has joined #litex
<somlo>
maybe I should re-try nfs-root (while I keep poking at litesdcard in the background) :)
<_florent_>
somlo: great, thanks for the feedback, i hope it will be useful for your tests
rohitksingh has quit [Ping timeout: 256 seconds]
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 272 seconds]
CarlFK has quit [Quit: Leaving.]
freemint has quit [Ping timeout: 256 seconds]
freemint has joined #litex
rohitksingh has joined #litex
<sajattack[m]>
_florent_: around?
<sajattack[m]>
I'm finally getting around to trying to set up vga
rohitksingh has quit [Ping timeout: 240 seconds]
<sajattack[m]>
linux_on_litex is trying to do hdmi still though, it grabbed hdmi_out rather than vga_out from platform, and it's erroring on hdmi stuffs in litevideo/output/driver.py
<sajattack[m]>
oh I see
<sajattack[m]>
the vga check is looking for hsync_n, but I have hsync
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 260 seconds]
<sajattack[m]>
is the bios meant to output vga?
rohitksingh has joined #litex
<sajattack[m]>
linux is hanging on simple-framebuffer initialization
<sajattack[m]>
possibly I did the clock wrong
<sajattack[m]>
is the clock domain supposed to be called cd_pix or just pix?
<_florent_>
sajattack[m]: the bios is not outputing anything no
<_florent_>
you need to create a clock domain similar to self.clock_domains.cd_pix = ClockDomain()
<sajattack[m]>
ok, linux isn't outputting either
<sajattack[m]>
ok that's what Ihad
<_florent_>
and do self.comb += self.cd_pix.clk.eq(your_generated_clk)
<scanakci>
_florent_: could you have a chance to look at my PR? I guess travis fails since I need to use a larger ROM than default. Let me know if there are other issues :)