iMXRT1021 flexspiNOR unable to use HAB Encrypted XIP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMXRT1021 flexspiNOR unable to use HAB Encrypted XIP

8,179 Views
t_thurgood
Contributor III

Hi,

I am using the iMXRT1021 with flexqspiNOR flash. We want to encrypt the .sb image and the use on-the-fly BEE decryption. I am using the elftosb.exe, sdphost and blhost to produce and flash the .sb image.

This all works for normal (unsigned) image, but I cannot get the past the first stage of encryption.

I have downloaded, "Code-signing-tools", "openssl", "ubuntu shell for win10". I can create all the SRKs and certificates.

elftosb\elftosb.exe -f imx -V -c bd_file\imx-flexspinor-normal-signed.bd -o elftosb\img\ivt_output_xip.bin elftosb\img\hermes.s19

results in a ivt_output_xip.bin with 0kB.

Second stage..

elftosb\elftosb.exe -f kinetis -V -c bd_file\program_flexspinor_image_qspinor_encrypt.bd -o elftosb\img\encrypt_hermes_image.sb elftosb\img\ivt_output_xip_nopadding.bin

results in...

failed to open source file: elftosb\img\ivt_output_xip_nopadding.bin (ignoring for now)
error: line 55: error opening source 'myBinFile'

And no .sb image is produced.

Please advise how I can generate an encrypted .sb file, download and execute with BEE.

best regards,

Tony

imx-flexspinor-normal-signed.bd

options {
flags = 0x04;
startAddress = 0x60000000;
ivtOffset = 0x0400;
initialLoadSize = 0x2000;
//DCDFilePath = "dcd.bin";
# Note: This is required if the cst and elftsb are not in the same folder
// cstFolderPath = "/Users/nxf38031/Desktop/CSTFolder";
cstFolderPath = "/Projects/code_signing_tool/cst-3.2.0/release/";

# Note: This is required if the default entrypoint is not the Reset_Handler
# Please set the entryPointAddress to Reset_Handler address
// entryPointAddress = 0x60002411;
entryPointAddress = 0x60019358;
}

sources {
elfFile = extern(0);
}

constants {
SEC_CSF_HEADER = 20;
SEC_CSF_INSTALL_SRK = 21;
SEC_CSF_INSTALL_CSFK = 22;
SEC_CSF_INSTALL_NOCAK = 23;
SEC_CSF_AUTHENTICATE_CSF = 24;
SEC_CSF_INSTALL_KEY = 25;
SEC_CSF_AUTHENTICATE_DATA = 26;
SEC_CSF_INSTALL_SECRET_KEY = 27;
SEC_CSF_DECRYPT_DATA = 28;
SEC_NOP = 29;
SEC_SET_MID = 30;
SEC_SET_ENGINE = 31;
SEC_INIT = 32;
SEC_UNLOCK = 33;
SEC_XIP_REGION0 = 34;
SEC_XIP_REGION1 = 35;
}

section (SEC_CSF_HEADER;
Header_Version="4.2",
Header_HashAlgorithm="sha256",
Header_Engine="DCP",
Header_EngineConfiguration=0,
Header_CertificateFormat="x509",
Header_SignatureFormat="CMS"
)
{
}

section (SEC_CSF_INSTALL_SRK;
InstallSRK_Table="crts/SRK_1_2_3_4_table.bin", // "valid file path"
InstallSRK_SourceIndex=0
)
{
}

section (SEC_CSF_INSTALL_CSFK;
InstallCSFK_File="crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem", // "valid file path"
InstallCSFK_CertificateFormat="x509" // "x509"
)
{
}

section (SEC_CSF_AUTHENTICATE_CSF)
{
}

section (SEC_CSF_INSTALL_KEY;
InstallKey_File="crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem",
InstallKey_VerificationIndex=0, // Accepts integer or string
InstallKey_TargetIndex=2) // Accepts integer or string
{
}

section (SEC_CSF_AUTHENTICATE_DATA;
AuthenticateData_VerificationIndex=2,
AuthenticateData_Engine="DCP",
AuthenticateData_EngineConfiguration=0)
{
}

