hi3516ev200: finish the Goke-to-HiSilicon symbol mapping - #215
Merged
Merged
Conversation
Eight of the thirty sensor drivers in this tree cannot be loaded on a
HiSilicon hi3516ev200 image. They name Goke SDK entry points, and nothing
in a HiSilicon rootfs defines those, so ld.so refuses the library at
relocation time and the camera has no video at all:
dlopen "/usr/lib/sensors/libsns_gc2053.so" error: Error relocating
/usr/lib/sensors/libsns_gc2053.so: GK_API_ISP_GetModParam: symbol not found
hicompat.h already exists for exactly this: it maps GK_API_* onto the
HI_MPI_* equivalents when SDK_CODE says HiSilicon, and declares each name
so the prototype follows whichever spelling the macro produced. It was
just incomplete in two ways, and each accounts for four of the eight.
- GK_API_ISP_GetModParam was never mapped. gc2053, f37, sc2231 and
sc500ai read the ISP's quick-start flag through it and were left with
that one symbol unresolved.
- Four drivers never included the header at all, so none of the six
mappings reached them: gc4023, gc5603, os02g10 and sp2308. gc5603 is
in both groups, which is why it was short seven symbols rather than
one or six.
The header also could not be included from a *_sensor_ctl.c, which brings
in gk_api_isp.h alone — its AE and AWB prototypes need types from
ae_comm.h and awb_comm.h, which only the *_cmos.c files happened to have
already. It now includes what it names, so it stands on its own.
Verified by building the whole tree both ways with the same sources:
SDK_CODE=0x3516E200 30 drivers, 0 left naming GK_API_*
SDK_CODE=0x7205200 30 drivers, 29 still naming GK_API_*
which is the point — the Goke build must go on resolving against Goke's
libisp, and only the HiSilicon one is remapped.
On a hi3516ev300 running the 2026-08-29 OpenIPC nightly, replacing the
shipped libsns_gc2053.so with the rebuilt one turns
Error relocating ...: GK_API_ISP_GetModParam: symbol not found
Cannot start SDK
into a driver that loads and an SDK that starts. (That board carries an
imx335, so the stream then times out for want of a gc2053 on the bus —
the load itself is what was being tested.)
Reported in OpenIPC/firmware#2338.
PR Summary by QodoComplete hi3516ev200 Goke-to-HiSilicon sensor symbol mapping
AI Description
Diagram
High-Level Assessment
Files changed (10)
|
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 enable the Remediation agent and Qodo fixes findings in a dedicated fix PR |
widgetii
added a commit
to OpenIPC/firmware
that referenced
this pull request
Aug 30, 2026
Eight of the thirty sensor drivers this package builds for hi3516ev200 could not be loaded on the images it ships them in. They named Goke SDK entry points, nothing in a HiSilicon rootfs defines those, and ld.so refused the library at relocation time — so a camera with one of these sensors came up with no video at all: dlopen "/usr/lib/sensors/libsns_gc2053.so" error: Error relocating /usr/lib/sensors/libsns_gc2053.so: GK_API_ISP_GetModParam: symbol not found Affected: gc2053, f37, sc2231, sc500ai, gc4023, gc5603, os02g10, sp2308. The other twenty-two were fine, which is why this went unnoticed — the sensors in the images most people run are all in that group. Fixed upstream in OpenIPC/openhisilicon#215, which completes the GK_API_* -> HI_MPI_* mapping the tree already had. Nothing here changes but the commit this package pins. Checked at the pin, not just at the tag: the tarball buildroot fetches for 001096a carries the mapping and the include in all nine affected files. Upstream built the whole tree both ways to prove the Goke side is untouched — 0 drivers left naming GK_API_* for SDK_CODE=0x3516E200, 29 of 30 still naming them for 0x7205200, which is what a Goke image needs. Reported in #2338.
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.
Eight of the thirty
hi3516ev200sensor drivers cannot be loaded on a HiSilicon image. They name Goke SDK entry points, nothing in a HiSilicon rootfs defines those, and ld.so refuses the library at relocation time — so a camera with one of these sensors gets no video at all:Reported in OpenIPC/firmware#2338 (gc2053). Affected: gc2053, f37, sc2231, sc500ai, gc4023, gc5603, os02g10, sp2308.
Why
hicompat.hexists for exactly this — it mapsGK_API_*ontoHI_MPI_*whenSDK_CODEsays HiSilicon, and re-declares each name so the prototype follows whichever spelling the macro produced. It was incomplete in two independent ways, four drivers each:GK_API_ISP_GetModParamwas never in the listgc5603is in both groups, which is why it was short seven symbols rather than one or six.A third thing had to change to make the first fix possible:
hicompat.hcould not be included from a*_sensor_ctl.cat all. Those bring ingk_api_isp.halone, and the header's AE/AWB prototypes need types fromae_comm.handawb_comm.hthat only the*_cmos.cfiles happened to have already. It now includes what it names.Verification
Whole tree built both ways from the same sources:
SDK_CODEGK_API_*0x3516E200(HiSilicon)0x7205200(Goke)The second row is the one that matters for regressions: a Goke build must go on resolving against Goke's
libisp, and only the HiSilicon build is remapped. The mapping is inside#if SDK_CODE == 0x3516E200, so that is what you would expect — this confirms it.On hardware, a
hi3516ev300running the 2026-08-29 OpenIPC nightly, swapping only the shippedlibsns_gc2053.sofor the rebuilt one:Sensor driver loadedCannot start SDKThat board carries an imx335, so the stream then times out for want of a gc2053 on the bus — loading the driver is what was being tested, and there is no lab board with any of the eight affected sensors to take it further.