Firmware-Image Accessor Index

The gen × engine × variant × region matrix that the host resolver nrtucode_get_memory_image walks into. This page is the single dense index of every embedded firmware-image getter in libnrtucode_internal.so: name, image pointer, size, real-blob-vs-cursor classification, and the (generation, engine, flavor, region) key that selects it.

Scope. This is the catalog page. Every getter gets a row; the resolver body is reproduced as annotated C; the per-blob byte semantics (S:/P%i: self-naming, the carve geometry, the three-source reconciliation) are summarized but live in detail on the per-generation image pages (sunda-*, cayman-*, mariana-*, maverick-*), the EXTISA inventory, the PROF CAM/TABLE formats, and the firmware-image catalog capstone. The host resolver itself is documented at runtime/image-hwdecode-resolvers.md.

0. Target binary

All facts below are static-analysis-derived: nm / objdump -d / readelf / dd / sha256sum over the shipped binary. [HIGH/OBSERVED] unless tagged otherwise.

Section/offset model (so addresses are reproducible)

readelf -SW confirms three layout deltas you need to carve blobs and read the tables: [HIGH/OBSERVED]

GOTCHA. Only .rodata is identity-mapped, so a getter's lea-target img-ptr is both the runtime VA and the file offset — dd skip=$imgptr count=$size carves the exact blob. The image_list/descriptor tables are not identity-mapped (delta 0x2000/0x3000); subtract the delta before dd/xxd or you read the wrong struct.

1. The getter shape and the naming grammar

Every accessor is the exact 4-instruction stub — verified instruction-exact on multiple getters: [HIGH/OBSERVED]

9b3540 <CAYMAN_NX_ACT_DEBUG_DRAM_get>:
   lea    -0x84a147(%rip),%rax     # 169400 <CAYMAN_NX_ACT_DEBUG_DRAM_get.data>   ; img-ptr
   mov    %rax,(%rdi)              ; *out_ptr  = blob
   movq   $0x6260,(%rsi)           ; *out_size = size
   ret

i.e. void <NAME>_get(void** out_ptr /*rdi*/, size_t* out_size /*rsi*/) — it writes the (image-pointer, size) pair through two out-pointers and returns. The img-ptr is always a named .rodata symbol <NAME>.data; all 386 objdump-parsed lea targets equal the nm .data symbol address, 0 mismatches. [HIGH/OBSERVED]

Naming grammar [HIGH/OBSERVED]

<GEN>_<CLS>_<ENGINE>_<VARIANT>_<REGION>_get

NOTE. NX_POOL is the SEQ-style sequencer pool image (S: self-names); Q7_POOL is the custom-op Vision-Q7 compute image (P%i: self-names). They are distinct cores and distinct getter families — do not conflate the two POOLs.

2. Counts — verified against the binary

nm libnrtucode_internal.so | rg -c '_get$' = 388 = 386 defined-local (nm type t) getters + 2 weak-undefined SUNDA Q7_POOL EXTISA stubs (see §5). The 386 defined getters: [HIGH/OBSERVED]

GOTCHA — the MARIANA grep trap. rg ' t MARIANA_.*_get$' returns 200 because MARIANA_PLUS symbols also begin MARIANA_. The true MARIANA-only count is 200 − 100 = 100. Always subtract the _PLUS slice.

Category partition (each verified by nm | rg -c): [HIGH/OBSERVED]

The base+DKL = 324 getters are the resolver-reachable set of get_memory_image; PROF (30) and EXTISA (32) are sibling lanes. 324 + 30 + 32 = 386, exact, no residue. [HIGH/OBSERVED]

CORRECTION. A "266-getter" figure circulated in the task brief. The binary does not produce 266 anywhere; the precise resolver-reachable count is 324 (or 288 base-only if DKL is excluded). The grand total is 386. Use these.

225 distinct image pointers back 386 getters [HIGH/OBSERVED]

objdump-parsing every getter's lea target and sort -u yields 225 distinct img-ptr addresses. The 386 → 225 collapse is because the (almost-always-empty) SRAM/EXTRAM segments return a (cursor, 0) pair where the cursor is the start of the next engine's blob — a boundary marker, not a real alias. Region population pattern: [HIGH/OBSERVED]

3. The resolver — nrtucode_get_memory_image

