lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f73743cb-fdea-4b53-9665-4cc303498171@cherry.de>
Date: Wed, 26 Mar 2025 11:07:47 +0100
From: Quentin Schulz <quentin.schulz@...rry.de>
To: Dragan Simic <dsimic@...jaro.org>, linux-rockchip@...ts.infradead.org
Cc: heiko@...ech.de, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, stable@...r.kernel.org,
 Alexey Charkov <alchark@...il.com>
Subject: Re: [PATCH v2] arm64: dts: rockchip: Remove overdrive-mode OPPs from
 RK3588J SoC dtsi

Hi Dragan,

On 3/24/25 12:00 PM, Dragan Simic wrote:
> The differences in the vendor-approved CPU and GPU OPPs for the standard
> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2]
> come from the latter, presumably, supporting an extended temperature range
> that's usually associated with industrial applications, despite the two SoC
> variant datasheets specifying the same upper limit for the allowed ambient
> temperature for both variants.  However, the lower temperature limit is
> specified much lower for the RK3588J variant. [1][2]
> 
> To be on the safe side and to ensure maximum longevity of the RK3588J SoCs,
> only the CPU and GPU OPPs that are declared by the vendor to be always safe
> for this SoC variant may be provided.  As explained by the vendor [3] and
> according to the RK3588J datasheet, [2] higher-frequency/higher-voltage
> CPU and GPU OPPs can be used as well, but at the risk of reducing the SoC
> lifetime expectancy.  Presumably, using the higher OPPs may be safe only
> when not enjoying the assumed extended temperature range that the RK3588J,
> as an SoC variant targeted specifically at higher-temperature, industrial
> applications, is made (or binned) for.
> 
> Anyone able to keep their RK3588J-based board outside the above-presumed
> extended temperature range at all times, and willing to take the associated
> risk of possibly reducing the SoC lifetime expectancy, is free to apply
> a DT overlay that adds the higher CPU and GPU OPPs.
> 
> With all this and the downstream RK3588(J) DT definitions [4][5] in mind,
> let's delete the RK3588J CPU and GPU OPPs that are not considered belonging
> to the normal operation mode for this SoC variant.  To quote the RK3588J
> datasheet [2], "normal mode means the chipset works under safety voltage
> and frequency;  for the industrial environment, highly recommend to keep in

FYI, the answer from Rockchip support about what "industrial 
environment" means is:

"""
Industrial environments encompass a wide range of settings, from
manufacturing plants to chemical processing facilities. These
environments are characterized by the use of complex machinery,
stringent safety protocols, and the need for continuous operations.
"""

which is not really helping me understand when we should be able to use 
the overdrive mode.

Why would you buy an RK3588J variant if you don't plan on using them on 
the -40 - -20°C range that isn't supported by the RK3588 variant, which 
seems to me to be the only advertised difference?

It also seems like the RK3588M supports the same operating range as the 
RK3588J but at faster speeds? c.f. 
https://en.t-firefly.com/product/industry/aio3588mq#spec and 
https://download.t-firefly.com/%E4%BA%A7%E5%93%81%E8%A7%84%E6%A0%BC%E6%96%87%E6%A1%A3/%E6%A0%B8%E5%BF%83%E6%9D%BF/iCore-3588MQ%20-%20Automotive-Grade%20AI%20Core%20Board.pdf

Couldn't find a datasheet though.

Talk about confusing specs...

I'll stop caring from now about this very topic :)

Cheers,
Quentin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