[openipc-ai]

Refs #266. This is left open until the reporter has run it on the camera.

An Ambarella S3L camera gets "SoC not recognised": the kernel lists no UART in /proc/iomem, and manufacturers[] has no row for Ambarella. This adds a small HAL that reads the SoC name from /proc/cpuinfo and sets sensor addresses for the probe.

What it reports:

• S3L, S2L, A5S and so on, from Ambarella <soc> (Flattened Device Tree). S3L and S3LM share that string.
• Sensors at the SDK driver defaults: OmniVision 0x6C, Sony 0x34, onsemi 0x20.

Left out on purpose:

• Exact part (33M, 55M, 66...): it is a word the DSP firmware writes, reachable only through /dev/iav. Opening that on a live camera is too intrusive for a report.
• AR0521: it shares 0x6C with OV4689, and the onsemi probe runs first.
• Total RAM: this stays what the kernel sees. IAVMEM ends at 512 MiB on a camera reported as 256 MiB. Amboot computes it from a compile-time DRAM_SIZE, and the DRAM config register is not in the programming manual.
• arm64: the row is under __arm__ only.

Tested:

• Host build, plus ambarella_test, anyka_test, longse_test, reginfo_test, sensors_test, hal_hisi_test and tools/test_pipeline.sh.
• arm32 static build of ipctool and ipcinfo, and ipcinfo with -DIPCHW_VENDORS=ambarella.

Not tested:

• Nothing has run on a camera, so sensor detection is unproven. /dev/i2c-* on Dahua's kernel is unconfirmed, and the sensor probably needs the vendor video stack running.
• The full binary was not run against the issue's /proc files. Only the parser is tested; the vendor match rests on the issue's own error line, which shows ipctool reading Ambarella.
• mips32 and arm64 builds were not run locally. CI covers them, along with the ipcinfo size budget.

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

PR Summary by Qodo

Detect Ambarella SoCs from the CPU machine string

🐞 Bug fix ✨ Enhancement 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

AI Description

• Recognize Ambarella ARM cameras whose kernels expose no UART in /proc/iomem.

Diagram

graph TD
  cpu["/proc/cpuinfo"] --> match["Vendor match"] --> parser["Ambarella parser"] --> report["SoC report"]
  parser --> hal["Ambarella HAL"] --> probes["Sensor probes"]

Loading

High-Level Assessment

The existing CPU-info detection fallback is the appropriate integration point because these kernels expose no UART in /proc/iomem. Reading /dev/iav for a more precise part number would be intrusive on a live camera, so reporting the machine-string SoC is the safer choice; camera validation is still needed for sensor probing.

Files changed (9) +147 / -2

Enhancement (4) +60 / -0

chipid.hDefine the Ambarella vendor name +1/-0

Define the Ambarella vendor name

• Adds the vendor constant used to identify Ambarella in detection results.

src/chipid.h

ambarella.cParse Ambarella SoCs and configure sensor addresses +47/-0

Parse Ambarella SoCs and configure sensor addresses

• Extracts the SoC name from the '/proc/cpuinfo' Hardware field and installs SDK-derived Sony, onsemi, and OmniVision I²C addresses. It does not attempt exact part-number or RAM detection.

src/hal/ambarella.c

ambarella.hDeclare the Ambarella HAL interface +11/-0

Declare the Ambarella HAL interface

• Exposes the machine-string parser, CPU detector, and HAL setup functions.

src/hal/ambarella.h

common.hExpose Ambarella declarations to HAL consumers +1/-0

Expose Ambarella declarations to HAL consumers

• Includes the new HAL header alongside existing vendor interfaces so the detection table can reference its functions.

src/hal/common.h

Bug fix (1) +3 / -0

chipid.cMatch Ambarella in ARM vendor detection +3/-0

Match Ambarella in ARM vendor detection

• Adds a guarded manufacturer-table entry that invokes Ambarella SoC detection and HAL setup through the existing CPU-info fallback.

src/chipid.c

Documentation (1) +10 / -0

CLAUDE.mdDocument Ambarella verification and reporting limits +10/-0

Document Ambarella verification and reporting limits

• Lists the parser test and explains why detection stops at the machine-string SoC rather than reading '/dev/iav' or inferring RAM from IAVMEM.

CLAUDE.md

Other (3) +74 / -2

pr-build-check.ymlRun the Ambarella parser test in CI +3/-1

Run the Ambarella parser test in CI

• Adds ambarella_test to the build-and-run job so the hardware-free parser cases run with the existing tests.

.github/workflows/pr-build-check.yml

CMakeLists.txtInclude the optional Ambarella HAL and parser test +8/-1

Include the optional Ambarella HAL and parser test

• Adds Ambarella to selectable vendor HALs and defines an ambarella_test executable linked with the parser's dependencies.

CMakeLists.txt

ambarella_test.cCover Ambarella machine-string parsing without hardware +63/-0

Cover Ambarella machine-string parsing without hardware

• Tests S3L, S2L, and A5S strings plus non-Ambarella inputs using temporary CPU-info files. It does not exercise detection or sensor probes on a camera.

src/hal/ambarella_test.c

[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. Ambarella SoC has no generation set ✓ Resolved

Description

ambarella_detect_cpu copies the parsed machine name into chip_name and returns, leaving
chip_generation at its zero default, while Anyka and FH detection both assign it. Generation-keyed
code in padmux.c, clocks.c and bootrom.c then sees an unknown SoC for this vendor, and since
the PR does not say the gap is intentional, a later reader cannot tell it apart from an omission.

---

2. Zero-length parsing corrupts memory ✓ Resolved

Description

ambarella_machine_name() writes to out[outlen - 1] after a successful match without checking
whether outlen is zero. If a caller supplies a zero-length output buffer and the file contains a
matching Hardware line, the index underflows and the function writes outside the buffer while
returning success.

---

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