Guidelines for Bootloader Firmware with MCUBoot and External QSPI Flash

Hello,

Please check the below application note and sample code which is using the MCUboot module on EK-RA4M3 with external QSPI flash as the secondary image storage area.

https://www.renesas.com/en/document/apn/booting-encrypted-image-ra4-using-mcuboot-and-qspi-application-project

www.renesas.com/.../booting-encrypted-image-using-mcuboot-and-qspi-application-project

Thanks for your quick reply.

I had previously prepared the MCUBoot firmware for internal flash, and based on your guidelines, I have successfully added support for external QSPI flash. However, I'm unsure how to transition the boot process from internal to external flash, as I now need to boot from the external flash instead. Could you please assist me with this?

Regards,

Parth

For EK boards with QSPI flash on board, after booting, the QSPI device is typically place in XIP mode. MCU can read directly from it(memory mapped). That means you can jump into codes in qspi area and begin execution from there. This has not been tested with MCUboot. 

However if it is a Cortex-M33 (trustzone) device like RA4M3, code in QSPI cannot run in secure mode as the entire qspi area is considered non-secure area, So application (in primary/secondary slot) will have to be a non-secure application.

The jump from MCUboot to application is not using R_BSP_NonSecureEnter(), so more work needs to be done.

In short, Direct XIP only for internal flash.

Another issue is difference in performance when running from QSPI vs internal flash.

It is better to boot this image from internal code flash.

Isn't this the reference document for preparing a bootloader firmware to boot application code from external flash using QSPI?

https://www.renesas.com/en/document/apn/booting-encrypted-image-ra4-using-mcuboot-and-qspi-application-project

Yes but this is not using XIP upgrade mode to boot directly from QSPI. The image is loaded into internal code flash and is boot from there:

Is it possible to first store the firmware in QSPI memory using application code, and then have the bootloader copy it to internal flash and boot from there? The bootloader would simply copy the data from QSPI to internal flash and boot, as I am not looking to use XIP mode specifically.

If yes, could you please provide guidelines for achieving this bootloader firmware?

below is my current configuration of MCUBoot.

Yes, this is what the application note and sample code is about. Using QSPI as secondary image slot and booting from code flash/

You mentioned 'I now need to boot from the external flash instead.' so I assumed you were interested in XIP mode.

Got it, thanks for explaining everything in details.

I have followed these docs still not able to do so? sharing snaps of MCUBoot configs, could you please help me identify what i have missed here? I don't need encryption for now so i have kept it disabled.

Have you tried the provided sample project ? Does this work for your device ? Do you want to just disable encryption on the example project ?

Note that as mentioned on the app note:

The major use case for encrypted image update is for external flash update image storage. External flash content is prone to theft in many ways. It is critical to secure the external flash secondary image storage area via encryption.

I do not see anything wrong. If you use EK-RA4M3 and the on-board QSPI you should use the same QSPI settings an in the example project.

The MCUboot settings depend a lot on your application (for example upgrade method, image sizes etc).

I believe I may have identified the source of the issue. Here's a brief explanation, and I would appreciate your help in finding a solution. In Approach 1, the data readbacks are incorrect, while in Approach 2, everything works as expected. In Approach 1, I'm directly accessing the memory location, whereas in Approach 2, I’m using the QSPI API with commands. I need to resolve the issue with Approach 1 because the bootloader might be reading data this way (as per approach-1).

#define QSPI_DEVICE_START_ADDRESS    (0x60000000)

#define QSPI_FLASH_ADDRESS(page_no)     (uint8_t *) (QSPI_DEVICE_START_ADDRESS + (page_no * PAGE_WRITE_SIZE))

uint32_t address = (uint32_t)(QSPI_FLASH_ADDRESS(0));

Approach 1:

memcpy(write_buffer, (uint8_t *)(address), SIZE_64KB);
R_BSP_SoftwareDelay(500,1000);

Approach 2:

data[0] = 0x03; // Read command
data[1] = (address >> 16) & 0xFF;
data[2] = (address >> 8) & 0xFF;
data[3] = address & 0xFF;
data[4] = 0x00;
R_QSPI_DirectWrite(&g_qspi0_ctrl, data, 4, true);
R_QSPI_DirectRead(&g_qspi0_ctrl, (uint8_t *)write_buffer, SIZE_64KB); // Reading only 3 bytes
R_BSP_SoftwareDelay(500, BSP_DELAY_UNITS_MILLISECONDS);

Please assist me to resolve this issue with approach-1.

Regards,

Parth

I believe I may have identified the source of the issue. Here's a brief explanation, and I would appreciate your help in finding a solution. In Approach 1, the data readbacks are incorrect, while in Approach 2, everything works as expected. In Approach 1, I'm directly accessing the memory location, whereas in Approach 2, I’m using the QSPI API with commands. I need to resolve the issue with Approach 1 because the bootloader might be reading data this way (as per approach-1).

#define QSPI_DEVICE_START_ADDRESS    (0x60000000)

#define QSPI_FLASH_ADDRESS(page_no)     (uint8_t *) (QSPI_DEVICE_START_ADDRESS + (page_no * PAGE_WRITE_SIZE))

uint32_t address = (uint32_t)(QSPI_FLASH_ADDRESS(0));

Approach 1:

memcpy(write_buffer, (uint8_t *)(address), SIZE_64KB);
R_BSP_SoftwareDelay(500,1000);

Approach 2:

data[0] = 0x03; // Read command
data[1] = (address >> 16) & 0xFF;
data[2] = (address >> 8) & 0xFF;
data[3] = address & 0xFF;
data[4] = 0x00;
R_QSPI_DirectWrite(&g_qspi0_ctrl, data, 4, true);
R_QSPI_DirectRead(&g_qspi0_ctrl, (uint8_t *)write_buffer, SIZE_64KB); // Reading only 3 bytes
R_BSP_SoftwareDelay(500, BSP_DELAY_UNITS_MILLISECONDS);

Please assist me to resolve this issue with approach-1.

Regards,

Parth