00:17 <mithro> Yay it seems to be working!

00:17 <mithro> xobs: ^

00:17 <xobs> mithro: yay!

00:18 <xobs> No Etherbone requests? That's odd. What if you use litex-devmem2?

00:19 <xobs> You should be able to use the `-d` option for "direct" (i.e. no litex_server in between) communication. For example, `./litex-devmem2 -t 192.168.100.50 -p 1234 -d 0x40000000`

00:19 <mithro> xobs: Etherbone requests are working

00:19 <mithro> It took me a while to rework the Python code

00:19 <xobs> Oh good. Etherbone over UDP (i.e. in hardware)? Or, oh! There was a time delay.

00:19 <xobs> Cool.

00:22 <mithro> Yes

00:22 <mithro> And Etherbone over TCP->UDP via the Python bridge

01:39 <xobs> _florent_: let me know when you make that crossover-uart change and I'll remove the _ev_ write from the wishbone bridge.

01:39 <xobs> But now that I've a working device, I've verified Ethernet support now works in `wishbone-tool`.

01:41 <xobs> I'll release a new version once the crossover patch is in. But the basic method is to run `wishbone-tool --ethernet-host 192.168.100.50 --csr-csv csr.csv -s gdb`

04:14 <scanakci> __florent_: I rebased my changes. It is ready for revision. For a reason, travis fails. I checked rocket and vexriscv with simulator and they work fine. Please let me know if anything is breaking previous commit.

04:14 <scanakci> _florent_:

04:15 <scanakci> _florent_: Currently, simulation for Litex-BIOS works with --with-sdram. I am working on LiteDRAM for running on FPGA.

05:33 <_florent_> mithro, xobs: thanks for the feedback on Etherbone, i just set rx_fifo_rx_we to True in LiteX

05:34 <_florent_> scanakci: thanks, i'll start reviewing the code

11:59 <mithro> _florent_: Next step is to actually build gateware in https://github.com/litex-hub/linux-on-litex-vexriscv/pull/71

11:59 <tpb> Title: Conda environment + Travis CI support by mithro · Pull Request #71 · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

12:30 <daveshah> somlo: if you ever get bored of ECP5, I've got the Rocket LiteX Linux example working on an Arty A35 with nextpnr-xilinx (and router2). Takes a while to build, and still a bit hacky, but if you're curious I can send you some instructions - https://asciinema.org/a/PNfFzebBV8RzgoCzeIBBokBjk

12:30 <tpb> Title: untitled - asciinema (at asciinema.org)

14:23 <somlo> daveshah: awesomeness!

14:26 <somlo> now all I need is micro-sd support (guess on the arty we could hook one up via pmod) to boot a pre-populated "real" distro

14:33 <somlo> $DAYJOB will get in the way for the next week or so, but maybe I can start by putting in an order for an arty board :)

14:39 <somlo> daveshah: does it matter (for the purpose of fully-open nextpnr-based workflow) if it's an A35 or an A100? The A100 arty might actually have room for the Rocket's FPU option (just like the nexys4ddr does)

14:40 <somlo> although the 256MB RAM (while double the nexys or versa) is still nowhere close to even the 1Gig on the trellisboard :)

14:45 <daveshah> The A100 isn't supported by prjxray yet, it wouldn't be much work but it wouldn't be out of the box either

14:45 <daveshah> There's also no DSP support yet so no GPU quite yet

14:45 <daveshah> *FPU

14:49 <somlo> daveshah: understood; while we're at it, is e.g. the nexys4video (512MB DDR3, yay!!!) in a similar situation, prjxray-wise? (it has an A200 chip)

14:49 <daveshah> Yes, although I think someone was working on A200 support

14:52 <somlo> daveshah: I'm at a point where I want to be careful about where I spend my (mostly political) capital when asking my boss to buy me stuff :)

14:52 <daveshah> Yeah, might be best waiting to see what happens in terms of support before buying anything

14:53 <somlo> not like there isn't ample work for me to still do getting sd support and actually trying to boot a "real" distro

14:54 <somlo> for the *next* FOSDEM ;) (really disappointed about $dayjob scheduling messing up my plans to show up for this upcoming one)

14:54 <daveshah> The 35T is actually too big for a Rocket+Ethernet SoC with Vivado - it's only the fact that's its really a 50T under the hood that makes it work with nextpnr...

14:56 <somlo> daveshah: is it a 50T that's marginal for some other reason that they determined has enough "good" cells to act as a 35T, or simply a "cheaper to make 50s only and sell lobotomized ones to the cheapskates" pure-marketing thing? :)

14:56 <daveshah> Vivado limits resource count, not parts of the chip, so it's not based on any kind of binning, just market segmentation

15:00 <daveshah> And I think Xilinx, Intel and Lattice all do this

15:01 <daveshah> It does show how much the cost of a mask set affects semiconductor economics

15:06 <sorear> even if masks were free, there’s a significant lead time difference

15:07 <sorear> if the 35 were a smaller chip with its own early masks, they’d need to predict demand 12 weeks earlier

15:11 <somlo> it's an *old* trick, too. There's the story (can't find a link) about the 70's IBM mainframe customer who wanted a faster CPU, and after they paid an arm-and-a-leg in upgrade costs, IBM sent over a tech to *remove* the "speed-limiter" they had pre-installed

17:01 <_florent_> daveshah: nice for Rocket on Arty with nextpnr-xilinx!