RA6M5 MCUBoot Linker Issue

Hello,

So I've been using the following examples:

https://www.renesas.cn/cn/zh/document/apn/booting-encrypted-image-using-mcuboot-and-qspi-application-project

https://www.renesas.com/us/en/document/apn/ra6-basic-secure-bootloader-using-mcuboot-and-internal-code-flash

to make a MCUBoot application. Everything compiles and runs fine until I try to include the boot_set_confirmed function. If I include a call to this function in my application code then I get a bunch of linker errors all related to gp_mcuboot_xspi_instance being undefined:

In my application configuration I have the MCUboot Image Utilities stack.

I have imported this following project as well and have gotten it to compile just fine after updating it to FSP 5.4, and I based my project off of it so I'm not sure what I'm doing wrong

https://en.na4.teamsupport.com/knowledgeBase/20773940

Thanks in advance for any help.

Parents
  • To impliment qspi flash boot project your using wrong stack you should use this stack attached in the image 

    Regards

    Gaurav N

  • As I understand it, that is the stack for the bootloader program. Which I have set up and working. And it boots my user application just fine. However, I'd like the application to "confirm" that the image is good. Then are you supposed to use the MCUBoot Image Utilities stack in the user application in order to call boot_set_confirmed and the like?

  • Hey Nick,

    Yes, in your case, after the bootloader has successfully booted the user application, the application should confirm that the image is good. This is typically done using the MCUBoot Image Utilities stack in the application. The function boot_set_confirmed() is used to mark the image as confirmed, ensuring that the bootloader doesn't roll back to a previous version during the next boot.

    Regards,

    GN_Renesas

  • The problem is though, while using the MCUBoot Image Utilities stack in the main application, if I try to call boot_set confirmed in the main application then I get the aforementioned loader issues. All these loader errors show up:

    If I don't call boot_set_confirmed then I don't get the loader errors.

  • Hii Nick,

    You need to call only one function quick setup the boot_set_confirmed function will be automatically called 

    Regards,

    Gaurav N

  • Nick, did you solve this yet?   I faced something similar and here's what I did>

    Do a global search for (in you case)  gp_mcuboot_xspi_instance, but for me it was gp_mcuboot_qspi_instance.

    In my bootloader project, I found it here, in Hal data.  It looks like an alias (so the name of the qspi can be anything) and the application can have access to it (though it is not used by the confirmation)

    Then, in my application, I instanced a QSPI and named it this alias name.

    Also, use --pad  in your boot loader.  Assuming you want fallback (in case the ap does not confirm) do not call boot_set_pending in the boot loader.  I found that it created a situation where ie would swap every time it was reset, whether the ap had confirmed itself or not.

    Hope this helps.

    Dale.

  • I appreciate your suggestions Dale, however they do not seem to work for me.

    Is there perhaps some good way to point the main application's linker program to the bootloader's hal_data file to appease the linker? I've tried referencing it in the main application's linker settings, which makes the undefined reference errors go away, but then I end up getting multiple definition errors for the qspi and gp_mcuboot_flash.

Reply
  • I appreciate your suggestions Dale, however they do not seem to work for me.

    Is there perhaps some good way to point the main application's linker program to the bootloader's hal_data file to appease the linker? I've tried referencing it in the main application's linker settings, which makes the undefined reference errors go away, but then I end up getting multiple definition errors for the qspi and gp_mcuboot_flash.

Children
  • Hii Nick,

    Please refer to the attached example project and documentation its the modified version of document and project for proper understanding .

    7178.MCUBOOT.zipLab Guide .docxMCUBOOT 1.pptx

  • Hi Nick.  When I upgraded FSP 5.5.0 I ran into this same issue.  I fixed it by adding these lines of code in hal_entry.c at the very top.

    qspi_instance_ctrl_t * const gp_mcuboot_qspi_ctrl = &g_qspi0_ctrl;

    spi_flash_cfg_t const * const gp_mcuboot_qspi_cfg = &g_qspi0_cfg;

    spi_flash_instance_t const * const gp_mcuboot_qspi_instance = &g_qspi0;

    And naming the QSPI instance g_qspi0 (or whatever it is name in the bootloader project)

    I attached a simple project that checks to see if it has already confirmed itself.

    And allows a user to confirm (or neglect to) for testing purposes.

    using --pad in the bootloader project.

    image_that_confirms_itself.zip

  • Thank you, Dale, this solved the problem I was having. This must be a FSP 5.5 issue.

    I'm running ThreadX but was able to just add the following lines of code to the hal_entry.c file and everything seems to be working as intended now.

    qspi_instance_ctrl_t * const gp_mcuboot_qspi_ctrl = &g_qspi_ctrl;
    spi_flash_cfg_t const * const gp_mcuboot_qspi_cfg = &g_qspi_cfg;
    spi_flash_instance_t const * const gp_mcuboot_qspi_instance = &g_qspi;
    spi_flash_instance_t const * const gp_mcuboot_xspi_instance = gp_mcuboot_qspi_instance;
    
    /*******************************************************************************************************************//**
     * main() is generated by the RA Configuration editor and is used to generate threads if an RTOS is used.  This function
     * is called by main() when no RTOS is used.
     **********************************************************************************************************************/
    void hal_entry(void)
    {
        /* TODO: add your own code here */
    
    #if BSP_TZ_SECURE_BUILD
        /* Enter non-secure code */
        R_BSP_NonSecureEnter();
    #endif
    }