08:08 <narmstrong> xdarklight: you basically came to the same conclusion as me, I have no board to help both of you....

08:18 <montjoie> narmstrong: I will put in production some extra board and I can share you one

11:14 <xdarklight> montjoie: narmstrong: I got one of these CH348 boards from aliexpress for ~15 USD. it seems they have gotten cheaper since - only ~11 USD now: https://www.aliexpress.com/item/1005006398789929.html - you'll have to solder the pins (which are supplied) yourself though (but that only takes a few minutes and is super simple since it's all DIP with 2.54mm pitch)

11:39 <montjoie> xdarklight: I use a custom design which permit stacking AND RS232 daughter board

12:01 <xdarklight> montjoie: sure, aliexpress designs won't give you that kind of flexibility. my use-case is simpler: getting rid of a bunch of individual CH340 and replace them with a single CH348

17:31 <narmstrong> phh: just saw I had -@ in my env, so yes you'll either need to pass -@ to build the DTB or let the kernel do the overlay apply

17:32 <narmstrong> so I need to fix the vim3 panel dtbo build aswell !

17:32 <narmstrong> (and sorry for the delay to reply...)

17:32 <phh> narmstrong: good thanks. and happy to catch a bug for you :P

17:35 <phh> narmstrong: no problem, that was fast enough

17:59 <phh> narmstrong: wrt the dtbos, they'll be automatically loaded on runtime (no need for user intervention) based on mmc pid/vid for those dtbo, and based on a saradc value for dvb dtbo when they come. Is there some already existing framework for that, or we'll just live with our own shell script doing that?

18:07 <narmstrong> phh: there’s nothing generic, but if you use fit image the dtbo can be specified in a configuration which is selectable at runtime when loading the fitimage

18:08 <narmstrong> You’ll still need to code the logic on shell or C to determine the fit configuration

18:08 <phh> well, fixing the bootloader is rather out of spec for me at the moment. Maybe with kexec though (as in, by adding a new bootloader stage)

18:10 <phh> so yeah that'll be some custom shell script using dynamic overlay

18:19 <xdarklight> montjoie: I think I know why the 4096 byte case is not working - the CH348 datasheet states: Integrated the 2048-byte RX FIFO and 1024-byte TX FIFO for each UART.

18:21 <xdarklight> s/4096/2048/

20:08 <xdarklight> montjoie: hmm, no - that's not it. RX buffer size of 1280 works fine, but 1536 is already problematic

20:09 <xdarklight> montjoie: but I found another issue and a matching fix: https://github.com/xdarklight/ch348/commit/359312432578899ef50870032794b73da937879e

20:26 <xdarklight> montjoie: oh, the vendor driver even has issues with 1024 byte buffers :D and it also fails with 2048 bytes. so I think what we have is good ;-)