[widgetii]

cpu-models v2

Moves the package to OpenIPC/cpu-models v2. It installs three files into /usr/share/majestic:

• person.qnet: the CPU person detector, the same model as v1's person.pdnet, in the new blob format. majestic's engine now reads one format for every network it runs.
• person.json: the thresholds of its presets, unchanged from v1 byte for byte.
• drum.qnet (new, 49 KB): the classifier majestic's meter reading uses on each drum of a water, gas or electricity meter.

Together they are 134 KB, 49 KB more than v1. All three were built by that repository's release workflow, which checks the engine bit for bit against the reference arithmetic on the host and on ARMv7 NEON before publishing. The release reproduced the local build's hashes exactly.

The help text now describes both models.

Ordering

A majestic that loads only person.pdnet finds no person model once this lands, and the majestic that reads person.qnet finds none without it. This must therefore land in the same nightly as that majestic change, which is ready to merge right behind it.

Verified

Image. A local hi3516ev300_ultimate build. This was the board whose last published ultimate image was closest to full.

• The three files are installed with the published hashes, and no person.pdnet is left. The install step also removes one left over in a reused target.
• firmware.bin is 10304 / 15808 KB. Tonight's nightly of the same board measured 10304 KB too.
• rootfs.ubi is 18304 / 24576 KB.
• STRICT=1 test_shell_parse.sh and ci-matrix.py --self-test pass.

drum.qnet on a camera. A SigmaStar SSC32x camera (sc2239 sensor) runs majestic with meter reading. It loads a drum.qnet whose sha256 is the v2 asset's, 4e2056686091c067ef31401e32ca9bc136c001fae37f9235e9042125e8d8c8ed, and reads an electricity meter every 20 s. It reports what the meter's drums show, 029866.4 kWh:

$ curl http://<camera>/api/v1/meters
{"enabled":true,"meters":[{"name":"power","unit":"kWh","value":29866.4,"drums":"0298664","dialsRead":false,"perHour":0.0,"margin":2.2465789787106045,"at":1792697452,"age":13}]}
$ curl http://<camera>/metrics | grep ^majestic_meter
majestic_meter_value{meter="power",unit="kWh"} 29866.400000
majestic_meter_per_hour{meter="power",unit="kWh"} 0.000000
majestic_meter_age_seconds{meter="power"} 13

Not verified on a camera this package targets. No HiSilicon/Goke camera has booted an image of this branch.

• person.qnet has not run on a HiSilicon camera. What vouches for it is the release workflow's check: the engine's ARMv7 NEON build under qemu matches the reference arithmetic bit for bit, on 40 person crops and 400 drum crops.
• A before/after on one of the nine boards needs the majestic that reads person.qnet as well. On its own, this image's "after" would only show the current nightly majestic finding no person.pdnet.

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

PR Summary by Qodo

Ship cpu-models v2 person and meter-reading models

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Replace person.pdnet with the v2 person.qnet format required by majestic’s engine.
• Add drum.qnet for water, gas, and electricity meter reading; retain unchanged person presets.
• Install the release-verified assets together, requiring a coordinated majestic rollout.

Diagram

graph TD
  Release["cpu-models v2 release"] --> Package["Buildroot package"] --> Target["/usr/share/majestic"] --> Engine["majestic engine"]

Loading

High-Level Assessment

Keep the existing Buildroot package and switch it to the published v2 assets. This reuses the established download, hash-verification, and installation path; the essential rollout decision is to ship it alongside a majestic build that reads person.qnet.

Files changed (3) +18 / -12

Enhancement (1) +6 / -5

cpu-models.mkDownload and install the v2 models +6/-5

Download and install the v2 models

• Moves the package to release v2, makes person.qnet the primary download, and adds drum.qnet alongside person.json. Installs all three files under /usr/share/majestic instead of installing person.pdnet.

general/package/cpu-models/cpu-models.mk

Documentation (1) +9 / -5

Config.inDescribe both v2 CPU models +9/-5

Describe both v2 CPU models

• Revises package help to identify person.qnet, its preset thresholds, and the new drum.qnet meter classifier. Updates the stated combined size to 134 KB.

general/package/cpu-models/Config.in

Other (1) +3 / -2

cpu-models.hashPin the v2 release assets +3/-2

Pin the v2 release assets

• Replaces the person.pdnet hash with the published person.qnet hash and adds the drum.qnet hash. The person.json hash remains unchanged.

general/package/cpu-models/cpu-models.hash

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

Code Review by Qodo

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

1. Hardware evidence lacks before/after 📘 Rule violation ☼ Reliability

Description

The cpu-models change reports a local build and image-capacity measurements, but no camera
behavior before and after installing the new models. The verification text does not show boot,
streaming, or other runtime output from hi3516ev300_ultimate, leaving the firmware behavior
unverified on hardware.

Code

general/package/cpu-models/cpu-models.mk[R10-12]

+CPU_MODELS_VERSION = v2
CPU_MODELS_SITE = https://github.com/OpenIPC/cpu-models/releases/download/$(CPU_MODELS_VERSION)
-CPU_MODELS_SOURCE = person.pdnet
+CPU_MODELS_SOURCE = person.qnet

Evidence

The change replaces the shipped person model and adds a drum model, so it can alter firmware
behavior on a camera. The checklist requires before-and-after hardware evidence for image-affecting
changes, while the supplied verification describes only a local build and capacity measurements
without runtime camera output.

Rule 3: Hardware evidence is present and honest
general/package/cpu-models/cpu-models.mk[10-15]

Agent prompt

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

## Issue description
The package changes the models shipped in the firmware, but the PR evidence reports only a local build and image-size measurements. Hardware validation must include before-and-after output from the affected camera, such as boot logs, stream behavior, or runtime model-loading results.
## Fix Focus Areas
- general/package/cpu-models/cpu-models.mk[10-12]
## Recommended Fix
Run the affected image on `hi3516ev300_ultimate` and record comparable before-and-after camera evidence, including successful boot, model loading, and streaming or meter-reading behavior. Add the measurements and affected-board details to the PR verification section.

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

---

2. Rebuilt images retain the old person model ✓ Resolved

Description

CPU_MODELS_INSTALL_TARGET_CMDS installs the new model files but never removes the previously
installed person.pdnet. When a build reuses a target directory from v1, that file remains
alongside the v2 models in the resulting image, despite the intended migration to one format.

Code

general/package/cpu-models/cpu-models.mk[26]

+		$(@D)/person.qnet $(@D)/person.json $(@D)/drum.qnet

Evidence

The changed install list has no operation that deletes the v1 filename. The existing rootfs script
documents this repository's need to remove stale package files from reused Buildroot target
directories on every build.

general/package/cpu-models/cpu-models.mk[23-26]
general/scripts/rootfs_script.sh[15-20]

Agent prompt

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

## Issue description
An incremental build can retain `person.pdnet` in the target directory after the package switches to `person.qnet`.
## Fix Focus Areas
- general/package/cpu-models/cpu-models.mk[23-26]
- general/scripts/rootfs_script.sh[15-20]
## Recommended Fix
Remove `/usr/share/majestic/person.pdnet` during the image build, including when Buildroot does not rerun the package install recipe. Keep installation of the three v2 assets unchanged.

ⓘ 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 ask Qodo to dismiss a finding you disagree with, with your reason on record

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