Re-generate boot descriptor file from command line

[brian_strickler]

Currently using Secure Provision Tool version 8.0 with the iMX RT1176.

I am attempting to build images for my own custom bootloader and main applications from the command line. In secure provisioning tools I am able to 'Regenerate all files for this build' using the "Update files" button under the "Build image" tab to update build scripts and configuration files. My issue is the two different images have different start addresses and it appears the imx_application_gen_win.bd is what controls what values are placed into the IVT at the start of the generated .bin file. I don't see a way for me to update this .bd file based on the source executable image from the command line. I could manually create different .bd files for the two images but this seems messy for future updates. I have a batch file similar to the build_image_win.bat to build the applications in MCUXpresso headless mode and attempt to make the applications bootable by using the nxpimage hab export command that SPT seems to use.

[brian_strickler · Accepted solution]

It appears that section 8 of the MCUXpresso Secure Provisioning Tool User Guide v9 has the documentation need to build the bootable images from the command line properly. Here is what I changed from what I was originally doing in my build process:

I generated .s19 srec files from the .axf files using post build scripts to do the following:

arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.s19"

Next in my build script I generate the bootable image using the build command from securep.exe

"%SPT%" -w "%SPT_WORKSPACE%" --device MIMXRT1176 build --source-image "%SPT_WORKSPACE%\source_images\boot.s19"

The same thing for the main application. I then am able to find both .bin bootable images in:

%UserProfile%\secure_provisioning\bootable_images

Now both images have the correct IVT and boot data structures that previously only had the previous configuration (out of date .bd file) from the last time I opened Secure Provisioning Tools. I hope this helps anyone else trying to automate the build process. Thanks again to @marek-trmac and @liborukropec for pointing me in the right direction.

Best,

Brian

 

[marek-trmac]

Hi Brian,

it is not clear why you need to build bootable application if you have bootloader. I suppose the processor starts the bootloader after reset, not the application, so I suppose you do not need bootable application image.

There are examples in MCUXpresso SDK how to use "MCUboot" open source bootloader and this use case is supported in MCUXpresso Secure Provisioning tool v9, see User Guide for step-by-step description.

[brian_strickler]

Hi Marek,

Thanks for the reply. To further clarify what I am implementing. I have a custom bootloader application that is loaded to QSPI Flash on FlexSPI 2 at 0x6000 0000. My application or bootloader will receive a file containing the bootloader application, arm m7 main application, and additional images for the m4 application and an fpga. My application or bootloader will parse this file and place images in QSPI Flash. When my bootloader reboots and verifies there is a valid arm m7 application it will load it into internal RAM and jump to the application. 

Currently, this relies on there being an IVT that is placed in RAM at 0x2000 so my bootloader can read the self address of the IVT and the start absolute address of the image in the boot data structure to be able to jump to the main arm m7 application.

#define IVT_ADDRESS 0x2000
static void load_application_image(uint32_t dst, uint32_t offset, uint32_t image_size)
{
  uint32_t applicationAddress;
  uint32_t stackPointer;
  uint32_t baseAddress;

  baseAddress = NOR_FLEXSPI_AMBA_BASE + offset;
  memcpy((void *)dst, (void *)baseAddress, image_size);
  uint32_t arm_m7_image_ram = (*(uint32_t *)(IVT_ADDRESS + 20) + *(uint32_t *)(IVT_ADDRESS + 32));
  stackPointer = *(uint32_t *)(arm_m7_image_ram); //self + start in ivt
  applicationAddress = *(uint32_t *)(arm_m7_image_ram + 4);
  jump_to_application(applicationAddress, stackPointer);  
}

and 

static void jump_to_application(uint32_t applicationAddr, uint32_t stackPointer)
{
    // Create the function call to the user application.
    // Static variables are needed since changed the stack pointer out from under the compiler
    // we need to ensure the values we are using are not stored on the previous stack

    static uint32_t s_stackPointer = 0;
    s_stackPointer = stackPointer;
    static void (*s_entry)(void) = 0;
    s_entry = (void (*)(void))applicationAddr;

    // Turn off interrupts
    __disable_irq();

    // Set the VTOR to the application vector table address.
    SCB->VTOR = (uint32_t)0x2000;

    // Memory barriers for good measure.
    __ISB();
    __DSB();

    // Set stack pointers to the application stack pointer.

    __set_MSP(s_stackPointer);
    __set_PSP(s_stackPointer);

    // Jump to the application.
    s_entry();
}

This works when I have the IVT and Boot Data Structure at the front of my main arm m7 application hence my reasoning for wanting to append the IVT and Boot Data Structure to the first 0x1000 4KB of my main arm m7 .bin.

I will explore the User Guide and see if I can get the results I want with MCUXpresso Secure Provisioning Tool V9.

[liborukropec]

Hi Brian,

first, could you please upgrade to SEC v9? It brings multiple improvements, including custom hooks which should allow you to be able to add custom scripts without modifying the main build/write scripts created by SEC tool.

SEC tool allows "additional" images to be flashed together with the main application, which might be handy for your use case.

Using custom "hooks" scripts you can execute your scripts during build & write at different phases of the scripts, without modifying the generated scripts, so special cases not supported by SEC tool can be implemented more easily while still using generated scripts from SEC tool.

Could you please describe your use case, what exactly you want to do in SEC tool?

Regards,

Libor

[brian_strickler]

Hi Libor,

I will upgrade to v9 of the Secure Provisioning Tool. I'm not sure the additional images portion will be as valuable as I will flash the images to varying addresses build-to-build as I create a dynamic file that includes other images for other peripherals that are not fixed in length or position. I'm trying to automate the build process as much as possible and don't want future engineers the need to open up the Secure Provisioning Tool GUI to build each image with the updated IVT and Boot Data Structure. Please see my reply to @marek-trmac for further details. I will explore the hooks in more detail.

Thanks,

Brian