Memory Reference Deep Census

Deeper reference memory census

Scope and separation

This addendum reexamines the existing, authorized Complex4627 image captures and two retained execution traces. It introduces no new firmware, game session, capture, rig access, or product implementation. The investigator inspected reference artifacts privately and did not inspect target product source. Shared outputs contain original measurements, public ABI names, and anonymous range identifiers only. Reference instructions, strings, pointers stored in tables, pseudocode, and control-flow graphs remain private. These procedural boundaries are not a legal certification.

The earlier REPORT.md and size-census.json remain unchanged. This addendum refines their classification and explains uncertainty; it does not replace their frozen measurements with a new native result. The reference data here is still the same 64 MiB cold-boot checkpoint. Current SpiritBoot progress belongs in the separately maintained owned census.

1. Every byte of the reference's resident image

The reference's resident kernel still occupies 45 physical pages / 184,320 bytes / 180 KiB. Translating the retained virtual content through the captured page tables verifies this partition, including the partial discardable page that survives because it shares backing with live content:

Disjoint resident image ownership	Bytes
Image header	704
Retained executable-flag region region_00	153,136
Retained writable regions region_01–region_03	28,772
Discardable region_04 content still backed on its shared first page	1,248
Backing outside those advertised content extents	460
Total unique resident physical backing	184,320

No physical content byte is charged to two rows. The writable total consists of 21,964 + 6,544 + 264 bytes. The 1,248 discardable bytes are already inside the 45 pages, not another page allocation. Their presence proves backing at this checkpoint; it does not prove that the content is needed after boot.

Virtual layout and measured physical backing

All intervals below are half-open: the final address is excluded. The image header begins at VA 0x80010000, backed by PA 0x00010000. The complete virtual image envelope is 0x80010000–0x800ab500 (636,160 bytes), which includes discarded content and alignment; it is not the resident RAM charge.

Anonymous content region	Virtual content interval	Exact content bytes	Intersected pages	RAM-backed pages at checkpoint	Physical page-backing interval at checkpoint
Header	0x80010000–0x800102c0	704	1	1	0x00010000–0x00011000
region_00, retained executable flag	0x800102c0–0x800358f0	153,136	38	38	0x00010000–0x00036000
region_01, retained writable	0x80035900–0x8003aecc	21,964	6	6	0x00035000–0x0003b000
region_02, retained writable	0x8003aee0–0x8003c870	6,544	3	3	0x0003a000–0x0003d000
region_03, retained writable	0x8003ca00–0x8003cb08	264	1	1	0x0003c000–0x0003d000
region_04, discardable	0x8003cb20–0x800ab4fa	453,082	112	1	Surviving first page: 0x0003c000–0x0003d000

The unique retained physical image backing is the contiguous 0x00010000–0x0003d000 range: 45 pages. The last 111 intersected pages of region_04 are unmapped at the checkpoint. This is a page-table observation, not a reconstruction of how the allocator labels every page.

Page sharing explains why the row page counts must not be added:

• Header and region_00 share VA page 0x80010000 / PA page 0x00010000.
• region_00 and region_01 share VA page 0x80035000 / PA page 0x00035000.
• region_01 and region_02 share VA page 0x8003a000 / PA page 0x0003a000.
• region_02, region_03, and the surviving start of region_04 share VA page 0x8003c000 / PA page 0x0003c000.

A section flag describes image content; a mapping's permission and lifetime apply to its whole page. Neither the full virtual image envelope nor an available large alias window should be counted as an equal-sized allocation. This is the resident image ledger, not the complete reference firmware-owned RAM census. Heap objects, page tables, stacks, and other physical owners must not be silently folded into these 45 pages.

2. Refining the 58,410 unclassified retained bytes

The original decoder reached 94,726 bytes in the 153,136-byte executable-flag region and left 58,410 bytes unclassified. A deeper metadata and trace pass now provides the following disjoint accounting:

