01:13 <xobs[m]> Hi cr1901 , I hear you had questions about Valentyusb.

03:18 <cr1901> Hi xobs[m], I'm here now for a little bit, lemme see if I can find the relevant IRC msg to link

03:20 <cr1901> xobs[m]: So while I'm looking, I'll give some context

03:20 <cr1901> Recently I designed a litex SoC for orangecrab optimized to take advantage of it's feather functionality

03:21 <cr1901> I'm using the Betrusted I2C core and valentyusb: https://github.com/cr1901/orangecrab-feather/tree/main/deps

03:22 <xobs[m]> Alright, it's been a while but I can try to answer any questions.

03:25 <cr1901> xobs[m]: I don't think it's a difficult question, just I'm not sure where I should "tack on" the functionality I need

03:25 <cr1901> The problem w/ my SoC as-is is that the UART TX will block until a host opens the USB port

03:26 <cr1901> There is a solution for non-USB UARTs in LiteX: https://libera.irclog.whitequark.org/litex/2022-03-06#1646587326-1646588438;

03:26 <tpb> Title: #litex on 2022-03-06 — irc logs at whitequark.org (at libera.irclog.whitequark.org)

03:27 <cr1901> Aaand I'm looking for the follow-up msg and can't seem to find it

03:29 <xobs[m]> Are you referring to a `UARTCrossover` implementation? Or is there a new version where it shows up as an actual serial device now?

03:30 <cr1901> In today's LiteX, valentyusb is an actual UART that the SoC can talk to

03:31 <cr1901> https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1227-L1236

03:32 <cr1901> https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L281-L298 This is the code to add an automatic TX flusher. It doesn't work for ValentyUSB because ValentyUSB doesn't actually have a stream endpoint w/ the correct name.

03:32 <cr1901> I was looking for an error message in the IRC logs, but I can't seem to find it. Give me a minute to duplicate

03:32 <cr1901> My question is: "How difficult would it be to modify valentyusb to support auto tx flush?"

03:33 <cr1901> xobs[m]: Whoops, sorry for not mentioning you :P ^

03:35 <xobs[m]> I'm not sure right now, I'll need to think. I think what you want is for it to drop data if it hasn't been read in a while, correct?

03:36 <cr1901> yes, because if it doesn't the SoC program will busy wait sending the BIOS banner and status messages until I connect a terminal

03:37 <cr1901> While I have to connect a USB cable, waiting for me to open a terminal for the main SoC program to run is not necessarily what I want (SD card boot, for instance)

03:39 <cr1901> xobs[m]: Take your time, btw. This isn't/wasn't urgent, and I wasn't actually expecting this quick a turnaround time :D

03:39 <cr1901> Just something to send off async and awai- *pulled off the stage by a hook*

03:45 <cr1901> http://gopher.wdj-consulting.com:70/paste/a71cee6d-266b-46b8-9941-5e4f9355f28c.txt\

03:45 <cr1901> http://gopher.wdj-consulting.com:70/paste/a71cee6d-266b-46b8-9941-5e4f9355f28c.txt

03:46 <cr1901> Yea, this is the error I recall seeing... add_auto_tx_flush would need to be added on the valentyusb side, and I'm not sure how to go about doing it

03:46 <xobs[m]> I actually have to go soon as well. But wouldn't it be possible to wrap the `tx_fifo` inside a `ResetInserter()` and add a timer to reset it if `tx_fifo.valid` is 1 for a very long time: https://github.com/litex-hub/valentyusb/blob/912d8e6dc72d45e092e608ffcaabfeaaa6d4580f/valentyusb/usbcore/cpu/cdc_eptri.py#L148-L161

03:48 <xobs[m]> Yeah, that's how I'd do it. Place the `tx_fifo` inside a `ResetInserter()` similarly to how the address field is in one, then reset the whole tx fifo when it is Valid for too long. https://github.com/litex-hub/valentyusb/blob/master/valentyusb/usbcore/cpu/eptri.py#L225-L234

03:50 <cr1901__> xobs[m]: Wifi is going to hell rn.

03:50 <cr1901__> Anyways, I didn't think of that. That's a reasonable idea and I'll look into trying it

03:50 <cr1901__> I'll send a PR if it works- no need to be compat w/ litex's add_auto_tx_flush

03:54 <xobs[m]> I think it's possible to still be compatible, and I'm curious to see how well it works.

03:56 <cr1901> the litex version drains the TX fifo one entry at a time, every interval, after timeout has occurred (without any activity from the PHY)

03:57 <cr1901> your solution sounds like "when timeout has passed, drain the fifo all at once"

03:58 <cr1901> That being said, I see that tx_fifo in CdcUsb is similar to the litex UARTs, so when I get the chance I'll play w/ it

03:58 <cr1901> Thanks for the hint

04:04 <cr1901> xobs[m]: It's midnight here, and while my sleep schedule hasn't been great the past few days, I've also lacked the b/w for most FPGA type stuff :P

04:04 <cr1901> Otherwise I would do it tonight

04:49 <AndrewD> @mithro: thanks for the spreadsheet link

04:52 <AndrewD> I'm intrigued by renode, I've thought about using it but was concerned that it may be another rabbit hole that takes quite a bit of time to get up to speed with. The high level introductory information available makes it look almost too easy to get started with demos, but it only gets useful when you dive into the less trivial stuff.