14:37 <somlo> _florent_, Xiretza: liteeth commit 153c160 causes the linux driver (minimally adapted for 64bit Rocket from the vexriscv driver) to hang during boot

14:38 <somlo> I noticed that change was further modified by commit 7a44209, which doesn't fix the behavior I'm observing

14:41 <somlo> I'm investigating to see what actually changes in terms of the memory map state before vs. after MACCore initialization that might impact the linux driver (the generated csr.csv file is the same before vs. after the "breakage", so at least "officially" my IRQ numbers, and CSR and MMIO buffer addresses are unchanged)

14:41 <somlo> so at first glance it's not that I'm telling the driver to access the "wrong" address(es)

14:57 <somlo> which is addmittedly weird, beacause gen.py shouldn't even come into play when building a litex SoC with "--with-ethernet"

14:59 <somlo> but weirdly enough, if I check out ec9bc57 (right before ec9bc57) the linux driver loads fine, and, before 7a44209, if *revert* 153c160 the driver also loads fine

14:59 <somlo> I'm very confused at this point :)

15:31 <tnt> Would anyone have a link to the vex configuration used in litex to run linux ?

15:31 <tnt> Does it use the Linux variant of https://github.com/m-labs/VexRiscv-verilog ?

15:31 <tpb> Title: GitHub - m-labs/VexRiscv-verilog: Using VexRiscv without installing Scala (at github.com)

15:32 <daveshah> tnt: almost, I think it actually uses https://github.com/enjoy-digital/VexRiscv-verilog

15:32 <tpb> Title: GitHub - enjoy-digital/VexRiscv-verilog: Using VexRiscv without installing Scala (at github.com)

15:37 <tnt> daveshah: tx.

15:38 <tnt> Failing miserably at trying to rebuild those though :/ https://pastebin.com/HrrysXTk

15:38 <tpb> Title: nt@ritsuko-ubnt:~/data/vex/VexRiscv-verilog$ sbt compile "runMain vexriscv.GenCo - Pastebin.com (at pastebin.com)

17:05 <somlo> _florent_, Xiretza: looks like I should rely on (my ability to use) git bisect a bit less :)

17:06 <somlo> last night I *thought* bouncing around in the liteeth tree made a difference in whether my liteeth linux driver would hang on boot or not, now it hangs no matter what I do in liteeth

17:07 <somlo> so I'm taking it all back, I really don't know what (combination of) litex and liteeth recent changes are causing the issue :)

17:27 <_florent_> tnt: sorry not sure i can help to generate Vexriscv, i only reused the instructions from @Dolu in the README more than 6 months ago, maybe it's no longer up to date.

17:29 <tnt> _florent_: Ah it's ok, got it worked out. Java version was too recent.

18:29 <somlo> _florent_: at least part of my problem might have been using ctrl-r to recall the last litex build command line I had used... Keeping multiple windows open, and logging into and out of the dev vm from many places during the day, I didn't notice I had retrieved the one where I'm asking for a 40MHz clock :)

18:30 <somlo> so now I'm trying again with the usual 60MHz, then I'm going bisecting again (if the problem still persists)

18:31 <somlo> so, apologies to everyone for the noise, will update if/when I figure out more about what's going on (and how I'm being an idiot) :D

18:35 <_florent_> somlo: no problem for the noise. From the quick test i did yesterday, it seems the problem also occurs in simulation, maybe it would be faster to bisect? (lxsim --cpu-type=rocket --with-ethernet --opt-level=O0)

18:46 <somlo> _florent_: I'll try both ways, see whether compiling trellisboard bitstream is slower than simulating rocket in verilator :)

18:47 <somlo> but thanks for the confirmation -- and now that I'm paying attention to my command line, bisect should hopefully produce something useful :)

18:57 <CarlFK> does someone have a URL to the $10 led driver board that has an fpga and 2 gig-e ports?

19:02 <somlo> _florent_: ok, so at litex commit #5b34f4cd and liteeth commit #ae10eea it works fine

19:02 <somlo> I'll take it from there and see what I can find...

20:37 <scanakci> I am a bit stuck when trying to use tftp to copy files into DRAM. My guess is that it is related to my network configuration (have very limited experience).

20:37 <scanakci> https://usercontent.irccloud-cdn.com/file/y6abQVkj/tftp.png

20:38 <scanakci> This is what I am getting after some time on FPGA.

