09:45 <dsimic> qschulz: very nice! :) I was already aware of the CH348 IC, but I haven't looked up the multiport adapters based on it

09:47 <dsimic> when it comes to WaveShare's USB UART adapters, just make sure that the available voltage levels are actually applied to the bridge chip itself, i.e. to the TX and RX lines, because some WaveShare adapters that I checked in detail applied the adjustable voltages to the separate Vcc pin only, while the bridge IC and the TX/RX lines were kept at 5 V

09:49 <dsimic> on top of that, many (if not all?) Rockchip SoCs should actually use voltages lower than 3.3 V on their UARTs... 3.3 V is, basically, stretching it into the maximum allowed voltages, which may beb accounted for the random UART failures in the field

09:49 <dsimic> Ermine: ^^^

09:49 <dsimic> s/may beb/may be/

09:52 <qschulz> dsimic: source?

09:53 <qschulz> The datasheet specifies max supported voltage for the 3.3V power rails is 3.63V

09:53 <qschulz> (for RK3588)

09:54 <dsimic> let me look it up...

09:54 <qschulz> an issue could be that the UART you want to access belongs to a power domain which can change its voltage to 1.8V (for other SoCs which need io-domains driver)

09:54 <dsimic> I'm currently importing more CH348 datasheets into my local archive :D

09:55 <qschulz> but then feeding it 3.3V is bad because you're outside specs and may damage the SoC as stated by Rockchip

10:12 <CounterPillow> qschulz: I've been using my self-designed CH348 based boards for a while now, they work well, but mainline driver still hasn't been merged iirc. I did manage to somehow damage one UART port on mine though, not sure how.

10:16 <Ermine> i have ch340 adapter

10:20 <qschulz> CounterPillow: mmm sad to hear it's not supported mainline yet :/

11:07 <Dex2x> I like the one I got that does multiple voltages

11:07 <Dex2x> Was a DSD Tech SH-U09C5 I got , can do 2.5, 3.3, 5, 1.8volt

11:29 <walter> Wait, that's why I sometimes get jibberish on the Radxa Rock 4B+ UART? It only has 5V and 3.3V, but it works, most of the time. Good to know. Thanks!

11:43 <dsimic> qschulz: sorry, I got distracted with various unrelated datasheets... :/

11:46 <dsimic> hmm, I'm having troubles finding where exactly I found that in Rockchip datasheets

11:46 <dsimic> I'll dig a bit deeper

12:13 <Ermine> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/tree/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi#n567 --- is it fine if address after @ and address in reg do not match? Usually they do

12:14 <mmind00> Ermine: they should definitly match :-)

12:15 <mmind00> qschulz: that waveshare thing really looks neat

12:16 <Ermine> oh nice, ezpz patch

12:16 <Ermine> the same typo is present in downstream kernel

12:19 <Ermine> ... in 6.1

12:25 <Dex2x> also need to set the correct Baud rate

15:56 <Kwiboo> qschulz: I got a few CH348Q-EVT-R0 boards that I am using for my new lab, they where smaller and cheaper than the waveshare 8ch ttl I was originally planing on getting, I think the waveshare one use the CH348L variant to support rts/cts for all 8 channels

16:01 <Kwiboo> they work pretty well, I had to use a CH34xSerCfg tool to write a custom serial number into eeprom, to make it easier to identify correct tty dev when I have two ch348q boards connected to single host using downstream linux kernel driver

16:07 <CounterPillow> I've been using the by-path thing in /dev to differentiate between several identical USB-UART adapters, since I tend to leave them plugged into the same USB ports

16:08 <CounterPillow> preliminary v9 revision of mainline driver is here atm https://github.com/xdarklight/ch348/tree/v9-prep-20250804

16:31 <Kwiboo> CounterPillow: possible my issue is related to use of downstream kernel driver, I did not manage to easily identify what ch348 board+channel a tty is related to for my labgrid env, will double check by-path once more, and I should probably try the mainline driver at some point :-)

16:33 <CounterPillow> I do recommend trying it as I've found it works for my purposes, also feel free to drop by #ch348 (though it's not very active)

16:34 <Kwiboo> with a serial number I could easily get labgrid to use correct tty more dynamically, I am still moving things around so exact usb ports are not yet fully stable :-D

16:39 <CounterPillow> I have yet to set up a lab at home, I keep putting it off :(

16:40 <CounterPillow> Maybe when I have a week off in November

16:52 <Kwiboo> hehe, I have also put it off for far too long, so I started looking into how I could get something not too pricy working some weeks ago, settled on using ch348q boards for serial console, using poe or usb port for power and ramboot from usb/network, seem to be working good enough so far

17:02 <CounterPillow> so are your boards completely blank, and you ramboot a u-boot binary that then network boots a kernel?

17:15 <Kwiboo> yes that is my plan, would like to get some sdmux or similar at one point for a few boards, not fully sure of the direction of this project yet, I was mostly tired of having to swap out sd-cards and what boards is hooked up to my main host

17:18 <Kwiboo> I also got some hdmi switches for the project, should hopefully ease up testing boot up and media playback with libreelec :-)

17:58 <mmind00> That was the same reason for my farm back in 2016 :-) ... not having the mess on my desk

17:59 <mmind00> though I stopped at tftp-booting the kernel + nfsroot ... with u-boot staying on the board

18:03 <mmind00> and all the serial stuff happening in a web-brower

18:03 <mmind00> now that we have that hdmi-rx driver for the rk3588 (a Rock 5 ITX is my main controller) ... I should try to find time to add my planned hdmi-to-webbrowser function :-D

18:24 <Ermine> is that driver to make board serve as a hdmi sink?

18:26 <CounterPillow> yes, RK3588 has HDMI receiver hardware, the mainline driver exposes it as a v4l2 device

18:30 <Ermine> oh cool. add a tv tuner and you can have a smart tv