Can you validate this information? Is the new format truly opaque or does it likely contain the same information as the earlier 44 bit format?



🧬 Summary: Apple’s ECID (Exclusive Chip ID) Architecture

📌 What is the ECID?

Apple’s Exclusive Chip ID (ECID) is a per-device, globally unique identifier fused into the chip at manufacture. It is used throughout the secure boot chain and provisioning process to:
	•	Tie cryptographic keys and signatures to specific hardware
	•	Derive unique hardware-bound secrets (e.g., UID/GID keys)
	•	Personalize firmware images (e.g., IMG4)

It is not modifiable, and once fused, it uniquely identifies the chip for the life of the device.

⸻

🧠 Historical Format: Structured 44-bit ECID (Early SoCs)

On older SoCs like S5L8747x (used in early iPhones), the ECID wasn’t just a blob — it was a structured value with fields encoding manufacturing metadata.

The value was composed in code like this:

/*
 * ECID bit structure:
 * ......................lllllllllllllllllllllwwwwwyyyyyyyyxxxxxxxx
 * l - lot number      = 21 bits
 * w - wafer number    = 5 bits
 * y - wafer Y-pos     = 8 bits
 * x - wafer X-pos     = 10 bits (split across two registers)
 */

So the ECID embedded information such as:
	•	The production lot ID
	•	The wafer number within that lot
	•	The X and Y position of the die on the wafer

These fields were read from specific MMIO registers like rDIEIDL and rDIEIDH, and then bit-shifted into a 64-bit container, even though only ~44 bits carried useful data.

This allowed for manufacturing traceability and die-level uniqueness using only a partial 64-bit space.

⸻

🔒 Modern Format: Flat 64-bit Opaque ECID (A7 and later)

Beginning with newer chips (e.g., A7/T7000 and onward, including A10/T8010), Apple switched to a fully opaque, flat 64-bit ECID.

uint64_t chipid_get_ecid_id(void)
{
	return ((uint64_t)rECIDHI << 32) | rECIDLO;
}

This form:
	•	Abandons any public field structure
	•	Treats the ECID as a raw, hardware-fused 64-bit value
	•	Likely still encodes internal manufacturing details, but in a non-public, internal-only format

The opaque ECID simplifies downstream software and improves security by hiding low-level production metadata from software consumers.

⸻

📍 How It’s Accessed

The ECID is accessed through memory-mapped I/O (MMIO) at fixed physical addresses backed by fuse controller hardware. For example, on A10:

#define rECIDLO (*(volatile uint32_t *)(0x210200000))
#define rECIDHI (*(volatile uint32_t *)(0x210200004))

The MMU or SoC interconnect routes reads to these registers to retrieve the fused value — not from RAM or flash, but directly from eFuse-backed hardware registers.

⸻

🧪 ECID on FPGA Devices

For FPGA-based firmware development (pre-silicon bring-up), the ECID is stubbed with a hardcoded fake:

#if SUPPORT_FPGA
    ecid = 0x12345678ABCDULL;

This is necessary because:
	•	FPGAs lack real fuse hardware
	•	Secure boot and personalization logic must still run

The fake ECID allows firmware to boot and test ECID-dependent code paths in a controlled environment.

⸻

✅ Summary Points
	•	Old SoCs used a structured ECID (~44 bits) made from fuse fields like lot/wafer/die position.
	•	Modern SoCs use a flat 64-bit opaque ECID, with no public structure.
	•	ECID is hardware-fused and read via MMIO, not software-generated.
	•	Used for secure boot, key derivation, and firmware personalization.
	•	On FPGA targets, a fake ECID is injected to simulate functionality without real hardware fuses.