13:00 <xdarklight> montjoie: I got a small CH348 dev board and started playing with it. the issue with the TX buffer overrun is weird though... maybe we can brainstorm a bit? I implemented the status/interrupt handling here: https://github.com/xdarklight/ch348 - and I thought I'd "just" have to wait for the R_II_B2 status, but it's still causing problems :-(

16:47 <f_> New EOFD: MMC: block number 0x101 exceeds max(0x0)

16:47 <f_> (error of the day)

16:48 <f_> looks like mmc->block_dev->lba is 0 for some reason

17:35 <f_> It actually couldn't select a mode and width: spl: mmc init failed with error: -524

17:37 <f_> https://bin.vitali64.duckdns.org/65c9059b w/ diff: https://bin.vitali64.duckdns.org/65c905d7

17:38 <f_> Some of it is me trying to get power init to write to the right registers to not mess around with mmc

18:04 <xdarklight> montjoie: with https://github.com/xdarklight/ch348/commit/ee063f320d17517eeb98fbd5f1cceec8a7f0f581 I have most of the tests of your test2a2.py script passing. only the 2048 byte buffer size case is broken (for all baud rates, and pretty consistently ~500 bytes are different)

21:15 <montjoie> xdarklight: thanks having working on it, my last try is to debug the vendor driver to find the difference, but fail to alloc time on it

21:29 <xdarklight> montjoie: I also wish that some days would have 36 or 48 hours. if you find the time to review my changes: I'm confident that I got the status reading correct. the main issue is that we're supposed to only take more data when we're notified by the hardware that the TX/write buffer of a port has been drained/sent out. I implemented "waiting for that TX/write buffer empty status event". I think it means we need to implement a custom .write

21:29 <xdarklight> callback (which I did). if you have questions: you know where to find me ;-)