clocks(v5): annotate HPM with source (chip|board) and svb_version#170
Merged
Conversation
Two cheap, useful annotations on the existing v5 hpm output:
source -- HPM_STORAGE_REG bit[30] (u_hpm_storage_reg.use_board_hpm
in svb.h). When set, HPM_STORAGE_REG bits[9:0] reflect a
board-fixture calibration override rather than an in-die
measurement averaged by boot software. The "chip" value
is the real silicon process bin; the "board" value is
whatever the manufacturing line decided to ship. Worth
knowing when comparing HPM readings across boards.
svb_version -- SVB_VER_REG (SYSCTRL+0x168) bits[5:2]
(u_svb_version_reg.svb_type / enum product_type):
1=SVB_10, 2=SVB_20, 3=SVB_00, 4=SVB_608, 0=none. The
"binning pass" threshold for "this die is fast enough"
depends on the SVB version (CORE_HPM_BOUND_10 / _20 /
_10_ESMT in svb.h). On boards where svb_version=none the
firmware isn't running SVB at all and the standard hpm_info
tri-state classification is informational only.
Hi3519DV500 demo board reads source=chip, svb_version=none -- which
matches what we observed in the SSMOD/HPM survey (HPM_STORAGE_REG bit[30]
clear; SVB_VER_REG=0x00100200 -> svb_type=0).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #168. Two cheap, useful annotations on the existing V5
hpmblock — both surfaced from registers we already discovered while bringing up Hi3519DV500.What
sourceHPM_STORAGE_REGbit[30] (u_hpm_storage_reg.use_board_hpm)chip= in-die measurement averaged by boot software;board= board-fixture calibration override.svb_versionSVB_VER_REG(SYSCTRL+0x168) bits[5:2] (u_svb_version_reg.svb_type)none/10/20/00/608perenum product_typein svb.h.The
sourceannotation matters when comparing HPM readings across boards — aboardvalue is whatever the manufacturing line decided to ship, not the real silicon process bin.svb_versionis the missing piece for SVB-version-aware binning. svb.h ships three different boundary constants (CORE_HPM_BOUND_10= 230,CORE_HPM_BOUND_20= 222,CORE_HPM_BOUND_10_ESMT= 210) and the "right" threshold depends on which SVB the firmware is configured for. Whensvb_version=none(this board's case), the firmware isn't running SVB at all and the standard tri-state classification is informational only.Output on Hi3519DV500
ipctool clocks(full) appendssourceandsvb_versionafter the existingreg/raw/value/bin/binning_window/aux_reg/aux_value/aux_nameblock.Test plan
0x12d47d2c→ bit[30]=0 →source: chip✓0x00100200→ svb_type=0 →svb_version: none✓Not in scope
bin_minfrom the live SVB version rather than the V4-style window 210..310 baked intov5_hpms[]. Doable but needs validation on multiple SVB-version chips; left for a follow-up.🤖 Generated with Claude Code