How to produce a complete image using offline tool od SPSDK

[mastupristi]

Hello,

To me complete image means an image containing of keyblob, FCB, etc. In other words an image containing some 4KB between 0x30000000 and 0x30000FFF.

If I understand correctly, using SPT (and thus the underlying SDSDK) a file is produced that is missing the first 4KB.
These will be populated by flashloader directly on the target, using parameters that will be communicated to it, right?
I would need to work offline instead. I need to produce a "full image" without having the ability to access a target.

how do i do that?

best regards

Max

[marek-trmac]

Hi Max,

you can use MCUXpresso Secure Provisioning tool to build the bootable image and write to the memory and then read the image back. The see flash memory content, you can use main menu > Tools > Flash Programmer.

[mastupristi]

Hi @marek-trmac ,

Thanks for the lightning-fast response! I must say, it seems my previous message might have gone on a little adventure of its own. Perhaps it got lost in translation, or maybe it's just shy and didn't want to reveal too much, especially about not wanting to use a hardware target.

To reiterate, my quest (sounds grander this way, doesn't it?) is to conjure a "full image" strictly via the magical realm of offline tools, without any direct whispers or nudges to a hardware target. Picture me as a wizard who left his wand at the office—trying to pull off a spell remotely!

So, if there are any secret scrolls or spells (a.k.a instructions or guidelines) that would enable me to do this, I would be most grateful. Seeking to work my magic entirely from within the confines of my digital cave!

Looking forward to your mystical guidance!

best ragrds

Max

[liborukropec]

Hello Massimiliano,

SEC tool does not offer such functionality, still it is doable with few manual steps using SEC and bundled SPSDK CLI utility (nxpimage).

First you need to have Flash Configuration Block binary file (fcb.bin), it can be read from Flash, or using Boot Memory Configuration dialog (accessible from toolbar) and then "Convert to complete FCB" button. Only at this point you need the device to be connected. Someone out of the cave might help.

Second, for example when I look into the write script (windos batch), I can see these pieces of code that write stuff into the Flash (SPI NOR):

call "%blhost%" %blhost_connect% -j -- write-memory 0x30000400 "%SPT_WORKSPACE%\bootable_images\fcb.bin"
call "%blhost%" %blhost_connect% -j -- write-memory 0x30000600 "%SPT_WORKSPACE%\configs\image_version.bin"
call "%blhost%" %blhost_connect% -j -- write-memory 0x30001000 "%SPT_WORKSPACE%\bootable_images\myapp.bin" 0

Then, SEC tool contains nxpimage utility located here: <INSTALL_DIR>/bin/_internal/tools/spsdk

Then this information can be transformed into this YAML config file consumed by the nxpimage:

name: My super binary image
pattern: zeros
alignment: 1

regions:
- binary_file:
    name: FCB
    path: bootable_images/fcb.bin
    offset: 0x400
- binary_file:
    name: image version
    path: configs/image_version.bin
    offset: 0x600
- binary_file:
    name: image itself
    path: bootable_images/evkmimxrt1160_ota_mcuboot_basic.bin
    offset: 0x1000

and finally the offline.bin can be created (expectation is that the offline.yaml is in the SEC workspace, nxpimage is in the PATH):

nxpimage utils binary-image merge -c offline.yaml -o offline.bin

Empty YAML config (template) file can be created by executing:

nxpimage utils binary-image get-template -o offline.yaml

Hope this helps.

Regards,

Libor

[mastupristi]

Hi @liborukropec 

what you tell me assumes that I know exactly the memory layout, thus the location of FCB, Image_Version, etc.
I would expect nxpimage to “know” where to go to place these items once the microcontroller is selected.

Is there another way to compose the image without indicating the addresses but only the micro?

Regards

Max

[marek-trmac]

Hi Max,

try "nxpimage bootable-image"

[mastupristi]

hi @marek-trmac 

try "nxpimage bootable-image"

this looks very interesting.
I followed the suggestion in the documentation and tried first
nxpimage bootable-image get-templates -f mimxrt1175 -o outDir

it creates a lot of files, but the one I'm interested in is bootimg_mimxrt1175_flexspi_nor.yaml

There are two questions I'd like to ask:

1. I don't see any section dedicated to Image_Version, has it been “forgotten” or is it not supported by this command?
2. At the end there's a reference to the file hab_container.yaml, which I can't find in the spsdk installation though. I also wonder if I should write this file myself but I have no idea how it should be done. Can you give me more detail on this point?

Last thing: If I wanted to write my own python script to do this operation what example could I follow?

best regards

Max

[nxf93270]

Hi @mastupristi ,

I might bring more light into this topic. 

The bootable image command was created exactly for this use case - customer wants to create a bootable image with all the segments before the actual image(such as FCB, keyblob etc) without bothering with looking for segment offsets in NXP documentation.

Regarding your questions:

1. Regarding the information I got today, the image_version should be placed on offset 0x600 in the final bootable image. Unfortunatelly this information is not in our database yet. It will be fixed and released in 2.6.1 release soon. 

2. The hab_container configuration setting is the actual HAB image(normally located on the offset 0x1000). It can be either yaml configuration file holding HAB configuration(and SPSDK will generate the binary) or the actual image in binary form. I assume you already have HAB generated, so just reference the file here.

Regarding FCB discussion above. You have several possibilities here. You can configure the memory on the chip using option word and then read the whole 512 bytes segment from the external  flash memory and then use it in the bootable-image configuration

Second option is to generate it "offline":

1. Generate FCB template with nxpimage bootable-image fcb get-templates
2. Update the template based on your preference
3. Export the binary using nxpimage bootable-image fcb export

[marek-trmac]

Hi Max,

all CLI tools including nxpimage are open source. 

Documentation: Applications — SPSDK documentation

Source code on GitHub

Sorry, I cannot answer your detailed questions, I have no experience with this command and I do not know the format of the bootable image. I'd recommend to use MCUXpresso Secure Provisioning tool as an example, how to do the operation properly.

[mastupristi]

hi @marek-trmac 

all CLI tools including nxpimage are open source. 

Documentation: Applications — SPSDK documentation

Source code on GitHub

I know that perfectly well, but it doesn't seem “easy” to reverse engineer the sources to figure out how to do what I want to do, to know if there is and what is an entry for Version_Image in the yaml, or to know how the file hab_container.yaml is used to figure out how I should write it.

Sorry, I cannot answer your detailed questions, I have no experience with this command and I do not know the format of the bootable image. I'd recommend to use MCUXpresso Secure Provisioning tool as an example, how to do the operation properly.

I've already tried going the Secure Provisioning Tool route, but it doesn't help me that far, precisely because it doesn't build the full bootable image.
Perhaps it would be appropriate for you to involve some of your colleagues who are more skilled than you on this topic

best regards

Max

[liborukropec]

Hi Max,

just for my curiosity, how does the tool limits you when the FCB is written separately from the rest of the image?

Regards,

Libor

P.S. And BTW SEC tool now supports script "hooks" during the build and write execution (without touching generated scripts), so you can use the SEC tool as is, at least for the build and in your hook you can just merge the FCB together with the image, still you might benefit from other features the SEC tool provides.

[mastupristi]

hi @liborukropec ,

how does the tool limits you when the FCB is written separately from the rest of the image?

In our infrastructure, we cannot use flashloader. Our board does not have any serial or USB accessible. We have ways to put the micro into reset and write its flash. But this assumes we have the whole image, complete with the first 4KB, containing FCB and Image_Version.
I am not aware that Secure Provisioning Tool (I guess that's what SEC term you are referring to) is capable of writing a full image. I am using SPT 9.0

And BTW SEC tool now supports script "hooks" during the build and write execution (without touching generated scripts), so you can use the SEC tool as is, at least for the build and in your hook you can just merge the FCB together with the image, still you might benefit from other features the SEC tool provides.

can you explain this better?

best regards

Max

[liborukropec]

Hi Max,

if you install SEC v10 (it should not interfere with v9) you can try, or at least you can just download User Guide for v10 here https://www.nxp.com/webapp/Download?colCode=MCUXSPTUG

And look to the chapter 7.4

7.4 Script hooks
Script hooks are executed before or during build, write, and manufacturing script execution. Script hooks enable
script customization outside the generated scripts. Script hooks are re-generated only on explicit request.
Hook scripts are located in the "hooks" subfolder and new workspace contain the examples for the selected
processor. In GUI, the hook script is created by a single click.

...

Basically hook scripts allows scenarios where you would like to integrate the SEC (yes, SEC is the abbreviation for Secure Provisioning tool) with other SW or workflows **without** manual edition of scripts generated (and rewritten with every build & write button action). You can put short scripts aside our script and the generated script executes (if present) the hook script in certain moments during build or during write. Your script can do appropriate actions at the very last moment, when all is "finished".

In your use case basically you can merge the FCB together with the produced almost-complete-bootable-image.

See fragment of generated hook (here for RT1050) , where you can see points in which the hook script is called:

... deleted header of build hook
:started
@rem hook executed before any other command is executed
@echo ### execution of build-hook: started ###
goto end
:build_image_done
@rem hook executed after build of bootable image is done
@echo ### execution of build-hook: build_image_done ###
goto end
:build_flashloader_done
@rem hook executed after build of unsigned or/and signed flashloaders is done
@echo ### execution of build-hook: build_flashloader_done ###
goto end
:build_encrypted_image_done
@rem hook executed after build of encrypted image is done
@echo ### execution of build-hook: build_encrypted_image_done ###
goto end
:finished
@rem hook executed after all steps of the script were executed
@echo ### execution of build-hook: finished ###
goto end
:end
@rem Reset error state at the end of the step execution, failed commands should be handled in step handling.
ver > NUL

To be honest, your use case prevents from fuse configuration and burning, so set of usable features for you is limited in your use case.

Regards,

Libor