2361750_en-US

Yes

i.MX6 HABv4 Boot Failure: `j4 err` After Successful USB Load on Production Board

**Objective:**
Our goal is to use the `imx_usb` loader to boot our board directly into RAM, bypassing the eMMC. This is a critical step in our failure analysis. We have physically disconnected the eMMC on the production board to ensure we are exclusively testing the USB boot path.

**Board States:**
1. **Development Board:** Fuses are not blown. The SoC reports it is in **Development Mode**.
2. **Production Board:** Fuses are blown for secure boot. The SoC reports it is in **Production Mode**.

**Summary of Results:**

We are observing two different outcomes when using the `imx_usb` utility.

**1. SUCCESS: Development Board**
On our development boards, an unsigned `u-boot.imx` loads and executes perfectly. The log confirms the binary is loaded and the SoC jumps to the entry point.

* **Command:** `sudo ./imx_usb u-boot.imx`
* **Key Log Output (`development.txt`):**
```
HAB security state: development mode (0x56787856)
...
loading binary file(u-boot.imx) to 877ff400, skip=0, fsize=5faa4 type=aa
succeeded (status 0x88888888)
jumping to 0x877ff400
```
*(Result: Board boots to U-Boot prompt)*

**2. FAILURE: Production Board**
On our production boards, we use a **signed `u-boot.imx`** provided by our manufacturing team, which is signed with the same keys whose hashes are fused in the SoC. The `imx_usb` tool reports that the DCD and the binary are loaded successfully. However, the final jump command fails.

* **Command:** `sudo ./imx_usb u-boot-signed.imx`
* **Key Log Output (`production.txt`):**
```
HAB security state: production mode (0x12343412)
...
loading binary file(u-boot.imx) to 877ff400, skip=0, fsize=5faa4 type=aa
succeeded (status 0x88888888)
jumping to 0x877ff400
j4 in err=0, last_trans=64 33 18 c0 00
```
*(Result: Board does not boot. No console output.)*

**Analysis and Key Questions:**

The critical difference is the outcome of the `jumping to 0x877ff400` command. On the production board, the process fails at this exact point, after the image has been successfully transferred to RAM. This strongly suggests that the SoC's boot ROM is performing a **HABv4 signature validation** on the image in RAM *before* executing it, and this validation is failing.

The `j4 err` is not a standard USB error; it appears to be an internal status code from the `imx_usb` tool related to the jump command. The core issue is that the jump is not successful.

1. **HAB Authentication Failure:** Is the `j4 err` (or the subsequent lack of boot) indicative of a HAB authentication failure? The boot ROM successfully accepted the image but appears to refuse to run it.

2. **Image Signing for USB Boot:** Is there a specific requirement or format for signing a U-Boot image that is intended to be loaded via the USB Serial Download Protocol? We are using an image signed for eMMC boot. Could there be a difference in the expected IVT (Image Vector Table) structure or other metadata that causes HAB to reject the image when it's loaded at `0x877ff400`?

3. **Load Address:** The image is being loaded to `0x877ff400`. Is this the correct address for a USB-loaded image on a secured i.MX6? Does the boot ROM expect the image to be at a different location in RAM for authentication?

Re: i.MX6 HABv4 Boot Failure: `j4 err` After Successful USB Load on Production Board

Hello,

Is your signed image built for eMMC boot?

the error shows the step load to RAM succeeded but the execution is denied by ROM due to a

HAB authentication failure.