03:08 <mithro> somlo: I would love to get linux-on-litex-rocket working with the Yosys+VPR toolchain, the linux-on-litex-vexriscv already works

03:10 <mithro> somlo: It would be good to get that potentially into https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html#xilinx-7-series and https://github.com/SymbiFlow/fpga-tool-perf too....

03:10 <tpb> Title: Building example designs SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io)

12:09 <zyp> when the bios uart is not a plain physical uart but an interface with flow control (e.g. crossover or usb-acm), what would be the reasonable way to not prevent the bios from booting until the interface is connected?

12:15 <zyp> I figure a simple solution would be to insert a «ready timeout» block in the tx stream, i.e. if downstream ready have been deasserted for longer than the timeout value, assert upstream ready so that any transmitted data is just blackholed

13:29 <_florent_> zyp: I also had to implement workarounds for this behaviour on some projects, this would indeed be good to implement a proper solution

13:37 <zyp> what would be a proper solution? :)

13:57 <_florent_> your solution seems fine, we could use a WaitTimer that waits when downstream ready is at 0 and set upstream.ready to (downstream.ready OR WaitTimer.done)

13:58 <_florent_> this way, as soon as downstream.ready is at 1, we get back to default behavior

13:58 <_florent_> and will have to wait again for the timeout to trigger the flush

13:59 <zyp> yes, that is the behavior I had in mind

14:52 <somlo> mithro: I'd also be curious to see if we can use a F/OSS flow to target xilinx chips for LiteX+Rocket; I haven't touched VPR in at least two years, though, so I'm really not familiar with all the moving parts...