Classification inside retained region_00	Bytes	Confidence
Prior recursively decoded instruction-byte union	94,726	Decoder coverage; not a compiler-function partition
Public export fixed directory	40	Exact format-defined metadata extent
Public export function-address array, 366 four-byte slots	1,464	Exact format-defined metadata extent
Additional trace-anchored decoded prefixes	740	Recorded block-entry roots; bounded decode, not complete execution or function-size proof
Remaining unclassified content	56,166	Exact remaining byte count; code/data/padding identity unresolved
Total retained region content	153,136	Exact section extent

The export directory advertises a 1,517-byte envelope. Its fixed directory and address array account for 1,504 bytes. The remaining 13 bytes inside that envelope remain untyped and are included in the 56,166-byte unknown row; no private string or identifier was exported. There are no named-export address or ordinal arrays.

Why the trace refinement matters

Some executed block-entry addresses fell outside the original recursive walks:

Existing trace / phase	Distinct entry PCs in the old unknown set	Recorded block entries
Public-entry guest, startup	62	5,961
Public-entry guest, runtime	18	41
Pool/thread guest, startup	64	5,995
Pool/thread guest, runtime	10	169

These sets overlap. Across both workloads there are 67 distinct anchors, not the sum of the four rows. Their presence directly demonstrates that the earlier unknown set includes executable locations; it cannot honestly be relabeled as unused data or padding.

The additional analysis starts only at those recorded PCs, stops at the first control transfer or existing classification boundary, and does not invent new function entries. It yields 239 decoded instruction starts / 740 additional disjoint bytes. All 740 bytes match the independent post-startup RAM capture; none are absent or differ, and none overlap another new instruction decode. Sixty-six anchor walks stop at their first control transfer; one reaches existing decoded content. No 256-byte safety limit was reached.

A recorded entry does not prove that every sequential byte in its decoded prefix executed, or that the prefix belongs to one complete compiler function. The 740 bytes therefore remain a separate evidence category. The analysis does not follow unresolved destinations or rename the prefixes as functions.

Range-level ledger

The old unknown set contained 233 disjoint spans. Twenty-six spans of at least 256 bytes contained 52,617 bytes, or about 90.1% of that set. After excluding exact public metadata and the bounded trace prefixes, 246 disjoint unknown spans / 56,166 bytes remain; the largest is 9,072 bytes. Splitting a span around newly classified content can increase the number of spans while reducing their total size.

Memory-Reference-Unclassified-Ranges records every remaining range using an anonymous ID, offset within region_00, exact length, page intersections, and candidate-start counts. It includes no reference contents. These ranges are accounting units, not recovered private objects. In particular, the span around a candidate table is not a table boundary.

What would resolve the remaining bytes: authorized symbol/section contributions would establish original object boundaries; otherwise, targeted execution and data-access observations would establish which ranges are code, which are accessed data, and when those accesses stop. Strings, pointer-like words, zero runs, and instruction decodability alone do not prove allocation type, table size, or discardability. Byte sizes can remain exact even where interpretation is unknown.

3. The 1,361 entry walks are not 1,361 functions

The existing set comprises 329 distinct public-export entries, 929 direct-call targets or the image entry, and 103 additional observed indirect-entry candidates. There were 106 observed indirect candidates overall; three already coincide with entries in another origin category. The 330 callable public export slots have one shared entry address.

Disjointness and envelope audit

Measurement	Result
Entry walks	1,361
Summed decoded bytes charged to individual walks	221,954
Disjoint union of those decoded byte positions	220,530
Duplicate byte charges in the sum	1,424
Distinct decoded byte positions shared by multiple walks	1,081
Walks touching such shared positions	27
Maximum walk owners for one decoded byte	4
Shared decoded positions in retained region_00	835
Duplicate charges in retained region_00	1,178
Walks with unresolved indirect sites	104
Unresolved indirect sites across those walks	133
Walks without the original terminated-walk flag	35

These totals span both retained and discardable executable regions. The 220,530-byte union is exactly 94,726 retained + 125,804 discardable bytes. The earlier region totals already used this union, so the image-size measurement does not need a correction. Adding the individual walk sizes, however, double-counts shared content.

