08:28 <mmind00> CounterPillow: looks like your thermal driver changes have made it

09:10 <diederik> a3f: Thanks for your remark about the SDcard as that was the key to make the maskrom work ... even with output on serial :-)

09:12 <diederik> I had borked the system on eMMC and when there's a working system on SDcard (which I had) then it just boots that. Remove the SDcard and I no longer had a bootable system -> the SoC (?) automatically went into maskrom mode

09:13 <diederik> But when I put a working system on the eMMC and kept the SDcard unplugged, then the maskrom button did what I expected it to do :-)

09:22 <CounterPillow> mmind00: twice, even ;D

09:23 <mmind00> CounterPillow: though I somehow never saw v5 getting applied

09:23 <CounterPillow> it was applied the same day as v6, they just picked the wrong one by accident

11:55 <diederik> Is there some reason why I don't see RK3568_PD_LOGIC_ALIVE being used?

12:02 <CounterPillow> It's likely an always-on power domain that defaults to on, and nothing should ever turn it off, so modelling it in any way doesn't really carry tangible benefits and just has the downsides of implementation bugs causing it to be messed with in the PD hardware

12:05 <diederik> I guess you're right. It would also explain why RK3568_PD_CPU_N isn't used either

12:05 <diederik> Or RK3568_PD_CORE_ALIVE or RK3568_PD_PMU

12:08 <diederik> While the ALIVE PD is defined in Table 7-1 (page 474-476 of TRM Part 1), it's not mentioned in Fig 7-2 (page 474)

12:24 <CounterPillow> mmind00: so, is it too late for the TSADC DT patches to land?

13:30 <detlevc> chewitt: I was able to see the same issue as you with the jellyfin hevc 10 bits test video file using rkvdec + mpv

13:31 <chewitt> that's good .. always nice to know it wasn't my own incompetence :)

13:31 <chewitt> I have your ffmpeg building now too

13:32 <detlevc> thos test files don't seem to be using any long or short term ref frame sets, so you can use them without my ffmpeg patch for now (not that the patch would work anyway)

13:33 <chewitt> I am still in discovery mode for RK things .. so I just figured out vp9 has no driver yet (for vdpu381) and av1 lacks an ffmpeg hwaccel

13:33 <chewitt> but, aside from 10-bit HEVC, everything LE users normally want seems to generally work

13:34 <chewitt> I need to move the board to a proper TV to experiment with 4K stuff ..

13:35 <detlevc> yes, currently it's onle hevc/h264. AV1 might come soon but vp9 is not planned for now on my side

13:46 <chewitt> possibly dumb question .. but how is deinterlaced media handled currently?

13:46 <chewitt> s/deinterlaced/interlaced

15:04 <CyReVolt> write leveling took me a while because of course I made stupid whoopsies

15:04 <CyReVolt> https://mastodon.social/@CyReVolt/114865778826433902

15:08 <linkmauve> CyReVolt, woohoo, congrats!

15:09 <linkmauve> I’ll test it on my rk3568 board as soon as you have it working. :)

15:59 <CyReVolt> <linkmauve> "I’ll test it on my rk3568..." <- Thanks!... (full message at https://u.pixie.town/pixie.town/NlwQAqtGtWMxFMlCWGdhSCEn)

16:06 <qschulz> CyReVolt: try to avoid formatting, many people don't want to be clicking on a link to read you :)

16:07 <qschulz> CyReVolt: the biggest difference I know (or I think I know, I have never worked with rk356x devices :) ) is that RK3568 has ECC support and RK3566 doesn't

16:10 <CyReVolt> qschulz: That makes sense. There are indeed some cases even in the RK3566 binary, presumably leftovers, to handle ECC.

16:11 <CyReVolt> qschulz: Sorry, I'm not sure what you mean by formatting and how it relates to links, could you explain? 🥺

16:11 <qschulz> CyReVolt: https://libera.catirclogs.org/linux-rockchip/2025-07-17#38438902;

16:12 <qschulz> somehow your client (likely?) replaces your message with a link to the full message

16:12 <qschulz> I'm used to seeing this with Matrix clients bridging with an IRC server but I';m not sure we're bridging this channel?

