07:42 <dsimic> walter: (there's U4 connected to CC1 & CC2. It's a CH224.) I'm wondering what schematic you referred to? perhaps ROCK 5A, which does use CH224D

07:43 <dsimic> wens: as sre explained it already, ROCK 5B uses a full-fledged PD controller that's "prodded" by the CPU

07:47 <dsimic> Dex2x: (re: do you have a desktop card reader that supports A2) frankly, I don't know do I... :) specifically, I've got a couple of fancy card readers, made by Kingston and SanDisk, but their specs are basically useless

07:53 <dsimic> pinchartl: (re: I've replied to the mail thread) nice, thanks! I just went through the resulting discussion

08:00 <dsimic> Dex2x: (re: now everything is moving to SD Express) frankly, I don't care about SD Express, because no boards I'm interested in support it :)

08:04 <dsimic> wens: for completeness' sake, ROCK 5C also employs a simple way to perform PD triggering, using juat a couple of resistors, but it actually pulls 5 V only

08:36 <walter> Yes, I was looking at ROCK 5A.

12:00 <wens> dsimic: the resistor network method gives 5V 3A

15:57 <dsimic> wens: I'm not sure that 3 A at 5 V, i.e. 15 W, would be enough for the ROCK 5C to work reliably, which is the reason why Radxa sells a somewhat custom USB PSU that's capable of delivering 5 A at 5 V

16:10 <CounterPillow> without power hungry peripherals it is

16:13 <dsimic> perhaps

16:14 <linkmauve> Hi, my rock5b is now stuck in a loop of these two messages in dmesg, I’ve tried a different Ethernet cable:

16:14 <linkmauve> [ 26.305145] r8169 0004:41:00.0 enP4p65s0: Link is Up - 1Gbps/Full - flow control rx/tx

16:14 <linkmauve> [ 29.080819] r8169 0004:41:00.0 enP4p65s0: Link is Down

16:14 <linkmauve> It happens roughly every five seconds.

16:14 <linkmauve> And it makes Ethernet unusable, so I only have the serial connection now.

16:16 <linkmauve> Oh, if I set the link down then up again, [ 225.684989] r8169 0004:41:00.0: Unable to load firmware rtl_nic/rtl8125b-2.fw (-2)

16:18 <dsimic> hello! I'd assume that the other end of the Ethernet connection isn't capable of providing some diagnostics? also, are you in a position to try rebooting the board, to see will the issue go away that way, or will it start occuring again?

16:19 <linkmauve> I’ve rebooted the board already; the other side is a proprietary router with no debug whatsoever but I could plug it in another computer if that could help.

16:19 <linkmauve> I do have /lib/firmware/rtl_nic/rtl8125b-2.fw.zst though.

16:20 <dsimic> maybe trying with another computer at the other end would be good, to eliminate any possibility that it's the current peer's fault

16:21 <dsimic> regarding the firmware message, it's perhaps some bug in the NIC driver

16:24 <linkmauve> Ok, I probably forgot to build my kernel with Zstd support for loading modules, if I uncompress the firmware the thing is now stable.

16:25 <linkmauve> I wonder why it was working previously.

16:28 <dsimic> hmm, it seems that the driver doesn't like the firmware image, this triggers the firmware error from above:

16:28 <dsimic> 222 if (!rtl_fw_format_ok(rtl_fw) || !rtl_fw_data_ok(rtl_fw)) {

16:28 <dsimic> 223 release_firmware(rtl_fw->fw);

16:28 <dsimic> 224 rc = -EINVAL;

16:28 <dsimic> 225 goto out;

16:28 <dsimic> 226 }

16:28 <dsimic> (taken from drivers/net/ethernet/realtek/r8169_firmware.c)

16:29 <dsimic> ah, alright, so it indeed didn't like the firmware image, but for another reason :)

16:33 <linkmauve> I was missing FW_LOADER_COMPRESS=y and FW_LOADER_COMPRESS_ZSTD=y.

17:08 <walter> "It happens roughly every five seconds." --- linkmauve: that could be a PowerDelivery issue. Are you using a PD-enabled PoE addapter?

17:10 <dsimic> walter: if those were power-related issues, the entire board would be resetting in such a fashion

17:15 <walter> Oh, I thought you were talking about the whole board.

17:24 <dsimic> BTW, those PoE "ejectors" with USB-C plugs and PD support are quite neat

17:24 <dsimic> but the inherent complexity at both ends of such PoE setups is amazing, or even horrifying :)

17:28 <walter> yeah, I'm waiting for the day when we hear about a poorly designed device that has been exploited by a cable via the CC pins.

17:32 <linkmauve> No, I’m using a good GAN power adapter, which can deliver 100W at up to 20V AFAIK.

17:35 <dsimic> walter: that actually already exists, in form of smartphones that expose their debugging interfaces over USB-C's debug-access mode (DAM)

17:36 <dsimic> basically, whenever such a phone is plugged into a "random" charger, it's at the "charger's" mercy

17:46 <walter> Nice!

17:49 <dsimic> actually, it's debug accessory mode or whatever it's called, I can't remember exactly

21:53 <diederik> linkmauve: I never knew firmware could be compressed (and be usable for the kernel), so thanks for that :)

21:56 <diederik> ... turns out it was already enabled in my (and Debian's) kernel