section (SEC_SET_ENGINE;
SetEngine_HashAlgorithm = "sha256", // "sha1", "Sha256", "sha512"
SetEngine_Engine = "DCP", // "ANY", "SAHARA", "RTIC", "DCP", "CAAM" and "SW"
SetEngine_EngineConfiguration = "0") // "valid engine configuration values"
{
}


section (SEC_UNLOCK;
Unlock_Engine = "SNVS", // "SRTC", "CAAM", SNVS and OCOTP
Unlock_features = "ZMK WRITE" // "Refer to Table-24"
)
{
}

Labels (1)
81 Replies

1,029 Views
t_thurgood
Contributor III

Hi kerryzhou

I tried this with Dev Unsigned Image Boot and got the same result, i.e. no download.

Trying different things, it seems the root of this problem is with the setting of ".sb" file. Sb generation is a bit wierd; Jay's readme admits that the tool has to be reset every time the sb needs to be generated. Also I found that .sb could only be generated by "All in one action", the generate image button won't do it.

Most importantly, if .sb is selected, then the tool fails to download the image and that was the cause of it hanging up. (for Unsigned and BEE encrypted modes) I had selected .sb, because thats what we have been doing with the standalone tools. We use blhost "ReceiveSbFile" as NXP bat files do this.

So, .sb=no. Reconnect tool. Generate image. Manually erase flash, the download actions don't seem to do that?

Now the image will be downloaded correctly. This can be done with "All in one" or manual operation. The board can be reset and is seen to be running correctly.

Now select BEE Encrypted Image Boot, do the reset, set the advanced options and erase the flash, etc

The "All in one action" prepares the SRK, image.bin, downloads the code and blows the fuses.

I inspected the flash and the image is encrypted (so the enc file appears to be working). I checked the fuse map and made sure everything is in order (I also have to blow BT_FUSE_SEL and ENCRYPTED_XIP).

Unfortunately, the board would not start up. The tool is locked out, because of the active bt_fuse_sel. IAR workbench does not connect (this always does for an dev_unsigned_image). However, I did get screen captures and logs, before disconnecting the tool.

c38_enc_fuse.png

c38_enc_60008000.png

I have attached 2 logs, one is for the unsigned operation and the other is for the BEE_encrypted operation.

I'm not sure what to try next, my only difference in your steps was that I selected "User Defined" encrypted region (Jay's notes said that was ok) start= 0x60001000 and length=0x3f0000. We use the upper region of flash as an NV store where we write/read directly, so don't want that exposed to BEE.

0 Kudos

1,029 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Tony Thurgood,

   You didn't try the tool's own app? Just like me:

NXP-MCUBootUtility-2.2.0\apps\NXP_MIMXRT1020-EVK_Rev.A2\led_blinky_0x6000a000.srec

  Please follow me to try it, and when it works, then you can modify your own app.

  I need to make sure the problem is not caused by the hardware, the firmware, the configuration at first.

  Please try it in your unsecured board led_blinky_0x6000a000.srec, make sure it works without secure operation at first. This firmware will toggle GPIO_AD_B0_05 pin, you can check the wave after you download it to check the code function.

  Please use the tool's app instead of your own .sb file at first, after it works, you can try your own code, your own operation. Thanks.

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.
-------------------------------------------------------------------------------

0 Kudos

1,031 Views
john8
Contributor III

Hi Kerry,

Can I get the image_enc2 source code? I wish to build and modify myself.

I have already done this for image_enc version 1.

We will be using RT1010 later and I need the OTFAD support.

Can you also send to my FAE? His details are below:

Ucu Maksudi

ucu.maksudi@avnet.com

Field Application Engineer

 

0 Kudos

1,030 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hello Tony,

I also attached my original app file, and the BEE readout .bin file for your reference.

led_blinky_0x6000a000.srec is the original app

kerry_readout.bin is the bee read out app

You can check the related image area, you can find the app is encrypted.

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.
-------------------------------------------------------------------------------

0 Kudos

1,030 Views
t_thurgood
Contributor III

kerryzhou

Thanks for your detailed solution.

It seems that the problem stems from the missing files in NXP-MCUBootUtility-2.2.0\tools\image_enc2\win\...

