Skip to content

ambarella: report total RAM from the DSP carve-out - #268

Merged
openipc-ai merged 2 commits into
masterfrom
ambarella-total-ram
Nov 6, 2026
Merged

openipc-ai merged 2 commits into
masterfrom
ambarella-total-ram

Conversation

@openipc-ai

Copy link
Copy Markdown
Contributor

Refs #266.

The reporter's camera shows ram: total: 128M with 512 MiB fitted, because mem=118M keeps the kernel far below the top of DRAM and the DSP has the rest. With this change it should report:

ram:
  total: 512M
  media: 392M
  • Source: /proc/device-tree/iavmem/reg, or the boot log's IAVMEM line on kernels with no /proc/device-tree, as on Dahua's 3.10.73.
  • Fallback: the log line is printed once. If the ring buffer has dropped it, the report falls back to what the kernel sees, so a long-running camera may still show 128M.
  • Why this is now safe: ambarella: detect the SoC from the machine string #267 refused to use IAVMEM because the issue said 256 MiB. The reporter has since corrected that from the DRAM marking and an aliasing check on the running board. CLAUDE.md is updated to match.

Tested: ambarella_test with the reporter's log and a device-tree fixture, plus the host and arm32 builds.

Not tested:

  • It has not run on a camera.
  • The device-tree path has no real sample, only the format the kernel parses.

Sensor reporting is unchanged. Stock firmware has no /dev/i2c-*, and sensor.ko owns the bus, so driving the controller registers directly would race it.

An S3L camera reported 128M with 512 MiB fitted (#266): mem=118M keeps
the kernel far below the top of DRAM, and the DSP has the rest. The
reporter read the DRAM marking, a 4 Gbit part on a 16-bit bus, and checked
that memory above 256 MiB does not alias, so the 256 MiB in the issue was
wrong and IAVMEM ending at 512 MiB was right. This replaces the note
that said not to trust it.

Total is now the top of the carve-out and media is its size, from
/proc/device-tree/iavmem/reg, or from the boot log's IAVMEM line where
there is no /proc/device-tree, as on Dahua's 3.10.73. That line is
printed once, so a ring buffer that dropped it falls back to what the
kernel sees.

Stock Dahua firmware has no /dev/i2c-*, because its own sensor.ko owns
the bus, so no sensor is reported there. CLAUDE.md records that.

The parsers are tested with the reporter's log. It has not run on a
camera.
@qodo-free-for-open-source-projects

Copy link
Copy Markdown

PR Summary by Qodo

Report Ambarella total RAM using the DSP carve-out

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

Grey Divider

AI Description

• Report total and media RAM from Ambarella's DSP carve-out instead of kernel-visible memory.
• Read device-tree data first, then the boot log; fall back to kernel memory when unavailable.
• Add parser tests and document the corrected RAM evidence and sensor-access limitation.
Diagram

graph TD
  DT["Device tree"] --> Choice{"DT available?"} -->|yes| Parse["Parse carve-out"] --> Valid{"Valid range?"} -->|yes| Report["RAM report"]
  Choice -->|no| Log["Boot log"] --> Parse
  Valid -->|no| Kernel["Kernel memory"] --> Report
Loading
High-Level Assessment

Using the existing HAL memory hook with device-tree data first and a boot-log fallback fits the affected kernels. Kernel-visible memory alone undercounts RAM, while relying only on the boot log would fail after its one-time line leaves the ring buffer.

Files changed (4) +109 / -5

Enhancement (1) +9 / -0
ambarella.hDeclare IAVMEM parser interfaces +9/-0

Declare IAVMEM parser interfaces

• Exposes the device-tree and boot-log parsers, with physical start and size returned in bytes.

src/hal/ambarella.h

Bug fix (1) +64 / -0
ambarella.cDerive Ambarella RAM from the IAVMEM carve-out +64/-0

Derive Ambarella RAM from the IAVMEM carve-out

• Adds device-tree and boot-log parsers and registers an Ambarella total-memory hook. The hook reports the carve-out's end as total RAM and its size as media RAM, falling back to kernel memory when no valid carve-out is found.

src/hal/ambarella.c

Tests (1) +25 / -0
ambarella_test.cTest Ambarella carve-out parsing +25/-0

Test Ambarella carve-out parsing

• Adds the reporter's boot-log example and a binary device-tree fixture. Checks missing log data and truncated or absent device-tree files.

src/hal/ambarella_test.c

Documentation (1) +11 / -5
CLAUDE.mdCorrect Ambarella RAM guidance +11/-5

Correct Ambarella RAM guidance

• Replaces the warning against trusting IAVMEM with the corrected 512 MiB board evidence and documents the two carve-out sources and kernel-memory fallback. Also explains why stock Dahua firmware does not report a sensor.

CLAUDE.md

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Nov 6, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

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

Grey Divider


Remediation recommended

1. Full logs can misreport camera memory ✓ Resolved
Description
ambarella_totalmem() replaces the final byte returned by get_dmesg_buf() with a terminator, even
when that byte belongs to the IAVMEM size. If a full log ends on a hexadecimal digit of that
value, the parser accepts the shortened number and reports incorrect total and media memory.

Grey Divider

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 ↗

Grey Divider

Qodo Logo

Review of #268. Overwriting the last byte of the log could shorten the
IAVMEM size if the log ended on it, and the parser took the shorter
number. The buffer now gets a real terminator, and the line has to end
in a newline to count.
@openipc-ai
openipc-ai merged commit 7c51a7e into master Nov 6, 2026
5 checks passed
@openipc-ai
openipc-ai deleted the ambarella-total-ram branch November 6, 2026 04:55
DeathCamel58 added a commit to DeathCamel58/openipc-ipctool that referenced this pull request Nov 6, 2026
rounded_num() counts the halvings it takes to reach zero and returns
1 << that count, so an exact power of two comes back doubled: 512 -> 1024.
A kernel MemTotal is never one, which is why it never showed, but since
OpenIPC#268 the Ambarella total is the top of the DSP carve-out, and on the S3L
camera from OpenIPC#266 that is exactly 512M (0x07800000 + 0x18800000). Both stock
and OpenIPC kernels reported `total: 1024M` there.

Return n unchanged when it is already a power of two. backup.c rounds its
total with the same function and gets the same fix.

ambarella_test now covers the 512M case, a 114940 kB MemTotal (112 -> 128),
513 -> 1024 and 1 -> 1; without the fix the 512M and 1 cases fail.
openipc-ai pushed a commit that referenced this pull request Nov 6, 2026
rounded_num() counts the halvings it takes to reach zero and returns 1 << count, so an exact power of two came back doubled. A kernel MemTotal is never one, so this never showed until #268 made the Ambarella total the top of the DSP carve-out, exactly 512 MiB on the S3L camera in #266.

It now returns n unchanged when n is already a power of two. backup.c rounds its total with the same function and gets the same fix.

Tested on an Amcrest IP4M-1026E: total 512M and media 392M on both stock Dahua 3.10.73 and OpenIPC 3.10.104.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant