[Nixitov]

What

Report the SoC and CPU temperature from the host, for the libkernel exports Overdrive (PPSA99058) and LZ4-Compression (PPSA99420) import:

• sceKernelGetCpuTemperature (previously the Unimplemented.cpp stub)
• sceKernelGetSocSensorTemperature

Both titles import the sensors and stop at start-up on main:

FAIL: unresolved ELF import zzKyvoELf4I from libkernel.prx

With this change they get past both sensors.

Behaviour:

• Sensor 0 is the CPU/package temperature (the PS5 SoC is the APU), falling back to the GPU die; sensor 1 is a stable board/ambient temperature; sensor 2 is an NVMe temperature; sceKernelGetCpuTemperature reports sensor 0. hwmon and thermal entries are read in sorted order and battery/power-supply (BAT*, AC, ucsi*) and network-adapter (iwl*, mt79*, ath*, rtw*, wlan*, wifi*) devices are skipped, so the board channel does not depend on directory order. On Linux the values come from /sys/class/hwmon and /sys/class/thermal; on Windows from the ACPI thermal zones (MSAcpi_ThermalZoneTemperature over WMI) and the storage temperature of the first physical drive that answers (StorageDeviceTemperatureProperty, read with a struct mirroring STORAGE_TEMPERATURE_DATA_DESCRIPTOR). A sensor the host does not expose (including any id above 2) returns EINVAL and leaves the output untouched; a null output returns EFAULT.
• The host sensors are not the console's, the ACPI reading is unavailable on many machines, the storage temperature property is numbered 52 on Windows 10 2004 and later and 22 before it (both are queried), and the console's SoC channel count and meanings are hardware dependent; the mapping, the values and the unsupported-input error are recorded in docs/dev/debt/libkernel.md.

sceKernelGetCpuFrequency is no longer part of this PR — it landed separately in #4466, so it was dropped after the rebase.

Tested

Windows 11, MinGW-w64 GCC 15.2.0 (WinLibs r7), Release. Linux reviewer run on Arch (Intel Core Ultra).

• guest_thermal_sensors passes: it reads a synthetic hwmon/thermal layout and checks the sensor mapping, that a battery and a Wi-Fi sensor are skipped and that the GPU die becomes the SoC channel when no CPU package sensor is present, a missing directory and a null root, and the EFAULT/EINVAL paths (including that an unsupported id leaves the output untouched).
• Storage channel checked on hardware. On a WD_BLACK SN7100 (NVMe) the built sceKernelGetSocSensorTemperature(2, …) returns 36 °C, matching the drive's own SMART/Health log (GET LOG PAGE 0x02, read over StorageDeviceSpecificProperty): composite temperature 309 K = 36 °C. The descriptor offsets were confirmed against the Windows SDK's ntddstor.h (InfoCount at +12, TemperatureInfo[0].Temperature at +26, the value in Celsius) and a static_assert pins them; the earlier code checked the warning threshold (+10), read a reserved field (+14), used the pre-2004 StorageDeviceTemperatureProperty value and applied a Kelvin adjustment, all now removed.
• Overdrive (PPSA99058, half144/overdrive-releases v0.1.4, asset Overdrive-PPSA99058.zip) and LZ4-Compression (PPSA99420, theghostonline/PS5-LZ4-Compression v1.4.2, asset LZ4-Compression-PPSA99420.zip), eboot.bin unwrapped from their SELF and relinked with the built relinker --windows: on main they stop at zzKyvoELf4I (sceKernelGetSocSensorTemperature). With this change they pass both sensors; after posix_spawn landed on main both run to the 12-second harness timeout with no unresolved import.
• python tools/check_conventions.py --base origin/main passes.
• The machine used here exposes no ACPI thermal zone, so on Windows sensors 0 and 1 are unsupported there and only the NVMe channel reports; the Linux sensor selection was exercised by the reviewer.
• (Thanks to @nicolasfalesy for the Linux run and the selection feedback, to @Amoenus for the caller evidence that the output must stay untouched on an unsupported id, and to @adriadam10 for the descriptor-offset review.)

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

[github-actions]

Progress report (2672a73 → 0f73f5f)

📈 System libraries: 88.07% (+0.03%, +2 implemented functions)

✅ 2 implemented

Library	Name
libkernel	sceKernelGetCpuTemperature
libkernel	sceKernelGetSocSensorTemperature

[Nixitov]

