ssc377qe - only 89592K from 262144K is available

[svpcom]

ssc377qe has 256MiB of RAM, but linux kernel use only 91MiB of them

Vendor	sigmastar
SoC	ssc377qe
Model	ssc377qe
Kernel	17:45:35 2026-09-18
RootFS	master+49908b5, 2026-09-18

root@ssc377qe-imx335:~# dmesg | grep -i Memory
Memory policy: Data cache writeback
Reserved memory: bypass cma0 node, using cmdline CMA params instead
Early memory node ranges
Memory: 89592K/262144K available (2404K kernel code, 347K rwdata, 1068K rodata, 124K init, 114K bss, 170504K reserved, 2048K cma-reserved)

root@ssc377qe-imx335:~# free
              total        used        free      shared  buff/cache   available
Mem:          91640       12444       69508           0        9688       75000
Swap:             0           0           0

Is it possible to use remaining memory?

[openipc-ai]

Yes — and none of it is lost, it is reserved on purpose. That 170504K is the MMA heap, the
contiguous pool the SigmaStar multimedia stack allocates every ISP/encoder buffer from. U-Boot
carves it out of DRAM before Linux starts.

Where the number comes from

OpenIPC's U-Boot ships this bootargs (include/configs/sstar-common.h):

... LX_MEM=${memlx} mma_heap=mma_heap_name0,miu=0,sz=${memsz} cma=2M

and board_late_init() in arch/arm/cpu/armv7/infinity6c/chip.c fills the two placeholders in
from the DRAM size it detects:

DRAM	memlx (LX_MEM)	memsz (MMA heap)
256 MB	0x10000000 (256 MB)	0x0A000000 — 160 MB
128 MB	0x8000000 (128 MB)	0x4600000 — 70 MB
else	0x4000000 (64 MB)	0x2000000 — 32 MB

So on your board LX_MEM is the whole 256 MB and the 160 MB heap is reserved inside it — which is
exactly what your dmesg adds up to:

262144K total
-163840K  mma_heap sz=0x0A000000
-  2048K  cma=2M          (shown separately as "cma-reserved")
-  4057K  kernel image    (2404 code + 347 rwdata + 1068 rodata + 124 init + 114 bss)
-  2607K  mem_map, page tables, early allocations
= 89592K available        and MemTotal 91640K = 89592 + the 2048K of CMA

Worth saying plainly: unlike HiSilicon's CMA-backed MMZ, SigmaStar's MMA is a static carve-out.
Idle video memory cannot be lent back to Linux, so shrinking the reservation is the only lever.

How much of it is actually used

Read it at /proc/mi_modules/mi_sys_mma/mma_heap_name0 — but exercise the camera first (pull
some snapshots, connect a client), because a freshly started pipeline under-reports:

           heap_name            pa_start              length               avail
      mma_heap_name0            23a00000             4600000             1dfa5c0

Measured here just now:

board	pipeline	heap	used
ssc377d, infinity6c, 128 MB	imx335, video0 2560x1920 + JPEG	70 MB	40 MB
ssc30kq, infinity6e, 256 MB	imx335, video0 full-res + video1 704x576 + JPEG 1280x720	158 MB	56 MB

The 256 MB profile reserves roughly three times what a 5 MP pipeline needs.

The trap: fw_setenv memsz does nothing

memsz and memlx are in the saved environment and fw_printenv will happily read your value
back — but board_late_init() runs setenv() on them unconditionally, every boot, before
bootcmd. Tested on both boards above: the new memsz was stored in flash and the kernel still
got the stock one. /proc/cmdline is the only honest answer.

What does work

Rewrite bootargs so the size is literal, leaving every other token byte-identical — in particular
leave LX_MEM=${memlx} and ${rootmtd} as placeholders, so you never retype mtdparts:

fw_printenv -n bootargs > /root/bootargs.orig          # keep the original

sed 's/\(mma_heap=[^ ]*,sz=\)[^ ,]*/\10x06000000/' /root/bootargs.orig > /tmp/ba
diff /root/bootargs.orig /tmp/ba                       # must show sz= and nothing else
fw_setenv bootargs "$(cat /tmp/ba)"
fw_printenv -n bootargs                                # read it back BEFORE rebooting
reboot

To undo: fw_setenv bootargs "$(cat /root/bootargs.orig)" — and keep a copy off the camera
too, since firstboot and sysupgrade -n wipe the overlay /root lives on while the U-Boot
environment survives.

Run the diff. Matching the sz= inside mma_heap rather than the ${memsz} placeholder
matters because some installations store a literal size instead — the older procedure in
install-sigmastar.md writes sz=0x1C00000 with mma_memblock_remove=1. Against those, a
substitution keyed on the placeholder replaces nothing, fw_setenv writes the same string back
and the camera reboots unchanged. An empty diff means nothing was replaced.

Verified on the 256 MB ssc30kq with sz=0x06000000 (96 MB heap):

before:  Mem:  92768 kB total          mma_heap length 9e40000, avail 666d000
after:   Mem: 156880 kB total          mma_heap length 5fc0000, avail 2810000

+64 MB to Linux, 40 MB still free in the heap, snapshots and streams unaffected. On the 128 MB
ssc377d the same edit to sz=0x3800000 (56 MB) moved MemTotal 53848 → 68184 kB — exactly the 14 MB
taken off the heap, 1:1 — with 16 MB spare in the heap, 10/10 snapshots at 213 KB and no allocation
failures.

sz=0x06000000 is the value I would start from on your ssc377qe. Two cautions:

• Measure with everything you actually use enabled. Overlays, a second stream, LDC and
  parameterised snapshots all take from this heap, and it is sized once at startup.
• Running short does not fail loudly. The vendor allocator returns an error deep inside the stack,
  so the symptom is a dead stream or a snapshot that never answers — and it may only show up at a
  later mode change (night switch, resolution change) rather than at boot. Keep real headroom over
  the measured peak, and keep the original bootargs where you can paste it back.

Separately: U-Boot resetting memsz on every boot while leaving it visible and writable in the
environment is a trap worth removing, so that fw_setenv memsz means what it looks like it means.
I will raise that against OpenIPC/u-boot-sigmastar.

---

Edited to fix the substitution: it now matches the sz= inside mma_heap whatever it holds,
rather than only the ${memsz} placeholder, and checks with diff before writing. All of the
above, with the per-family sizes and both sets of measurements, is now on the wiki:
Memory tuning → SigmaStar boards.