Add DDR bandwidth test subcommand (memset/memcpy/read scan)

[widgetii]

Motivation

While debugging an encoder fps gap between OpenIPC and vendor firmware running on identical gk7205v300 silicon, I needed a quick way to verify that DDR was actually performing at the same speed on both boards. Building, deploying, and timing a one-off C benchmark for each test ate a lot of session time. A bundled tool would have made this a one-liner.

Memory-throughput is a useful baseline check whenever an SoC misbehaves: encoder/ISP fps caps, frame drops, slow dd to flash, etc. It separates "the CPU pipeline is the bottleneck" from "the DDR pipeline is the bottleneck" in a few seconds.

Concrete example from the field

Two boards, same goke,gk7205v300 per device-tree, same OTP at 0x12020084, same chip ID registers, same DDR-clock select bit (CRG 0x12010080 = 0x549 → 450 MHz on both):

Op (16 MB buffer, both streamers idle)	OpenIPC	XM vendor	Ratio
memset (write)	1622 MB/s	2264 MB/s	+40%
read scan (volatile uint32_t sum)	496 MB/s	558 MB/s	+12%
memcpy (R+W)	1547 MB/s	2109 MB/s	+36%

That ratio matched the wire-fps gap (~20%) we were seeing, which immediately pointed the investigation at the CPU/DDR PLL multiplier — set by mask ROM based on per-die HPM characterization (HPM_CHECK_REG at 0x1202015c differed: 0xF3 vs 0xF6 → mask ROM picks CPU PLL FBDIV=0x77 vs 0x8F → 952 MHz vs 1144 MHz).

Without a bundled bandwidth test, this was hours of cross-compile / scp / measure / cross-compile loop.

Proposed subcommand

ipctool membw [options]
  --size MB         buffer size per pass (default: 16; must exceed L2 cache)
  --iters N         number of passes per op (default: 16)
  --ops set,...     comma list of ops to run: write,read,copy (default: all)
  --json            machine-readable output

Sample run:

$ ipctool membw
Chip: gk7205v300  DDR clock: 450 MHz
Buffer size: 16 MB, iters: 16
memset (write):  1622 MB/s  (0.090 s)
read scan:       496 MB/s   (0.288 s)
memcpy (R+W):    1547 MB/s  (0.220 s)

Reference implementation

Self-contained, static, libc-portable. Uses mmap of /dev/zero rather than malloc so the buffers come from anonymous DDR pages rather than tmpfs/page cache. The read scan loop uses volatile uint32_t sum to force actual loads (compiler can't elide).

// see attached membw.c in the issue (~70 lines)

Notes / caveats worth documenting in the tool:

• Buffer size must exceed L2 (typically 256K-1MB on V4 family) or you measure L2, not DDR.
• Streamer activity loads DDR via DMA. Stop majestic / vendor App before measuring DDR config; run with streamer when comparing real workload bandwidth.
• libc memset/memcpy implementations differ (musl vs uClibc vs glibc); the read scan loop is libc-independent and is the most trustworthy across builds.
• On very dark scenes, AE-extended exposure dominates rate; measure under known lighting if you correlate with stream fps.

Where this fits in ipctool

Currently ipctool is "the read-only hardware probe" — chip ID, sensor, MMZ layout, etc. membw fits the same shape: read-only, fast, prints a one-shot diagnostic. Doesn't write anything, doesn't need privileges beyond root (which ipctool already has).

The size measurement should be small enough that running on a live camera with majestic up doesn't cause frame drops (8 MB × 8 iters takes <2 s and consumes ~1 GB-second of bandwidth).

Related work

Companion request being filed in OpenIPC/defib to run the same test in U-Boot/bare-metal context — useful for proving "DDR is fine on bare metal, Linux is the problem" or vice versa.

Self-contained C source attached.

[widgetii]

Reference implementation (Linux-side, static-ARM, libc-portable):

/* membw.c — Synthetic DDR bandwidth test
 *
 * Build: ${CROSS_COMPILE}gcc -O2 -std=gnu99 -static membw.c -o membw
 * Usage: membw [MB] [iters]    (defaults: 16 MB, 16 iters)
 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <time.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>

static double now_sec(void) {
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return ts.tv_sec + ts.tv_nsec / 1e9;
}

int main(int argc, char **argv) {
    size_t MB = (argc > 1) ? atoi(argv[1]) : 16;
    int iters = (argc > 2) ? atoi(argv[2]) : 16;
    size_t sz = MB * 1024UL * 1024UL;

    int fd = open("/dev/zero", O_RDWR);
    if (fd < 0) { perror("open /dev/zero"); return 1; }
    char *a = mmap(NULL, sz, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
    char *b = mmap(NULL, sz, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
    if (a == MAP_FAILED || b == MAP_FAILED) { perror("mmap"); return 1; }

    memset(a, 1, sz);  /* fault pages in */
    memset(b, 2, sz);

    printf("Buffer size: %zu MB, iters: %d\n", MB, iters);

    double t0 = now_sec();
    for (int i = 0; i < iters; i++) memset(a, i & 0xff, sz);
    double t1 = now_sec();
    printf("memset (write):  %.1f MB/s  (%.3f s)\n",
        (double)sz * iters / (t1 - t0) / 1e6, t1 - t0);

    /* volatile sum forces actual loads; libc-independent */
    volatile uint32_t sum = 0;
    t0 = now_sec();
    for (int i = 0; i < iters; i++) {
        uint32_t *p = (uint32_t*)a;
        for (size_t k = 0; k < sz/4; k++) sum += p[k];
    }
    t1 = now_sec();
    printf("read scan:       %.1f MB/s  (%.3f s)\n",
        (double)sz * iters / (t1 - t0) / 1e6, t1 - t0);

    t0 = now_sec();
    for (int i = 0; i < iters; i++) memcpy(b, a, sz);
    t1 = now_sec();
    printf("memcpy (R+W):    %.1f MB/s  (%.3f s)\n",
        (double)sz * iters * 2 / (t1 - t0) / 1e6, t1 - t0);

    munmap(a, sz); munmap(b, sz); close(fd);
    return 0;
}

Verified on:

• arm-openipc-linux-musleabi-gcc (gk7205v200/v300 — V4 family)
• arm-xm-linux-uclibcgnueabi-gcc (vendor XM uClibc ABI, same SoC)

Caveats baked into the design:

• Uses mmap(/dev/zero) rather than malloc so the buffers come from clean anonymous DDR (not tmpfs / not page cache).
• Buffer must exceed L2 cache (on V4, 256K-1MB). Default 16 MB is safe.
• memset and memcpy performance depends on libc's vectorization. The read scan loop is the only libc-independent number — use it for cross-firmware comparison.
• Streamer activity loads DDR via DMA. Stop majestic / vendor App before measuring DDR config; run with streamer when measuring real workload bandwidth (those are two different questions).