Thanks bot. A note on the overlaps this PR has, so you can pick whichever you prefer:

This PR implements the host CPU/thermal surface for PPSA99058 and PPSA99420, which import all three and stop at start-up on main:

• sceKernelGetCpuTemperature (was the Unimplemented.cpp stub)
• sceKernelGetSocSensorTemperature
• sceKernelGetCpuFrequency

Sensor 0 = host CPU/package, 1 = first other, 2 = NVMe; values come from /sys/class/hwmon and /sys/class/thermal on Linux, and from the ACPI thermal zones (MSAcpi_ThermalZoneTemperature over WMI) and the storage temperature property on Windows. A host that exposes none reports the sensor as unsupported. Verified on Windows: the two titles get past all three and stop at posix_spawn_file_actions_init; guest_thermal_sensors passes.

Overlaps:

• feat(libkernel): export sceKernelGetMainSocId, sceKernelGetCpumode and sceKernelGetCpuFrequency #4466 covers sceKernelGetCpuFrequency alone (opened before this one). I'm happy to drop that one function here if you prefer feat(libkernel): export sceKernelGetMainSocId, sceKernelGetCpumode and sceKernelGetCpuFrequency #4466 — the sensors and the frequency are independent.
• feat(libSceLibcInternal): implement fminf required for PPSA99902 startup #4592 covers sceKernelGetSocSensorTemperature (opened ~3 min after this one) as part of a broad symbol-export PR. If you'd rather take that one, I can drop the sensor from here and keep only what's left.

The two titles need all three, so as long as each function lands in some PR they are unblocked either way. Happy to rebase or split on request.

AI-assisted: yes

[babyhuey]

Heads-up on the overlap the bot flagged: #4466 also exports sceKernelGetCpuFrequency, for PS5SX2 (PPSA99203). It returns the host TSC rate that sceKernelGetTscFrequency already measures, where this PR reads the host's nominal clock. PS5SX2 only prints the value at start-up, so either definition gets it past the import. Whichever PR merges second should drop its copy, and I'll do that on #4466 if this one lands first.

[Nixitov]

Thanks @babyhuey — agreed, and that's a clean plan.

• If feat(libkernel): export sceKernelGetMainSocId, sceKernelGetCpumode and sceKernelGetCpuFrequency #4466 lands first, I'll drop sceKernelGetCpuFrequency from this PR (and keep the two sensors).
• If this one lands first, please drop it on feat(libkernel): export sceKernelGetMainSocId, sceKernelGetCpumode and sceKernelGetCpuFrequency #4466 as you offered.

Same arrangement stands for #4592 and sceKernelGetSocSensorTemperature: whichever merges first, the other drops its copy. Either way PS5SX2 / PPSA99058 / PPSA99420 are unblocked.

For reference, this PR's sceKernelGetCpuFrequency reads the host's nominal clock (the ~MHz registry value on Windows, cpufreq sysfs / /proc/cpuinfo on Linux), so if #4466's TSC-rate definition is preferred for PS5SX2 I'm happy to leave it to #4466.

AI-assisted: yes

[adriadam10]

Thanks for the PR. Two things to fix before this can merge:

• sceKernelGetCpuFrequency is already on main since #4466 (core/libs/prx/libkernel/Time/Time.cpp, returns the TSC rate sceKernelGetTscFrequency reports, pinned by GuestCurrentCpu.cpp). Keeping this copy exports the symbol twice. As agreed with @babyhuey, please drop it from ThermalSensors.cpp, the test and TechnicalDebt (including HostCpuFrequencyHz and the cpufreq/registry code), and keep the two sensors.
• The branch conflicts with main: TechnicalDebt entries now live in docs/dev/debt/libkernel.md (the sceKernelGetCpuTemperature line is there, at the "imported by PPSA99902" entry). Rebase and move your line there, in the section where the old one was, not at the end.

Also: #4592 (open) adds a throwing sceKernelGetSocSensorTemperature stub in Unimplemented.cpp. Whichever lands second must drop its copy; if #4592 lands first, remove the stub there when you rebase.

Windows-only paths (WMI, IOCTL_STORAGE_QUERY_PROPERTY) and the title start-ups remain untested on our side; the Windows CI job isn't run automatically, so please re-run your local Windows test after the rebase.

[Amoenus]

