===================================================
Platform state partitions: cdt, ddr, uefivarstore
===================================================

Three small partitions XBL reads and writes at runtime to configure the
board, train DDR, and persist UEFI variables — distinct from the signed
firmware images documented elsewhere in this section.

``cdt`` — board identity is empty
=====================================

``cdt.bin`` (LUN3, 128 KB, start ``0x20000``) is **entirely zero** on this
unit. The Configuration Data Table normally encodes board/platform ID and
DDR-device selection, but here the standalone partition carries nothing —
platform identification does not come from this partition. It comes from
the CDT/``PlatformInfo`` data embedded in XBL itself (platform "Bitra") and
the SoC's own fused platform/chip IDs read by ``ChipInfo``/``PlatformInfoDxe``
(:doc:`dxe`). A bootloader that replaces XBL cannot recover board identity
from ``cdt`` — it must read it from the SoC as XBL does.

``ddr`` — likely a DDR training cache
=======================================

``ddr.bin`` (LUN3, 1 MB, start ``0x40000``) holds a compact ~1.4 KB
structure in an otherwise-reserved 1 MB partition: sentinel ``0xdeadcafe``
at ``+0x18``, version word ``0x0800``, a device/rank presence code (ASCII
``NDND…MDMD…``), and a table of 16-bit timing/margin values (``0x62c 0x657
0x5c6 0x556 0x57b 0x4fd …``, repeating per frequency point) — a structure
consistent with a **DDR training cache** (inferred from the data's shape —
sentinel, version word, per-frequency timing table — not confirmed by
tracing XBL's own code): XBL trains the PHY once, writes the converged
parameters here, and reuses them on later boots to skip full retraining.
It is board- and part-specific runtime data, not signed firmware — a
replacement loader either performs full DDR training itself or consumes
this cache in the same format. The actual DDR Config Blobs XBL trains
*from* are the two ``dcb.bin`` entries bundled in :doc:`xbl-config`.

``uefivarstore`` — persistent UEFI variables
================================================

``uefivarstore.bin`` (LUN4, 512 KB, ~1 KB populated) is **not** the
standard EDK2 authenticated-variable/FTW store — it is a Qualcomm-custom
format with magic ``PTBL`` at ``+0``, a version word ``0x00000100``, an
entry-count/index table, and ``VAR2`` / ``DStr`` variable records. This is
where the UEFI phase persists NV variables across boots — the mechanism ABL
uses when it sets ``RESET_PARAM="EDL"`` before ``ResetSystem`` to force EDL
(:doc:`/edl/entry`, :doc:`/boot/keys`). Individual values are not stored as
plain ASCII, so the live variable set is not readable from a static dump.

:Source: ``_READONLY/lun3/cdt.bin``, ``_READONLY/lun3/ddr.bin``,
   ``_READONLY/lun4/uefivarstore.bin``.
:Cross-refs: :doc:`/xbl/index`, :doc:`dxe`, :doc:`xbl-config`,
   :doc:`/edl/entry`, :doc:`/boot/keys`.