[widgetii]

On NT9856x boards U-Boot splits the RAM by the osmem variable, while the kernel sizes itself from mem= in bootargs. The bootcmd on this page re-runs the saved bootargs, so a number stored there never follows osmem. Changing one without the other either stops the camera right after kernel decompression (osmem larger) or crashes it in a loop once the video drivers load (mem= larger).

This replaces the Known issues section with an explanation of both cases and a procedure that replaces only the mem= value in the existing bootargs with a literal ${osmem}. The board's own partition layout is left alone, a backup is kept, and the result is checked before reboot. After that, osmem is the only setting to change. The section also says the right size depends on the board's RAM and stream, and gives 32M and 54M on a 128 MB NT98566 with a 5 MP sensor as the tested example.

Verified on that hardware class: the fw_setenv/sed step keeps the placeholder, and the next boot expands it. fw_setenv osmem 54M plus a reboot then boots with the larger split and streams.

Background: OpenIPC/firmware#2107. Firmware guard for the mem= larger case: OpenIPC/firmware#2657.

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

PR Summary by Qodo

Keep Novatek kernel memory settings aligned with osmem

📝 Documentation 🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Explain why mismatched osmem and mem= values can hang or panic Novatek cameras.
• Preserve ${osmem} in saved bootargs so the existing bootcmd resolves it at boot.
• Document how to change the memory split and verify the saved setting.

Diagram

graph TD
  O["osmem value"] --> N["nvt_boot"] --> L["DT and HDAL"]
  O --> B["bootargs placeholder"] --> C["bootcmd expansion"] --> K["Kernel mem limit"]

Loading

High-Level Assessment

Keep the placeholder-based instructions. The existing bootcmd already expands saved bootargs, so documenting that mechanism avoids a separate command or a second memory setting that could become stale.

Files changed (1) +21 / -2

Documentation (1) +21 / -2

install-novatek.mdDocument a single Novatek memory-split setting +21/-2

Document a single Novatek memory-split setting

• Replaces the vague known-issues note with the failure modes caused by mismatched 'osmem' and 'mem=' values. Adds boot arguments retaining '${osmem}' and instructions to change and verify the split from Linux, including tested 32M and 54M configurations.

en/install-novatek.md

[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. Public docs expose vendor internals 📘 Rule violation ⛨ Security

Description

The page names nvt_boot, HDAL, and nvtmpp_heap_init and quotes `Uncompressing Linux... done,
booting the kernel.`, while the PR description includes captured kernel command-line and memory
output. When published alongside the NT98566/SC501AI verification details, these additions expose
vendor implementation details and lab-specific console evidence rather than only observable memory
behavior.

Code

en/install-novatek.md[R28-30]

+The vendor U-Boot's `nvt_boot` lays memory out from `osmem`: Linux gets the
+first `osmem`, the video pool (HDAL) gets the rest of the DDR, and the device
+tree is placed just below `osmem`. The kernel itself only sees `mem=` from

Evidence

The added page identifies vendor boot and memory-subsystem internals, quotes a boot-console
diagnostic, and ties the test to specific hardware and configurations. The PR description also
includes captured kernel command-line and memory output from that verification, showing that both
the documentation and public metadata contain implementation or lab-specific details.

Rule 1: Documents behaviour, not the internals behind it
Rule 2: No lab environment details
en/install-novatek.md[28-40]
en/install-novatek.md[33-35]
en/install-novatek.md[49-52]

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 public page and associated PR metadata disclose vendor implementation names, an internal boot diagnostic, and captured output from project verification hardware instead of limiting the explanation to observable memory configuration and behavior.
## Fix Focus Areas
- en/install-novatek.md[28-40]
- en/install-novatek.md[33-35]
- en/install-novatek.md[49-52]
## Recommended Fix
Rewrite the page to explain the observable relationship between the memory setting, kernel memory, video memory, and boot success. Describe failure and successful memory ranges without vendor function names, internal subsystem identifiers, quoted console output, or captured measurements from project test hardware. Retain only reproducible hardware-class and configuration details allowed by the checklist, and remove the matching captured output and implementation details from the PR description and other public metadata before merge.

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

---

2. Memory tuning can hide saved settings ✓ Resolved

Description

setenv bootargs replaces the entire partition map rather than changing only the mem= setting. On
the linked NT98566 board, its existing rootfs data begins at 0x6d0000, but the proposed map moves
that partition to 0x750000, so the camera no longer sees its existing settings after reboot.

Code

en/install-novatek.md[44]

+setenv bootargs 'earlyprintk console=ttyS0,115200 mem=${osmem} panic=20 nprofile_irq_duration=on root=/dev/mtdblock3 rootfstype=squashfs init=/init mtdparts=spi_nor.0:64k(loader),256k(boot),2048k(kernel),5120k(rootfs),-(rootfs_data)'

Evidence

The added command sets a 5120k rootfs after 64k+256k+2048k, placing rootfs_data at 0x750000. The
linked ticket describes an in-scope NT98566 board with a 0x480000 rootfs at 0x250000, placing its
existing rootfs_data at 0x6d0000; the page also identifies that partition as the settings store.

en/install-novatek.md[4-4]
en/install-novatek.md[23-24]
en/install-novatek.md[43-46]

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 example replaces the whole partition map while trying to keep `mem=` synchronized with `osmem`. The linked board has a different rootfs size, so applying this command moves its rootfs data partition and hides existing settings.
## Fix Focus Areas
- en/install-novatek.md[39-50]
## Recommended Fix
Show how to back up the current `bootargs` and replace only its `mem=` value with a literal `${osmem}` placeholder, leaving the board's existing root and partition arguments intact. Verify the saved value before reboot.

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

---

3. The 54M setting can starve other cameras ✓ Resolved

Description

fw_setenv osmem 54M is presented as a general next step even though the page says that value was
tested only on one 128 MB NT98566 configuration. The page also says HDAL receives the DDR left after
osmem, so a reader with less RAM or a larger video-pool requirement can leave too little memory
for video by following this instruction.

Code

en/install-novatek.md[49]

+From Linux, change the split with `fw_setenv osmem 54M` and reboot. Check first

Evidence

The page covers both NT98562 and NT98566 boards, states that the video pool gets the DDR remaining
after osmem, and gives the 54M command before identifying its sole tested 128 MB configuration.

en/install-novatek.md[4-4]
en/install-novatek.md[28-31]
en/install-novatek.md[49-52]

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 page recommends setting `osmem` to 54M across its Novatek board scope, while the stated streaming test covers only one 128 MB board. Other RAM sizes and video-pool requirements need a board-specific value.
## Fix Focus Areas
- en/install-novatek.md[49-52]
## Recommended Fix
Label 54M as an example for the tested 128 MB configuration before showing the command. Tell readers to determine their board's DDR size and video-pool needs before choosing an `osmem` value.

ⓘ 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 ↗

[widgetii]

Finding 1 (vendor internals / lab details) refers to the first revision. At b9b95ae the page has no vendor function or subsystem names and no quoted console lines, and the commit message and PR description were rewritten the same way. The only hardware mentioned is a hardware class (128 MB NT98566, 5 MP sensor), which the checklist allows. The one nvt_boot left is the U-Boot command inside the bootcmd the page already documented. Findings 2 and 3 are resolved. Merging.