08:13 <_florent_> cr1901_modern: we should probably fix this in the gateware, I'm currently trying to remove such workarounds from LiteX :) I could also look at that if you create an issue with your findings

09:30 <zyp> sounds to me like the root problem is that the queues don't support resetting only half of it

09:32 <zyp> I imagine that will be an issue anywhere you deliberately want to reset only one of the clock domans it is crossing

09:34 <zyp> so I figure the right solution would be to somehow reset both sides of the queue even if only one of the clock domains are reset

09:49 <_florent_> zyp: thanks, that's also what I was thinking. Doing a reset of both side should still allow the link to stay up.

11:40 <cr1901_modern> _florent_: I will open an issue in a few hours, when I'm a bit more awake. I have an idea how to fix it.

11:42 <cr1901_modern> Hopefully nextpnr-ecp5 won't allocate more than two extra SLICEs with my changes, but I'll measure and see

11:45 <cr1901_modern> _florent_: Basically, my idea is to add a third clock domain to the CdcUsb core- it uses usb12's clock, but it has a separate reset that comes from the system clock domain (internally synchronized by the CdcUsb module)

13:40 <_florent_> cr1901_modern: ok thanks

13:44 <cr1901_modern> _florent_: I opened an issue, but for now I'm taking a break from litex issues. I'm satisfied that I figured out the problem.

13:45 <cr1901_modern> I wanted to test orangecrab out, litex was a good way to do this, and the USB serial issue was the "big" issue I wanted to fix w/ litex

13:48 <_florent_> cr1901_modern: sure, thanks a lot already for looking at this. What's the occurrence of the issue (just to give me indications when I'll try to reproduce)?

13:50 <cr1901_modern> "python3 litex_boards/targets/orangecrab.py --l2-size=0 --integrated-rom-size=24576 --integrated-sram-size=4096 --integrated-main-ram-size=16384 --cpu-variant=minimal --uart-name=usb_acm --doc --build --load", type a char at the UART, then press button to reset

13:51 <cr1901_modern> Chances are, the UART will stop echoing back. Type a few more characters, and the CPU completely stops responding

13:51 <cr1901_modern> >Chances are, the UART will stop echoing back

13:51 <cr1901_modern> Sorry. Let me rephrase.

13:52 <somlo> _florent_: 697ff744 broke add_uartbone() for me

13:52 <cr1901_modern> The UART will echo fine. But if you type in more characters into the terminal after resetting via push button, chances are the chars will not be echoed back

13:52 <geertu> cr1901_modern: Is this related to the issue where you copy and paste a command into lxterm, causing lxterm to crash, _and_ the orangecrab needing a cold reboot?

13:52 <cr1901_modern> And eventually, the CPU will infinitely wait for the USB to drain it's TX queue

13:53 <cr1901_modern> geertu: I don't know

13:53 <cr1901_modern> This crash only happens after I've reset using a pushbutton

13:53 <somlo> _florent_: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1170

13:54 <somlo> that should be `self.platform.request(name)` and s/bandrate/baudrate/ :)

13:55 <somlo> even then, I now get something about "TypeError: unsupported operand type(s) for /: 'int' and 'NoneType'" from the UARTPHY initialization call

14:00 <_florent_> somlo: sorry, this should be fixed

14:01 <_florent_> https://github.com/enjoy-digital/litex/commit/8623b0a16ad65c0ff76c50409ac8a4500370fde2

14:04 <_florent_> cr1901_modern: ok thanks, so we should make sure both side of the CDC have a proper reset on push button reset or avoid propagating the system reset to the CDC. I'll have a closer look next week

14:04 <somlo> _florent_: thanks, building ok again :) Is the idea to go back to using the "normal" uart for console and do litescope over JTAG?

14:10 <_florent_> somlo: I'm working on a system where I only have a JTAG connector and want to be able to use the bridge for debug on this system, so I'm trying to get LiteX server running over JTAG

14:11 <_florent_> somlo: if working, you could swap things on your side yes if that's more convenient

14:12 <somlo> oh, so what I said would be a side-effect of that :) But it would indeed be more intuitive to keep the "normal" uart for "normal" console and do debugging over jtag :)

14:13 <somlo> I'm ok either way, now all I need is some peace and quiet from $DAYJOB to focus on what signals I want to trace and how to trigger the capture at just the right time...

14:19 <geertu> cr1901_modern: The board indeed crashes when holding ENTER in lxterm, and pressing the board button

14:19 <geertu> A large copy-and-paste into lxterm is a different issue. If I don't press the button, it recovers. If I do press the button, it probably triggers the above issue.

15:14 <geertu> Created https://github.com/litex-hub/linux-on-litex-vexriscv/issues/187

15:20 <_florent_> geertu: thanks, I also saw something similar. Note that's it's only happening with the CDC ACM UART that is a bit "hacky"

19:08 <cr1901_modern> geertu: What are the settings you use to build linux-on-litex-vexriscv for orangecrab? The RAM bringup doesn't seem to work on mine (but I have a prototype v0.2)

20:19 <_florent_> cr1901_modern: your issue is probably https://github.com/litex-hub/linux-on-litex-vexriscv/issues/174, it's still not fixed.

20:20 <cr1901_modern> _florent_: Yes, that's it. Thanks

20:22 <cr1901_modern> _florent_: I'm willing to take a stab at the CDC issue tonight. But after that, no more litex issues for me for now lol. I'm procrastinating and I need to stop

20:25 <cr1901_modern> for me after that*

20:26 <_florent_> cr1901_modern: I'm going to have a quick look at it now in fact, I'm just building the target to try to reproduce it

20:26 <cr1901_modern> Awesome, the command line I provided is a minimal SoC, designed for quick turnaround w/ nextpnr

22:01 <_florent_> cr1901_modern: I just pushed changes and update the PR, can you do a test and provide feedback? Thanks.

22:11 <cr1901_modern> _florent_: Will check in 2 seconds, please stand by

22:11 <cr1901_modern> I want to finish what I'm doing right now (downloading a bunch of docs) and then I'll move on to testing :)

22:48 <cr1901_modern> _florent_: Before I test this... https://github.com/litex-hub/litex-boards/commit/23760e2

22:48 <cr1901_modern> 1. Shouldn't this be added to _CRG as well?

22:49 <cr1901_modern> oh... it was already

22:49 <cr1901_modern> I misread

23:02 <cr1901_modern> _florent_: https://github.com/enjoy-digital/litex/issues/779#issuecomment-765733218 Seems to work fine