reginfo: add Hi3519DV500/Hi3516DV500 pinmux dump; audit cv6xx table#177
Merged
Conversation
widgetii
force-pushed
the
feat/dv500-reginfo
branch
3 times, most recently
from
e8b7d45 to
9424ce7
Compare
…v6xx DV500 (V5, aarch64) has three IOCFG controllers at IOCFG0 0x10260000, IOCFG2 0x179F0000, IOCFG3 0x0EFF0000 (IOCFG2/3 differ from cv6xx), plus the AON pad-mux in the PMC at 0x11120000. It is already detected as HISI_OT but regs_by_chip() routed it to CV610regs, so reginfo decoded cv6xx pins at cv6xx addresses. Add a dedicated DV500regs[] and dispatch 3519/3516DV500 to it. Function lists are built from the vendor SDK pin_mux.c (every function the SDK selects across its modes, indexed by mux value) and cross-checked / extended with the vendor U-Boot register-init spreadsheets (the per-board .xlsm "pinout"/"normal" sheets). For DV500 the xlsm filled the index-0 GPIO and index-1 names pin_mux.c never configures (GPIO2_6/2_7, MDCLK0/MDIO0, the GPIO13/14 alternates on the MIPI_RX1 pads), added five U-Boot-only pins (PWM0/1/2, USB_PWREN, USB_OVRCUR), and provided the PMC AON GPIO9 pads (0x11120204-0x1112021C). Mux values nothing selects are left "reserved". All addresses verified in-range, de-duplicated, and every pin_mux.c- configured register is covered. Also audit CV610regs (cv6xx): against the SDK pin_mux.c, add 19 registers the SDK configures that were missing (the VI data bus io2 0x30-0x78 and UART2 io1 0x10/0x14); and against the vendor cv6xx U-Boot .xlsm, add five more the kernel never touches: SFC_CSN1 (io0 0x24), USB_OVRCUR/USB_PWREN (io0 0x58/0x5C) and the Ethernet link LEDs (io1 0x18/0x1C). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
widgetii
force-pushed
the
feat/dv500-reginfo
branch
from
9424ce7 to
40ccb65
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
1 participant
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.
What
reginfodecodes the pinmux (IOCFG) registers and prints the active function per pin (--scriptemitsdevmemlines). DV500 was already detected (HISI_OT) butregs_by_chip()routed it to the cv6xxCV610regstable — so on a 3519/3516DV500 it decoded cv6xx pins at cv6xx addresses, which are wrong (different IOCFG bases, different pins).Changes
DV500regs[]— Hi3519DV500 / Hi3516DV500 (V5, aarch64). Three IOCFG controllers:0x10260000, IOCFG20x179F0000, IOCFG30x0EFF0000(IOCFG2/3 differ from cv6xx).pin_mux.c(every function the SDK selects across its modes; mux values the SDK never uses left"reserved"). All addresses verified in-range and de-duplicated.regs_by_chip()case HISI_OTnow returnsDV500regsfor3519DV500/3516DV500,CV610regsotherwise (cv6xx unchanged).CV610regsagainst the cv6xx SDKpin_mux.cand added 19 registers it configures that were missing: the VI data bus (io20x30–0x78) and UART2 (io10x10/0x14).Testing
cmake .. && make).SENSOR0_CLK@ IOCFG2+0x44,I2C0_SCL@ IOCFG0+0x70) follows directly from the SDKpin_mux.cmux indices.🤖 Generated with Claude Code