Mt. Collins channel mapping, re-transcribed from the rendered table geometry

[gunbai-bot]

Supersedes #9873, whose rows encoded the wrong physical topology and were withdrawn. I obtained the source document and read Tables 10-13 myself, so nothing here rests on a relayed reading.

What was wrong, and what decides it

Tables 12-13 print eight MCU headers at a 57.6pt pitch over sixteen connector columns at a 28.8pt pitch, at a constant 6.6pt offset across all eight headers in both sockets. Each header therefore spans exactly two adjacent columns:

MCU0 = J1+J2	MCU1 = J3+J4	MCU2 = J5+J6	MCU3 = J7+J8	MCU7 = J16+J15	MCU6 = J14+J13	MCU5 = J12+J11	MCU4 = J10+J9

#9873 paired the flattened text stream positionally into J1+J16, J2+J15, … That is a different physical topology, not a different notation for one. A merged-header table is not recoverable from a flattened text stream — that single fact produced the error.

The discriminating check reproduces a stated set

Table 10's four-channel configuration names MCU0/MCU1/MCU4/MCU5. Table 11's matching population J1/J3/J9/J11 maps onto exactly that set under this mapping; the refuted reading gives MCU0/MCU2/MCU4/MCU6 and contradicts Table 10. The one-, two- and eight-channel widths reproduce likewise from Tables 12-13's own population marks, and the 16-DIMM odd sequence touches all eight controllers.

The previous channel-count argument is retracted in the file rather than quietly dropped, because it was wrong in an instructive way: pairing J1 with J2, J3 with J4 and so on yields the same 1/2/4/8 counts while disagreeing with every pair. A cardinality that agrees with a hypothesis is not evidence for it when it agrees with the alternatives too.

Two facts, not one overloaded row

• MtCollinsChannelConnectorPair — channel membership, with neutral table_left_connector / table_right_connector recording only what the rendered row visibly prints. No claim about installation order, electrical priority, or primary versus secondary slot.
• MtCollinsChannelPopulationRole — connector_used_at_one_dpc / additional_connector_at_two_dpc, derived separately from the population rows. "First" is avoided deliberately; it reads as either installation order or a vendor-defined primary slot, and the guide states neither.

Keeping these apart is what prevents a misread of pair geometry from silently manufacturing an installation-priority claim — exactly what the withdrawn version did. The header claim is restored in the form the tables actually support: the 1DPC population uses the odd-numbered member of every pair.

Revision boundary, handled explicitly

The cited issue advances 1.00 → 1.05 because 1.05 is the revision I read. Every Table 11 sequence was re-read against it and is unchanged — including the printed 32-DIMM row's omission of J32, already recorded here as a defect — so this re-cites identical content rather than silently swapping one revision's table for another's. memory_population_revision_basis records that reasoning, and the sha256 of the exact bytes read is in the source-document row. My read also independently confirms the file's existing J32 correction: Table 12's full row does populate all sixteen connectors per socket.

The document is marked Ampere Proprietary and Confidential and is deliberately not committed; only its identity and digest are.

Verification

• gunbc compile --entry …/memory_population.dag --target dag — 0 blocking errors, advisory count unchanged at the 103 baseline.
• Rows parsed back out of the authored file and re-checked: J1..J32 covered exactly once, MCU0..MCU7 once per socket, roles consistent with pairs, 1DPC member odd in all 16, and Table 10's four-channel set reproduced from J1/J3/J9/J11.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TcDddekju59A4jxouNif8J

[briansrls]

REQUEST_CHANGES — exact head 8ea1432ab20827c13401add0c51fb20da9c31d06.

The load-bearing correction is accepted. Both sockets now use the adjacent connector pairs from the rendered geometry; pair membership is neutral (table_left_connector / table_right_connector); 1DPC/2DPC population role is a separate fact; the odd-member header claim is restored without inventing a “first DIMM” label; and the old cardinality argument is explicitly retracted in favor of the exact MCU-set discriminator.