I want to... 

 b) add image_enc2 files

    This is very important, your problem should be caused by lacking this file. Jay didn't add it in the released MCUBootutility tool directly, you need to download image_enc2 and add it to MCUBootutility manually.

    https://www.cnblogs.com/henjay724/p/10189602.html 

    Download image_enc2.zip, unzip it, and copy it to NXP-MCUBootUtility-2.0.0\tools\image_enc2

However when I follow the link, it takes me to Jay's cn blog page. I cannot read Chinese. I tried the obvious actions (translation tool, entering the access codes etc), but I am unable to get the download. It seems the page wants me to install BaiduNetdisk and somehow copy the zip to there?

Is that necessary?

I am forbidden to install third party software and as its in Chinese, it is extremely difficult.

Also I see this...only for personal learning purposes, the consequences of the violator solely.

Can you please upload the required zip file to this forum, using the UPLOAD FILES facility?

Or make it available on the NXP web-site.

br,

Tony

0 Kudos

1,030 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Tony Thurgood,

    Thanks a lot for your question summarize, and sorry for my later support for your question.

    I already help you to check it with Jay internally, any updated information will let you know, please give us more time, thanks so much!

Best Regards,

Kerry

0 Kudos

1,030 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Tony Thurgood,

   As this testing is really consuming the EVK board(we have limit EVK boards, especially during novel coronavirus, we are working at home), sorry for the later detail test result.

   I have finished the MIMXRT1020-EVK board BEE with OTPMK(SNVS) key, after testing, the board's app image is encrypted, and boot is also works, please check the following detail reply. My MCUBootutility tool is a little old, you can use the new one, it's OK, the same operation.

1. MCUBootUtility tool prepare

    a)  Just as my post has mentioned:

   RT1050 HAB Encrypted Image Generation and Analysis 

   If the cst is your own configured, please do the following configuration at first:
(1)Copy the configured cst folder to folder:
NXP-MCUBootUtility-2.0.0\tools
Delete the original cst folder.
(2)Copy SRK_1_2_3_4_fuse.bin and SRK_1_2_3_4_table.bin to folder:
NXP-MCUBootUtility-2.0.0\gen\hab_cert
Now, you can use the new MCUBootutility to connect your board which already done the HAB encrypted method.

 b) add image_enc2 files

    This is very important, your problem should be caused by lacking this file. Jay didn't add it in the released MCUBootutility tool directly, you need to download image_enc2 and add it to MCUBootutility manually.

    https://www.cnblogs.com/henjay724/p/10189602.html 

    Download image_enc2.zip, unzip it, and copy it to NXP-MCUBootUtility-2.0.0\tools\image_enc2

    pastedImage_3.png

2. Now give you my testing result

1) DEV unsigned image boot

   Used to check the board download is working, and check the original fuse map.

pastedImage_6.png

pastedImage_7.png

  We can find the DEV unsigned image is totally the same as the downloaded source image.

  I am just using the MCUBootutility tool app:

NXP-MCUBootUtility-2.0.0\apps\NXP_MIMXRT1020-EVK_Rev.A2\led_blinky_0x6000a000.srec

OK, everything works OK without BEE or HAB. We can go to the next steps.

2) BEE Encrypted Image Boot

  board enter serial download mode, and connect it with the MCUBootUtility, then do the BEE Encrypted image configuration:

pastedImage_8.png

Click "All-In-One-Action" button, click yes:

pastedImage_9.png

Waiting until download finished:

pastedImage_10.png

These are the related image picture after readout:

pastedImage_11.png

pastedImage_12.png

pastedImage_13.png

pastedImage_14.png

Please note, the above image, totally be encrypted, not the original image any more, it is encrypted by the BEE.

pastedImage_15.png

pastedImage_16.png

pastedImage_17.png

Give you the new fuse map:

pastedImage_18.png

pastedImage_19.png

You can find the cfg1, SRK0 fuse data is burned.

After checking all the image, then reset device, change the board to boot from internal mode, BT_CFG[0]=1, then Power off the board and power on the board again, I find my led is blinking, so the BEE code is working.

  Then, enter serial download mode again, use the MCUBootUtility connect the chip again, it still works:

pastedImage_20.png

So, until now, RT1020 with BEE encrypted mode works with MIMXRT1020-EVK board and MCUBootutility tool.

