lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<DC-IRC>
<mariob> it's not this
<DC-IRC>
<mariob> all boards are affected by pvtm
<DC-IRC>
<mariob> rk860 is basically a fan53555 with higher current
<DC-IRC>
<mariob> rk860 is basically a fan53555 with higher current capability
<DC-IRC>
<mariob> and i guess that's still not quite enough
<DC-IRC>
<mariob> the soc may need more current than the 860 can provide at the target voltage for the max clock
<DC-IRC>
<mariob> the soc may need more current than the 860 can provide at the target voltage for max clock
<DC-IRC>
<mariob> you can increase the voltage to compensate for worse silicon quality, but the power draw is also increased
<DC-IRC>
<mariob> rk860 is basically a fan53555 with higher current capability and wider voltage range
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-rockchip
<DC-IRC>
<Tonymac32> I don't know your background, so I can't comment about your being wrong or not without knowing your insight on the subject, however I design power electronics on occasion. The RK860 data sheet advertises 7 amps, so it's entirely possible for a cheap inductor to fall on its face since the SoC might possibly ask for more than it can provide at the voltage setpoint. Don't forget v <clipped message>
<DC-IRC>
<Tonymac32> oltage sag over shitty board layouts/too thin of copper traces, too
<DC-IRC>
<Tonymac32> PVTM is not a new feature in Rockchip parts, such shittily powered boards as the original Asus Tinker Board has pvtm and I've never seen a derating of the clock no matter what was going on around it
<DC-IRC>
<Tonymac32> but, it's not really important, hitting snags like this is bound to happen when 2nd/third teir hardware teams start to deal with "big" hardware3
<DC-IRC>
<Tonymac32> whether it's Rockchip or downstream, someone screwed up
<DC-IRC>
<mariob> i have seen this in *all* rk3558s i have
<DC-IRC>
<Tonymac32> likely it's along the lines of what was discussed elsewhere, we just don't have the right opps, the RK3288 has 3 sets of voltages per opp based on the leakage
<DC-IRC>
<mariob> it may not be the rk860 circuitry itself actually
<DC-IRC>
<mariob> just the soc downclocking to match its internal leakage fuse values
<DC-IRC>
<Tonymac32> with the lack of opp points to support them that would be it's only option
<DC-IRC>
<mariob> it's promoted as a feature for some reason
<DC-IRC>
<Tonymac32> well sure, stability
<DC-IRC>
<mariob> *yes i really want my 2.4 GHz part to run at 2.2*
<DC-IRC>
<mariob> it just seems like a huge hack
<DC-IRC>
<Tonymac32> I haven't bothered getting deep into it, but now that I can use *not the vendor kernel* I'm interested again
<DC-IRC>
<Tonymac32> I use these things headless
<DC-IRC>
<Tonymac32> so
<DC-IRC>
<mariob> so this actually happens outside the kernel too
<DC-IRC>
<mariob> the soc just knows somehow that it can't provide max clock at the intended voltage
<DC-IRC>
<Tonymac32> right but I won't play with the vendor kernel. I probably lost 400 hours to that pile of flaming trash on the Tinker Board 😄
<DC-IRC>
<Tonymac32> I will, however, review the dvfs situation and the available opp points
<DC-IRC>
<mariob> there's been some extensive discussion here
<DC-IRC>
<mariob> so pvtpll can be disabled, at the cost of stability
<DC-IRC>
<Tonymac32> oh lawdy midstream
<DC-IRC>
<lanefu> Man that was a thorough discussion on that GitHub issue
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-rockchip
<DC-IRC>
<Tonymac32> it looks to me like a clear cut case of an underperforming chip design, or perhaps too conservative of core voltage settings in the datasheet. I see device trees using up to 1.000 Volts, when 1.100 is absolute max and 1.050 is considered max normal operating conditions. I would propose 1050 mV be the max setpoint for the higher (2.2 GHz +) opps, but, it still likely won't "cure <clipped message>
<DC-IRC>
<Tonymac32> " a truly bad part, and these chips should be binned according to these values.
<DC-IRC>
<Tonymac32> I also see a big uptick in heat on the "bad pvtm value" SoC's, so it's likely that even if yo uget the clock speed up you'll just thermal throttle
<DC-IRC>
<mariob> there isn't much OC headroom
<DC-IRC>
<mariob> even with good-ish silicon, max i could do is 2 GHz on little cores and 2.5-2.55 on big clusters
<DC-IRC>
<mariob> and passed a run of geekbench
<DC-IRC>
<mariob> on the big clusters i applied 1.3 V
<DC-IRC>
<mariob> little cluster: 1.1 V, big cluster: 1.3V
<DC-IRC>
<Tonymac32> yeah, considering how friendly the RK3288 was to OC it's a little disappointing
<DC-IRC>
<Werner> @tenkawa42 Just installed to NVMe on OPi5+ and the loadavg of >1 issue seems still present.
<DC-IRC>
<tenkawa42> @werner well thats unfortunate...
<DC-IRC>
<tenkawa42> a bit high compared to my pci-e but its on a riser card and fan (on a different board)
<DC-IRC>
<tenkawa42> nvme-pci-0100
<DC-IRC>
<tenkawa42> Adapter: PCI adapter
<DC-IRC>
<tenkawa42> Composite: +30.9 C (low = -0.1 C, high = +84.8 C)
<DC-IRC>
<tenkawa42> (crit = +94.8 C)
<DC-IRC>
<tenkawa42> heheheh
<DC-IRC>
<mariob> i have some old micron trash, idles at 70 C
<DC-IRC>
<mariob> if it's powered on but the OS doesn't initialize it, almost melts itself down
<DC-IRC>
<Werner> Mine here is a WD_BLUE SN570
<DC-IRC>
<tenkawa42> I have Samsung, WD Blue and Black, Intel, Crucial, and HP I think currently.
<DC-IRC>
<tenkawa42> I have Samsung (various types), WD Blue and Black, Intel, Crucial, and HP I think currently.
montjoie has quit [Ping timeout: 245 seconds]
<DC-IRC>
<rpardini> Hey sorry to hear.... wondering if this is really kernel related? amazingfate & co have been careful with what we've let through on this kernel. I've it working pretty great on 3 other boards (not Rock5b, though). Some ideas...
<DC-IRC>
<rpardini> 1) Maybe it's not kernel related? `rock-5b` (via `rockchip-rk3588.conf`) is directly using https://github.com/radxa/u-boot/commits/next-dev u-boot branch, and that's in some flux, maybe try with a pinned commit from a few months ago? (`BOOTBRANCH=commit:<sha1>` in a hook)
<DC-IRC>
<rpardini> 2) Maybe kernel _is_ borked, maybe also try with a `KERNELBRANCH=commit:<sha1>` from early May?
<DC-IRC>
<rpardini> Sorry to only offer terrible advice 😉
montjoie has joined #armbian-rockchip
<DC-IRC>
<lanefu> sweet glad it's easy to test against a commit hash, will play around.
key2 has joined #armbian-rockchip
<DC-IRC>
<lanefu> speaking of something completely different. but mainline rk3588(s) related.