The missing page image is not a merge blocker. The prior bar allowed rendered geometry or an equivalent exact-set cross-check. This head has both the measured geometry and the independent J1/J3/J9/J11 -> MCU0/MCU1/MCU4/MCU5 check, bound to an exact Issue 1.05 filename and SHA-256. Requiring a persisted page crop would reproduce confidential source content without materially strengthening the identity binding. Preserve access to the source bytes where the operator is entitled to hold them; no image belongs in this PR.

Two narrow source-honesty corrections remain.

P1 — the one-revision boundary still has an Issue 1.00 residue

The unchanged annotation immediately above mt_collins_population_32_dimms_as_printed still says:

The 32-DIMM row AS PRINTED in Issue 1.00

But the module now says it cites one issue, Issue 1.05, and that every Table 11 row was re-read there. Since this row is also printed identically in 1.05, name the cited revision there — e.g. AS PRINTED in Issue 1.05 (unchanged from Issue 1.00) — or simply say Issue 1.05. As written, the file still presents this row as answering from the superseded revision.

In the same small edit, replace matches byte-for-byte at the connector-list grain with matches exactly at connector-list grain unless there was genuinely a byte-level comparison of both revision artifacts. Connector-list equality is the claimed and sufficient fact; “byte-for-byte” overstates a normalized-grain comparison.

P1 — Table 10 support and Table 11’s enumerated population sequence are still conflated

Your direct Table 10 extraction contains two supported one-channel sets, {MCU0} and {MCU4}. Table 11’s two-DIMM sequence realizes the {MCU0} choice per socket, not both. The unchanged annotation nevertheless says the Table 11 sequences are “the only supported shapes,” while the new basis/body says the other supported widths reproduce and names only {MCU0} at width one.

Remove the exhaustion claim, or explicitly distinguish Table 10-supported controller sets from the Table 11 population sequences transcribed in this module. The one-channel cross-check should say it reproduces the MCU0 one-channel row, not imply that it exhausts both one-channel configurations. I am not requiring a full Table 10 configuration model in this PR; only that the module not turn one listed sequence into an exclusivity claim contradicted by the table now read directly.

After those corrections, exact-head green CI remains required. No further topology or evidence-artifact change is requested.

[gunbai-bot]

Both corrections from review 5074009059 applied in 649df7f. Verified each against the file first; both were real. No topology change — the mapping, the neutral pair names, the separated population role and the retracted cardinality check are all untouched.

1. Issue 1.05 cutover completed

The 32-DIMM annotation still read "AS PRINTED in Issue 1.00" while the module had moved to 1.05, so one row went on answering from the revision the module says it superseded. It now names Issue 1.05 and records that the row is unchanged from 1.00.

memory_population_revision_basis also claimed the sequences match "byte-for-byte", which overstates what I actually did. The established fact is equality of the normalized connector sequences — I compared transcribed lists, not the two artifacts' bytes. The row now says that explicitly rather than borrowing a stronger word than the evidence supports.

2. Table 11's roster no longer speaks for Table 10's support

This one I could confirm directly from my own extraction, and you're right that it was too strong. Table 10 decodes to two distinct one-channel configurations — MCU0 alone and MCU4 alone — plus a six-channel configuration, and Table 11 supplies a connector sequence for none of them. Calling the transcribed rows "the only supported shapes" turned an enumeration into an exhaustion claim.

The comment now describes them as the sequences enumerated by Table 11, and states the distinction that matters to a consumer: a width absent from these rows is unenumerated by Table 11, not unsupported.

The same overstatement had ridden into the mapping basis, which claimed the join holds at "every other supported width" while in fact citing only widths Tables 12-13 mark. It is now scoped to the MCU0 one-channel, two-channel, four-channel and eight-channel rows, and explicitly disclaims Table 10's MCU4-alone and six-channel rows. That was the same failure as the retracted cardinality check in miniature — a claim quantified over a population wider than the evidence covered — so I'd rather it be narrow and checkable.

Compile clean, advisory count unchanged at the 103 baseline. CI is running on the new exact head 649df7fc37, which as you note is now the controlling receipt.

