msposd: build the hi3536 target on hi3536dv100

[widgetii]

Problem

general/package/msposd/msposd.mk has no case for hi3536dv100, so it falls through to else → star6e. Enabling BR2_PACKAGE_MSPOSD on a hi3536dv100 image therefore builds a SigmaStar msposd linked against libmi_rgn, libmi_sys and libcam_os_wrapper. MSPOSD_INSTALL_LIBRARIES installs those only when the vendor is sigmastar, so on a HiSilicon NVR the binary cannot start.

msposd has a hi3536 target. Since OpenIPC/msposd#107 it draws the OSD on the hifb layer (/dev/fb0) and links no HiSilicon library. Part of OpenIPC/msposd#18 and #1621.

Hardware tested on

Hi3536DV100 NVR, OpenIPC hi3536dv100_lite nightly-20261015-1d9c834, with the MPP set from hisilicon-osdrv-hi3536dv100 loaded through its load_hisilicon, and silicon_research vdec at 720p60.

Evidence

Built from this branch, rebased on 5c01f0a92, for hi3536dv100_lite with BR2_PACKAGE_MSPOSD=y added only to the local .config. msposd is fetched from upstream main (MSPOSD_VERSION = HEAD), so it includes msposd#107.

Before (master's fallthrough, MSPOSD_FAMILY=star6e):

-D__INFINITY6E__ -D__SIGMASTAR__ -lcam_os_wrapper -lmi_rgn -lmi_sys

After:

-D__GOKE__ -D__HI3536__ -levent_core -lm
build/msposd-HEAD/msposd:
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libevent_core-2.2.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [ld-linux.so.3]

That binary, run on the NVR next to vdec -m 720p60, with msposd --master 127.0.0.1:14551 --osd -r 50 -v:

/proc/umap/hifb0:
Show state                   	 :ON
xres, yres                   	 :(1280, 720)
ColorFormat:                 	 :ARGB1555
solid OSD pixels in /dev/fb0: 133092   (the font preview msposd draws at start)

No flight controller was attached, and the HDMI output was checked from /dev/fb0 and /proc/umap, not on a monitor.

python3 .github/scripts/ci-matrix.py --self-test: ok.

Scope

• No kernel patches under general/package/all-patches/linux/ (those go to OpenIPC/linux)
• No files specific to a single retail camera model (those go to OpenIPC/builder)
• No probing or bring-up tooling (that goes to OpenIPC/ipctool)
• Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a value specific to my board
• Package sources come from an OpenIPC repository, and any version bump keeps at least the specificity of the pin it replaces (a new package should pin a full 40-character SHA)
• No LD_PRELOAD, and no binaries that cannot be rebuilt from source
• New code is selected by a defconfig, so CI actually builds it

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Build msposd's hi3536 target for hi3536dv100

🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Map hi3536dv100 to msposd's hi3536 target instead of the SigmaStar fallback.
• Point the build at the matching HiSilicon OSDRV package, avoiding unavailable SigmaStar libraries.

Diagram

graph TD
  A["SoC family"] --> B{"hi3536dv100?"} -->|yes| C["hi3536 target"] --> D["msposd binary"] --> E["hifb framebuffer"]
  B -->|other| F["Existing mappings"]

Loading

High-Level Assessment

Use the existing hi3536 target through a SoC-specific mapping. Changing the fallback would affect unrelated families, while adding HiSilicon library installation would not correct the SigmaStar build selection. The PR does not add a defconfig selection or pin the existing HEAD source reference, so neither is covered by this change.

Files changed (1) +3 / -0

Bug fix (1) +3 / -0

msposd.mkSelect the hi3536 msposd target for hi3536dv100 +3/-0

Select the hi3536 msposd target for hi3536dv100

• Adds a hi3536dv100 branch that selects the hi3536 build target and its matching HiSilicon OSDRV package directory. This prevents the SoC from using the default SigmaStar star6e target.

general/package/msposd/msposd.mk

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Hi3536 OSD has no framebuffer to draw on ✓ Resolved

Description

The new hi3536 branch selects the framebuffer-backed target, but msposd does not select or
depend on the Hi3536 driver package. When BR2_PACKAGE_MSPOSD is enabled alone on the lite image,
that package's hifb.ko module and load_hisilicon script are absent, so the OSD cannot draw to
/dev/fb0.

Code

general/package/msposd/msposd.mk[R17-19]

+else ifeq ($(OPENIPC_SOC_FAMILY),hi3536dv100)
+	MSPOSD_FAMILY = hi3536
+	MSPOSD_OSDRV = $(HISILICON_OSDRV_HI3536DV100_PKGDIR)

Evidence

The new branch chooses hi3536, while msposd declares only libevent-openipc as a dependency. The
lite defconfig does not enable the OS driver; its install recipe supplies the modules and loader
script, and that script inserts hifb.ko.

general/package/msposd/msposd.mk[8-19]
general/package/msposd/Config.in[1-4]
br-ext-chip-hisilicon/configs/hi3536dv100_lite_defconfig[40-61]
general/package/hisilicon-osdrv-hi3536dv100/hisilicon-osdrv-hi3536dv100.mk[11-20]
general/package/hisilicon-osdrv-hi3536dv100/files/script/load_hisilicon[89-95]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Selecting msposd alone for hi3536dv100 builds the framebuffer-backed target without installing the package that supplies its framebuffer module and loader script.
## Fix Focus Areas
- general/package/msposd/Config.in[1-4]
- general/package/msposd/msposd.mk[17-19]
## Recommended Fix
Add a hi3536dv100-specific package selection or dependency for the Hi3536 OS driver, and ensure the framebuffer loader runs before msposd attempts to draw.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can pick a display mode instead of tweaking every Display option by hand

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