Where can I get "image_generate.exe" tool mentioned in AN12604 Implement second bootloader...

cancel
Showing results for 
Search instead for 
Did you mean: 

Where can I get "image_generate.exe" tool mentioned in AN12604 Implement second bootloader...

Jump to solution
326 Views
audio_guy
Contributor III

Where can I get "image_generate.exe" tool mentioned in AN12604 Implement second bootloader on i.MXRT 10xx series". It's not in the AN12604SW.zip package. I'm implementing a second bootloader for our i.MXRT 1015 board. 

 

Thanks

Peter

 

Labels (1)
0 Kudos
1 Solution
272 Views
audio_guy
Contributor III

Thanks for your help. I'll keep your uTasker solution in mind before I start our next project. In the mean time I found the "image_generate.exe" tool in the AN12604SW.zip file linked under the i.MXRT 1050 documents. I'm going to give this a try.

Peter

View solution in original post

0 Kudos
7 Replies
273 Views
audio_guy
Contributor III

Thanks for your help. I'll keep your uTasker solution in mind before I start our next project. In the mean time I found the "image_generate.exe" tool in the AN12604SW.zip file linked under the i.MXRT 1050 documents. I'm going to give this a try.

Peter

View solution in original post

0 Kudos
270 Views
mjbcswitzerland
Specialist V

OK

I also added this new video showing some more details of security and how it can be completely verified:

https://youtu.be/o7hQbOqhJoc

Regards

Mark

 

0 Kudos
322 Views
mjbcswitzerland
Specialist V

Hi

If you have difficulties there is an off-the-shelf loader for the 1015 with UART, Modbus, USB, SD card, Memory Stick secondary loading, OTA support, XiP BEE On-the-Fly and AES256 from internal RAM (clone and IP protected).

- i.MX RT 1015: https://www.utasker.com/iMX/RT1015.html
- Boot loader concept including XiP on-the-fly decryption, clone protection or AES256 protected RAM execution.
-- Boot Loader concept flow chart: https://www.utasker.com/docs/iMX/Loader.pdf and usage reference https://www.utasker.com/docs/iMX/uTaskerLoader_TestDrive.pdf
-- Serial Loader features: https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf
-- Building the loader with MCUXpress: https://www.utasker.com/docs/iMX/MCUXpresso.pdf (and video guide https://youtu.be/p_eUGo6GypY )
-- Building the loader with IAR: https://www.utasker.com/docs/iMX/IAR.pdf (and video guide https://youtu.be/XPCwVndP99s )
-- Building the loader with VisualStudio and GCC: https://www.utasker.com/docs/iMX/GCC.pdf (and video guide https://youtu.be/0UzLLSXABK8 )
----https://www.youtube.com/watch?v=5iT7KP691ls How to make any application up-loadable and run from encrypted XiP in 5 minutes
----https://www.youtube.com/watch?v=fnfLQ-nbscI How to make any application (that fits) up-loadable and run optimally in zero wait state ITC in 7 minutes

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

 

0 Kudos
317 Views
audio_guy
Contributor III

Unfortunately we cannot go in this direction. In our case we have many legacy products with various uC that use proprietary methods (i.e. pc and mobile applications) to store application images in SPI FLASH. In this case the bootloader needs to transfer an image from a 2nd FlexSPI FLASH to the first one and jump to the application. We cannot support a kboot type interface to load an application image into FLASH without a lot of changes in these applications. In this case the product will support firmware updates over Bluetooth and USB. 

 

Peter

 

0 Kudos
311 Views
mjbcswitzerland
Specialist V

Hi

If I understand correctly you don't need a serial loader but a boot loader that support OTA transfers to an intermediate storage location in SPi flash.
That is, just the part in the flow diagram shown below.

mjbcswitzerland_0-1602182495714.png


The loader supports this for updating the application (copying from an area in the same SPI flash or a different SPI flash on FlexSPI or LPSPI) or updating the loader itself. Typically new images are transferred over Ethernet, Bluetooth, 4G modem, RF links, etc. whereby it is the application that actually performs the transfer/save and then the loader that subsequently handles fail-safe uploading and security.
This is also explained in https://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf which has been used since 2005 on Coldfires, Kinetis (and various others) and now i.MX RT.
Plus a guide to using the serial loader to update itself if needed: https://www.utasker.com/docs/uTasker/uTaskerSerialLoaderUpdater.pdf using the OTA method.
There is in addition a video explaining the basic OTA part (on a Kinetis) https://www.youtube.com/watch?v=lm3M-ZlaFLQ&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=17 and how its operation can be simulated to check all settings.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

 

0 Kudos
296 Views
audio_guy
Contributor III

I already have a bootloader as in the highlighted diagram above that works with unencrypted code. I want to add encrypted XIP support. I had planned to add support for this using BEE by using the jump_to_application() function of AN12604SW. I need the "image_generate.exe" to prepare the image. Apparently uTasker has similar tools to prepare an image for use by your Bare-Minimum Loader. 

 

Peter

0 Kudos
290 Views
mjbcswitzerland
Specialist V

HI

Yes, uTasker tools are compatible and integrated into a single one so that the process is easier:
https://www.utasker.com/forum/index.php?topic=1445.0

However I have never actually tried it with the "standard" NXP BEE method directly because that involves programming a known AES128 key to the eFUSE area that can't be modified. I developed an alternative methods that is compatible for BEE and OTFAD that uses a secret AES128 key (unique to and known only to the specific processor's encryption unit) and use that to encrypt the project's AES256/128 keys to QSPI flash that only that single processor can decrypt (clone and bit manipulation proection) which allows the same board to be used in completely different projects with different keys too if ever needed. In addition the method is identical for devices (from a users standpoint) for i.MX RT parts with BEE or i.MX RT parts with OTFAD, so there is no double-learning curve and different tools as is otherwise needed when using both. [Also there is a risk in using the eFUSE AES128 key directly for XiP OTF because if something goes wrong when programming and an incorrect key is programmed - or simply somehow lost - the board/or batch of boards become scrap since it becomes impossible to load code that will work on them......]

I needed to reverse engineer the original methods since NXP don't give documentation (although similar older devices documentation using similar techniques tend to give away just enough secrets to crack it in a fairly short time) - in order to develop the utilities and also the solution - I can however fully simulate the operation of the OTFAD and BEE and OTF decryption to product identical results on real HW and in the simulation environment.

I expect the uTasker utilities can be used to generate on-the-fly encrypted code if used appropriately.

In any case I believe I know the full working to the smallest detail and can can thus solve any related problems if needed.

Regards

Mark

 

0 Kudos