[IMX6Q HAB issue]: Download signed images into a “close” device by using mfgtool.

[ashleysheng]

Hi,

I'm working on HAB on a customer board. The operating system on the board is android 5.0. When I started to test the HAB function, I read several user guides & posts such as

AN4581.pdf Secure Boot on i.MX50, i.MX53, and i.MX 6 Series using HABv4 

iMX 6 Linux High Assurance Boot (HAB) User's Guide

https://community.freescale.com/docs/DOC-96451

https://community.freescale.com/docs/DOC-94864

and so on. But, no one of the above documents mentions about how to singed the Android images for HAB function. Eventually, I got “i.MXAndroidHDCP2.xUserGuide” and then I followed the step 4 in the menu to singed the android images, and then I used “fastboot” command to burn the u-boot, boot, recovery and system these android images into our device (eMMC). I was able to run HAB function successfully without any problem, so I turned the device to “close” mode.

Now, I have to use mfgtool to burn the android images into the devices (eMMC). I followed the step in the same menu but I wasn't able to burn the images into our device by using mfgtool. The mfgtool showed “Jumping to OS image” and then stopped. From the mfgtool log, it seems like there are some problems to initialize the memory.

My steps to set up mfgtool for download HAB images are

1. I used the code base Yocto 3.10.53_1.1.0 ga release to build uboot and zimage with the patch “0001-yocto-u-boot-enable-mx6-hab-on-3.140.53.patch.txt.zip” for mfgtool.

2. I checked my u-boot.imx by command “od -x -N 64 u-boot.imx” and I got the result as

0000000 00d1 4020 0000 1780 0000 0000 f42c 177f

0000020 f420 177f f400 177f a000 1785 0000 0000

0000040 f000 177f d000 0005 0000 0000 03d2 4000

0000060 02cc 04fc 0e02 9807 0c00 0000 0e02 5807

0000100

  IVT address:  IVT.self = 0x177ff400.

  Image length: IVT.csf – IVT.self = 0x1785a000 - 0x177ff400 = 0x5AC00

3.  I referred the step 12. Sign Yocto 3.10.53 u-boot for mfgtools firmware in https://community.freescale.com/docs/DOC-96451 to sign the u-boot.

4.  I replaced 4 files located in mfgtools\progiles\linux\OS Firmware\firmware\ which are

     u-boo.imx with siged u-boo.imx,

     zImage,

     fsl-image-mfgtool-initramfs-imx6qdlsolo.cpio.gz.u-boot

     zImage-imx6q-sabresa-ldo.dtb.

   (These files were built by yocto 3.10.53_1.1.0)

But the mfgtool still shows “Jumping to OS image” and then stopped. I don't know if any steps I did the wrong?

Original Attachment has been moved to: sign_mfg_command.sh

Original Attachment has been moved to: csf_u-boot_yocto_mfg_3.10.53.txt.zip

Original Attachment has been moved to: i.MXAndroidHDCP2.xUserGuide.html.zip

Original Attachment has been moved to: MfgTool.log.zip

Original Attachment has been moved to: 0001-yocto-u-boot-enable-mx6-hab-on-3.10.53.patch.txt.zip

Original Attachment has been moved to: ucl2.xml.zip

Original Attachment has been moved to: mod_4_mfgtool_yocto.sh

[kevinchu]

Hi Ashley

I'm so glad to see that your problem was fixed.

I had a similar problem ,I hope you can give me some suggestion.

First , I'm a hardware engineer , so I'm not good at any software and I really don't understand your way to fixed your problem.

My situation as below

We pilot run some PCBA then got some doesn't work and worked PCBA

Some PCBA can load F/W complete by Mfgtools but some stuck at "Jumping to OS image"

I try any hardware rework method but it still can't working......

I use eMMC FLASH for OS!

I think DDR is OK, it working fine with DDR stress test.

BTW, what does "Close and Open" device means?

Refer to your experience, it seems just modify DCD length.

Would  you mind to  make a step by step explanation for me

Many thanks~~

[ashleysheng]

Have you solved the problem yet?

I have several questions after reading your problem description.

1. Have you enabled the HAB function on these pilot run mother boards? If you enabled HAB function with same efuse value, it should not be the condition that you can only successfully download the FW to some mother boards but get failed on some mother board. That sounds weired to me.

2. If you DON'T enable HAB function on these pilot run mother boards, and get problem on “Jumping to OS image” when you're using Mfgtool. You can try the following steps to see if these steps work to you.