Runtime update, 2026-10-13: Before #4588, fresh PPSA99902 conversion on integration f1a3/main068 stops at unresolved zzKyvoELf4I after 0.034 s (0xC0000139). With merged #4588 in a353/main021, that import-binding failure is absent; startup reaches the multisample-DCC graphics refusal after 32.560 s. The diagnostic replay confirms normal-render Mode 1, 8 samples, DCC enabled (31.577 s). Both post-merge runs restore originals/runtime/guest/user data with no cleanup errors.

Adapted integration native validation: full build/checks, 18 selected groups x5 under both requested NVIDIA GPL modes (including CPU thermal tests), full NVIDIA 1092 passed / 0 failed / 8 skipped of 1100, max 24.3817 s. This confirms the title's import-binding prerequisite is resolved; it does not demonstrate sensor-call execution, host/console temperatures or units. No duplicate sensor PR. Earlier static caller evidence below retains its original scope.

Exact-main unit refresh (2026-10-16): the original guest_thermal_sensors fixture builds and passes 5/5 on main 5d9dcc42d2ec5401aebd089028b8d4d7410a77b4 on Windows 11 / WinLibs GCC 15.2 r7 (maximum 0.44 s) and Ubuntu 24.04 WSL2 / GCC 13.3 (0.01 s). Source and fixture include the post-merge changes; no local code fix. These checks cover synthetic sensor parsing/classification and unavailable/error output preservation, not accurate console sensor mapping or a new title run. The old bring-up backlog's "CPU temperature still refuses" statement has been corrected in place.

Earlier static caller evidence

Additional static caller evidence from Sonic Unleashed Recompiled PPSA99902 01.003.000 for zzKyvoELf4I (sceKernelGetSocSensorTemperature):

• Original guest ELF VA 0x29a5212 passes sensor 0 in EDI and a stack output pointer in RSI.
• VA 0x29a5372 passes R14D, in a loop initialized to 1, incremented until 16: IDs 1–15.
• Both initialize the output to INT_MIN; immediately after the call the code checks the output against the accepted range 1–150, rather than testing the return code. This makes preserving the output on unsupported IDs relevant. Your fixture already checks ID3's error; checking that a sentinel remains unchanged for ID3 and ID15 would cover the unsupported part of this observed loop more directly.

I rechecked the argument/loop instruction bytes against the original ELF today (SHA256 c34f5b0848ef49e96a855076d8254254047e966e4fe56589d0e504fe13828479), using independently decoded assembly, not inferred Ghidra names. These are potential telemetry calls, not demonstrated execution or a startup blocker in our run. They do not establish console sensor meanings, temperature units or correctness of the proposed host mapping. At the time of this earlier static check I had not built/tested the PR; later validation is recorded above. No duplicate sensor contribution planned.

AI-assisted investigation/reporting: Codex. No game assets attached.

[nicolasfalesy]

Linux test (Arch, GCC 16.2.1, Release, Dell XPS 16 with an Intel Core Ultra), this PR merged onto main 7e181fc:

• guest_thermal_sensors passes.
• ReadThermalSensors_nid_no_patch("/sys/class") from the built libkernel.prx gives a sane CPU value (coretemp) and storage value (nvme).

The SoC value is the problem. It is the first hwmon entry that is not CPU or NVMe, in directory_iterator order, which is unsorted. This laptop's hwmon entries with a temp1_input:

BAT0=31600  nvme=34850  dell_ddv=55000  dell_smm=55000  coretemp=48000  iwlwifi_1=57000

and /sys/class/hwmon lists them as hwmon8 hwmon6 hwmon4 hwmon2 hwmon0 hwmon9 hwmon7 hwmon5 hwmon3 hwmon1. So the "SoC" is the Dell embedded controller's sensor, the Wi-Fi card (iwlwifi_1) or the battery (BAT0), depending on that order and on which drivers are loaded. With a copy of the same name/temp1_input files:

• in a different directory order: soc = the Wi-Fi card's temperature;
• without the dell_ddv, dell_smm and iwlwifi entries (a laptop without those drivers): soc = 31, the battery.

A suggestion: skip hwmon devices that are power supplies (BAT*, AC*, ucsi_source_psy_*; they have a device/type of Battery/Mains/USB, or sit under power_supply) and network adapters (iwlwifi* and similar), sort the entries so the pick is stable, and fall back to the CPU package temperature (coretemp / x86_pkg_temp) for the SoC, since the PS5's SoC is the APU that holds the CPU. A GPU sensor (amdgpu's edge, xe/i915) would be the other natural choice.

