HAB on i.MX6

[stephencox]

Hi.

I have both a i.MX6Q and a i.MX6S board which boot a signed u-boot compiled from https://github.com/Freescale/u-boot-imx. This was fairly easy using the HAB CST UG and the HAB V4 API RM. My boards are not fused, so I can boot unsigned images, but the hab status returns No HAB events found! I take that as a good sign.

Then I will verify and boot Linux, and then some questions show up. But first: I have extended u-boot with more hab commands in the file arch/arm/cpu/armv7/mx6/hab.c to call other functions in HAB ROM function table (run_csf, assert, authenticate image). I can manipulate the images and use those functions to generate various hab states in a way that assures me that I do a lot of things correct. My first try in uImage was to wrap it the same way as u-boot.imx with the IVT first, padding out, a CSF at the correct place pointed to from the IVT, no DCD, etc.The uImage is compiled with 0x10800000 as load address. When I wrap it, I use 0x20000000 as load address. So the IVT points there the uImage starts at 0x20000C00 and the CSF comes far behind somewhere. Then I use imx_usb from Boundary Device to load u-boot signed and uImage over USB and boot u-boot (not Linux). Now u-boot runs an uImage is at 0x20000C00 (wrapped in image loaded to 0x20000000). If I do "bootm 20000C00" from u-boot, the kernel boots. This tells me that a lot is OK.

Then I try to call HAB Authenticate Image from 0x20000000. I get four or five HAB events depending on what I do with the IVT. The first HAB event is this:

0xdb  0x00 0x08 0x41            0x33           0x22                0x0a                     0x00, which means

event size          HAB version HAB Failure Invalid Address authenticate image

This looks ok. But what does "Invalid address" mean? In the HAB V4 API RM it says "access denied" in one place. After the authenticate_image function is says "address outside allowed region" (seems equal to access denied), "IVT, DCD; Boot Data, or CSF outside image bounds (they are not), IVT self or entry points is NULL (they are not). The reason why I can say "they are not" is because if I try images with various information in the IVT (without self for instance) I get other HAB events that fit to the intended error.

After trying this for i while I found another document Linux HAB UG that show how to verify and boot a signed uImage. It wraps uImage differently, but otherwise is is quite like my first try. And I get almost the same result ... :-(

So to the questions:

- I compile uImage with load address 0x10800000 and load it to DDR 0x20000000. The "bootm 20000000" command then copies the image from 0x20000040 to 0x10800000 and jumps there, right?

- Where is it supposed to be verified? At 0x20000000 or at 0x10800000?

- Which u-boot-version does the document refer to? I have tried to find the CONFIG_SECURE_BOOT symbol in my u-boot-clone from github and it is almost non-existing. It is not found in any files I would suspect were used om i.MX6. It also refers to a bootm command that do call authenticate_image. Where is that function?

- Btw. the clocks (caam) refered to in the Linux HAB UG is not configured on my board, but doing it does not help (mw 20c4068 ff3f3f shold do the trick ... but doesn't.

Thanks for your help.

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[abdulrasheed]

stephencox‌ did you find answer to this question?
I am facing the VERY SAME issue.

[Devang_Shethna]

Hello abdulrasheed‌,

Please DO NOT attempt to join this group! NewCo Labs is a demonstration portal that does not contain "live" data and does not have real members.

stephencox‌ simply copied this question from the general i.MX community for demo purposes.

We would suggest that please search the general i.MX community to see if this question was ever answered.

Please go to www.nxp.com/prosupport for additional information on our professional support program.

If there are further questions or concerns on this, please let us know. Thanks!

Best Regards,
Devang Shethna
(on behalf of Team Pro-Support)