A. Since you are hardware engineer, you can try to heat up CPU and DDR area by heat gun. (Caution: don't heat up the CPU and DDR area with long period of time that could damage your mother board.)

B. Quickly switch the mother board to download mode and use mfgtool BEFORE the temperature on CPU and DDR drops down.

C. If you can successfully download FW with mfgtool after heating up CPU and DDR area. It probably means that the DDR parameter is incorrect. You need the software engineer in your company to fine tune the DDR parameters.

D. I attached a excel file which can be used to generate a set of correct DDR parameters. You need to input the DDR parameters in “register configuration” sheet according to DDR datasheet. The excel can generate correct DDR parameters, you need to give the generated DDR parameters to the software engineer in you company. The software engineer needs to use these parameters and rebuild a u-boot.imx for mfgtool to use.

Although you mentioned DDR worked fine with stress test, I think your problem may be caused by inappropriate DDR parameters. The steps I provided above just for you to distinguish the problem. Hopefully, this reply helps you!!!

[kevinchu]

Hi Ashley

Thanks for your quickly reply!

I followed your suggestion that heat up the CPU and DDR then switch to FW download by mfgtools.

but unfortunately it still stuck at "Jumping to OS image".....

I suspect problem might be DDR parameters just like you mentioned .

I think I need to ask more detail with our software engineer.

Anyway, I'm very appreciate for your help. 

[tommyduan]

HI,I meet the same question,finally,what's it the really reasons?How can we resolve it?

[ashleysheng · Accepted solution]

Answer to myself :

Eventually I got HAB worked on both fastboot mode and mfgtool mode.

The reason to cause mfgtool stopping at “Jumping to OS image” while using mfgtool is because the length of DCD table (u-boot.imx) wasn't signed HAB key properly.  I used another “open” device for checking HAB again and turned on the HAB log.  I typed “HAB_status” and got HAB error event as “db 00 14 41 33 0c a0 00 ”. The error event means that one of the following required areas is not signed as documented in the Operation section for authenticate_image() API: 

IVT;

DCD (if provided);

Boot Data (initial byte - if provided);

Entry point (initial word).

In order to check the above required areas, I used mfgtool source code and added some logs in the source code(MxHidDevice.cpp).  I got the SDPCmd.datacount in DCDWrite function as total DCD data count of my u-boo.imx is (hex) 300.  So I modified my csf file as following :

[Authenticate Data]

Verification index = 2

Blocks = 0x00910000 0x2C 0x300 "u-boot-pad.bin"

[Authenticate Data]

Verification index = 2

Blocks = 0x177FF400 0x00 0x5AC00 "u-boot-pad.bin"

The problem got fixed and the “close” device can be flashed with new images by mfgtool.

[ericnelsonaz]

Thanks very much Ashley!

I was stuck trying to use one block of '[Authenticate Data]' and this note showed me that I needed two of them (one for DCD and one for the code in DDR).

[jimmychan]

Do you connect the debug port (Uart) when you using the MFGTool? If yes, can you show me the log message?

Let me try to explain the MFGtool for you.

The MFGtool is running the script ucl2.xml to program the images.
In the ucl2.xml, there are many scripts and separated by the LIST name.
Type the LIST name in the cfg.ini, the MFGtool will run the script under the same LIST name in the ucl2.xml.

When you read the script, there are two parts. One is CMD state="BootStrap" , and other one is CMD state="Updater".

In the "BootStrap" part, it will load the firmware (u-boot, kernel and RAM filesystem) to the DDR.
Then the board will boot up and running the firmware, it is a small linux system.
When the system is up, the storage device will be under the /dev/. For example, the device of SD Card is mmcblk.
Then in the "Updater" part, it can use the linux commands to download the images to the SD Card.
 

In the MFGtool, the firmware is board specific. If your own designed board is not the same as SabreSD/SabreAuto such as DDR, UART port setting, then you need to build the firmware for your board.

[ashleysheng]

Hi Jimmy,

     Yes, I did connect the debug port when I used mfgtool to download the images. Unfortunately, I was not able to get any log from the debug port. The reason I didn't get any log form the debug port is because mfgtool stopped at the point where is before jumping to the OS image. (I think the time for log starts to show should be "after" jumping to the OS image. )

    I got your point that we have to customize the firmware in order to match board requirement. Actually, we have configured u-boot, kernel and even RAM file system for mfgtool to be able to download the images on our custom board. We tested these firmware files via same mfgtools version for the following conditions:

1. Both board and firmware are without HAB enabled: all images can be downloaded via mgtool successfully.

2. The board is enabled (close) with HAB function but the firmware doesn't include HAB function: we can use fastboot to update the signed images.

3. The board and firmware are enabled with HAB function: the mfgtool shows “jump to OS image” and stops.

I used the same configuration for the firmware during the test. The only difference is to enable HAB function in u-boot.

[jimmychan]

Have you try to use Mfgtool like the condition(2) that the firmware doesn't include HAB function? As you can program the signed images to your board manually, the mfgtool is like a tool for helping you program the images automatically (running commands in the ucl scripts).

[ashleysheng]

Hi Jimmy,

I just did what you recommend in your previous post that to burn the singed image to a “close” device via mfgtool with no HAB function firmware. Unfortunately, I still got the same problem that mfgtool stuck at “jumping to OS image” message.

I checked the MFGtool.log and it seems like the same problem as

ExecuteCommand--Boot[WndIndex:0], File is C:\Documents and Settings\ModuleID[2] LevelID[1]: WriteReg(): Invalid write ack: 0xa00c3304

ModuleID[2] LevelID[1]: Failed to initialize memory!

ModuleID[2] LevelID[1]: PortMgrDlg(0)--MxHidDevice--Command Boot excute failed

ModuleID[2] LevelID[10]: CmdOperation[0], current command executed failed, so SetEvent(hDevCanDeleteEvent)

ModuleID[2] LevelID[10]: CCmdOpreation[0] thread is Closed

ModuleID[2] LevelID[10]: CCmdOpreation[0] thread is Closed

ModuleID[2] LevelID[10]: DeviceManager::OnMsgDeviceEvent() - EVENT_KILL

ModuleID[2] LevelID[10]: CMyExceptionHandler::OnMsgExceptionEvent() - KillExceptionHandlerThread

ModuleID[2] LevelID[10]: Exception Handler thread is closed

ModuleID[2] LevelID[1]: delete MxHidDeviceClass

ModuleID[2] LevelID[10]: delete MxHidDevice[00CA09B8]

ModuleID[2] LevelID[10]: Device Manager thread is closed

[jimmychan]

In your condition (2), you used the fastboot to update the signed image. so the u-boot can run when the board start , right?

[ashleysheng]

Hi Jimmy,

Do you have any suggestions?

[ashleysheng]

Hi Jimmy,

Yes, it is correct. The u-boot can run when the board start after using fastboot.