20:39 <scanakci> I followed this link to set up tftp on my machine (https://askubuntu.com/questions/795481/how-can-i-make-my-tftp-server-visible-available-on-my-local-network). Also, I looked into this link to get more info: https://github.com/timvideos/litex-buildenv/wiki/Networking

20:39 <tpb> Title: networking - How can I make my tftp server visible/available on my local network? - Ask Ubuntu (at askubuntu.com)

20:40 <scanakci> I also put a fake boot.bin file under /tftpboot folder

20:43 <scanakci> I connected the ethernet cable to my host machine by using a usb Ethernet Internet Adapter.

20:44 <scanakci> The ip for this interface is set 192.168.1.100 (not sure if this is correct)

20:44 <scanakci> https://usercontent.irccloud-cdn.com/file/SqeUEGW0/ethernetadapter.png

20:46 <scanakci> it would be great if you can point out some useful links that can help me for setting up tftp properly (or ways to debug where the problem originates from).

20:56 <somlo> scanakci: you have to ensure that your host machine has 192.168.1.100 as one of the available IP addresses on the network interface you connected to the fpga

20:57 <somlo> the way I do that is "sudo ip addr add 192.168.1.100/24 scope global dev enp1s0"

20:57 <somlo> replace enp1s0 with whatever your network interface is named

20:58 <somlo> then, obviously, "systemctl start tftp.service"

20:58 <somlo> last, but not least: I tried connecting my laptop with an ethernet cable to the fpga board, and nothing happened

20:59 <somlo> some auto-negotiation speed/duplex failure

20:59 <somlo> it did work when I used a cheap/generic gigabit capable switch, and connected both the laptop *and* the fpga to it with rj45 cables

21:00 <somlo> haven't had a chance to track down why direct point-to-point didn't work (I tried with a straight-through *and* with a cross-over rj45 cable, neither worked, not even after manually hard-coding the speed/duplex settings on the laptop side)

21:04 <scanakci> Thank you so much @somlo. I will try it soon.

21:04 <somlo> at any point after connecting the fpga to the computer, whether through a switch or directly, you can (should) run a sniffer, e.g. "tshark -i enp1s0 host 192.168.1.50" to check for any sort of activity

21:44 <somlo> _florent_, Xiretza: seems to work fine (if I pick 60MHz) with current git masters (57fb3720 for litex, 466223e for liteeth)

21:44 <somlo> on trellisboard, so I didn't try the simulator

21:47 <levi> I'd highly recommend running a sniffer to debug network problems, but be aware that you typically won't see problems below the layer of complete and correct Ethernet frames, and when you're dealing with a FPGA, that's unfortunately a likely layer for errors to occur in. There's a program called `ethtool` that will sometimes let you configure a NIC to accept malformed frames anyway instead of dropping them, but there needs

21:47 <levi> to be support in both the NIC and driver for it to work.

21:51 <somlo> I spoke too soon, it boots, gets past the linux liteeth driver initialization to the busybox shell prompt

21:51 <somlo> but when I try ifconfig on eth0, I get "LITEETH_READER_READY timed out"

21:52 <somlo> so that behavior is relatively new, and should be something I can use as a bisect criterion

21:54 <somlo> levi: thanks, but it's not really a "network" problem, it's getting Linux to talk to liteeth before driving it to generate network traffic to begin with

21:55 <somlo> interestingly, tftp seems to work from the bios (that's how I get my kernel), but then the driver I had that used to work from inside linux is now either hanging during initialization (on boot) or seriously malfunctioning once it got past inititialization

21:56 <somlo> it's entirely possible (althoug I'm not sure yet) that the LiteETH "hardware" (RTL) is now *better* than before, and the linux driver needs to be updated.

22:37 <scanakci> @somlo: I plug FPGA and my machine to a switch. Also, I did "sudo ip addr add 192.168.1.100/24 scope global dev eno1". However, still no luck :( .

22:38 <scanakci> Unfortunately, could not catch any packet with tshark for 192.168.1.50.

22:43 <scanakci> ip addr shows returns this. I assume 192.168.1.100 is one of the available IP addresses on the network interface now https://usercontent.irccloud-cdn.com/file/FOFUIEqq/ipaddr

22:50 <somlo> scanakci: for about the last year I've plugged the fpga into a switch port that also has my workstation on a different port, and things worked fine

22:51 <somlo> then a few days ago I set up a laptop for a "portable" demo I wanted to do in a conference room, and tried to use a single rj45 cat6 ethernet cable between the laptop's usb-ethernet dongle and the fpga

22:51 <somlo> not one single ethernet frame made it across

22:51 <somlo> until I plugged them both into a netgear switch, then they started talking :)

22:52 <somlo> so there's something (probably on the LiteETH side) that doesn't autonegotiate speed, duplex, or mdi/mdix properly

22:52 <somlo> but if you go through an ethernet switch, it works (at least for me)

22:52 <somlo> wait

22:52 <somlo> you said you did that -- sorry, my reading comprehension is not the greatest today :)

22:54 <somlo> and yeah, your ip address lools ok

23:02 <daveshah> I've never had any issues with liteeth directly connected to a proper motherboard Ethernet port

23:03 <daveshah> With a cheapo realtek USB adaptor I have had issues before, primarily with NFS but once or twice TFTP too

23:03 <daveshah> Pretty sure that was just dodgy PC side Linux drivers as much as anything else

23:15 <somlo> daveshah: dodgy pc-side cheapo usb ethernet, passed-through by osx to the linux VM I was using :)

23:16 <somlo> the only one I had handy at the time, though (aside from the 4-port netgear switch sitting around in a drawer :)

23:16 <somlo> which was really a last-ditch effort to throw something at the wall and see if it sticks -- and it stuck!

23:16 <daveshah> In a similar situation I had three different USB ethernet dingles handy and all used the same dodgy chipset

23:16 <somlo> that's how cargo-cult style myths are born, I guess...