Noted and not acted on, per your ruling: no page image, no additional evidence artifact, and Nat stays as-is.

— sent from snappy-crab-469

[briansrls]

REQUEST_CHANGES — exact head 649df7fc3788dbeec933174a5b0b2459dff85646.

The prior re-review bar is substantively closed: the Issue 1.05 cutover is complete, “byte-for-byte” is gone, the 32-DIMM annotation now names 1.05, the mapping basis is scoped to the MCU0 one-channel/two-channel/four-channel/eight-channel rows, the MCU4-alone and six-channel rows are explicitly disclaimed, and exact-head workflow run 33473284820 is green across fabric-evidence, required-witnesses-build, required-witnesses-floor, rust-unit-tests, and the aggregate witnesses job; emit-copy-qualification-battery is skipped as expected. No topology or model blocker remains.

One source-honesty sentence introduced by the repair is still false or, at best, materially ambiguous:

Table 10 carries two distinct one-channel configurations (MCU0 alone and MCU4 alone) and a six-channel configuration, and Table 11 gives a connector sequence for neither.

Table 11 does give the connector sequence for the MCU0-alone one-channel configuration: its two-DIMM row is J1/J17, one MCU0 connector per socket. What Table 11 does not enumerate is the MCU4-alone one-channel alternative and the six-channel configuration. The later mapping-basis paragraph says this correctly, so the file currently contradicts itself at the exact distinction this commit was meant to repair.

Replace that sentence with an unambiguous statement such as:

Table 10 also carries an MCU4-alone one-channel configuration and a six-channel configuration, and Table 11 gives a connector sequence for neither; its two-DIMM row enumerates the MCU0-alone one-channel configuration.

or equivalent. Preserve every other change. Then bind green CI to the resulting exact head. This is the sole remaining blocker; no PR-body, topology, evidence-artifact, or model change is requested.

[briansrls]

CODE ACCEPTED / MERGE HOLD — exact head 49ffb69d4dbc0fc61250bf3335c6f91a780b3b23.

The sole source-honesty blocker from review 5074713169 is closed. The one-commit delta changes only the explanatory paragraph: it now says Table 11's two-DIMM row enumerates the MCU0-alone one-channel configuration, while the MCU4-alone alternative and the six-channel configuration are the two Table 10 configurations not enumerated there. That agrees with the connector rows and with discriminating_check; the internal contradiction is gone. The remainder is line wrapping. No topology, connector list, model value, PR body, or evidence artifact changed.

No further code change is requested. The accepted topology, neutral pair membership, separate population role, Issue 1.05 authority boundary, exact-set discriminator, cardinality retraction, and Nat ruling all remain closed.

Merge approval is withheld only because exact-head workflow run 33479068384 is still in_progress. At this check, fabric-evidence, required-witnesses-build, required-witnesses-floor, and rust-unit-tests were running with no failed step reported; emit-copy-qualification-battery was skipped as expected. Once that same run is fully green, this head is eligible for approval without another commit.

[briansrls]

REQUEST_CHANGES — exact head 5a3b35e4e4d3d60f9b4e459849abe3c5c61a9358.

The second reviewer’s duplication finding is correct, and the principal repair is accepted: the two socket-scoped literal role rosters are gone; mt_collins_channel_population_roles now derives from the channel pairs plus Table 11’s 16-DIMM population; the descending pairs reproduce the prior role order; and no topology/source row changed.

One structural blocker remains in the new derivation.

P0 — the claimed XOR totality is not encoded; the else arm is still a default

mt_collins_population_role_of_pair asks only whether table_left_connector appears in the 16-DIMM row:

if left_is_one_dpc {
  used = left; additional = right
} else {
  used = right; additional = left
}

That is correct for today’s roster because you externally checked that exactly one member of each current pair appears. It is not a total join over the function’s writable input domain, and the code does not establish the invariant its comment relies on.

Two counterexamples remain authorable and silently produce a role:

• neither member appears — e.g. a pair {2,4} returns connector_used_at_one_dpc = 4, although 4 is absent from the 16-DIMM row;
• both members appear — e.g. a pair {1,3} returns additional_connector_at_two_dpc = 3, although 3 is already present at 1DPC.

A future drift in either source relation therefore still typechecks and is absorbed into a plausible role. An arbitrary caller can also hand the general helper either pair today. The statement “the else-arm is the complementary case rather than a default” is true of the current data population, but false of the modeled function.

Required close: inspect membership of both pair members and construct a MtCollinsChannelPopulationRole only on the two XOR cases. both and neither must produce an explicit refusal/standing (or otherwise make a bare role unconstructible), and the aggregate must not expose a normal List<MtCollinsChannelPopulationRole> when any pair fails that partition. A global standing over the whole pair population or a per-pair coproduct is fine; do not repair this with another hand-authored 16-row assertion.

Add discriminating evidence for both invalid cases plus the positive current population: {2,4} refuses, {1,3} refuses, and the actual 16 pairs derive exactly the accepted 16 roles. This is the executable check for the exact drift class this commit exists to remove.

All prior rulings remain closed: corrected adjacent topology, neutral pair ordering, separate population-role meaning, Issue 1.05 authority/digest, exact-set discriminator, cardinality retraction, Table 10/Table 11 scope, no page-image requirement, and Nat for connector ordinals. Exact-head workflow run 33480671869 is currently in progress, but CI cannot close this source blocker.

[briansrls]

APPROVE — exact head ac4bcd10d3db795522f7d71aac803a0d7f861bfa.

The remaining P0 is closed.

mt_collins_population_role_of_pair now reads membership of both pair members and constructs a normal role only in the two XOR cases. BothPairMembersAppearAtOneDpc and NeitherPairMemberAppearsAtOneDpc are explicit refusal arms, so neither invalid population is absorbed by a plausible else result. At aggregate grain, any refusal yields PopulationRolesUnestablished; a normal role list is exposed only when every pair resolves. The hand-authored 16-row parallel authority has not returned.

The discriminating evidence covers the exact bar: {2,4} refuses as neither; {1,3} refuses as both; one bad pair withholds the whole role population; the actual 16 source pairs resolve; and the descending MCU7 pair derives J15-at-1DPC/J16-additional despite its printed J16/J15 order. The required-witnesses-floor log for exact-head run 33484732279 records all five witness identities as planned-and-passed / planned_as_changed_witness / passed, so this is enrolled acceptance-path evidence rather than a local-only demonstration.

Run 33484732279 completed successfully on this exact SHA: fabric-evidence, required-witnesses-build, required-witnesses-floor, rust-unit-tests, and aggregate witnesses all succeeded; emit-copy-qualification-battery was skipped as expected. Nothing is pending or cancelled.

All earlier rulings remain closed: corrected adjacent connector topology, neutral pair ordering, separately derived population role, Issue 1.05 authority and digest, exact-set discriminator, retracted cardinality argument, Table 10/Table 11 scope, no page-image requirement, and Nat for connector ordinals.

Squash-merge is authorized at this exact head. Any subsequent head movement invalidates this approval.

[briansrls]

POST-MERGE RECORD CORRECTION — landed as 104b6751e4378223677c7dd1792f17547ca742e9 from exact approved head ac4bcd10d3db795522f7d71aac803a0d7f861bfa.

My approval review 5075880644 described the final semantics correctly but misstated three identifiers. The merged code's refusal causes are NeitherMemberAtOneDpc and BothMembersAtOneDpc, and the aggregate refusal arm is PopulationRolesRefused. The longer cause names and PopulationRolesUnestablished appearing in my review text do not exist in the landed module. This is a review-record correction only, not a code defect.

The squash commit message also concatenates the superseded intermediate commit bodies. In particular, it retains the earlier assertion that the role join was total because the else arm was complementary. A later body in the same squash message explicitly retracts that assertion and records the final repair: both members are inspected, only the XOR cases resolve, and BOTH/NEITHER refuse. The landed source carries only that final structure.

No module follow-up or reopen is required.