HAB events loading through SDP

[ericnelsonaz]

I'm stuck trying to understand a HAB event on a custom i.MX6Q board when loading over USB (SDP).

I haven't yet closed the device, and am forcing SDP mode by using "bmode usb" from U-Boot v2016.01.

The board boots from SPI-NOR and the signed U-Boot works properly (shows no HAB events) when

booting that way.

The single event generated when loading over USB is this:

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------

event data:

0xdb 0x00 0x08 0x41 0x33 0x22 0x0a 0x00

STS = HAB_FAILURE (0x33)

RSN = HAB_INV_ADDRESS (0x22)

CTX = HAB_CTX_AUTHENTICATE (0x0A)

ENG = HAB_ENG_ANY (0x00)

The U-Boot binary used to create the signature has the DCD cleared out (I ran mod_4_mfgtool.sh) and the .csf file I'm using has the proper address for loading the DCD (0x910000 to match my mx6_usb_work.conf):

[Authenticate Data]
Verification index = 2
Blocks = 0x177ff400 0x0 0x0006dc00 "u-boot.imx"[Authenticate Data]
Verification index = 2
Blocks = 0x00910000 0x0000002c 0x00000340 "u-boot.imx"

The same structure also works on a SABRE Lite using U-Boot v2016.11 using the same keys, though with different addresses and sizes.

I've reviewed the addresses and sizes in use and they appear to be correct. Using more or less than the 0x340 bytes for the DCD data or the 0x6dc00 for the image causes additional HAB failures and I'm not seeing what might be going on.

Can someone provide more background on what conditions generate an error code of HAB_CTX_AUTHENTICATE?

[ericnelsonaz]

Update 2: After closing the device, the HAB event is still generated when using "bmode usb", but the device will boot the image loaded using imx_usb:

=> hab_status

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99

--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x08 0x41 0x33 0x22 0x0a 0x00

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ADDRESS (0x22)
CTX = HAB_CTX_AUTHENTICATE (0x0A)
ENG = HAB_ENG_ANY (0x00)

So it seems that the error isn't fatal.

[tengri]

Hi ericnelsonaz‌

Have you got this issue resolved ? I ran into the same issue while working on HAB/SDP. Kindly share your thoughts with us. 

Anuradha

[ericnelsonaz]

Hi tengri‌

As mentioned above, the error reported wasn't fatal and didn't appear when the image was flashed to the boot media, so I didn't chase it any further.

[tengri]

Thanks Eric, your observation when BM switches set to SDP is correct, all events disappeard. so just to get clarify :

1. Suppose that I have flashed only a signed image (no SDP) to a (NOR chip of) board and it just works fine without any events. So I lock the device.

2. Then for trouble shooting I want to re-flash u-boot. This has to be done through SDP. So I prepare a signed (using the same keys as was in 1.) and SDP enabled image. Can I load this binary with imx_usb to the board and re-flash NOR ? 

3. If the 2.) generates HABs, should the signed image of 1.) be SDP enabled too ?

Anuradha

[ericnelsonaz]

2. Yes. As I tried to say in "Update 2", you'll likely still get the errors but the image will load and run. Note that there are lots of ways to re-flash U-Boot though, and SDP doesn't really have anything to do with flashing.

I don't understand the question in bullet 3. You can't really disable SDP on the hardware side except by not exposing the BOOT_MODE pins.

[tengri]

Hi Eric, what I actually meant by SDP-Flashing is the standard run upgradeu process after SDP. My requirement is to restrict the u-boot access to the end user. So if bullet 2.) is doable then even if the BM switches are exposed, user cannot download unsigned binary images through SDP. Is my understanding right ?

I earlier thought, the current signed image that runs in NOR should essentially have SDP functionality in order to download a new signed image via imx_sub_loader ! So from you answer it's clear that, it does not matter whether the current NOR image has SDP or not, all we need is a new signed + SDP image in imx_usb_loader folder to recover (debug) the board. 

Thanks a lot !

Anuradha

[ericnelsonaz · Accepted solution]

Update: I just used the BOOT_MODE pins to force a boot directly into the Serial Download Protocol and the HAB event disappeared.

In other words, the error generated above appears to be related to the use of the "bmode usb" command and not a problem with the image I was downloading.

I'm going to flag this as "answered", although there is an outstanding question of "why?".