Please find a new board on your side, and follow my steps and try it.

If you have any difficulties, please let me know, I will send some testing software to you on my side.

Thanks a lot for your patience and understanding!

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.
-------------------------------------------------------------------------------

0 Kudos

1,030 Views
t_thurgood
Contributor III

kerryzhou

Please respond to discussion/questions.

Can I email you?

br,

Tony

0 Kudos

1,030 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Tony Thurgood,

    You don't need to blow the BOOT_CFG[0] in the fuse, when you really enter the BEE mode, when boot from it, you just need to connect BOOT_CFG[0] pin to high, SW8_1 ON is OK.

    Sorry for my later reply, I have got one MIMXRT1020-EVK board on my home now.

    What's the detail situation on your side now? BEE mode still can't work right? both the flashloader mode or the MCUBootUtility tool, right?

   Please give me your newest detail situation, then I will test it on my side with my MIMXRT1020-EVK board.

Best Regards,

Kerry

0 Kudos

1,030 Views
t_thurgood
Contributor III

Hi kerryzhou

I am not using the MIMXRT1020-EVK board. We are developing a product (many 1000s/year) that uses the iMXRT1021. Our target board design has assigned all of the IO pins for control logic, so I am unable to use external BOOT configs.

The MCU BOOT Utility assumes everyone is developing an EVK environment, so it does not work for OEM board developers.

1. The biggest issue with the utility tool  (and please inform Jay) is that when attempting to configure encryption e.g. "BEE Encrypted Image Boot", the eFuse blowing is hard coded and does NOT allow for end user control. I have tried manually setting eFuses for the positions I need, I have tried editing the fuse_settings.json file, but when "Load Encrypted Image" is actioned, the tool forces BOOT_CFG1[1], (SEC_CFG[1]) to be blown. That one-time action forces authenticated HAB and is not necessary for development. There is no indication that this going to happen.

2. There is no explanation for configuring Encrypted Region, I have selected 0x60008000 (main image start) and Region Length as 0x3f0000. The other settings are default. I hope the OTPMK settings are good.

3. I download the BEE encrypted image "...gen\bootable_image\ivt_myName_extracted_dcd_signed_nopadding.bin" clicking "Load Encrypted Image" button, I then read from location 0x60008000 and see that the code is not encrypted. Its identical to a "DEV Unsigned Image Boot".

4. The Tools/Generate .sb file doesn't seem to have any effect ...both selections give the same output as in item 3 above.

5. What is the purpose of the "fuse_settings.json" file?

So, my status at the moment is, I can generate encrypted image and keys using the utility tool, or manually using CST/elftosb tools. I believe I know which fuses need to be blown. I am unsure why the downloaded image doesn't appear encrypted.

When I tried downloading using the manual tools, it failed (my original question on this thread).

I have read all the documents, but I must say that iMXRT1021 is always ignored and I have to assume that 1010, 1050, 1060 explanations are good enough.

So far, my board with encrypted code has failed to start up.

br,

Tony

0 Kudos

1,030 Views
t_thurgood
Contributor III

One other thing, the MCU Boot Utility Tool has an annoying comms timeout period. I use serial port connection (we have no USB stack support). I connect my board ok, get the blue light. I can then scan and read ok. If I don't do anything for a number of seconds, serial connection is lost and actions respond with ..."No response received for ping command".

I have to reset the device and start a new connection. 

Why the timeout? Can it be user configurable?

Also...

The flash download command is...

Executing: C:\NXP-MCUBootUtility-2.2.0\tools\blhost2_3\win\blhost -t 5242000 -p COM3,115200 -j
-- write-memory 1610616832 C:\NXP-MCUBootUtility-2.2.0\gen\bootable_image\ivt_myName_extracted_dcd_signed_nopadding.bin 9

Location 5242000 is 0x60001000 ...is that correct for 1021?

0 Kudos

1,030 Views
t_thurgood
Contributor III

Hi Kerry,

Can you update me please.

br,

Tony

0 Kudos

1,030 Views
t_thurgood
Contributor III

There is a "new" document available "AN12681 How to use HAB secure boot in i.MX RT10xx". I haven't had a chance to read in detail, but it may help to further the cause.

As it discusses security issues, it requires authenticated approval to download....