The minimum-to-maximum address envelopes are substantially less reliable as sizes. Their sum is 1,060,582 bytes, while the summed decoded content is 221,954 bytes. The largest envelope is 239,514 bytes, versus a maximum decoded walk of 3,957 bytes. Twenty-two walks reach bytes below their proposed entry. Twenty-eight envelopes contain other proposed entries; collectively those broad envelopes include 1,283 entry addresses. That last figure is not 1,283 proved interior aliases: a walk can cross large holes and encompass many unrelated entries between its lowest and highest decoded addresses.

The numeric ledger therefore preserves three distinct concepts:

• Inferred envelope: address span, useful for finding uncertainty, not an allocation size.
• Decoded walk bytes: reached bytes excluding callees, with shared bytes still charged in each walk.
• Exclusive/shared bytes: bytes covered only by that walk versus bytes also covered by another walk. A shared byte is counted once in global physical accounting.

Memory-Reference-Entry-Walk-Ledger supplies one row per entry walk, with those sizes, origin, retained/discardable entry location, unresolved-site counts, and separate entry/body coverage. It publishes no call edges or reconstructed control-flow graph. Public compatibility names identify public entries; internal entries remain anonymous.

Coverage and lifetime

Entry location	Walks	Entries observed in either bounded trace	Bodies observed in either bounded trace
Retained	722	354	356
Discardable	639	549	549

Coverage includes startup and runtime and therefore does not demonstrate continued runtime use. Body coverage can be present through another entry or shared tail without the named entry having been called. 199 public entry walks remain unobserved across these workloads. No public function has been proved never used.

Only an original boundary map or a stronger independently observed entry/exit and lifetime model would justify compiler-function claims. Likewise, late callbacks, interrupts, errors, reset, and other titles must be considered before asserting that a retained range may be discarded. This addendum makes no source-removal recommendation from absent coverage.

4. Ten retained indirect-table candidates

The earlier JSON has 22 candidate records at 20 distinct addresses: ten retained executable-region addresses, one writable-region address, and nine discardable-region addresses. Two pairs of retained records duplicate a candidate address. The following table gives every unique retained candidate. Offsets are relative to anonymous region_00; all starts are RAM-backed at the captured checkpoint.

Canonical candidate ID	Region offset, bytes	Earlier duplicate record	First four bytes wholly in the old unknown set	Enclosing old unknown span, bytes
table_candidate_002	16,484	table_candidate_003	Yes	292
table_candidate_006	120,976	—	No	Not wholly unclassified
table_candidate_005	121,100	—	Yes	309
table_candidate_004	121,208	—	Yes	309
table_candidate_007	121,224	—	Yes	309
table_candidate_010	121,368	—	No	Not wholly unclassified
table_candidate_009	121,536	—	Yes	330
table_candidate_008	121,616	table_candidate_011	Yes	330
table_candidate_012	123,776	—	Yes	694
table_candidate_001	131,408	—	Yes	76

The eight wholly unclassified candidate starts lie in five prior unknown spans. Several candidates share an enclosing span. This does not prove that they are distinct arrays, portions of one array, or tables of those span lengths. The other two candidate starts intersect the recursive decoder's covered set, which is another reason not to assert an exact code/data partition from the current analysis.

Exact table byte sizes, slot counts, object identities, accessed-index ranges, and final-use times remain unknown. The current evidence recognizes a possible indexed indirect-control access but does not establish a complete bounded index domain. A sequence of words resembling valid addresses would be a plausibility check, not a table-size proof.

To resolve each candidate's size, record the access width and index/address domain at its consumer, establish the permitted bounds on all relevant paths, and distinguish shared/interior starts before charging bytes to separate objects. Observed accesses can establish a minimum used extent; exhaustive bounds or authorized object metadata are needed for an exact allocation extent. To resolve lifetime, observe the last possible consumer through title execution, errors, callbacks and reset, then inspect mapping/ownership retirement. Merely leaving the backing mapped does not prove liveness.

5. ROM calls: what is actually established