16:13 <CyReVolt> huh weird - I have no idea how that happened, sorry... I'm here via Matrix, yes. :/

16:14 <qschulz> ah yes, then that explains it I think :)

16:14 <CyReVolt> #libera_#linux-rockchip:pixie.town is what I use

16:14 <qschulz> I think it may work if you simply do not use "fancy" things like newlines (and/or quoting)?

16:15 <CyReVolt> oh gotcha - I'll avoid newlines, that is doable

16:15 <qschulz> CyReVolt: let's see how if that is what triggered it :)

16:15 <diederik> CyReVolt: Most people use rk3566_ddr_1056MHz_v1.23.bin on rk3566 I suspect. IIRC the _ultra variant is for (extra?) power saving functionality?

16:16 <CyReVolt> I have no idea yet what the difference is. I went with the 528MHz one because it is small and I expected it to be simple.

16:16 <qschulz> diederik: very likely indeed as this is the one used by RKBOOT/RK3566MINIALL.ini

16:17 <CyReVolt> At some point, I will look at the other ones as well, but first I want to be done with one and have a rough idea how this stuff works. :)

16:17 <diederik> I wasn't aware of rk3568 supporting ECC, but it does support higher frequency (so the default is rk3568_ddr_1560MHz_v1.23.bin)

16:17 <qschulz> CyReVolt: yeah, starting small and having something working is already very nice

16:17 <qschulz> some people probably care more about an open DDR init than having it run at high(er) frequencies

16:18 <diederik> I guess you haven't been in the #pinetab channel then ;-P

16:18 <qschulz> diederik: https://opensource.rock-chips.com/images/b/b6/Rockchip_RK3568_Datasheet_V1.3-20220929P.PDF

16:18 <qschulz> Support 8bits ECC for DDR3/DDR3L/DDR4

16:19 <qschulz> which makes me really mad

16:19 <qschulz> WHY oh WHY haven't they added ECC support to RK3588 or RK3576?

16:19 <CounterPillow> RK3588 has ECC support

16:20 <qschulz> CounterPillow: publicly advertised?

16:21 <qschulz> or you mean the basic one that comes with DDR5?

16:21 <qschulz> (is it even there on LPDDR5?)

16:21 <CounterPillow> No I don't

16:22 <CyReVolt> I will take a quick glance at some binary diffs at some point. That could reveal how much they really diverge. I hope it's mainly configuration parameters and the logic is otherwise the same.

16:22 <diederik> qschulz: indeed. Also found it in my Rockchip_RK3568B2_Datasheet_V2.0-20230926.pdf, but not in my Rockchip_RK3566_Datasheet_V1.0-20201210.pdf one

16:23 <qschulz> CounterPillow: uh, a few hits for an "ecc" grep in the RK3588 TRM

16:23 <qschulz> we probably need an EDAC driver for that?

16:25 <qschulz> there's one edac driver in linux-6.1-stan-rkr3.2 which is used for the rk3568 but don't see one for rk3588

16:26 <CyReVolt> Ah I should also look at the TRM part 2 of the other SoCs, because I hope they DDR PHY is still the same. That would help a lot.

16:26 <CounterPillow> I honestly don't know, it's possible the TRM regs are just a copypaste mistake. I vaguely recall seeing ECC stuff when I looked at DFI

16:27 <CyReVolt> I can at least confirm that there are errors and some things clearly missing in the TRMs for the RK3566. ^^

16:28 <CyReVolt> e.g. the vendor code using some registers in "reserved" blocks

16:29 <CyReVolt> btw I just got my tickets for Kernel Recipes, would be happy to meet some of you there if you'd like to chat in person :)

16:47 <linkmauve> Ow, I don’t have 180€ to spend on a conference, but I’d like to come. :(

17:09 <linkmauve> CyReVolt, it is LPDDR4 too apparently, that’s the ODROID-M1.

20:18 <detlevc> mmind00: I remember now which clocks are needed for hdmi audio regs: Those are the vp clocks, for the video port in use by the vop. So we'd need a bit of api between the drivers (hdmi and vop) to get the clocks and the video port in use

20:19 <detlevc> maybe that's a bit much for writing fake values in registers