There are *a lot* of new extensions in the Linux kernel now (Linux
v6.16) since the last time I checked (Linux v6.2.10), so added them all
plus ime, which is not present in the kernel apparently, but that I
spotted in a RISC-V chip.
Previously, the mask was represented with a uint64_t value, which is
fine as long as we have less than 65 possible extensions. This is not
the case anymore, so instead I replaced that with a pointer of bool,
which gets allocated depending on the max number of extensions that
we support.
This follows the same approach of gpufetch (in
6589de971750b7f4e52c0c35c031fe6204cefdba) where, instead of having a
separate struct for long and short names, both gets merged in a single
struct (ATTRIBUTE_INFO)
This indirectly fixes a bug in RISC-V printer where, if the output
was too large and the short name was selected, it could try to print
an out-of-bound value when accessing the ATTRIBUTE_PEAK. The reason is
that the long and short structures didnt have the same length (because
one attribute name was missing in the short struct). This is now fixed
since we have combined both long and short attribute names.
commit 6e8cccde32
Author: Dr-Noob <peibolms@gmail.com>
Date: Wed Oct 29 21:54:38 2025 +0100
Reorganize attributes in printer
Getting these 3 RISC-V cpuinfo fields allows the detection of
microarchitecture (and other information), extending the RISC-V
detection capabilities. In particular, this is used here to detect
the marchid of Spacemit X60 uarch.
This commit also changes how the microarchitecture is fetched
(i.e., get_uarch) so that it does not rely only in the uarch field
in cpuinfo, but also on the marchid value.
This is a major change in the SoC detection methodology.
Previous to this commit, the SoC (model, vendor and manufacturing
process) would only appear if the exact model was found in the LUT.
In other words, every supported SoC must be added manually to the LUT.
This would allow to show the precise SoC model and the manufacturing
process, which can only be hardcoded (i.e., it cannot be dynamically
determined).
This commit introduces guess_raw_soc_from_devtree, a new way of
inferring the SoC. This simply reads from the compatible file in the
device tree and tries to find a matching vendor to that string. If
there is a match, then we simply copy the model also from the
compatible string and show it directly.
This new implementation will show a less "precise" SoC name and
no manufacturing process because there would be no hardcoded value for
that SoC. However, it improves the scalability of the SoC detection
significantly because there is no longer a need to hardcode every
single SoC.
Lastly, there are some SoC vendors intentionally left outside the
scope of this function: For now I prefer to keep updating manually
the LUT for those to ensure the highest quality detection (e.g.,
showing precise SoC name and manufacturing process).
Overview of changes:
- Adds field max_pp in frequency struct to hold the max freq for peak-performance estimation.
- Instead of getting the max frequency in get_peak_performance, we get it in get_cpu_info (more natural).
- Adds fill_frequency_info_pp which fills the max_pp of the passed cpu by calling measure_frequency.
The approach is to call measure_frequency with a vector where the max frequencies are stored. Then,
the first time measure_frequency is called, the frequency is measured while running all the cores,
and the max frequency is computed per module (e.g., in the case of 2 modules, we would compute
the freq for the first and for the second module), and saved into this vector. Subsequent calls to
measure_frequency will just read the corresponding value for the vector. In other words, the frequency
is only measured once for the whole CPU.
There are cases where measure_frequency is called after binding the
process to a specific core via bind_to_cpu (e.g., when iterating over
modules in hybrid architectures). Thus, in measure_frequency we must
set the affinity of the newly created threads, ensuring they are
binded to the right core.
* Add Intel and AMD 486, Intel Pentium Pro, and AMD K5 chips
* Update infer_cpu_name_from_uarch to support added CPU uarches
* Add sources for more of the legacy chip data
* Add the more specific codename for Intel Pentium MMX Mobile chips
* Document source of AMD 486/K5 variants
* Add link to documentation for Intel 486
---------
Co-authored-by: Timothy Warren <tim@timshomepage.net>