The existing mapping inventory exposes three large 4 MiB physical-ROM-window mappings and three small aliases. A mapping is an available access path, not execution evidence or extra firmware storage.

Rechecking both execution logs against the frozen mapping inventory finds:

Trace	Startup direct ROM block PCs / entries	Runtime direct ROM entries	Runtime entries through frozen lower virtual aliases
Public-entry guest, 11,084,723 total block entries	57 / 27,655	0	0
Pool/thread guest, 12,572,266 total block entries	57 / 27,655	0	0

All observed direct ROM startup PCs occupy the final 4 KiB virtual page. That physical window can include the supplied MCPX and BIOS bootstrap inputs; this observation does not attribute every startup instruction to Complex alone.

The second trace's lower-alias recheck is additional analysis of the existing trace, not a new capture. Both checks use a single post-startup mapping snapshot, not a physical instruction-fetch identity captured at each event. They cannot exclude a temporarily installed lower alias that is absent at the checkpoint. Block-entry logs also lack a complete call/return graph.

The established conclusion is therefore: startup ROM execution was observed; runtime ROM execution was not observed in these two public-API workloads, including aliases present in the retained checkpoint map. The evidence does not establish that gameplay, media errors, debugger paths, shutdown or warm reset never execute ROM. It also does not support ROM execution as the demonstrated explanation for the small resident image: the observed resident executable region and public entry points are RAM-backed.

A decisive follow-up observation would record physical instruction-fetch backing, or its mapping epoch, for each executed block while covering gameplay, storage error handling and reset. Keep ROM reads as data separate from execution, and distinguish supplied MCPX from the BIOS's ROM region. If a runtime ROM target is then observed, record only the original behavior, physical extent, entry/exit, mapping conditions and lifetime; no reference body needs to enter the product implementation.

6. Verified additions and remaining limits

This bounded pass improves the reference ledger in three ways:

1. The complete 180 KiB resident image now has a disjoint byte accounting, including 1,248 surviving discardable bytes and 460 backing bytes outside content extents.
2. The retained executable-region unknown set is refined into exact 1,504-byte public metadata, 740-byte trace-anchored prefix coverage, and 56,166 still-unknown bytes. The remaining spans are individually listed.
3. The function and candidate-table records now expose overlapping walks and unknown boundaries rather than implying compiler symbols or exact private structures.

No exact private table size or universal never-called proof emerged. This is a concrete limitation of the available metadata and coverage, not a reason to guess. The sizes and observations can guide independent SpiritBoot source audits, while actual removal or lifetime changes must be justified by owned-source contracts and validated separately.

Public metadata ledgers

• Memory-Reference-Entry-Walk-Ledger: all 1,361 entry walks, with decoded versus envelope bytes, overlap and bounded coverage.
• Memory-Reference-Unclassified-Ranges: all 246 remaining anonymous ranges / 56,166 bytes.
• Memory-Reference-Census: all 330 public-entry comparisons.

Numeric counts and disjoint totals were checked against retained original CSV/JSON metadata. Private reference captures and instructions remain segregated. No new title compatibility or firmware performance claim is made.

Second bounded pass

Memory-Reference-Content-and-ROM resolves the formerly untyped 13 bytes in the export envelope as exact format-defined metadata, leaving 56,153 semantically unknown retained bytes. It adds an exclusive evidence partition for the same 246 range rows, bounded table-access windows, all 460 non-content gap bytes, and a recheck of execution against both captured ROM mapping epochs. The original counts above preserve their earlier measurement identity; new pattern evidence is not a certified code/data/object split.

Follow-up on table consumers and byte ownership

Memory-Reference-Table-and-Function-Ownership records six local access windows totaling 152 bytes, a disjoint public/anonymous walk-byte partition, and containing-block trace observations missed by exact-PC matching. Six window bytes overlap prior inferred decodes, so neither code-only classification nor exact table size is promoted from these observations. The 56,153-byte semantic remainder and 180 KiB physical image remain unchanged. No runtime ROM execution or safe-unused function is newly established.