topic Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue in i.MX RT Crossover MCUs

MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

t_thurgood — Wed, 04 Mar 2020 15:07:58 GMT

I am using the (MBU) MCU Boot Utility v2.2.0 with an iMXRT1021 target and the following selections...

Serial Port UART
BEE Encrypted Image Boot
Boot Device Configuration - Quad mode = "Set StausReg1[6]" (enable write)
Fixed Otpmk(SNVS) Key
Advanced Key Settings - User Defined region - 0x60002000, 0x3f6000

Using the "All-in-one Action", I re-use SRKs etc, generate the signed bootable image, download and blow fuses.

Disconnect serial port and power cycle, at this point the target should boot up, which it fails to do.

I tried many things to resolve this issue and found the problem is with the HAB secured boot. To prove this, I used the SRK keys and generated image from the the MBU and mimicked the download commands using the BLhost application. I sent every command with the exception of not blowing SEC_CONFIG_1 fuse i.e. HAB security=open.

Now the target boots up and runs normally with BEE encrypted code, so my questions are...

1. Why does the secure HAB reject the image+csf generated by the Utility tool?

2. Why does the MBU force the HAB to be closed? (this action is part of the image download).

The documented advice from NXP is to leave the HAB open during development, so the tool should reflect this and allow for some end user control.

I have run the demo app on the 1020EVK and it boots ok with encryption, so why the problem with my target?

br,

Tony

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

t_thurgood — Wed, 04 Mar 2020 15:29:55 GMT

kerryzhou‌

Attached a copy of the download. only the code section was encrypted, ivt, boot etc are readable.

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

kerryzhou — Thu, 05 Mar 2020 11:45:16 GMT

Hey Tony Thurgood,

Thanks so much for your effort and the new question post!

So, your own board issue is mainly related to the HAB close right?

You said, "used the SRK keys and generated image from the MBU and mimicked the download commands using the BLhost application."

Please tell me more details about it, SRK keys is dowloaded in the fuses.

1. Generated image from the MBU, how do you get it? Please give me more details about it.

2. using BLhost application to download commands, please give me the whole commands with BLhost you have tried.

Just without burn the HAB close fuse, right?

About your two questions:

1. Why does the secure HAB reject the image+csf generated by the Utility tool?

Answer: Because I can't reproduce the problem, then I also need to consider how to find the root problems.

Do you have the failed boot board image with Utility tool? Please share it with me both image and the fuse map.

Your own BLhost download code boots ok, please also share with me your working board image and the fuse map.

I want to review it.

2. Why does the MBU force the HAB to be closed? (this action is part of the image download).

Answer: In the previous training by jay, I remember that jay told me, the official BEE also suggest based on the HAB, I think this is why Jay's MBU close the HAB, but Jay also tell us, HAB is not the must item to BEE, no relationship in fact.

You said, "The documented advice from NXP is to leave the HAB open during development"

Please tell me which document, the BEE related document tell you HAB open?

Please give me the link, I will double check it.

After you give me the details, I will also try to talk with Jay, find more details about the MBU.

If I can reproduce your problem, maybe it is better to find the root problem.:(

3. About your question, MIMXRT1020-EVK board work, but your own board can't work.

This is also my interesting point, I also want to know what's the difference caused this interesting result. But I can't reproduce your problem because I don't have your board. Maybe we still need to do more research find the different, I will also consult with our internal expert, whether the hardware point may influence this secure boot action or not.

BTW, your attached.doc is your own working board which is downloaded with BLhost?

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

t_thurgood — Fri, 20 Mar 2020 14:22:17 GMT

Hi kerryzhou

Sorry for the delay, I was tasked with other development issues, but now I can re-visit this problem.

To answer your questions...

In the MBU, I did...
- Serial Port UART
- BEE Encrypted Image Boot
- Boot Device Configuration - Quad mode = "Set StausReg1[6]" (enable write)
- Fixed Otpmk(SNVS) Key
- Advanced Key Settings - User Defined region - 0x60002000, 0x3f6000
- All-In-One Action
- Having done the above, I then accessed NXP-MCUBootUtility\gen\bootable_image\ivt_filename_extracted_dcd_signed_nopadding.bin

2. blhost commands...

// set memory parameters

blhost -t 5242000 -p COM3 fill-memory 538976256 4 3221225735 word
blhost -t 5242000 -p COM3 fill-memory 538976260 4 0 word
blhost -t 50000 -p COM3 configure-memory 9 538976256
blhost -t 2048000 -p COM3 flash-erase-region 1610612736 192512 9
blhost -t 5242000 -p COM3 fill-memory 538984448 4 3759210496 word
blhost -t 5242000 -p COM3 fill-memory 538984452 4 1610620928 word
blhost -t 5242000 -p COM3 fill-memory 538984456 4 4153344 word
blhost -t 50000 -p COM3 configure-memory 9 538984448
blhost -t 5242000 -p COM3 fill-memory 538980352 4 4026531855 word

// Blow 8 x SRK fuse registers
blhost -t 50000 -p COM3 efuse-program-once 24 c5ae10bb
blhost -t 50000 -p COM3 efuse-program-once 25 627bf7b1
blhost -t 50000 -p COM3 efuse-program-once 26 523e7627
blhost -t 50000 -p COM3 efuse-program-once 27 52c34eee
blhost -t 50000 -p COM3 efuse-program-once 28 ff74507f
blhost -t 50000 -p COM3 efuse-program-once 29 264446be
blhost -t 50000 -p COM3 efuse-program-once 30 226ab53b
blhost -t 50000 -p COM3 efuse-program-once 31 a1395b04

blhost -t 50000 -p COM3 efuse-program-once 6 00002010 << BEE_KEY0_SEL, BT_FUSE_SEL, Hab open
blhost -t 50000 -p COM3 efuse-program-once 5 00000001 << EncryptedXIP

// write memory 0x60001000 encrypted_image
blhost -t 5242000 -p COM3 write-memory 1610616832 C:\NXP-MCUBootUtility\gen\bootable_image\ivt_filename_extracted_dcd_signed_nopadding.bin 9

"Jay also tell us, HAB is not the must item to BEE, no relationship in fact."

This is true, the HAB has no influence on the inner workings of the BEE. But the HAB will stop the encrypted code from executing because there is some authentication problem. The reason that the HAB refuses to boot is not given, so difficult to diagnose and remedy.

Do you have the failed boot board image with Utility tool? Please share it with me both image and the fuse map.

Your own BLhost download code boots ok, please also share with me your working board image and the fuse map.

I want to review it.

I have attached images, but there is absolutely no difference in image or other fuse settings between the board that starts and the board that doesn't. The only difference is the non setting of SEC_CFG_1 (hab).

Please tell me which document, the BEE related document tell you HAB open?

AN12681 - How to use HAB secure boot in i.MX RT10xx 5.2 Program image during development
In Development phase, the device may be under HAB open mode for most use cases.
Security Reference Manual for the i.MX RT1050 Processor 3.3.6 Boot security settings Open: This level is intended for use in non-secure products or during the development phases of a secure product.
i.MX MCU Manufacturing User's Guide 6.3 Program bootable image during development
In development phase, the device may be in HAB open mode for most use cases.
How to use i.MXRT Security Boot 4.2. Program image during development In Development phase, the device may be under HAB open mode
Secure Boot on i.MX25, i.MX35, and i.MX51 using HABv3 3.2.2 Non-Secure Boot Image Layout This is the final configuration for Non-Secure products as described above. The Engineering
configuration should also be used for development purposes of secure products where CSFs and other data
components for secure boot can be debugged.
i.MX RT1020 Processor Reference Manual 8.3.6 Boot security settings Open: This level is intended for use in non-secure products or during the development phases of a secure product.

So I have a BEE encrypted board that starts and can be run with the j-link IAR Workbench debugger, is it possible to find out what step of the HAB is failing?

br,

Tony

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

t_thurgood — Tue, 24 Mar 2020 17:05:55 GMT

Hi kerryzhou,

Do you have any answers for this?

br,

Tony

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

kerryzhou — Wed, 25 Mar 2020 00:17:35 GMT

Hi Tony Thurgood,

Thanks for your detail updated information.

Please give me more time, I will check the details, then give you feedback, thanks.

Best Regards,

Kerry

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

kerryzhou — Tue, 31 Mar 2020 07:24:42 GMT

Hi Tony Thurgood,

Sorry for my later reply.

Could you please check the following point:

1. Don't use the code relocated offset 0x2000, you can use the 0XA000.

Eg, use the led_blinky_0x6000a000.srec, then in your own board which HAB is closed and try again.

2. Do you use the MIMXRT1020 sample chip?

3. I have contacted with Jay

In fact, the MCUbootUtility tool can choose the Hab open or close ,it is this option:

But, when customer use the key as OTPMK, then the item can't be modified to no, because using this key, the HAB must close, otherwise, otpmk will use all 0 as the key to encrypt the image.

So, if using the otpmk as BEE key, and HAB is open, it means you use all 0 as the key, not the real SNVS key. as you know, all 0 is also one type of key.

When choosing the user key, then the "Enable Certificate for HW encryption" can be modified.

For your question, Jay just told me you can't use 0X2000 as the app startpoint, and he is very busy, I still didn't get the details. So, could you please in your own HAB closed board, try the other app point code, like 0XA000, any difference?

Best Regards,

Kerry

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

t_thurgood — Tue, 31 Mar 2020 21:07:25 GMT

Hi kerryzhou

Going through your numerated points...

1. Don't use the code relocated offset 0x2000, you can use the 0XA000.

My code isn't located at offset 0x2000. If you look at the first 2 lines of the srecs....

led_blinky_0x6000a000.srec

S01200006C65645F626C696E6B792E73726563F5
S113A0000000012029AF00003FAA000073AC00004B

my srec

S00D00006865726D65732E73313963
S315600000004643464200040156000000000103030017

You can see my code is linked to the normal 0x60000000 base address.

and the first few lines of my .icf are...

define symbol m_interrupts_start = 0x60002000;
define symbol m_interrupts_end = 0x600023FF;

define symbol m_text_start = 0x60002400;
define symbol m_text_end = 0x60007FFF;

If you are referring to... Advanced Key Settings/User Defined...

Region start: 0x60002000 Region Length: 0x3f6000

then I don't understand the problem. That is my choice of flash memory region that I want to be encrypted. I chose 0x2000 offset because I want to see the IVT and Boot data...

0x60001000 d1 00 20 40 c9 a6 02 60 00 00 00 00 40 10 00 60 .. @...`....@..`

0x60001010 20 10 00 60 00 10 00 60 00 d0 02 60 00 00 00 00 ..`...`...`....

---------------------------------Boot Data--------------------------------------------

0x60001020 00 00 00 60 00 f0 02 00 00 00 00 00 00 00 00 00 ...`............

0x60001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

------------------------------------DCD-----------------------------------------------

that's readable, so I can confirm correct placement. It has nothing to do with... "Jay just told me you can't use 0X2000 as the app startpoint".

2. Do you use the MIMXRT1020 sample chip?

Yes, our product is designed with the iMXRT1021

3. In fact, the MCUbootUtility tool can choose the Hab open or close ,it is this option:

Sorry to disagree, but that is not an option, more of a mutual exclusion.

I want to use "Fixed Otpmk (SVNS) Key" AND keep the HAB open for development. I know this is possible, because I have working board with those settings. Its the MCU Boot Utility Tool that is not allowing that choice.

Does Jay agree with the NXP documentation that says the HAB can be open for development?

With regard to my previous post, I still have this unanswered question...

I have a BEE encrypted board that starts and can be run with the j-link IAR Workbench debugger, is it possible to find out what step of the HAB is failing?

To elaborate on that question;

The HAB is closed and with a normal power on, the board fails to start. The same code and keys are loaded to anther board, with the HAB open and it will start and run normally.

So with the first example, the HAB runs confidence checks at boot, something is detected as wrong and the boot process is halted. Can we determine the cause of the HAB failure?

br,

Tony

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

kerryzhou — Wed, 01 Apr 2020 00:26:29 GMT

Hi Tony Thurgood,

1. Maybe I didn't describe it very clear, I mean try the code reset handler not with 0X2000.

You can try other address, eg, 0xa000.

You can relocate your code:

define symbol m_interrupts_start = 0x6000a000;
define symbol m_interrupts_end = 0x6000a3FF;

define symbol m_text_start = 0x6000a400;
define symbol m_text_end = 0x6000FFFF;

Then try it in your own board which already fuse the HAB close.

After you test it, please tell me the result, thank you.

2. You mentioned:I want to use "Fixed Otpmk (SVNS) Key" AND keep the HAB open for development.

As Jay told me, if the HAB open, the code won't read the real OTPMK key as the BEE key, it may use all 0 as the BEE encryption, but just the MCUBootUtility tool didn't allow you choose the HAB close as no.

You can do it like your way, choose SNVS key, and with HAB open, it also can boot, just the encryption key is all 0, not the real OTPMK

From the reference manual, I find this description may also demonstrate Jay's description:

When the HAB is open, the HAB secure won't work, then it also can't use the master secret key selected by SNVS, and may use 0X00 as the default key.

3. Does Jay agree with the NXP documentation that says the HAB can be open for development?

Yes, Jay agree that you can leave HAB open, it also can boot with BEE.

4. I have a BEE encrypted board that starts and can be run with the j-link IAR Workbench debugger, is it possible to find out what step of the HAB is failing?

To be honest, I still didn't find the detailed way to find out the HAB failing, that's why I can't confirm it now. I will still try to find help from our internal side, and try to reproduce your problem with some of our other boards(not EVK).

Anyway, I suggest you follow Jay's suggestion, don't relocate the reset handler to offset 0x2000, you can try 0XA000, any improvement?

After your test, please give me your test result, thanks!

Best Regards,

Kerry

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

t_thurgood — Wed, 01 Apr 2020 07:24:11 GMT

Hi kerryzhou

I am surprised that the position of the Interrupt vector table could be the cause of my problems. Our project started with the EVK-MIMXRT1020 and the bundled software.

The demo-apps, e.g. led_blinky/iar/MIMXRT1021xxxxx_flexspi_nor.icf have...

define symbol m_interrupts_start = 0x60002000;
define symbol m_interrupts_end = 0x600023FF;

define symbol m_text_start = 0x60002400;
define symbol m_text_end = 0x607FFFFF;

define symbol m_data_start = 0x20000000;
define symbol m_data_end = 0x2000FFFF;

define symbol m_data2_start = 0x20200000;
define symbol m_data2_end = 0x2021FFFF;

define exported symbol m_boot_hdr_conf_start = 0x60000000;
define symbol m_boot_hdr_ivt_start = 0x60001000;
define symbol m_boot_hdr_boot_data_start = 0x60001020;
define symbol m_boot_hdr_dcd_data_start = 0x60001030;

That is the standard flash memory configuration from NXP, so there seems to be some conflicting viewpoints?

Anyway, I am currently working from home and have limited resources (no evk boards). Travel to the office is very restricted. I have one target device that has a fresh MCU, but I will need check with our manager to see how we can proceed.

You could try running your EVK with the blinky app+BEE at 0x2000 ?

Why is offset 0xA000 fundamental to the HAB/BEE execution?

br,

Tony

Re: MCU Boot Utility, iMXRT1021, BEE Encryption - boot issue

kerryzhou — Thu, 02 Apr 2020 03:12:28 GMT

Hi Tony Thurgood,

Hopes you are fine!

Today, I really test my BEE RT1020-EVK board with app+bee relocated the offset at 0x2000, it is still working.

So, this point is not the root problem of your can't working customer board. Then I double check with jay, it is a mistake of my understanding, he means the non-XIP, XIP code shoud no influence. So, to XIP code, please ignore my last suggestion, sorry about it.

Could you please check the following information?

1 About your another customer board which didn't close the HAB, do you also burn the OTPMK?

2, About your working MIMXRT1020-EVK board, and your can't working customer BEE Hab close board.

Do you totally use the same BEE burn configuration, the same app firmware?

Do you also read out your MIMXRT1020-EVK board BEE image, and compare with your HAB close customer board's image, any difference?

About the firmware, do you use the simple project like just led_blinky to test the BEE boot in your HAB closed customer board? could you please use the totally the same simple app in both your customer board and the EVK board, then readout the image, and compare the difference? Mainly compare EKIB area.

3. If you have interest, you also can try user key(SW_GP2 key), this mode can select the HAB close or open freely in the MCUBootUtility.

Best Regards,

Kerry