Plugin Image on imxrt1050

[diogocacador]

Hello,

I'm having trouble running a Plugin Image on imxrt1050. I've created a small program which I can run in XIP mode, however when I set the PLUGIN_FLAG macro to 1 in "fsl_flexspi_nor_boot.h" file it fails to boot.

Why would this fail?

Regards,

Diogo

[kerryzhou]

Hi Diogo Cacador,

    If you just want to run the small program, you can use the normal ROM boot directly.

   There are two types of i.MX MCU bootable image:
• Normal boot image: This type of image can boot directly by boot ROM.
• Plugin boot image: This type of image can be used to load a boot image from devices that are not natively supported by boot ROM.

   Could you tell me why you need to use the plugin image? What the detail function you want to realize?

Have a great day,
Kerry

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

[diogocacador]

Thank you Kerry Zhou for the answer,

In summary I'd like to create a bootloader that is able to update an application image setup to run in Hyperflash in XIP mode.

In my understanding, if this bootloader where to be setup to run in XIP mode from the Hyperflash it would not be able to write a new application image into the Hyperflash.

Therefore I thought of running the bootloader from RAM, which would do some checks and overwrite the application image in hyperflash (if new image were available). Then the bootloader would return from main (as it is a plugin image) with the necessary information for the boot ROM to start the application image from hyperflash in XIP mode.

This is to enable over-the-air updates.

What's your thoughts?

Best regards,

Diogo

[Takashi_Kashiwagi]

Hi Diogo

I do not know what "plugin image" means, so sorry if I said strange things.

I think the following threads are useful.

[i.MX-RT mapping of functions in RAM (ITCM)] https://community.nxp.com/thread/484829

[non-xip example with MCUXpresso] https://community.nxp.com/thread/484714

> In my understanding, if this bootloader where to be setup to run in XIP mode from the Hyperflash it would not be able

> to write a new application image into the Hyperflash.

I think that there is almost right. (In Strictly, Flash ROM can be rewritten if the Flash rewrite function is set to RAM execution function with the __attribute__ macro. But This method requires attention as it is.)

> Therefore I thought of running the bootloader from RAM, which would do some checks and overwrite the application

> image in hyperflash (if new image were available).

I think it's a good idea. 

> Then the bootloader would return from main (as it is a plugin image) with the necessary information for the boot ROM

> to start the application image from FlashROM in XIP mode.

In my sample project, Jump to ResetISR of the read image simply as follows.

In my sample project, In order to avoid this problem, My BootLoader copies the application image from FlashROM to SDRAM and run it on SDRAM. And My sample project can update application image by BIN file in SD card.

https://github.com/tkashi-github/IMXRT1060-EVK

Best Regards,

T.Kashiwagi

[diogocacador]

Hello Takashi,

Thank you for the reply.

> I do not know what "plugin image" means, so sorry if I said strange things.

Bellow is a snippet of the Reference Manual for i.MXRT1050 regarding plugin images. I believe it essentially allows you to return from the "main" function of the application back into NXP's ROM Bootloader with the necessary information to boot an application again. It sounds like this would allow my own secondary bootloader to launch my application running in XIP mode from hyperflash instead of having to load it into RAM.

What do you think about this?

I'll have a look at your sample project as a backup plan to the "plugin image" scenario, because at the moment I don't have enough RAM to fit my application code as well as data requirements. That's why I'm really trying to find a way for the secondary bootloader (running from RAM) to launch the application, which would run from hyperflash in XIP mode.

Any thoughts on this?

Best regards,

Diogo

[Takashi_Kashiwagi · Accepted solution]

Hi Diogo

Thank you for responding.

> Bellow is a snippet of the Reference Manual for i.MXRT1050 regarding plugin images. I believe it essentially allows

> you to return from the "main" function of the application back into NXP's ROM Bootloader with the necessary

> information to boot an application again. It sounds like this would allow my own secondary bootloader to launch my

> application running in XIP mode from hyperflash instead of having to load it into RAM. 

> What do you think about this?

I think your understanding is correct. I found a sample code as follows.

https://github.com/ArtecDesign/imx-plugin/blob/master/plugin.c

According to the sample code, it seems that plugin_load_data determines the address to actually load.

> I'll have a look at your sample project as a backup plan to the "plugin image" scenario, because at the moment I don't > have enough RAM to fit my application code as well as data requirements. That's why I'm really trying to find a way for > the secondary bootloader (running from RAM) to launch the application, which would run from hyperflash in XIP mode.

> Any thoughts on this?

Although some modification is necessary, I think that you can do it. 

In my sample project,

• IMXRT1060-EVK_BOOT
  • This is a traditional second bootloader.
  • CheckROM(source/common/update.c) function copies the program from ROM to RAM and sets the PC to ResetISR in APL.
• IMXRT1060-EVK_APL
  • This is a sample application running on SDRAM (0x80000000-).

If you want to run the IMXRT1060_EVK_APL on FlashROM, Please modified CheckROM(in IMXRT1060-EVK_BOOT) and Linker script file(IMXRT1060-EVK_APL).

Best Regards,

T.Kashiwagi

[diogocacador]

Thank you Takashi,

The source file you pointed at helped solve may problem.

It comes down to the "Image Entry Function" address in the "image_vector_table" defined in file "fsl_flexspi_nor_boot.c" of sdk (usually in "xip" folder) being set to the address of the Vector Table instead of the entry function (usually "main").

By changing that and prototyping main function according to Plugin Image requirements the image now loads.

Hope this helps anyone else trying to use the plugin image mechanism.

Best regards,

Diogo 

[diogocacador]

Ps.: Also would be nice if the SDK is updated by NXP to correct this.

Regards,

Diogo