MCUBoot Scratch possibility in EEPROM

Hello David,

Thanks for reaching out Renesas Engineering Community.

As far I can understand you are facing issues with the fact that the image size is too large, and when trying to build the bootloader project you get an overflow error? Could you please send me the project to check?

Regarding your question if it is possible to put the scratch area space into the external memory and not into the code flash memory.

Generally the scratch are is an area that according to the MCUboot bootloader documentation needs to be reserved when the selected upgrade mode is swap. The reason is that you must reserve some space during the swap of the two image applications, so that if for some reason while swapping the images the MCU powers off (for example), there is an area that keeps the part of the image that has not been swapped due to the power-off. So we could say that it is a back up area for making reliable swap.

So theoretically yes you could reserve this scratch area into an external flash if you want to. However after taking a look in the code for the implementation of the mcuboot bootloader that has been ported into the FSP the scratch area is reserved inside the internal code flash memory by default.

So you have two options:

1. To edit the code of the mcuboot so that the scratch area will be reserved into the external memory.

2. Select an other mode like overwrite for example, but in this case you will loose the initial primary image that has been overwritten by the image stored in the external memory.

Please also check the application note we provide for booting and swapping the  encrypted image from QSPI memory.

This picture here is a general overview of how it works:

Booting Encrypted Image using MCUboot and QSPI – Application Project

Best Regards,

IK

My main objective is to maximize the space of my application, since it will be a large project and i don't want to get space problems in the middle future.
My first intention was using tinycrypt (thats why I asked you to encrypt with it) because it has a lower size of usage flash, but no way to make encrypted images with mcuboot.

The second one is to share mbedTLS crypto functions between bootloader and main application, because my application has this mbedTLS crypto and have it two times is a waste of flash size.

I can not find how to map the initial point of image 2. If using QSPI, will be always 0x6000000? If yes, I can reverse my idea and put image 2 at the beginning of the EEPROM and the stuff of my application in the second half.

At this moment, i'm trying the configuration of the overwrite mode, and when it will work, i will try to switch to swap with scratch space in external EEPROM.
I'm facing this error at signing process:

Error: Image size (0x8001754) + trailer (0x180) exceeds requested size 0xe8000.

Why imgtool thinks my application has the size of 0x8001754 if my application has only about 170Kb? I can not find any info about this. Can you help me?
Thanks.

Just post if somebody has the same issue like me.

The script to sign the binary file, makes a first binary file extracted from the elf file. My mistake was that I made some initialization at dataflash, as a default parameters. This makes a binary file that tries to write at positions of dataflash.

After remove the initialization file from compilation, the temporary file has a reasonable size and the script makes a signed file.

At this moment, bootloader still doesn't work. Now, I have issues with E2Studio that doesn't sync correctly adresses of these 2 images (bootloader and application). Replying the steps in a new blank project works correctly, but in my application no. I found that the order of images/symbols added at debug configuration makes some changes, but non working correctly.

Hello David,

Since you have some memory restrictions and you would like to reserve more space for your application then you could develop the bootloader without signature if you would like to. This is a very common option in devices that have restricted memory.

Regarding the issues you are facing in your application would it be possible to share it with me to check it?

If you prefer you can also share the project with me via private message.

Thank you.

Best Regards,

IK

Hello,

I solved the sync issue. My problem was that i made a custom script of linker file, because i want my dataflash with some "partitions" and make diferent sections to write in it.

To have a better readability of the adresses, I copied all the content of the file "memory_regions.ld" and put it in the fsp.ld file. And remove the include of memory_regions file.

At the moment to put the bootloader, this memory_regions file changes, but this was not updated in my fsp.ld. This makes a cross addresses from bootloader and my aplication. No warning or error, just see it's all wrong when debugging.

Now i will start reconfiguring the signing and encryption of image that I think is important to have, and make QSPI to work for the image 2. I hope to not have any problem. Not sure if i will try to modify MCUboot to make scratch area in EEPROM.

About restricted memory, is not about restriction, is about no waste space that you will need in a year. My bootloader can be slowly, inefficient and ugly, but is no updatable like my application, so I need to be with minimal size and full secure.

Thanks for the Help.

David.

Hello David,

Please check my private message.

Regards,

IK

Hello David,

Please check my private message.

Regards,

IK