06:42 <_florent_> somlo: Good for the Fedora progress. Charles got his 64-bit NaxRiscv booting Debian, this could probably be a nice alternative to Rocket for your project (but it's optimized for 7-series for now, tests on ECP5 will have to be done)

06:43 <_florent_> minute: The RGMII PHY only works with a 1Gbps Switch/Port in front, so I would recommend making sure speed is negotiated at 1Gbps.

10:19 <minute> _florent_: thanks for confirming. for some reason, i get only a 100mbit link at the moment. there's no way to make the phy work with 100 mbit, yes?

11:19 <minute> _florent_: ok i swapped out the PHY chip and it works now with 1gbe

11:42 <minute> in linux i get > [ 293.997306] liteeth f0003000.mac eth0: LITEETH_READER_READY not ready

11:47 <minute> ah, dts issue

12:11 <minute> _florent_: are there any examples of OHCI host code i can copy? i now have a new revision of the kintex-7 module where i have USB DP/DN on fpga pads, plus a 1.5k pull resistor output (copied from valentyusb)

12:16 <minute> ah, i see there is USBOHCI

13:09 <somlo> gatecat: just for grins, I did a little experiment trying to build a fpu-capable litex+rocket for the ecpix5:

13:10 <somlo> litex-boards/litex_boards/targets/lambdaconcept_ecpix5.py --build \

13:10 <somlo> [ --yosys-abc9 --yosys-nowidelut ]

13:10 <somlo> --cpu-type rocket --cpu-variant fulld --sys-clk-freq 50e6 \

13:10 <somlo> --nextpnr-seed $RANDOM --nextpnr-timingstrict \

13:10 <somlo> --with-ethernet --with-sdcard \

13:10 <somlo> (also at https://pastebin.com/LCwjhR3K)

13:11 <somlo> I'm trying to get fmax 50MHz (I suspect it's why the thing fails to properly train litedram). Here's the box plot of `nowidelut` vs. `abc9`:

13:11 <somlo> https://imgur.com/a/IQftIDa

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

13:12 <somlo> tldr -- `yosys-abc9` by itself (without `yosys-nowidelut`) results in the highest (40-ish MHz) fmax, when asking for 50

13:12 <somlo> I did 9 runs for each combination, so not a huge sample size, but still :)

13:18 <minute> hmm hmm i have the ohci controller from spinalhdl building in litex, but the dts generator is looking for if "usb_ohci_ctrl" in d["memories"]:

13:18 <minute> usb_ohci.py doesn't mention anything about CSRs...

13:19 <minute> it has a wishbone dma interface, i guess i have to map that into memory somehow

13:19 <somlo> gatecat: in case you can think of any additional "knobs" (on either yosys or nextpnr) I could be turning for extra optimizations; if not, take it as just a bunch of data points :)

13:20 <somlo> _florent_: does Charles have a write-up (maybe similar to linux-on-litex-rocket) with his litex build command line, dts, and whatever else he did to boot the OS?

13:21 <somlo> I could try to replicate that on one of my xilinx boards, then see how well it translates to ecpix5 and/or trellisboard with yosys/trellis/nextpnr

13:23 <somlo> honestly I'm not really stuck on rocket, if I can get a Free rv64gc design to boot fedora, I can declare victory, retire, become a consultant, whatever :)

13:27 <minute> ahh, here's an usb host integration example https://github.com/litex-hub/litex-boards/blob/cf030402d496102005161023b8d27123546ae53d/litex_boards/targets/machdyne_schoko.py#L132

14:16 <_florent_> minute: sorry, was away. Good the the Ethernet PHY

14:17 <_florent_> minute: it should be possible to get things working at 100mbps, but someone needs to have a look at it :) (haven't spent time on it yet)

14:17 <_florent_> minute: otherwise, for OHCI, I'm pretty sure this has been integrated in linux-on-litex-vexriscv recently, let me look

14:19 <_florent_> minute: looking at https://github.com/litex-hub/linux-on-litex-vexriscv/pull/293/files should allow you to see what needs to be done

15:57 <gatecat> somlo: I would investigate the flow3 stuff at https://github.com/Ravenslofty/yosys-cookbook/blob/master/ecp5.md

15:57 <gatecat> it's the best remaining knob I can think of

16:53 <minute> _florent_: thank you, ohci works now! i have some new weirdness with the framebuffer, somehow there's address confusion. i will dig into it tomorrow. i've moved the framebuffer base to 0x4fc00000 (in soc.py). but i've noticed that writing to memory at 0x4fc00000 doesn't have any effect on the random pixels. but when i set the base address to 0x0fc00000 via videophy register poke, i can see those

16:53 <minute> changes in memory

16:53 <minute> (on screen)