AM2432: How to boot another appimage from RAM

Hello,

It should be possible to let your appimage act as a bootloader for another appimage. You only need to use the bootloader driver APIs to parse the appimage, load the appimage, and self-reset the core to pass the execution control to the loaded appimage.

You may not need the first three steps you mention for SBL as they are specific to the SBL (second bootloader) only.

Regards,

Prashant

Hi Prashant,

Thank you for your reply.

I attempted to boot a second appimage from RAM as instructed. But failed on authentication. By debugging, it shows calling hierarchy as:

1) failed on Bootloader_parseMultiCoreAppImage();
2) failed on Bootloader_verifyMulticoreImage() in bootloader.c;
3) failed on Bootloader_socAuthImage() in bootloader.c;
4) failed on Sciclient_procBootAuthAndStart() in bootloader_soc.c;
5) successful on Sciclient_service() in sciclient_procboot.c, but the flags are not valid;

    retVal = Sciclient_service(&reqParam, &respParam);
    if((retVal != SystemP_SUCCESS) ||
        ((respParam.flags & TISCI_MSG_FLAG_ACK) != TISCI_MSG_FLAG_ACK))
    {
        retVal = SystemP_FAILURE;
    }
    return retVal;

The second appimage is in DDR. I tried to duplicate the 0x676 bytes authentication data to MSRAM and pass the duplicated data to code. Still got the same error on authentication.

Any ideas on how to do further debug?

Regards,

James

Hi James,

I see. I think this is not as straightforward to implement. That issue is actually expected because of the call Bootloader_socSecHandover done as part of the self-reset sequence from SBL to Application.

As a successful result of this call, the SYSFW relinquishes the Security services & so the TISCI_MSG_PROC_AUTH_BOOT message, which is used for authenticating an image, fails when called from the application.

You may skip the authentication with the following check in the Sysconfig assuming you added Bootloader instances in the application's Sysconfig to overcome the failure and move forward.

Regards,

Prashant

Hi Prashant,

I've tried skipping the authentication with the check in the Sysconfig.

And I could pass through the Bootloader_parseMultiCoreAppImage(). But stuck on Bootloader_loadSelfCpu().

By debugging, see the calling hierarchy:

1) couldn't step over Bootloader_loadSelfCpu().
2) couldn't step over Bootloader_rprcImageLoad() in Bootloader_loadSelfCpu() in bootloader.c, line 197.
3) couldn't step over config->fxns->imgSeekFxn() in Bootloader_rprcImageLoad() in bootloader.c, line 287.
But able to step into config->fxns->imgSeekFxn() and get return successfully in next debug cycle attempt.

Then in next debug cycle attempt, after stepping into config->fxns->imgSeekFxn(),
4) couldn't step over config->fxns->imgReadFxn() in Bootloader_rprcImageLoad() in bootloader.c, line 288.
5) couldn't step over memcpy() in Mem_imgRead() in in bootloader_mem.c, line 67.

Any idea on how to debug further?

Regards,

James

Hi James,

For the memory bootloader instance, you will need to set the "memArgsAppImageBaseAddr" field of Bootloader_Params structure to the base address of the array holding the appimage.

Please refer to the SBL_UART's main.c file which also receives the image in RAM & boots it from the same.

Once this field is set, the "appImageBaseAddr" field of the Bootloader_MemArgs will be initialized with the "memArgsAppImageBaseAddr" field during the Bootloader_open.

Regards,

Prashant

Hi James,

I understand the previous reply may not be relevant. If you are not initializing the "memArgsAppImageBaseAddr" then it will have the initialized value of BOOTLOADER_INVALID_ID in which case the "appImageBaseAddr" will not be overwritten.

Also, if you are past the Bootloader_parseMultiCoreAppImage step then there is no problem with the initialization of the different bootloader arguments.

Let me try this out once myself and get back to you.

Regards,

Prashant

Hi James,

I have tested this successfully!!

Following is the test function which is integrated in the R5FSS0-0 Hello World application to load & boot another appimage from the memory.

#include "appimage_hs_fs.h"
uint8_t gAppimageBuf[APPIMAGE_HS_FS_SIZE_IN_BYTES] __attribute__((section(".data.buf"))) = APPIMAGE_HS_FS;