T nrtucode_get_memory_image @0x9b2960 (front-lib twin @0x30adf0). The first arg is not a raw coretype — it is a flat (gen, engine) image index 0..37 that the host driver precomputes. [HIGH/OBSERVED]

// nrtucode_get_memory_image — internal twin @0x9b2960, byte-exact from objdump+IDA.
// Returns: 0 ok | 1 idx>37 | 2 flavor-miss/region>3/empty-slot | 3 region-getter NULL
//        | 8 removed-env-flag tripwire (NRTUCODE_MPLUS_ON_MARIANA set to "1").
typedef void img_get(void** out_ptr, size_t* out_len);   // the 4-insn getter stub

struct image_desc {        // 0x28 = 40 bytes, .data, R_X86_64_64 getter relocs
    uint64_t  flavor_key;  // +0x00  1=PERF/RELEASE 2=DEBUG 3=TEST 17/18/19=DKL_{P,D,T}
    img_get*  IRAM_get;    // +0x08  region 0
    img_get*  DRAM_get;    // +0x10  region 1
    img_get*  SRAM_get;    // +0x18  region 2
    img_get*  EXTRAM_get;  // +0x20  region 3
};
struct image_list_ent {    // 16 bytes; image_list @0x9b8d20 is 38 of these (size 0x260)
    uint64_t       count;       // +0x00  # of flavor descriptors for this (gen,engine)
    image_desc*    table;       // +0x08  R_X86_64_RELATIVE addend = descriptor array base
};
extern image_list_ent image_list[38];   // @0x9b8d20 (.data.rel.ro)

int nrtucode_get_memory_image(unsigned idx,   /*edi: flat (gen,engine) index 0..37*/
                              int region,      /*esi: 0=IRAM 1=DRAM 2=SRAM 3=EXTRAM */
                              int flavor,      /*edx: 0=auto|1=PERF/REL|2=DEBUG|3=TEST|17/18/19=DKL*/
                              void** out_ptr,  /*rcx*/
                              size_t* out_len) /*r8 */
{
    int result = 1;
    if (idx > 0x25 /*37*/) return 1;                        // 9b2965 cmp $0x25,%edi

    // (A) REMOVED-flag tripwire — NOT a live MARIANA_PLUS-on-MARIANA selector.
    const char* mp = getenv("NRTUCODE_MPLUS_ON_MARIANA");   // 9b2987 (env @VA 0x4fae)
    if (mp) {                                                // first-byte logic:
        int t = (unsigned char)mp[0] - '1';                 //   value "1" (exactly) trips it
        if (mp[0] == '1') t = mp[1];
        if (-t == 0) {                                       // value == "1"
            fwrite(/*0x99-byte "...flag has been removed..."*/, 0x99, 1, stderr);
            return 8;                                        // 9b2ae9 → ret 8
        }
    }

    image_list_ent* e = &image_list[idx];                   // 9b29b5 lea image_list; idx*16

    // (G) flavor==0 → env-auto resolution (NEURON_UCODE_FLAVOR)
    if (flavor == 0) {                                       // 9b29bf test r15d
        const char* fv = getenv("NEURON_UCODE_FLAVOR");      // env @VA 0x52e2
        if (!fv)                            flavor = 1;      // unset → PERF
        else if (!strcmp(fv,"debug") ||
                 !strcmp(fv,"DEBUG"))       flavor = 2;      // → DEBUG
        else if (!strcmp(fv,"test"))        flavor = 3;      // → TEST
        else flavor = (strcmp(fv,"TEST")==0) ? 3 : 1;        // "TEST"→3 else PERF default
        // NOTE: no env path ever yields 17/18/19; DKL is host-driver-explicit only.
    }

    // (E) linear scan of `count` descriptors for flavor_key == flavor
    result = 2;
    if (e->count == 0) return 2;                             // empty slot (incl. idx 36)
    image_desc* d = e->table;
    for (uint64_t n = e->count; flavor != d->flavor_key; d++)// stride 0x28 (9b29e0..9b29f4)
        if (--n == 0) return 2;                              // no matching flavor → ret 2

    // (F) region select via jump table @VA 0x555c, then call the getter
    if ((unsigned)region > 3) return 2;                      // 9b2a79 cmp $0x3,%ebp
    img_get* g;
    switch (region) {                                        // 0x555c: 4×int32 rel32
        case 0: g = d->IRAM_get;   break;                    // +0x08
        case 1: g = d->DRAM_get;   break;                    // +0x10
        case 2: g = d->SRAM_get;   break;                    // +0x18
        case 3: g = d->EXTRAM_get; break;                    // +0x20
    }
    if (!g) return 3;                                        // 9b2ae2 region-getter NULL
    g(out_ptr, out_len);                                     // 9b2ad0 call *%rax
    return 0;                                                // 9b2ad2 xor %eax,%eax
}

