10:06 <warpme> guys: has anybody successfully booting 3576 from sd card on 6.16-rc1? Mine nanopi-m5 box was perfectly booting on 6.15.2 but after switch to 6.16-rc1 it gives: https://gist.github.com/warpme/9fee6782a6a12de3013284a45d7a468e I already dec. mmc freq to 200HMz and remove all high caps in dt. no change. Any ideas here?

10:07 <warpme> s/200MHz/20MHz/

10:08 <CounterPillow> haven't used SD in a while but I can try today I guess

10:08 <warpme> qll thx!

10:52 <diederik> warpme: Check what changed wrt "rockchip-pm-domain 27380000.power-management:power-controller: Failed to create device link (0x180) with supplier soc for /soc/power-management@27380000/power-controller/..." I'm reasonably sure that's where all the problems come from

10:54 <warpme> diederik : i have such exactly same entries on working 6.15.2... By curiosity i implanted whole drivers/mmc from 6.15.2 to 6.16-rc1 and issue is still present....

10:57 <robmur01> another thing to check might be if anything's changed to break USB PD negotiation such that the board is underpowered

10:58 <diederik> warpme: Sounds like you may got lucky with 6.15, but it's still problematic

10:58 <robmur01> my old RK3288 box can boot on 500mA from USB (rather than a proper 2A+ PSU), but starts falling over once userspace starts hammering SD/eMMC with serious I/O

11:00 <diederik> if you have the dts source, you may want to run DTB validation ... which probably points to (several) things that should be fixed/improved

11:00 <warpme> robmur01 : nanopi-m5 has dedicated STM32G030F6P6 mcu talking with fusb302 to drive usbpd nego...

11:01 <robmur01> ooh, clever!

11:01 <warpme> diederik : currently i reduced dt to minimal with: pmic, mmc and eth. still no go

11:02 <warpme> robmur01 : indeed - friendlyelec has this design in many boards where supply is via usbc with pd

11:04 <diederik> I thought I did recognize some things wrt my nanopi-r5s (concerning pd)

11:04 <qschulz> warpme: v6.15-v6.16-rc1 shouldn't be too much of a gap that git bisect would be slower than debugging by hand?

11:04 <warpme> infact i must say that they have best hw i'm dealing with. best i mean every detail is well thought...

11:05 <CounterPillow> diederik: those errors are inconsequential and very hard to fix, it just defers creating the link until later, which is the proper way to handle this situation, the only downside is the message in the log

11:09 <robmur01> first thing I'd try is enabling all the debug prints for drivers/mmc/ to see if that sheds any light on why it thinks the card keeps needing resetting

11:10 <diederik> CounterPillow: I assume you're right, but those lines would be the first ones I'd look into. IME most problems with SBCs come from (improper) power (supply) and (poor) storage (SDcards)

11:10 <warpme> robmur01 : good idea thx!

11:11 <diederik> and I'd really do the DTB validation. It's pretty easy and can point to areas worth investigating

11:12 <warpme> bisecting is a bit more difficult when i have series patches req. to enable hw working....

11:12 <diederik> but also as qschulz said: a git bisect is worth it as well

11:15 <diederik> Saving ``dmesg`` from both 6.15 and 6.16-rc1, stripping the timestamps and putting them in (f.e.) kdiff3 can be revealing as well

11:16 <diederik> another thing I often look at is the output of ``dmesg --level 0,1,2`` (this should be empty) and ``dmesg --level 3`` (errors) and ``dmesg --level 4`` (warnings)

11:16 <CounterPillow> if it's a regression then the first thing to look into is a bisect

11:18 <robmur01> warpme: driver patches, or just DT? The latter should be easy enough to decouple from a bisect, assuming 6.15 still works with a 6.16-based DTB (and if not then you know where to start looking!)

11:19 <warpme> robmur01 : fortunately for rk3576 it is dts :-)

11:19 <warpme> mainly

17:09 <CounterPillow> looks like warpme left, but for future reference: SD cards work fine for me on RK3576.

17:12 <warpme> CounterPillow : what rk3576 hw you have?

18:18 <CounterPillow> Sige5