void test_func() {
    DebugP_log("/* Begin testing */\r\n");

    int32_t status = SystemP_FAILURE;

    Bootloader_BootImageInfo bootImageInfo;
    Bootloader_Params bootParams;
    Bootloader_Handle bootHandle;

    Bootloader_Params_init(&bootParams);
    Bootloader_BootImageInfo_init(&bootImageInfo);

    bootParams.memArgsAppImageBaseAddr = (uintptr_t)gAppimageBuf;

    bootHandle = Bootloader_open(CONFIG_BOOTLOADER0, &bootParams);
    DebugP_assert(bootHandle != NULL);

    status = Bootloader_parseMultiCoreAppImage(bootHandle, &bootImageInfo);

    if(status != SystemP_SUCCESS) {
        DebugP_log("Failed to parse appimage\r\n");
    } else {
        DebugP_log("Appimage parsed successfully!\r\n");
    }

    bootImageInfo.cpuInfo[CSL_CORE_ID_R5FSS0_0].clkHz = Bootloader_socCpuGetClkDefault(CSL_CORE_ID_R5FSS0_0);
    status = Bootloader_loadSelfCpu(bootHandle, &bootImageInfo.cpuInfo[CSL_CORE_ID_R5FSS0_0], FALSE);

    if(status == SystemP_SUCCESS) {
        DebugP_log("Application loaded successfully!!!\r\n");
    } else {
        DebugP_log("Application load failed...\r\n");
    }

    status = Bootloader_runSelfCpu(bootHandle, &bootImageInfo);

    DebugP_log("/* End testing */\r\n");
}

The second appimage is R5FSS0-0 GPIO_LED_BLINK application & here are the successful boot logs.

[19:17:02.743] Starting NULL Bootloader ...

[19:17:02.747] DMSC Firmware Version 9.2.8--v09.02.08 (Kool Koala)
[19:17:02.751] DMSC Firmware revision 0x9
[19:17:02.754] DMSC ABI revision 3.1

[19:17:02.756] INFO: Bootloader_runCpu:155: CPU r5f1-0  is initialized to 800000000 Hz !!!
[19:17:02.761] INFO: Bootloader_runCpu:155: CPU r5f1-1 is initialized to 800000000 Hz !!!
[19:17:02.769] INFO: Bootloader_runCpu:155: CPU m4f0-0 is initialized to 400000000 Hz !!!
[19:17:02.778] INFO: Bootloader_runCpu:155: CPU a530-0 is initialized to 800000000 Hz !!!
[19:17:02.786] INFO: Bootloader_runCpu:155: CPU a530-1 is initialized to 800000000 Hz !!!
[19:17:02.794] INFO: Bootloader_loadSelfCpu:207: CPU r5f0-0 is initialized to 800000000 Hz !!!
[19:17:02.806] INFO: Bootloader_loadSelfCpu:207: CPU r5f0-1 is initialized to 800000000 Hz !!!
[19:17:02.809] INFO: Bootloader_runSelfCpu:217: All done, reseting self ...

[19:17:15.800] /* Begin testing */
[19:17:15.966] Appimage parsed successfully!
[19:17:16.128] Application loaded successfully!!!
[19:17:16.343] GPIO LED Blink Test Started ...
[19:17:16.343] LED will Blink for 10 seconds ...
[19:17:26.344] GPIO LED Blink Test Passed!!
[19:17:26.347] All tests have passed!!

Please note I modified GPIO_LED_BLINK to use 4th Bank instead of the default 3rd Bank since Hello World would already be running from the 3rd Bank. So, have you made sure the second appimage loadable sections addresses do not conflict with the address space used by the appimage acting as a bootloader?

Regards,

Prashant

Hi Prashant,

Your test_func is very straight forward and clear.

I've made a double check on the aspects you reminded:
1. make sure the appImageBaseAddr is pointing to the right location of the loaded second appimage.

In my code, the absolute address of the second appimage buffer was figured out through a pre-debug procedure and filled in the mem bootloader settings in syscfg.

I understand this is not the formal way and I will need to refactor it to the similar way as in your test code. But it worked for debug. So in my code, even though the memArgsAppImageBaseAddr kept as BOOTLOADER_INVALID_ID, but the appImageBaseAddr in gBootloaderConfig[0] was already with the correct value. And this made the Bootloader_parseMultiCoreAppImage() happy.

2. make sure the 2nd appimage uses a different MSRAM bank from the il3_boot.

