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> <Werner> Indeed
<DC-IRC> <tenkawa42> is that a 3588 or a 3588s?
<DC-IRC> <Werner> 3588
<DC-IRC> <Werner> s variant working fine
<DC-IRC> <tenkawa42> yeah I dont think my radxa's have high load... you dont have one do you?
<DC-IRC> <tenkawa42> (I need to load up an os to test again)
<DC-IRC> <Werner> Nope, don't have any radxa boards nor any other rk3588 based ones
<DC-IRC> <tenkawa42> oh.. you are running that .160 kernel
<DC-IRC> <tenkawa42> have you tried the .110 one?
<DC-IRC> <tenkawa42> that .160 has a lot of "modifications"
<DC-IRC> <Werner> Yeah I tested .110 from sd a few days ago and it is fine.
<DC-IRC> <tenkawa42> I had a fair amount of trouble with getting it to .160 stable myself before
<DC-IRC> <tenkawa42> (with my own efforts)
<DC-IRC> <Werner> Interestingly the OPi5 (without +, with rk3588s) does not have this issue on .160
<DC-IRC> <Werner> Maybe something pcie related?
<DC-IRC> <tenkawa42> Yeah... I think its a nvme pci-e specific problem
<DC-IRC> <tenkawa42> same thing I'm fighting right now on the risc-v boards
<DC-IRC> <efectn> does rock5b have the same problem
<DC-IRC> <tenkawa42> @efectn yes
<DC-IRC> <tenkawa42> I have the Rock5 not an Opi
<DC-IRC> <tenkawa42> It didn't appear until I hit around .130 or so
<DC-IRC> <tenkawa42> I was doing about 10 revs at a time
<DC-IRC> <lanefu> i couldn't get rock5b to boot on most recent armbian .160
<DC-IRC> <tenkawa42> yeah I saw you had that panic
<DC-IRC> <lanefu> different problem tho
<DC-IRC> <tenkawa42> What do you power with?
<DC-IRC> <Werner> Should I raise an issue for that loadavg problem at the rk repo?
<DC-IRC> <lanefu> was using official raxda power supply for that particular case
<DC-IRC> <tenkawa42> What is the rk repo address? I want to try building against it
<DC-IRC> <lanefu> 👆 it says improved right there in the description
<DC-IRC> <tenkawa42> @werner Thats a modified repo though
<DC-IRC> <tenkawa42> there's a lot of "changes" in there
<DC-IRC> <tenkawa42> armbian's sources have changed the "rk" repo a fair amount
<DC-IRC> <tenkawa42> 110 to 160 need a lot of manual tweaking
<DC-IRC> <tenkawa42> (to apply)
<DC-IRC> <tenkawa42> thanks.. thats the one we really should base from
<DC-IRC> <Werner> Should talk to @amazingfate . I think it was their idea to fork
<DC-IRC> <tenkawa42> no.. thats .66
<DC-IRC> <tenkawa42> its out of date too
<DC-IRC> <efectn> This is also .160 and armbian source is based on that onrle
<DC-IRC> <tenkawa42> oh.. nm.. goofy interface
<DC-IRC> <efectn> This is also .160 and armbian source is based on that one
<DC-IRC> <tenkawa42> yes.. "based" with a lot of mods
<DC-IRC> <Werner> Let me know if you were successful in building an image from that sources. Happily testing it
<DC-IRC> <lanefu> yeah .160 comes from it being bsp rkr4 vs rkr36 right?
<DC-IRC> <tenkawa42> that repo doesn't even have the rock5 dts
<DC-IRC> <efectn> .110 is rkr3.6
<DC-IRC> <tenkawa42> that in itself is problematic
<DC-IRC> <tenkawa42> @werner it would require patches minimally just to build the dts support....
<DC-IRC> <Werner> no clue 🙂
<DC-IRC> <tenkawa42> No.. I'm telling you..
<DC-IRC> <tenkawa42> It has no rk3588 Rock5 dts
<DC-IRC> <tenkawa42> He retrofit it in his fork
<DC-IRC> <lanefu> is what its built from
<DC-IRC> <tenkawa42> @lanefu I know this
<DC-IRC> <tenkawa42> but it is "highly modified"
<DC-IRC> <lanefu> gotcha.. probably started as dts from raxda's rkr36 fork
<DC-IRC> <tenkawa42> yes
<DC-IRC> <lanefu> you're saying sensible things
<DC-IRC> <tenkawa42> I think the dts pci-e settings is likely our culprit for the high load
<DC-IRC> <tenkawa42> timing there or in the driver itself
<DC-IRC> <tenkawa42> I know I had to add nvme settings on my risc-v boxes to help it
<DC-IRC> <Werner> Would it make sense to compare Armbian .160 dtb against vendor .110 dtb?
<DC-IRC> <tenkawa42> would be useful yeah
<DC-IRC> <Werner> Aight, can do that later
<DC-IRC> <tenkawa42> I have to add nasty boot args like these to some of my nvme drives in risc-v tests currently lol
<DC-IRC> <tenkawa42> pcie_aspm=off nvme.poll_queues=4 nvme_core.default_ps_max_latency_us=0 nvme_core.apst_secondary_timeout_ms=100 nvme_core.io_timeout=30 nvme_core.max_retries=10 nvme_core.admin_timeout=60 nvme_core.apst_primary_latency_tol_us=3 nvme_core.apst_secondary_latency_tol_us=5
<DC-IRC> <tenkawa42> talk about annoying
<DC-IRC> <tenkawa42> had to run through about 20-30 diff combinations (each drive likes different parameters)
<DC-IRC> <Werner> NVMe getting pretty warm without load as well
<DC-IRC> <Werner> Not sure if that is normal though
<DC-IRC> <efectn> What's sensors output
<DC-IRC> <Werner> 48C
<DC-IRC> <efectn> Seems normal for a nvme drive
<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.
<DC-IRC> <lanefu> i dont fully grok, but sharing