https://www.nxp.com/webapp/sps/download/mod_download.jsp?colCode=AN12681&appType=moderated

0 Kudos

1,030 Views
t_thurgood
Contributor III

Hi Ronnie,

Thanks for your help. I will see if I can do anything externally, otherwise another board will need to be blown. :smileyangry: 

br,

Tony

0 Kudos

1,030 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Tony Thurgood,

    So sorry for my later reply because of Chinese Spring Festival. And as you know,  Corona virus in China, it delays the back to work time, so, I will back to work on Feb.10th, at that time, I will help you to test it on my side.

    As I know, Jay Heng has tested the  encrypted f/w on a 1021 target with MCUBootUtility.

    Now, I am still on my home, and don't have the MIMXRT1020-EVK board, I will test it after I am back to work.

    About the MCUBootUtility connection, if in the encrypted secured mode, it will do the certification at first, from your picture, it seems the certificate is failed.

    So sorry about it.

    If you are in hurry, you also can try to create a new question post about it, then our other RT engineer will also help you.

Best Regards,

Kerry

0 Kudos

1,030 Views
t_thurgood
Contributor III

BEE Encrypted Image Boot

-------------------------------------

 

The RM manual, section 8.2 says... "Encrypted XIP on Serial NOR via FlexSPI interface powered by BEE and DCP
controller" .

The fuse for this is 0x450 Boot Cfg0 bit 0 = EncryptedXIP, but this is not blown by the MCU_Boot_Utility. Should this be blown for BEE encryption?

 

Jay's README.md says...

"All operations are correct. Set Boot Mode to 2'b10(Internal Boot mode) via SW7 DIP switch on the board, and sets BT_CFG[1] to 1'b1 (Encrypted XIP is enabled). The rest remains all 0s. You can see that the BEE encrypted image is executed normally."

Please note, we are building a product with the 1021 MCU and have long discarded EVB development.

0 Kudos

1,030 Views
john8
Contributor III

Hi Tony,

You DO NOT need to blow the eFuse BOOT_CFG[0]

There are THREE ways to enable BEE.

1. Use the BEE driver API function BEE_ENABLE() it sets the BEE enable bit in the BEE CTRL register.

This is best for development and even for production for non-bootable images - see my example posted earlier.

It uses this function:

static inline void BEE_Enable(BEE_Type *base)
{
   base->CTRL |= BEE_CTRL_BEE_ENABLE_MASK;
}

2. Use SW8-1 (GPIO_EMC_18) which corresponds to BOOT_CFG[0]. Works only IF you have not blown BOOT_CFG[0]. Also good for development.

3. IF you are encrypting ALL of Flash for BEE, Not Recommended, then you can either blow the BOOT_CFG[0] eFuse to permanently enable BEE or use a switch or link to do what SW8-1 does i.e. set GPIO_EMC_18 High.

The recommended way is to:

1. Use HAB Encryption for your bootloader only.

2. Have your bootloader

   a. enable BEE for the region where your firmware is located e.g. 60008000 - 60400000,

   b. authenticate your firmware image, then jump to it. The code I posted here and emailed you is part of this procedure.

DCP - Works similarly. I use DCP to decrypt other areas of my Flash which are not subject to BEE. You can use other decryption algorithms such as AES128ECB (Does not require Nonce) or AES128CBC. You can also use it for CRC32 among other things. I use it for ECB and CRC32.

You can make use of the same key that you use for your BEE or use a different key. NOTE: If you use the BEE key i.e. OTP, then you will need to Byte Swap the key prior to DCP encryption. This not documented and the KeyByteSwap API feature appears not to work.

The DCP driver code is pretty good but it does not fully show how to use the OTP key. The above information took many hours to figure out.

FINALLY

Please note the main purpose of HAB and BEE is twofold:

1. HAB prevents unauthorized code from booting, hence its name...

2. HAB Encrypted boot encrypts your 'bootloader' - an additional side attack protection - but not really necessary if your bootloader is simple. i.e. UBoot vs Linux kernel.

3. BEE prevents reverse engineering of your main code i.e. Firmware. HAB ROM extensions allow your bootloader to extend the chain of trust to your Firmware image, which can be BEE encrypted.

