[openipc-ai]

Refs #266. Tested on a lab Hikvision DS-2CD2423G0-I (S3Lm, 256 MiB, NAND, AR0237) with its stock firmware. It's a second, independent S3L: the #266 camera is a Dahua design with NOR and an OV4689.

	master	This PR
Chip	Ambarella / S3L	same, plus family: S3Lm
RAM	total: 256M, media: 192M	total: 256M, media: 144M
Sensor	none	AR0237, bus 0, 0x30

• Sensor address: this board uses 8-bit 0x30, not the SDK default 0x20. The module's bus_addr parameter reads 24, which is 0x18.
• Sensor ID: register 0x3000 reads 0x0950, the same with write-then-read and I2C_RDWR. 0x3004 and 0x31FE respond too. ipctool reads 16-bit values little-endian here, so the table has 0x5009. This is not datasheet-verified: the vendor driver reads the register without checking it, so the name rests on the firmware driving this sensor with its ar0237 module.
• Media RAM: Hikvision's kernel moves the split at boot and leaves /iavmem stale. The tree says 0x04000000, 0x0c000000, while /proc/iomem has Linux up to 0x06ffffff and the boot log says IAVMEM = 0x07000000, 0x09000000. The end agrees, so total was right. Media is now what lies above Linux's RAM. On SoC not recognised: Ambarella S3L (Amcrest IP4M-1026E / Dahua IPC-HFW1430SN) #266's numbers this still gives 392M.
• Family: /proc/ambarella/iav has AMBARELLA_CHIP=S3Lm once iav.ko is loaded. The model stays S3L, because ipcinfo -c and the firmware's hostname use it.

Tested: all of the above on the camera itself, built with the published toolchain.ambarella-s3l, plus the unit tests, with ambarella_test covering both boards' memory layouts. sensors_golden.txt gained the new ID.

Not tested: the #266 camera with this PR. It has the same iav file per its ls, and its RAM figures are covered by the unit test only.

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

PR Summary by Qodo

Correct Ambarella S3L media RAM and detect Hikvision AR0237

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

AI Description

• Calculate media RAM from Linux’s actual RAM boundary when Hikvision’s device-tree split is stale.
• Detect the Hikvision AR0237 and report S3Lm family when IAV information is available.
• Cover both boards’ memory layouts and the new sensor ID with tests.

Diagram

graph TD
  D["DT or boot log"] --> H["Ambarella HAL"] --> R["RAM fields"] --> J["ipctool report"]
  I["Linux RAM map"] --> H
  V["IAV chip info"] --> H
  H --> P["Sensor probe"] --> O["AR0237 result"] --> J

Loading

High-Level Assessment

Keep the existing device-tree-or-boot-log source for the carve-out end and use /proc/iomem for the actual Linux RAM boundary. Trusting the device-tree start would preserve the Hikvision error, while relying on the boot log alone would fail when its entry is unavailable; the existing carve-out-size fallback remains useful.

Files changed (6) +101 / -5

Enhancement (2) +9 / -0

ambarella.hDeclare Ambarella memory and family helpers +3/-0

Declare Ambarella memory and family helpers

• Exposes the new media-RAM calculation and IAV family parser for use by the HAL and hardware-free tests.

src/hal/ambarella.h

sensors.cRecognize the Hikvision AR0237 sensor ID +6/-0

Recognize the Hikvision AR0237 sensor ID

• Maps the observed little-endian 0x5009 register value to AR0237. The association is based on the camera firmware’s driver, not a verified datasheet ID.

src/sensors.c

Bug fix (1) +42 / -4

ambarella.cCorrect media RAM and expose the S3Lm family +42/-4

Correct media RAM and expose the S3Lm family

• Adds the Hikvision sensor address to Onsemi probing. Calculates media RAM from the carve-out end and /proc/iomem when possible, falling back to the carve-out size; also reports the chip family from /proc/ambarella/iav when present.

src/hal/ambarella.c

Tests (2) +46 / -0

ambarella_test.cTest both S3L RAM layouts and family parsing +45/-0

Test both S3L RAM layouts and family parsing

• Adds fixtures for Hikvision’s stale carve-out start and Dahua’s matching boundary, plus a missing-iomem fallback. Checks S3Lm extraction and behavior when the IAV file is absent.

src/hal/ambarella_test.c

sensors_golden.txtAdd AR0237 to expected sensor results +1/-0

Add AR0237 to expected sensor results

• Adds the new Onsemi 0x5009-to-AR0237 mapping to the sensor golden output.

src/sensors_golden.txt

Documentation (1) +4 / -1

CLAUDE.mdDocument S3Lm reporting and the media RAM boundary +4/-1

Document S3Lm reporting and the media RAM boundary

• Explains the optional IAV-derived family field and why media RAM uses Linux’s actual RAM boundary rather than the potentially stale carve-out start.

CLAUDE.md

[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. Media RAM falls back to the stale carve-out size ✓ Resolved

Description

ambarella_media_kb only uses the trusted carve-out end when /proc/iomem lists a System RAM
range above the carve-out start. Otherwise it returns size / 1024, where size was derived from
the stale /iavmem start, so the Hikvision board's 192M figure comes back whenever /proc/iomem is
unreadable or has no matching System RAM line. The PR's own unit test (ambarella_test.c, the
/nonexistent case) locks in this behaviour, so the stale value is accepted as the expected result
rather than flagged.

---

2. Split RAM ranges inflate media size ✓ Resolved

Description

ambarella_media_kb() uses line_from_file() to read only the first System RAM range and treats
its end as the top of Linux RAM. If /proc/iomem lists a later range extending into the carve-out,
the reported media size includes memory Linux uses; the new tests cover only single-range layouts.

---

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 ↗