Repository navigation
hisi: report the Hi3536DV100 chip revision - #249
Merged
Merged
Conversation
PR Summary by Qodohisi: Report Hi3536DV100 chip revision
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can see how risky a PR is at a glance with blast radius labels |
widgetii
added a commit
that referenced
this pull request
Oct 17, 2026
… size (#251) The budget compared stat -c %s of ipcinfo before and after. That file is page-quantised: the RW segment's file offset has to equal its address modulo 4096, so it jumps a whole page whenever the code in front of it crosses a boundary. On master the code segment ends exactly where the data segment begins (0xae68 both), so the slack is zero bytes. A change adding 12 bytes of code (#249) and one adding 24 (#250) each "grew" ipcinfo by 4096 and failed the 1024-byte budget. Measure text + data + bss from size(1) instead: what the camera loads, growing by the bytes the change adds. With the CI toolchain those two PRs measure +12 and +24.
SCSYSID0[31:24] is "chip version" in the data sheet, left as TBD. A lab NVR reads 2 there, and the HiSilicon V2.0.2.0 SDK's vdec and venc refuse every frame on such a part: they read the revision back from 0x12060024 and fail allocation, send and get above 1, so the decoder parses the stream and never outputs a picture. Later vendor builds carry a path for revision 2. Print it under chip as `revision`, so a report says which SDK a board needs before anyone debugs the decoder.
widgetii
force-pushed
the
hi3536dv100-revision
branch
from
October 17, 2026 11:04
6910441 to
4a894a6
Compare
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.
On a Hi3536DV100, the
chip:section now also reports the chip revision:Why
The value is
SCSYSID0[31:24](0x12050EE0). The Hi3536DV100 data sheet names that field "chipid: Chip version" and gives its value as TBD.Revision 2 parts exist, and HiSilicon's V2.0.2.0 SDK cannot drive them:
vdec.koandvenc.koread the revision back from0x12060024.VDEC_AllocFrame,VDEC_SendPic,VDEC_GetImage,VencGetStream,VencSendPicand the H.264 encode path, they fail silently when the value is above 1.FSP_AllocFrame failed, and the VDH interrupt stays at 0.So the revision says which SDK a board needs, before anyone has to debug the decoder.
The model name stays
3536DV100, because the chip ID is unchanged and I couldn't confirm a part number for revision 2.Tested
cYAML_testandreginfo_testpass.libipchwbuilds with-DONLY_LIBRARY=ON -DIPCHW_HISI=v4, where the new code is compiled out.devmem 0x12050ee0on that board reads0x02000000.devmem 0x12060024reads0x00000002.