In my linker.cmd file, the il3_boot is using bank7, and only using one forth of bank7, most of it is using DDR. bank3 to bank6 are free for 2nd appimage. So there should not be a conflict on the bank usage.

Unfortunately, the issue is still sticking on the Bootloader_loadSelfCpu(). I tried to load the default hello world as the second appimage, also tried to integrate your test_func instead, no difference.

Do you have any further suggestions on narrowing down the issue?

On the other hand, I have two minor questions on your test_func and debug logs.

1).  How did you load the GPIO_LED_BLINK appimage into gAppimageBuf by debug tool?
Currently, I am relying on the integrated features of TFTP and Telnet to load a 2nd appimage from TFTP server. If I know the way of loading 2nd appimage into RAM via debug tool, then I can try to comment out some code from my project, ex. the TFTP, the Telnet, and so on to narrow down the issue.

2). The line 14 in your debug logs, "INFO: Bootloader_runSelfCpu:217: All done, reseting self ..." is from the SBL when calling "Bootloader_runSelfCpu". Should there be a similar print between line 18 and 19 from the test_func when calling "Bootloader_runSelfCpu"? Why it is missed from your debug logs?

Looking forward to hearing from you.

Regards,

James

Hi James,

1) I integrated the GPIO_LED_BLINK appimage as an array of bytes (gAppimageBuf) into the Hello World example itself. So, when I am loading the Hello World, the BLINK appimage is automatically loaded at the address assigned to gAppimageBuf.

Following are steps I have that builds the BLINK appimage & converts it to a header file for it to be included as an array of bytes in the Hello World example.

make -s -C examples/drivers/gpio/gpio_led_blink/am64x-sk/r5fss0-0_nortos/ti-arm-clang PROFILE=debug scrub all

python3 tools/bin2c/bin2c.py \
    examples/drivers/gpio/gpio_led_blink/am64x-sk/r5fss0-0_nortos/ti-arm-clang/gpio_led_blink.debug.appimage.hs_fs \
    examples/hello_world/appimage_hs_fs.h \
    APPIMAGE_HS_FS

make -s -C examples/hello_world/am64x-sk/r5fss0-0_nortos/ti-arm-clang PROFILE=debug scrub all

2) That log has a "INFO:" prefix at the start which means it is printed with the DebugP_logInfo macro. This macro outputs the log only if the INFO logging is enabled in the Sysconfig. It is enabled in the SBL NULL's Sysconfig but not in Hello World's Sysconfig & so there is no such from the call Bootloader_runSelfCpu in the context of the Hello World.

---------------------

Coming to the issue, can you try changing the buffer address from 0x89923458 to a more aligned address, let's say, 0x89920000 to avoid any possible alignment issues?

Regards,

Prashant

Hi Prashant,

I couldn't even reproduce what have done on the EVM board. I could only pass the step of Bootloader_loadSelfCpu(). The logs from my EVM board are as:

Starting NULL Bootloader ...

DMSC Firmware Version 8.5.3--v08.05.03 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

INFO: Bootloader_runCpu:155: CPU r5f1-0  is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:155: CPU r5f1-1 is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:155: CPU m4f0-0 is initialized to 400000000 Hz !!!
INFO: Bootloader_loadSelfCpu:207: CPU r5f0-0 is initialized to 800000000 Hz !!!
INFO: Bootloader_loadSelfCpu:207: CPU r5f0-1 is initialized to 800000000 Hz !!!
INFO: Bootloader_runSelfCpu:217: All done, reseting self ...

Hello World!
/* Begin testing */
Appimage parsed successfully!
Application loaded successfully!!!

I am on top of mcu_plus_sdk_am243x_08_06_00_45. I practiced the demo code on EVM strictly:

1) Modified the LED_blink linker.cmd file from bank3 to bank4:

    MSRAM     : ORIGIN = 0x700C0000 , LENGTH = 0x40000

2) Compiled the LED_blink in debug mode. Got appimage of "gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage.hs_fs".

3) Converted it to appimage_hs_fs.h.

4) Copied appimage_hs_fs.h to sdk8.6\hello_world_am243x-evm_r5fss0-0_freertos_ti-arm-clang.

5) Modified the hello_world linker.cmd file. Added one more line:

    .data.filebuf : {} > MSRAM

6) Modified the hello_world syscfg. Added bootloader:

7) Modified the hello_world.c. Used 128 bytes aligment. Copied exact the same test_func as yours.

#include <drivers/bootloader.h>
#include "appimage_hs_fs.h"

/* GLOBAL VARIABLES */

uint8_t g_u8_appimage_buf[APPIMAGE_HS_FS_SIZE_IN_BYTES] __attribute__
((aligned(128), section(".data.filebuf"))) = APPIMAGE_HS_FS;

static void test_func(void);

void hello_world_main(void *args)
{
    /* Open drivers to open the UART driver for console */
    Drivers_open();
    Board_driversOpen();

    DebugP_log("Hello World!\r\n");
    test_func();

    Board_driversClose();
    Drivers_close();
}

static void test_func(void)
{
.....
}

8) Compiled the hello_world in debug mode. Debugged it on the EVM. Tried simply run all or step by step.

Please help to check if I was doing anything wrong or missing something?

Regards,

James

Hi James,

These steps look good & the exact of mine. I think the final piece you are missing is the following patch

diff --git a/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c b/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c
index a6f38f03..80b800ca 100644
--- a/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c
+++ b/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c
@@ -1001,7 +1001,7 @@ int32_t Bootloader_socCpuResetReleaseSelf(void)
         }
         if(status==SystemP_SUCCESS)
         {
-            status = Bootloader_socSecHandover();
+            /*status = Bootloader_socSecHandover();*/
         }
         if(status==SystemP_SUCCESS)
         {

This is needed because the SBL would have already requested the Security Handover when self-resetting to the application. If successful, the Security Handover cannot be requested again.

So, for now you may just skip the Security Handover call altogether & see if it starts working.

Sorry, I missed including this important diff earlier.

Regards,

Prashant

Hi Prashant,

With your latest fix on the sdk, the hello_world demo code is working properly on both the EVM board and my own board. The logs from my board are as:

Starting NULL Bootloader ... 

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

INFO: Bootloader_runSelfCpu:217: All done, reseting self ...

Hello World!
/* Begin testing */
Appimage parsed successfully!
Application loaded successfully!!!
/* End teGPIO LED Blink Test Started ...
LED will Blink for 10 seconds ...
GPIO LED Blink Test Passed!!
All tests have passed!!

My il3_boot project with integrating the test_func and LED_blink appimage is not working yet. And I need time to narrow down the issue.

I need your further clarification on:

1) Should this fix be treated as a workaround for when the appimage acting as a bootloader likes what in my case? The SBL and other appimage should still stick on the standard sdk?

Or

2) Can this fix be treated as a permanent fix for all projects, including the SBL, the appiamge acting as a bootloader and the general appimage?

3) Will you suggest the TI to provide a formal fix in future release of sdk?

Regards,

James

Hi Prashant,

I am having one more issue on running the demo code. It is running successfully under the CCS, debug loading. But not working under the OSPI, SBL loading. The logs stopped here after booting from OSPI:

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH 
[BOOTLOADER_PROFILE] Boot Media Clock : 166.667 MHz 
[BOOTLOADER_PROFILE] Boot Image Size  : 92 KB 
[BOOTLOADER_PROFILE] Cores present    : 
r5f0-0
[BOOTLOADER PROFILE] SYSFW init                       :      12022us 
[BOOTLOADER PROFILE] System_init                      :      29252us 
[BOOTLOADER PROFILE] Drivers_open                     :        273us 
[BOOTLOADER PROFILE] Board_driversOpen                :      22083us 
[BOOTLOADER PROFILE] Sciclient Get Version            :      10025us 
[BOOTLOADER PROFILE] CPU load                         :     145724us 
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     219385us 

Image loading done, switching to application ...
Hello World!
/* Begin testing */
Appimage parsed successfully!
Applicat

To isolate the issue, I didn't use my own hardware and not touch my own project. I was completely on top of the EVM board and the modified hello_world and LED_blink examples code.

Do you know what can cause the different behaviors between the CCS loading and the SBL loading? Are you able to try flashing on your side?

Regards,

James

Hi James,

I haven't tried this yet with SBL OSPI but I do not think this should behave any different with SBL OSPI than CCS.

The issue maybe because of the UART corruption. Are you seeing the issue randomly or everytime on multiple PORs? If the UART is configured in Interrupt Mode in Hello World application, can you configure it to Polling mode through Sysconfig & see if the issue still occurs.

Regards,

Prashant