[adriadam10]

Thanks for dropping sceKernelGetCpuFrequency. Remaining points:

• core/libs/prx/libkernel/System/src/ThermalSensors.cpp:62-73: the "other" sensor (id 1) is the first hwmon entry that is not CPU or NVMe, in directory_iterator order, which is unsorted. @nicolasfalesy measured on Linux that it ends up being the battery, the Wi-Fi card or the embedded controller depending on order and loaded drivers. Please sort the entries so the pick is stable, skip power supplies (BAT*, AC*, ucsi_source_psy_*) and network adapters (iwlwifi*), and prefer a SoC-like sensor (GPU edge, or the CPU package) as the fallback.
• core/libs/tests/GuestThermalSensors.cpp: add a case where the layout has several non-CPU/NVMe entries (a battery plus another one) in a non-alphabetical directory order and pin which one is picked, and check that *out keeps a sentinel for unsupported ids (3 and 15), as @Amoenus noted the title checks the output rather than the return code.
• The branch conflicts with main in Unimplemented.cpp (the sceKernelGetCpuTemperature stub sits next to new lines); please rebase and rerun guest_thermal_sensors.

Build and guest_thermal_sensors pass here on the PR head. The Windows paths (WMI, storage IOCTL) were not run.

[Nixitov]

Thanks — you were right: the board channel was whichever entry directory_iterator happened to yield first, so it could land on a battery, an EC sensor or the Wi-Fi card. The pick is now deterministic and role-based:

• hwmon and thermal entries are sorted before use.
• Power supplies (BAT*, AC, ACAD*, ucsi*) and network adapters (iwl*, mt79*, ath*, rtw*, wlan*, wifi*) are skipped by name.
• Sensor 0 = CPU package (coretemp/k10temp/zenpower/*cpu*), falling back to the GPU die (amdgpu/i915/xe/radeon/nvidia) since the PS5 SoC is the APU; sensor 1 = the first remaining board/ambient sensor; sensor 2 = NVMe.
• The thermal-zone pass only fills sensor 0 (x86_pkg_temp/cpu-thermal) and sensor 1 (acpitz etc.).

guest_thermal_sensors now builds a layout with amdgpu, BAT0 and iwlwifi_1 and asserts the SoC channel is the GPU die while the battery and Wi-Fi entries are ignored. Thanks for the Linux run and the concrete suggestion.

[Nixitov]

Thanks — I read the title's usage the same way: the output is set to INT_MIN and then validated against 1..150 rather than keying off the return code, so an unsupported id must not touch it.

sceKernelGetSocSensorTemperature validates the id (< 0 || >= 3 → EINVAL) before it reads or writes, and an id the host does not actually expose also returns EINVAL without assigning *outCelsius. The test now asserts that explicitly with a sentinel — id 15, and id 0 when the host exposes nothing — so the loop over 1..15 keeps seeing the untouched INT_MIN and treats those sensors as absent, which is the intended behaviour.

[adriadam10]

Thanks for the update; the sorted, role-based pick on Linux looks good. Remaining points:

• core/libs/prx/libkernel/System/src/ThermalSensors.cpp:200-201: ReadStorageTemperature reads the wrong offsets of STORAGE_TEMPERATURE_DATA_DESCRIPTOR (docs). Version/Size are 4 bytes each, then CriticalTemperature (+8), WarningTemperature (+10), InfoCount (+12), Reserved0[2] (+14), Reserved1[2] (+16), and TemperatureInfo[0] starts at +24 (Index WORD, Temperature SHORT at +26). The code checks +10 (the warning threshold) as if it were the count and reads +14 (reserved, zero) as the temperature, so a drive that answers would report 0 °C as sensor 2. Please check InfoCount at +12 and read Temperature at +26 (a struct mirroring the descriptor would also make returned bounds checks clearer), and require returned >= 28.
• Since your machine takes the unsupported path, this code has never run. Please test it on a host that exposes the storage property (any NVMe drive normally does) and paste the value next to the drive's own reading.
• No code comments are allowed: ThermalSensors.hpp:4-6 and the inline // StorageDeviceTemperatureProperty, // PropertyStandardQuery, // IOCTL_STORAGE_QUERY_PROPERTY, // some drivers report tenths of Kelvin in ThermalSensors.cpp (use named constants instead).
• The branch conflicts with main in Unimplemented.cpp; please rebase.

[Nixitov]

Rebased onto current main (the sceKernelGetCpuTemperature stub now conflicts with the sceCoredumpWriteUserData move; resolved by dropping the stub) and re-verified: guest_thermal_sensors passes, check_conventions.py is clean, and both Overdrive (PPSA99058) and LZ4-Compression run to the 12-second harness timeout with no unresolved import on the rebased head.

[adriadam10]

Thanks for the rebase. The head still has the points from the previous review (only the conflict was addressed):

• core/libs/prx/libkernel/System/src/ThermalSensors.cpp:200-201: ReadStorageTemperature reads the wrong offsets of STORAGE_TEMPERATURE_DATA_DESCRIPTOR. InfoCount is at +12 and TemperatureInfo[0].Temperature at +26 (Version/Size are 4 bytes, then CriticalTemperature +8, WarningTemperature +10, InfoCount +12, Reserved0[2] +14, Reserved1[2] +16, TemperatureInfo[0] +24). The code checks +10 (the warning threshold) and reads +14 (reserved), so a drive that answers would report 0 °C. Check +12, read +26, require returned >= 28; a struct mirroring the descriptor would make the bounds clearer.
• This path has never run on the author's machine. Please test it on a host with an NVMe drive and paste the value next to the drive's own reading.
• No code comments: ThermalSensors.hpp:4-6 and the four inline comments in ThermalSensors.cpp (StorageDeviceTemperatureProperty, PropertyStandardQuery, IOCTL_STORAGE_QUERY_PROPERTY, tenths of Kelvin). Use named constants instead.

The Linux side (sorted entries, power/network skipped, unsupported id leaves the output untouched) looks good.

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#3643	core/libs/prx/libkernel/CMakeLists.txt L62
#5091	core/libs/prx/libkernel/CMakeLists.txt L78
#5144	core/libs/prx/libkernel/CMakeLists.txt L78

[Nixitov]

Fixed all three — and the offset review led me to the real reason the path never ran.

Descriptor offsets. ReadStorageTemperature now reads a struct that mirrors STORAGE_TEMPERATURE_DATA_DESCRIPTOR: Version, Size, CriticalTemperature, WarningTemperature, InfoCount, Reserved0[2], Reserved1[2] (ULONG[2]), then TemperatureInfo[0] (Index, Temperature, OverThreshold, UnderThreshold, the three changeable flags, Reserved0, Reserved1: ULONG). The bound is offsetof(Descriptor, information) + offsetof(Information, temperature) + sizeof(SHORT) = 28, and a static_assert pins InfoCount to +12 and Temperature to +26. Temperature is signed Celsius, so the - 273 adjustment is removed.

It now actually runs. The old code also queried PropertyId = 22. In the current SDK StorageDeviceIoCapabilityProperty is pinned to 48, which renumbers everything after it, so StorageDeviceTemperatureProperty is 52 (22 was the value before Windows 10 2004). With 22 the IOCTL returns ERROR_INVALID_FUNCTION on every drive — that, not the hardware, is why nothing ever ran. The code now queries 52 and falls back to 22.

Hardware result. On this machine (WD_BLACK SN7100, NVMe) the built sceKernelGetSocSensorTemperature(2, &value) returns 36 °C:

rc2=0 v2=36

Independently, the drive's own SMART / Health Information log (GET LOG PAGE 0x02, read over StorageDeviceProtocolSpecificProperty) reports composite temperature 309 K = 36 °C for the same drive. (The Windows machine here exposes no ACPI thermal zone, so sensors 0 and 1 stay unsupported on it and only sensor 2 reports a value.)

Comments. Removed the ThermalSensors.hpp header comment and the four inline comments (StorageDeviceTemperatureProperty, PropertyStandardQuery, IOCTL_STORAGE_QUERY_PROPERTY, tenths of Kelvin). The values are named constants now: kStorageDeviceTemperatureProperty, kLegacyStorageDeviceTemperatureProperty, kPropertyStandardQuery, kIoctlStorageQueryProperty. check_conventions.py passes.

[adriadam10]

Checked on this PR merged onto main: build and the libkernel/libs tests pass on Linux, including guest_thermal_sensors; the descriptor offsets (+12 InfoCount, +24 TemperatureInfo[0], +26 Temperature) and property ids 52/22 match the SDK; sensor selection is sorted and skips power/network devices; unsupported ids leave the output untouched. The Windows path is covered by the full Build. Merging.