So if you take the UBoot/Linux Kernel analogy, HAB is for UBoot, BEE is for Kernel, UBoot authenticates Kernel, UBoot executes Kernel.

Hope that helps.

0 Kudos

1,030 Views
t_thurgood
Contributor III

Hi John,

Thanks for your detailed explanation.

The main problem I am faced with, is that for some time we have to use a production target board. That design uses the the io pins for various control logic and inhibits the external io boot options. In development we blow the BT_FUSE_SEL so the board can start up correctly. In that scenario, we are still able to use the j-link debugger and IAR Workbench, but serial download is a one-shot process. 

Using your suggestion of programmatically setting BOOT_CFG[0] may be an option and I will try this out, but I didn't have much success trying to encrypt defined regions of flash. So I must re-visit that operation and get a targeted area of flash using BEE. I already have the device starting up at 60002400 and then branching to a bank at 60008000 or 60200000 for f/w upgrade ability.

br,

Tony

0 Kudos

1,030 Views
john8
Contributor III

Hi Tony,

I understand where you are coming from. The code I posted should get you going with BEE, study it and if you have questions, DM me. You must get your BEE proof of concept going first. Start with register based Keys/Nonce. Then move onto OTP based keys e.g. SW_GP2. This essential.

My thoughts:

1. You don't need access to ANY boot pins. I don't use any except for the normal flash boot mode and for production that will be burned. In any case 1021-EVK boards are cheap at $59... for proof of concept.

2. If you burn the BEE enable eFuse then you MUST make use of KIB/EKIB and PRDB/EPRDB - Read section 2.4-2.7 of AN12079. This mechanism will require those special areas 'Protection Region Descriptor Blocks - PRDB' to be in Flash at 0x400/0x480 for Region0 and 0x800/0x880 for Region1. This is for 'Bootable BEE XIP'. This is not what I use. I determined it is inappropriate for the way my OTA firmware update works. Plus, its a lot more work for little gain.

3. I dont use the Flashloader, I dont need to. The IDE does it for me. The flashloader is a pain during development.

4. Once you close the HAB, then yes, you will need to use the Flashloader or download your own signed code to burn the Flash with your image. But I dont do this till production and even then its the last step, so in reality we never use the flashloader.

5. Our Bootloader boots normally, but is HAB authenticated, like yours it is around 0x2000. Our firmware is at 0x60008000 and our update sits midway up the memory map (although it does not execute from there). Our Bootloader is not encrypted, though it can be. I probably will later using encrypted HAB and SNVS based keys. But its just another security layer/side vector protection.

6. The firmware is authenticated by the Bootloader using the HAB BootROM functions - See HAB4_API.pdf included in the CST 3.3 release. You only need three functions: hab_rvt_entry(), hab_rvt_authenticate_image_no_dcd() and hab_rvt_exit().

7. I suggest the following memory map for you:

0x60000000-0x60008000 - Your HAB enabled Bootloader - potentially RSA encrypted as well if you wish.

0x60008000-0x60200000 - Your BEE Region0 AES128 encrypted, HAB enabled, application firmware.

0x60200000-0x60400000 - Your storage area for new application firmware. This area is not BEE enabled. You would copy the new firmware over the old. How you manage this process is up to you and your bootloader.

Hope that clarifies things.

regards,

0 Kudos

1,030 Views
t_thurgood
Contributor III

Hi John,

Yes, that is very specific...thanks.

I will endeavour to follow through your suggestion with our dev environment. The flash memory locations are very similar to what I have chosen ...I also use the upper 32k (8 sectors) for NV parameter store.

Thank you for your time on this,

Tony

0 Kudos

1,030 Views
t_thurgood
Contributor III

A bit more on this...

 

I edited the FuseMAP in "bin\fuse_settings.json" file with the values I wanted, i.e. open HAB. I thought this might dictate the fuse blowing for BEE Encrypted Image Boot, however that is not the case as the download encrypted file button seems to be hard-coded to burn what it thinks are the appropriate fuses i.e. SEC_CONFIG[1:0] = 11 and EncryptedXIP as default (0).

I was able to blow that one whilst still connected to the Utility, but then the board still refused to start!

 

What is the purpose of the fuse_settings.json file?

0 Kudos