2361750_en-US

[#1]

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.

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

Hi All, what is the status of this ticket and how can this be moved forward?  Is a face-to-face (on-site) meeting needed?

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

Hello,

Yes image is signed for emmc boot. Perfectly working on RAM but not able to flash on emmc .

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

Using  imx_usb_loader  (Serial Download Protocol), we successfully boot into U-Boot and Linux entirely from RAM. From that live U-Boot session we wrote the following images to eMMC:

# U-Boot IVT at mandatory 1 KiB hardware offset

mmc dev 1 0

mmc write 0x82000000 0x2 0x400

# FIT image to raw sectors beyond active partitions

mmc write 0x80800000 0x66000 0x3000

# Boot environment

setenv bootargs "console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw"

setenv loadfit  "mmc dev 1 0; mmc read 0x80800000 0x66000 0x3000"

setenv bootcmd  "run loadfit; bootz 0x808000e8 - 0x80da4bc0"

saveenv

Executing run boot manually from this U-Boot prompt works correctly — Linux boots and mounts /dev/mmcblk1p2 without issue. Working logs attached in mail.

Failure State:

On any cold power cycle or hardware reset, with the USB OTG cable physically disconnected, the board produces zero UART output and silently re-enters USB Serial Download Mode. The ROM appears to never reach the eMMC.