[LS1046A] Fuse Provisioning Image Fails on OTPMK

[james_browning]

Hello,

I'm trying to create a working fuse provisioning image for programming the fuses of our LS1046A SOCs. I'm following these guides:

• LLDPUG 5.15
• Fuse Provisioning on LS1046ARDB
• TF-A Fuse Provisioning

The issue I'm hitting is that after enabling POVDD and running the provisioning image, the fuses never get blown. I can see the mirror registers contain the correct expected values when I probe with the codewarrior TAP, but they disappear after a reboot since the fuses are never blown.

When the fuse provisioner, runs I'm getting value 0x19 in the SCRATCHRW4 register. This value indicates an error in writing to the OTPMK (as per include/drivers/nxp/sfp/sfp_error_codes.h

#define ERROR_OTPMK_WRITE		0x19

I found that it is getting set by prog_otpmk() as the result of a write failure (drivers/nxp/sfp/fuse_prov.c):

ret = write_fuses(sfp_ccsr_regs->otpmk, fuse_hdr->otpmk, 8);

	if (ret != 0) {
		ret = (ret == ERROR_ALREADY_BLOWN) ?
			ERROR_OTPMK_ALREADY_BLOWN
			: ERROR_OTPMK_WRITE;
	} else {
		 /* Check for DRV hamming error */
		if ((sfp_read32((void *)(get_sfp_addr() + SFP_SVHESR_OFFSET))
			& SFP_SVHESR_OTPMK_MASK) != 0) {
			ret = ERROR_OTPMK_HAMMING_ERROR;
		}
	}

The error code returned from write_fuses() is ERROR_WRITE which indicates the read back failed:

static int write_fuses(uint32_t *fuse_addr, uint32_t *fuse_hdr_val, uint8_t len)
{
	int i;

	 /* Check if fuse already blown or not */
	for (i = 0; i < len; i++) {
		if (sfp_read32(&fuse_addr[i]) != 0) {
			return ERROR_ALREADY_BLOWN;
		}
	}

	 /* Write fuse in mirror registers */
	for (i = 0; i < len; i++) {
		sfp_write32(&fuse_addr[i], fuse_hdr_val[i]);
	}

	 /* Read back to check if write success */
	for (i = 0; i < len; i++) {
		if (sfp_read32(&fuse_addr[i]) != fuse_hdr_val[i]) {
			return ERROR_WRITE;
		}
	}

	return 0;
}

This aligns with what I would expect to happen, based on the fact that OTPMK cannot be read back by design. This is explicitly mentioned in several documents:

"For obvious reasons, the SFP does not allow the value written to the OTPMK registers to
be read out. Once a non-zero value is written to any of the OTPMK registers, any read
will return all 1s"

Based on this, I'm not sure how this code is intended to work? The write_fuses() function will always fail on OTPMK because the read back will always return all 1's. I also verified this by reading the OTPMK registers in u-boot and observing they only return 1's. Am I misunderstanding or doing something wrong? OTPMK is required to enable secure boot, so surely this must have worked at some point, but it seems to me in the current state this code cannot be used to enable secure boot on Qoriq Trust platforms (although the documentation mentions support for LS1046A).  We are using the nxp-qoriq atf v2.6 source code by the way. I checked other source versions and it seems this code hasn't really changed.

[yipingwang]

After blow OTPMK fuse, register 0x1e80234-0x1e80250 should be displayed as "ffffffff", before fuse blowing, it should be all "0".

At the U-Boot prompt, verify that the SNVS registers for OTPMK are correctly written.
Check if OPTMK is fused.
=> md $SNVS_HPSR_REG (byte swap)
80000900
OTPMK_ZERO_BIT (second nibble) is 0, indicating that OTPMK is fused.

=>md 1e90014(byte swap)

              80000900

Now you will see ‘0’ in second nibble. No parity errors, i.e. bits marked in read would be all 0’s.

=> md 1e80024

00000000

[james_browning]

Thank you @yipingwang, but we would specifically like to rely on the fuse provisioning image built by the qoriq atf repo so we can quickly and automatically program the fuses. All of the documents I shared above describe the fuse provisioning feature and explicitly state that it is supported by this SOC, but it seems the source code incorrectly handles reading the OTPMK, and cannot blow the fuses as a result. I'm confused as to how NXP was able to use this to enable secure boot, it seems the source code is incorrect?

[yipingwang]

Please provide the result of the following command on your custom board.

=>md 1e90014

[james_browning]

=> md 1e90014
01e90014: 002b0088 00000080 00000000 00000000

[yipingwang · Accepted solution]

I checked LLDPUG 5.15 to build Fuse Provisioning ATF image.

Added DISTRO_FEATURES:append = " fuse" in build_ls1046ardb/conf/local.conf, then rebuild atf image.

$ bitbake qoriq-atf -c cleansstate

$ bitbake qoriq-atf

I encountered the error "create: unrecognized option '--fuse-prov'", so there is defect in atf source code to build Fuse Provisioning image in LLDPUG 5.15.

Please use LSDK 21.08 release to build Fuse Provisioning ATF image.

[james_browning]

Thank you for investigating this @yipingwang. Based on your suggestion, I got fuse fuse provisioning to work by taking the fuse provisioning and sfp code from 21.08 and integrating it into the v2.6 branch (used by lf5.15.71). Since fuse provisioning is not properly supported in lf5.15.71, I think either the code should be patched or the documentation should be updated since it incorrectly states that fuse provisioning is supported.  

[james_browning]

=> md 1e90014
01e90014: 002b0088 00000080 00000000 00000000 ..+.............
01e90024: 00000000 00000000 00000000 00000000 ................
01e90034: 00000000 00000000 00000000 00000000 ................
01e90044: 00000000 00000000 08000000 00000000 ................
01e90054: 00000000 00000000 00000000 00000000 ................
01e90064: 00000000 00000000 00000000 00000000 ................
01e90074: 00000000 00000000 00000000 00000000 ................
01e90084: 00000000 00000000 00000000 00000000 ................
01e90094: 00000000 00000000 00000000 00000000 ................
01e900a4: 00000000 00000000 00000000 00000000 ................
01e900b4: 00000000 00000000 00000000 00000000 ................
01e900c4: 00000000 00000000 00000000 00000000 ................
01e900d4: 00000000 00000000 00000000 00000000 ................
01e900e4: 00000000 00000000 00000000 00000000 ................
01e900f4: 00000000 00000000 00000000 00000000 ................
01e90104: 00000000 00000000 00000000 00000000 ................