Fixed with CSF tweak 🌈

@jynik thank you for your providing useful insights ✌🏾. However, I had to make some minor changes to get it boot on a closed i.MX 6SX SABRE-SD.

My sequence:

1. Cleared DCD pointer on u-boot.imx

dd if=/dev/zero of=u-boot.imx.cleardcd seek=12 bs=1 count=4 conv=notrunc

1. Appended separate authentication block for DCD (from OCRAM)

Blocks = 0x877FF400 0x00 0x97C00 "u-boot.imx.cleardcd", \
#        Separate DCD block authentication
         0x910000 0x2C 0x220 "u-boot.imx.cleardcd"

1. Concatenated the original u-boot.imx and the CSF binary
2. Boot with -cleardcd flag on UUU tool

@nxpfrankli you could have point us to the HABv4 closed chip support on UUU.pdf that contain the useful information. See the excerpt below 👇🏽:

So… it’s not really a UUU bug/issue insomuch as added steps apparently being necessary?

I too feel this now 😬

---

CC @tkmozhi

Update - Solved

To answer my own question: Yes, to boot a signed image on an i.MX6ULL, one must prepare a special image for booting over SDP. As @jmonkman noted, this requires changes to the CSF and metadata in the “imx” image that is signed.

So… it’s not really a UUU bug/issue insomuch as added steps apparently being necessary? Kudos to y’all whose breadcrumbs helped me understand this after reading docs for hours.

Details

We begin with an “imx” image produced by U-Boot. My image normally would boot directly from NAND, with the DCD taking care of the DDR initialization.

$ cat u-boot-dtb.imx.log
Image Type:   Freescale IMX Boot Image
Image Ver:    2 (i.MX53/6/7 compatible)
Mode:         DCD
Data Size:    356448 Bytes = 348.09 KiB = 0.34 MiB
Load Address: 877ff420
Entry Point:  87800000
HAB Blocks:   0x877ff400 0x00000000 0x00054c00
DCD Blocks:   0x00910000 0x0000002c 0x000001e8

When booting from NAND, I can simply follow the signing instructions included in the U-Boot docs and/or the NXP CST documentation.

However, when attempting to boot via SDP I need to account for the fact that the DCD will be copied into OCRAM @ 0x910000, and that the DCD address in the authenticated IVT will be zeroized.

This requires a CSF whose Authenticate Data section includes the 3 separate writes that will occur when using UUU:

[Authenticate Data]
    # Key slot index used to authenticate the image data
    Verification index = 2
    # Authenticate Start Address, Offset, Length and file

    # 3 sections to verify signature over:
    # IVT + Boot Data: Offset 0, Len 0x2c  (Fixed)
    # DCD: Offset 0x2C, Len 0x1e8  (From imx.log file emitted by U-Boot build)
    # Image Data: Offset 0xc00, Len <rest of image>
    Blocks =  0x877ff400 0x00000000 0x0000002c "u-boot-dtb.imx.cleardcd",\
              0x00910000 0x0000002c 0x000001e8 "u-boot-dtb.imx.cleardcd",\
              0x87800000 0x00000c00 0x00054000 "u-boot-dtb.imx.cleardcd"

Here, u-boot-dtb.imx.cleardcd is the u-boot-dtb.imx image produced by U-Boot, with the DCD pointer zeroized.

I then concatenated the original u-boot-dtb.imx and the CSF binary into a u-boot-dtb.imx.signed, and then booted that with UUU as follows:

uuu SDP: boot -f ./u-boot-dtb.imx.signed -cleardcd

This boots – but I still have some heebie jeebies here and need to further convince myself that all “attacker controlled” data that needs to be covered by a signature validation in fact is. I’m generally not thrilled by the idea of having separate signed images for recovery over SDP. (Don’t sign permissive images with production keys, folks! 😉 )

But alas, I’m not really sure what NXP’s intended flow is supposed to be here on the i.MX6ULL and friends is.

Original message (for posterity)

@jmonkman - With the UUU code as-provided, do you still need to construct a special CSF for SDP-based boot and sign an image with the DCD pointer in the IVT zeroized? (I am under the impressions that this has to be necessary in i.MX6ULL, but still looking for a good example.)

What you describe doing sounds similar in Appendix E: Freescale Manufacturing Tool of a 10/2015 version of AN4581, which was removed in later revisions…

@nxpfrankli - Any chance you could take a look at my preceding posts and comment further?

@danie007 - Does my previous post apply at all?

If not, would you mind sharing a some screenshots (redacted if as needed) of a Wireshark usbmon capture showing the summary of the SDP HID transfers? This probably won’t show much, beyond confirming that the timeout occurs upon sending the jump operation that’ll kick off what probably ends up being an auth failure?