extdeps.memory.micron: identify MTA36ADS2G72PZ-2G1A1 from Micron's own data, and the DDP stacking value it needs

[gunbai-bot]

What

Gives the corpus its first Micron authority and answers the work item's five questions from Micron's own documents. Full reading with the document table and the SEL analysis: docs/plans/micron-mta36ads2g72pz-identification.md.

• extdeps.vendor.micron — the vendor entity.
• extdeps.memory.micron — mta36ads2g72pz_2g1a1_catalog (the "2DRx4" quartet) and mta36asf2g72pz_2g1a2_catalog (the "2Rx4" quartet that trained), each with FactCitations to Micron-hosted catalogue records (which carry the full DDR4 SPD image) plus the Micron DDR4 Module Part Numbering System Rev. 05-Dec-2018 and the DDR4 RDIMM Core Rev. B 12/2021.
• extdeps.memory.types DramDieStacking gains DualDiePackage, JEDEC's multi-load stack class (SPD byte 6), because a DDP is neither monolithic nor 3DS and the axis had no honest arm for it. dram_module_class_eq extended; no other consumer matches the enum.
• Witnesses: test.claim.micron_dram_module (siblings differ ONLY in stacking; density derives to 4 Gb for both; Altra fold separates them; product.installed_bom_reconcile confirms a cataloged Micron part on mtcollins1 and refuses when the expectation is the other sibling), and a DDP control in test.claim.altra_memory_controller_witness.
• Manifest rows in gunbc.extdeps_scope_frontier scope_carrier_paths.

Findings (all cited to Micron unless stated)

1. MTA36ADS2G72PZ-2G1A1 = 16 GB, 2 package ranks, x4, DDR4-2133 CL15 (-2G1), ECC, RDIMM (P), VLP 18.75 mm, 18 dual-die packages × two 4 Gb dies (36 dies = the 36 field). SPD: byte 6 0x91 non-monolithic / 2 dies / multi-load stack; byte 128 0x04 height ≤ 19 mm; byte 12 0x08 2 ranks x4; byte 4 0x84 4 Gb/die. Status obsolete.
2. ADS vs ASF: module-options field DS = "VLP Dual-Die w/Temp Sensor" vs SF = "FBGA w/Temp Sensor". D = height class, S = package. That letter difference is exactly the answer.
3. "2DRx4" = 2 ranks, dual-die, x4 — the operator hypothesis, now verified by Micron's SPD rather than adopted.
4. Ampere: the Altra Rev A1 datasheet (Issue 1.55) lists RDIMM / LRDIMM / 3DS RDIMM and 8 Gb / 16 Gb devices; DDP, dual-die, multi-load and 4 Gb appear nowhere. Note both quartets use 4 Gb dies and the monolithic one trained, so unlisted density does not separate them. The DDP class is modelled as not among the listed classes, kept distinct from a withdrawal. OCP Table 3 "Different DRAM DIES = Yes" is a mixing cell and was not read as construction support.
5. AVL Issue 1.15 (Dec 2025): neither part is listed; the AVL carries no 16 GB 2Rx4 row from any vendor and no 2133 row, so it is equally silent about both quartets. Not read as a prohibition.

What Micron's data leaves as the only differences between the two quartets: package construction (multi-load stack vs monolithic), PCB outline (18.75 vs 31.25 mm), and with it the raw-card byte (0x08 vs 0x01) and module-attribute byte 131. Everything else is byte-identical.

SEL second half

Raw bytes preserved, no decoder minted. The only public serializer of a 3a cd 00 / C0 record of this shape is meta-ampere dimm_train_fail_log.sh (ampere-openbmc/openbmc @ f68588807957), which writes sensor 0xeb and byte 3 = (channel<<4)|(socket<<3)|4; ours is 0xde with low nibble 3, so it is a related schema. The 0xde serializer is not public (searched ampere-openbmc/openbmc, ampere-ipmi-oem, the Mt. Jade/Mitchell sensor YAMLs, and the script's full history; Mt. Collins runs AMI MegaRAC, whose Ampere port is unpublished). The syndrome semantics the cousin copies are the SoC-BMC Interface Spec Issue 1.43 register 0xB5; under that layout the 11 02 tail reads as two different training steps depending on byte order, and ff 10 reads as Reserved or N/A, so nothing is promoted past AssociatedByIdenticalSignature.

Not landed, and why

• No HostMemoryStanding / CausalExperimentReceipt rows for the eight configurations: the brief carries no instants, masks or slot locators, and authoring them from a summary would fabricate observed_at (the exact defect that module's notes record). The receipts belong with the lane holding the raw BMC log; they now have a catalog row to bind to.
• No typed SEL carrier (one night's payloads under an unpublished schema are not an authority).
• No form_factor/height field on DramModuleCatalogRow — carried in the annotation until a chassis-clearance consumer exists (§3c).
• Two Micron PDFs are cited through distributor copies with sha256 digests because assets.micron.com rejects this session's fetches; the catalogue records themselves are Micron-hosted.
• The ASF row's -2G1A2 suffix is the Micron catalogue SKU; the operator's trained quartet was named only "2Rx4", so the die/PCB revision pair should be confirmed from the label.

Evidence

The five affected witness entries (micron_dram_module, altra_memory_controller, samsung_dram_module, sk_hynix_dram_module, installed_bom_reconcile) were run through claim_batch --roster-from-discovery --claim-run --wet on BuildBuddy in one dispatch with the tree staged; results are recorded in a follow-up comment, and CI runs the floor.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XAQV5DkCKgGqrGAZd44vqx

[gunbai-bot]

Review 64247 (dashboard artifact) — addressed in 039b1fe. The Samsung M386A4G40DM0-CPB row's own provenance sentence (72 dies on 36 dual-die packages) already named the multi-load-stack class; the field now reads DualDiePackage with the reason beside it, at the same label standing as the rest of that row, and the Samsung witness asserts it. No consumer folds that row's stacking value today, so no verdict elsewhere changes; the Altra fold would answer "not among the listed classes" for LoadReduced × DualDiePackage exactly as it does for the Micron part, and the srv3/srv4 receipts in gunbc.host_memory_qualification grade class support against the BOARD's statement, not this fold.

[gunbai-bot]

Witness evidence, run on BuildBuddy in one dispatch (build + claim_batch --entry … --functions … --claim-run --wet, 20 GB cgroup bound) against the staged tree at 039b1fe:

• test.claim.micron_dram_module: 8/8 PASS (including the two installed_bom_reconcile consumer rows, one green, one discriminating red).
• test.claim.altra_memory_controller_witness: 11/11 PASS (including the new DDP control).
• test.claim.sk_hynix_dram_module: PASS.
• test.claim.samsung_dram_module: fails to RESOLVE outside the floor with effect summary incomplete … names no registry row — and does so identically with main's versions of the test, samsung.dag and types.dag checked out in the same dispatch. That module declares no imports (bare references), so standalone claim_batch cannot join them the way the floor's bare-reference index does; pre-existing, not a regression of this PR. CI's floor run is the executing evidence for that entry.

Since the last review: fafec55 and 2079c47 fold in hw-first-host's SOL capture of the same part (firmware reads byte 6 = 0x91, refuses the mixed socket on byte-6 disagreement — a MIXING rule; the trained sibling's label is 36ASF2G72PZ-2G1A2II, the catalogue SKU plus process code II) as observing-layer corroboration in the row annotations and the survey; no row cites it.