Every branch, the region jump table @VA 0x555c, the 0x28 descriptor stride, the env logic, and the return codes were triple-anchored (objdump disasm + IDA decompile + raw-byte reads agree). [HIGH/OBSERVED]

Return-code table [HIGH/OBSERVED]

QUIRK — boundary cursor vs absent slot. A zero-size SRAM/EXTRAM getter is a real, non-NULL function returning (cursor_ptr, 0); the resolver's test %rax,%rax on the getter pointer passes, it calls the getter, the getter writes size 0, and the resolver returns 0 (success) with *out_len == 0. Code 3 only fires when the descriptor slot itself is NULL (a genuinely absent engine/flavor, e.g. front-lib MAVERICK or front-lib DEBUG/TEST). This cleanly separates "this image has no SRAM bytes" from "this variant is not present in this build."

4. The image_list key → getter selection map

image_list @0x9b8d20 is 38 × 16 B (size 0x260). The raw count vector read straight from the binary (dd skip=0x9b6d20, delta 0x2000) is, slot by slot:

[ 1,1,1,1,1,1,1,  3,3,3,3,3,3,6,3,  3,3,3,3,3,3,6,3,  3,3,3,3,3,3,6,3,  3,2,2,2,2,0,3 ]
   └─ SUNDA 0..6 ─┘└── CAYMAN 7..14 ─┘└─ MARIANA 15..22 ┘└ MPLUS 23..30 ┘└ MAVERICK 31..37 ┘

Σ = 102 descriptors (SUNDA 7 + CAYMAN 27 + MARIANA 27 + MPLUS 27 + MAVERICK 14). 102 × 4 region slots = 408 getter references → 324 distinct getters (boundary cursors share pointers). [HIGH/OBSERVED]

Flavor enum [HIGH/OBSERVED]

NOTE — engine ↔ slot. The engine is encoded by slot position, not a separate arg. Per gen the order is NX_ACT, NX_DVE, NX_POOL, NX_PE, NX_SP, NX_SP, Q7_POOL [, Q7_POOL]. This reconciles with the CSR sequencer-aperture ordering PE=0x000, POOL=0x100, ACT=0x200, DVE=0x300; PE=0 and DVE=3 are OBSERVED, POOL=1/ACT=2 are INFERRED from that ordering [MED/INFERRED]. The same flat firmware binary loads on any engine slot; engine_idx is computed at boot from engine_base_addr.

QUIRK — the double-SP slots. Every generation enumerates NX_SP twice (e.g. il[4]&il[5] SUNDA; il[34]&il[35] MAVERICK). Both descriptors point at the same NX_SP getters — byte-identical duplicates. The aliasing is OBSERVED; the reason (left/right SP, sync-pair, or a fixed per-gen slot stride) is INFERRED [MED]. idx 36's empty slot is the consequence: MAVERICK has no NX_ACT, so the NX block is one slot short and a 1-slot gap opens before Q7_POOL at idx 37.

5. SUNDA EXTISA — the two weak-undefined getters

nm reports 388 _get symbols = 386 local + 2 weak-undef:

w SUNDA_Q7_POOL_RELEASE_EXTISA_0_SO_get
w SUNDA_Q7_POOL_RELEASE_EXTISA_0_JSON_get      ; .dynsym: NOTYPE WEAK UND, value 0

These have no body and no .data — they are link-time placeholders resolved only when the runtime libnrtucode_extisa.so container is present. SUNDA ships its 24 base RELEASE engine images in-lib, but its Q7 POOL custom-op kernel lives in the runtime EXTISA container, not here. [HIGH/OBSERVED] Consequently get_num_ext_isa_libs returns 4 only for gen indices whose bit is set in mask 0x2020202000 = {13,21,29,37} (CAYMAN/MARIANA/MARIANA_PLUS/MAVERICK); SUNDA's bit is unset → 0 in-lib EXTISA libs. See EXTISA inventory.

6. The full getter matrix (all 386)

