Application offset in bootable image *.bin file

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

Application offset in bootable image *.bin file

Jump to solution
7,397 Views
arnisj
Contributor II

I am using MCUXpresso Secure Provisioning v 3.1.

I am compiling code to run from BOARD_SDRAM, but bootable image is intended to be stored un eMMC/SD.

The problem is that application binary in generated bootable image is always located at 0x00001000. regardless BOARD_SDRAM location in memory configuration (0x80001000 or 0x80003000 et.).

Is it possible to change this offset in final *.bin file? How to do that? Will RT1050 built-in Boot ROM be able to boot from such image (with different application offset than 0x1000)?

My intention is to use 2 secondary bootloaders (for safety) and after updating one of them to change IVT to point to other bootloader in bootable image. I am using 2 separate projects and the idea was to store both bootloaders in final *.bin (which will be 1:1 stored on eMMC/SD) in different loacations. Then RT1050 booting from eMMC or SD would pick up the one pointed to by IVT.

However it seams that IVT contains ONLY pointers to locations in target memory, e.g. in my case in BOARD_SDRAM.

0 Kudos
1 Solution
7,141 Views
arnisj
Contributor II

So far I've solved problem in following manner.

In *.c or *.cpp wrote this:

__attribute__((used, section(".bl1"))) const char bl1PlaceHolder [1024*252] = {};

It doesn't matter whether there is or is not "const".

Then in Project Options->C/C++ Build->Settings->Managed Linker Script-> Tab "Tool settings" in “Extra linker script input sections” I set:

Input section description:             Region:                                 Section type:

KEEP(*(.bl1))                                    BOARD_SDRAM_BL1     .bss (.rodata or maybe .text won't work)

View solution in original post

12 Replies
7,142 Views
arnisj
Contributor II

So far I've solved problem in following manner.

In *.c or *.cpp wrote this:

__attribute__((used, section(".bl1"))) const char bl1PlaceHolder [1024*252] = {};

It doesn't matter whether there is or is not "const".

Then in Project Options->C/C++ Build->Settings->Managed Linker Script-> Tab "Tool settings" in “Extra linker script input sections” I set:

Input section description:             Region:                                 Section type:

KEEP(*(.bl1))                                    BOARD_SDRAM_BL1     .bss (.rodata or maybe .text won't work)

7,373 Views
marek-trmac
NXP Employee
NXP Employee

Hi Arnisj,

bootloader use case is not supported in Secure Provisioning Tool, so I cannot help much here.

The application offset cannot be directly changed in SEC tool. However the bootable image is created via the build script so you can manually modify it (see bd_files\imx_application_gen_win.bd in your workspace to modify parameters for bootable image and then run build_image_win.bat).

Regards,
Marek
0 Kudos
7,365 Views
arnisj
Contributor II

Does not work. Tried to change in imx_application_gen_win.bd to

startAddress = 0x80002000;

or 

startAddress = 0x80003000;

And in both cases runing build_image_win.bat I get crash. See attached image.

0 Kudos
7,382 Views
liborukropec
NXP Employee
NXP Employee

Hi Arnisj,

in addition to Marek's response - when/where do you want to change the IVT? Please be aware that if you want to change the IVT in the target device by your application, you might not boot next time if the "Authenticated" boot type is used because the signature won't match anymore.

 

Regards,

Libor

0 Kudos
7,380 Views
arnisj
Contributor II

I want to change IVT after I've modified application in my eMMC/SD.

I am aware that getting pofwer fail during IVT device won't boot.

I am not intended to use authenticated image.

I want to introduce dual second bootloader mechanism. While one bootloader is working, the other copy can be updated and after update IVT rewritten. This is possible in XIP mode, as I understand, because application code in image file is located in correct offset. This is not the case in image files for non-XIP code.

0 Kudos
7,391 Views
marek-trmac
NXP Employee
NXP Employee

Hi Arnisj,

please find in the PDF documentation, how to build the image for SDRAM:

- chapter 7.2.1.3 contains info how to build the source image

If you have EVK board, you can also use pre-compiled image located in c:\nxp\MCUX_Provi_v3.1\bin\data\targets\MIMXRT1050\source_images\evkbimxrt1050_iled_blinky_SDRAM.s19

Here is how the configuration should look line in the tool:

marektrmac_0-1631696631575.png

Hope this helps

The offset cannot be directly changed in SEC tool. However the bootable image is created via the build script so you can manually modify it (not recommended unless you are an expert).

Regards,
Marek
0 Kudos
7,381 Views
arnisj
Contributor II

Hello, Marek!

If I do as you suggest, in generated file application code starts at 0x00001000 regardless SDRAM location is set to 0x80002000.

Look in image I attached. Is there a way to get application code start in image file at address 0x00002000 ?

0 Kudos
7,368 Views
marek-trmac
NXP Employee
NXP Employee

Hi Arnisj,

please mind, that location of the non XIP image in the bootable image does not match with the target address, where the image will be executed. ROM code will copy the image into target address.

So image can start at 0x1000 even SDRAM location is set to 0x80002000.

Regards,
Marek
0 Kudos
7,360 Views
arnisj
Contributor II

I fully do understand this.

The question is can I somehow change this 0x1000 location in image file? And if yes, then will Boot ROM of RT1050 know from which address in bootable image take application to copy to target memory?

0 Kudos
7,355 Views
marek-trmac
NXP Employee
NXP Employee

Hi Arnisj,

I'd recommend you to download "Flashloader i.MXRT1050" from nxp.com and read "doc\i.MX MCU Manufacturing User's Guide.pdf". You can find there details about BD file arguments.

As your use case is not supported by MCUX Secure Provisioning Tool, I cannot provide any expert answer.

 

Regards,
Marek
0 Kudos
7,348 Views
arnisj
Contributor II

I've read "i.MX MCU Manufacturing User's Guide.pdf" through and still did not get answer. Closes information I've found in "3.1. Bootable image layout in target flash device":

* XIP (Execute-In-Place) boot image ... "The boot device memory is identical to the destination memory."...

* Non-XIP boot image ... "The boot device memory is different from the destination memory." ...

But there is NOTHING anywhere about fixed 0x1000 application offset in non-XIP image file and whether this offset can be changed and how?

Also "initialLoadSize" changing in *.bd file does not affect application offset 0x1000 in image file.

Is it a problem to tell that Boot ROM expects for non-XIP image files application to reside at offset 0x1000? If this is true, then I need to rethink architecture of my secondary dual bootloader project. If this is not true, I want to understand how I can change that offset specifically for non-XIP image files.

0 Kudos
7,342 Views
marek-trmac
NXP Employee
NXP Employee

Hi Arnisj,

Secure Provisioning Tool is designed to support most common use cases. Currently the tool does not support bootloader and does not support manual configuration of the application offset. 

The additional use cases could be done by manual modification of the files, generated during build.

The additional use cases were not tested by MCUX Secure Provisioning Tool team, so I'm afraid we cannot answer your questions in this forum. You may consider to ask in different forum, because your question is not related to Secure Provisioning Tool, but it is related to functionality of the processor itself.

See also chapter 8.7.1 in i.MX RT1050 Processor Reference Manual:

The location of the IVT is the only fixed requirement by the ROM.

 

Regards,
Marek
0 Kudos