Columns: GEN · CLS · ENG · VARIANT · REGION · SYMBOL · ACCESSOR(.text VA) · IMG-PTR(.rodata VA == file off) · SIZE · class. size 0x0 = empty segment / boundary cursor. "class": R = real blob, C = boundary cursor ((ptr,0) marker into the next engine's blob).

GOTCHA — DRAM-string offset. For a DRAM blob, the device-VA-to-blob offset is VA − 0x80000 (DRAM sits at device VA 0x80000, IRAM at 0x0). The img-ptr column below is the host .rodata file offset of the blob, not the device VA — see the per-gen image pages for the device-side string carve.

6.1 SUNDA (24 — RELEASE only, no PROF/DKL/EXTISA-in-lib)

QUIRK. SUNDA_Q7_POOL_RELEASE_EXTRAM is the sole non-zero EXTRAM in the entire catalog (0x1b40) — SUNDA's Q7 POOL carries an extra EXTRAM segment.

6.2 CAYMAN (100)

6.3 MARIANA (100)

NOTE. MARIANA and MARIANA_PLUS POOL ucode is byte-identical to each other (distinct gen labels over the same shipped kernels). The two are separate image_list slot ranges with their own getter blobs in .rodata, but the POOL kernel bytes match.

6.4 MARIANA_PLUS (100 — same shape as CAYMAN/MARIANA)

6.5 MAVERICK (62 — no NX_ACT, no DEBUG except DVE/Q7_POOL, no DKL)

WALL — v5 is header-OBSERVED, interiors INFERRED. MAVERICK getter bytes are present and carved here, but the v5 firmware interior semantics (instruction layout, S:/P%i: string structure beyond the carve) are INFERRED from the v2–v4 precedent, not byte-grounded the way SUNDA/CAYMAN/MARIANA are. The catalog facts (symbol, ptr, size, real-vs-cursor) are HIGH/OBSERVED; the firmware meaning of a MAVERICK blob is [MED/INFERRED].

QUIRK — MAVERICK runs SP & Q7_POOL from SRAM, not IRAM. For MAVERICK NX_SP and Q7_POOL, the IRAM getter is size 0 (a cursor) and the SRAM getter carries the real code (0xf580/0xf6c0 for SP PERF/TEST; 0x14480/0x1d100/0x15dc0 for Q7_POOL PERF/DEBUG/TEST). NX_DVE/NX_PE/ NX_POOL still load from IRAM normally. Verified by getter-body movq $0x0 on IRAM and the non-zero movq on SRAM. [HIGH/OBSERVED]

7. The FILE-ABSENT cells (do not claim these as present)

The MAVERICK row is structurally pared down. The following (engine, gen, flavor) cells have zero getter symbols in this binary — verified nm | rg -c = 0: [HIGH/OBSERVED]

CORRECTION. Cells in the table above must never be rendered as present getters. MAVERICK_NX_POOL_DEBUG in particular is the canonical missing cell — the 0xf3 body-depth wall flagged in the Part-6 coherence pack. It is absent from both nm and image_list (idx 32 = MAVERICK NX_POOL carries keys {1,3} only). The internal twin does keep MAVERICK_Q7_POOL_DEBUG (key 2 at idx 37, count 3 = {1,2,3}), so do not over-generalize "MAVERICK has no DEBUG."

8. Three-source reconciliation (one corpus, three packaging views)

The 386 *_get accessors are not distinct firmware — they are pointers into .rodata that is the byte-identical, statically-linked-in copy of three archive families, which are in turn the same kernels the runtime EXTISA container ships. Proven by sha256 byte-identity, not inference: [HIGH/OBSERVED]

The EXTISA SO sha256 was re-verified live here: dd skip=0x2ef7e0 count=0xa260 | sha256sum = 910d41c3ededce67cd00ec7041a5e66c3c39536d2e9b16fe21ea019db4b55527, matching the runtime container. [HIGH/OBSERVED]

NOTE — internal.so is a host-side superset, not a 1:1 mirror. The shipped front lib libnrtucode.so (stripped, sha 06d3f0b1…) carries the same 38-slot image_list shape but populates only the PERF (and DKL_PERF) getters; DEBUG/TEST and all MAVERICK getters are NULL → a request for those returns code 3. The internal twin populates DEBUG/PERF/TEST and MAVERICK fully (linked from an external MAVERICK build object — MAVERICK has 0 members in this libnrtucode.a). The front-lib image_list is the unnamed unk_30F4E0 @0x30f4e0, structurally identical to internal image_list.

NOTE — SP is a real programmable NX core. SP (Top Sync Processor) has no sequencer-config CSR aperture (unlike PE/POOL/ACT/DVE) yet ships a full NX firmware-image set per gen. The only structural way SP differs in this catalog: SP has no PROF_CAM/PROF_TABLE getters (no HW-decode opcode CAM) — consistent with SP routing notifications/SPC rather than decoding instructions.

9. Adversarial self-verification

Five strongest claims, re-challenged against the binary:

1. Getter count = 386 defined-local (+2 weak SUNDA EXTISA). nm libnrtucode_internal.so | rg -c '_get$' = 388; ' t .*_get$' = 386; ' w .*_get$' = 2. ✓ Per-gen 24/100/100/100/62 each independently rg -c-verified (with the MARIANA-vs-MARIANA_PLUS subtraction trap noted). ✓ Category split 288 base + 36 DKL + 32 EXTISA + 30 PROF = 386. ✓

2. Resolver key tuple = (idx 0..37, region 0..3, flavor) — NOT raw coretype. Disassembly of nrtucode_get_memory_image @0x9b2960 confirms cmp $0x25,%edi (idx ≤ 37) → image_list[idx*16] → count/descriptor*; descriptor scan at 0x28 stride matching flavor_key; region jump table @VA 0x555c with add $0x8/$0x10/$0x18/$0x20 = IRAM/DRAM/SRAM/EXTRAM; call *%rax. ✓ The raw image_list count vector read from 0x9b6d20 is exactly [1×7, …, 0, 3] Σ = 102. ✓ Challenge: is the first arg really not coretype? The map enumerates (gen, engine) with double-SP slots and an empty idx-36 between MAVERICK SP and Q7_POOL — a coretype index (6/13/21/29/37) would not produce that shape. Resolved: it is the flat (gen,engine) index. ✓

3. FILE-ABSENT: MAVERICK_NX_POOL_DEBUG (and MAVERICK_NX_ACT, MAVERICK DKL, non-DVE/Q7 DEBUG) are genuinely absent. nm | rg -c = 0 for each. ✓ image_list idx 32 (MAVERICK NX_POOL) count = 2, keys {1,3} — DEBUG (key 2) not in the descriptor set. ✓ Challenge: does the front lib hide them as NULL rather than absent? No — they are absent from the symbol table of the internal twin, the most complete view; the front lib NULLs them additionally. Distinction preserved (absent symbol vs NULL slot vs (cursor,0)). ✓

4. 225 distinct image pointers back 386 getters. objdump-parse every getter's lea target, sort -u = 225. ✓ Challenge: are the duplicates real aliases (two images sharing bytes) or boundary cursors? Spot-checked CAYMAN_NX_PE_PERF_SRAM_get → ptr 0xa0600 = CAYMAN_NX_POOL_PERF_IRAM.data with movq $0x0 → it is a (next-engine-cursor, 0) empty marker, not an alias. The 386 → 225 collapse is entirely the zero-size SRAM/EXTRAM cursors. ✓

5. EXTISA SO bytes are the runtime container kernel. dd skip=0x2ef7e0 count=0xa260 | sha256sum = 910d41c3ededce67… ✓ — identical to the byte the EXTISA container ships, proving the three packaging views are one corpus. ✓ All *_EXTISA_n_JSON sizes are uniformly 0x20 (the {"dummy_message":"hello world"} manifest placeholder for the 4 EXTISA-bearing gens). ✓

All five survive re-challenge with zero corrections to the catalog data.

10. Cross-references

• EXTISA inventory — the 32 EXTISA SO/JSON getters and the get_ext_isa lane.
• PROF CAM/TABLE formats — the 30 PROF getters and the get_hwdecode_table lane.
• Per-generation image pages: SUNDA POOL · CAYMAN ACT / DVE / PE / POOL / SP · MARIANA ACT · MARIANA_PLUS ACT · MAVERICK ACT (the ACT→DVE fold).
• Firmware-image catalog capstone — the cross-gen overview that consumes this index.
• runtime/image-hwdecode-resolvers.md — the host get_memory_image / get_hwdecode_table resolvers in full (this page reproduces the get_memory_image body; the resolver page covers both lanes plus the front-lib twin).