[参考译文] AM2432：如何从 RAM 启动另一个 appimage

您好！

应该可以让您的 appimage 充当另一个 appimage 的引导加载程序。 只需使用引导加载程序驱动程序 API 来解析 appimage、加载 appimage 并自复位内核即可将执行控制传递到加载的 appimage。

您可能不需要提及 SBL 的前三个步骤、因为它们仅特定于 SBL (第二引导加载程序)。

此致、

Prashant

Prashant、您好！

感谢您的答复。

我尝试按照指示从 RAM 引导第二个 appimage。 但身份验证失败。 通过调试、它显示了调用层次结构、如下所示：

1) Bootloader_parseMultiCoreAppImage()失败;
2)在 bootloader.c;中的 Bootloader_verifyMulticoreImage()失败
3)引导加载程序.c 中的 Bootloader_socAuthImage()失败;
4)在 bootloader_soc.c 中的 Sciclient_procBootAuthAndStart()上失败；
5) 在 sciclient_procboot.c 中的 Sciclient_service()上成功、但这些标志无效；

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

 第二个 appimage 在 DDR 中。 我尝试将0x676字节的身份验证数据复制到 MSRAM、并将复制的数据传递到代码。 身份验证仍然遇到相同错误。

是否有关于如何进行进一步调试的想法？

此致、

James

尊敬的 James：

我明白了。 我认为实施起来并不简单。 实际上、预计会出现这个问题、这是由于从 SBL 到应用的自复位序列中完成了引导加载程序_socSec切 换调用。

由于该调用成功后、SYSFW 将放弃安全服务、因此用于验证映像的 TISCI_MSG_PROC_AUTH_BOOT 消息会在从应用程序调用时失败。

假设您已在应用程序的 SysConfig 中添加引导加载程序实例以克服故障并继续操作、则可以在 SysConfig 中进行以下检查、从而跳过身份验证。

此致、

Prashant

 Prashant、您好！

我已尝试通过检查 SysConfig 跳过身份验证。

我可以通过 Bootloader_parseMultiCoreAppImage ()。 但停留在 Bootloader_loadSelfCpu()上。

通过调试、请参阅调用 层次结构：

1)无法单步执行 Bootloader_loadSelfCpu()。
2)无法单步执行 bootloader.c 第197行 Bootloader_loadSelfCpu()中的 Bootloader_rprcImageLoad()。
3)无法单步执行 bootloader_rprcImageLoad()中的 config->Fxns->imgSeekFxn()、位于 bootloader.c 第287行。
但能够进入 CONFIG->Fxns->imgSeekFxn ()并在下一次调试周期尝试中成功返回。

然后在下一个调试周期尝试中、在进入 CONFIG->Fxns->imgSeekFxn ()之后、
4)无法单步执行 bootloader_rprcImageLoad()中的 config->Fxns->imgReadFxn()、位于 bootloader.c 第288行。
5)无法单步执行 bootloader_mem.c 第67行中 mem_imgRead ()中的 memcpy ()。

对如何进行进一步调试有什么想法吗？

此致、

James

尊敬的 James：

对于存储器引导加载程序实例、您需要将 Bootloader_Params 结构的"memArgsAppImageBaseAddr"字段设置为保存 appimage 的数组的基址。

请参阅 sbl_uart 的 main.c 文件、该文件也会在 RAM 中接收映像并使用相同的映像进行引导。

设置此字段后、 将在 Bootloader_open 期间使用"memArgsAppImageBaseAddr"字段初始化 Bootloader_Mem 387gs 的"appImageBaseAddr"字段。

此致、

Prashant

尊敬的 James：

我理解之前的回复可能不相关。 如果未初始化"memArgsAppImageBaseAddr"、则它将具有 bootloader_inVALID_ID 的初始化值、在这种情况下、"appImageBaseAddr"将不会被覆盖。

此外、如果已超过 Bootloader_parseMultiCoreAppImage 步骤、则不同引导加载程序参数的初始化没有问题。

让我自己尝试一次、然后回到你身边。

此致、

Prashant

尊敬的 James：

我已成功测试此功能！！

以下是集成在 R5FSS0-0 Hello World 应用中的测试函数、用于从存储器中加载和引导另一个 appimage。

#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");
}

第二个 appimage 是 R5FSS0-0 GPIO_LED_LINK 应用程序、这里是成功引导日志。

[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!!

请注意、我修改了 GPIO_LED_BLINK 以使用第4个组、而不是默认的第3个组、因为 Hello World 将已从第3个组运行。 所以、您是否已经确保第二个 appimage 可加载段地址不与用作引导加载程序的 appimage 所使用的地址空间相冲突？

此致、

Prashant

 Prashant、您好！

您的 test_func 非常简单明了。

我 对您提醒的方面进行了仔细检查：
1.确保 appImageBaseAddr 指向加载的第二个 appimage 的正确位置。

在我的代码中、 通过预调试过程计算出第二个 appimage 缓冲区的绝对地址、并填充 syscfg 中的 mem 引导加载程序设置。

我知道这不是正式的方式、我需要按照与您的测试代码类似的方式对其进行重构。 但它用于调试。 因此在我的代码中、即使 memArgsAppImageBaseAddr 保存为 bootloader_inVALID_ID、但 gBootloaderConfig[0]中的 appImageBaseAddr 已具有正确的值。 这使得 Bootloader_parseMultiCoreAppImage ()快乐。

2.确保第二个 appimage 使用与 iL3_boot 不同的 MSRAM 组。

在我的 linker.cmd 文件中、 iL3_boot 正在使用 bank7、并且只使用 bank7的四分之一、而它的大部分都使用 DDR。 bank3到 bank6是免费的第二附加图像。 因此不应在银行使用方面产生冲突。

不幸的是、问题仍然停留在 Bootloader_loadSelfCpu()上。 我尝试将默认的 hello world 加载为第二个 appimage、同时还尝试集成您的 test_func、没有区别。

对于缩小问题的范围、您还有什么其他建议吗？

另一方面、我在 test_func 和调试日志中有两个小问题。

1)。  您如何  通过调试工具将 GPIO_LED_BLINK 应用映像加载到 gAppimageBuf 中？
目前、我依靠 TFTP 和 Telnet 的集成功能从 TFTP 服务器加载第二个 appimage。 如果我知道通过调试工具将第二个 appimage 加载到 RAM 中的方法、那么我可以尝试注释掉我项目中的一些代码、例如 TFTP、Telnet 等、以缩小问题范围。

2)。 调试日志中的第14行"info：bootloader_runSelfCpu：217：all done、reseting self..."来自调用"Bootloader_runSelfCpu"时的 SBL。  调用"Bootloader_runSelfCpu"时、test_func 的第18行和19行是否应该有类似的打印 内容？ 为什么从调试日志中遗漏了该内容？

期待收到您的回复。

此致、

James

尊敬的 James：

1) 1)我将 GPIO_LED_BLINK appimage 作为字节数组(gAppimageBuf)集成到 Hello World 示例本身中。 因此、当我加载 Hello World 时、闪烁 appimage 在分配给 gAppimageBuf 的地址自动加载。

以下是构建 bLINK appimage 并将其转换为头文件、以便它以字节数组包含在 Hello World 示例中。

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)该日志的开头有"info："前缀、这意味着使用 DebugP_logInfo 宏来打印。 仅当在 SysConfig 中启用了信息日志记录时、此宏才会输出日志。 它在 SBL NULL 的 SysConfig 中启用、但在 Hello World 的 SysConfig 中未启用、因此 在 Hello World 上下文中调用 Bootloader_runSelfCpu 中不存在此类情况。

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

现在出现问题、您是否可以尝试将缓冲区地址从0x89923458更改为更对齐的地址(例如0x89920000)来避免任何可能的对齐问题？

此致、

Prashant

 Prashant、您好！

我甚至无法再现 EVM 板上完成的工作。 我只能 传递 Bootloader_loadSelfCpu()的步骤。 我的 EVM 板上的日志为：

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!!!

我目前使用的是 mcu_plus_sdk_am243x_08_06_00_45。 我 在 EVM 上严格实践了演示代码：

1)将 LED_BLINK linker.cmd 文件从 bank3修改为 bank4：

    MSRAM     : ORIGIN = 0x700C0000 , LENGTH = 0x40000

2) 2)在调试模式下编译了 LED_BLINK。 获得了"gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage.hs_fs"的 appimage。

3) 3)将其转换为 appimage_hs_fs.h

4) 4)将 appimage_hs_fs.h 复制到 sdk8.6\hello_world_am243x-evm_r5fss0-0_freertos_ti-arm-clang。

5) 5)修改了 hello_world linker.cmd 文件。 添加了另外一行：

    .data.filebuf : {} > MSRAM

6) 6)修改了 hello_world syscfg。 添加了引导加载程序：

7) 7)修改了 hello_world.c. 使用了128字节配置。 复制的 test_func 与您的一样。

#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) 在调试模式下编译了 hello_world。 进行了重新调试。 已尝试简单地运行全部或一步一步。

请帮助检查我的操作是否有问题或缺失？

此致、

James

尊敬的 James：

这些步骤看起来 很好、并且准确地反映了我的情况。 我认为您缺少的最后一个部分是以下补丁

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)
         {

这是必要的、这是因为当自我复位到应用程序时、SBL 已经请求了安全移交。 如果成功、安全移交将不能被再次请求。

所以、现在你可以完全跳过安全切换呼叫、看看它是否开始工作。

对不起、我之前漏掉了这项重要的差异。

此致、

Prashant

 Prashant、您好！

使用您在 SDK 中修复的最新问题、hello_world 演示代码可以在 EVM 板和我自己的板上正常运行。 我的板上的日志为：

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!!

我用于集成 test_func 和 LED_bLINK appimage 的 iL3_boot 项目尚未正常工作。 我需要时间来缩小问题的范围。

我需要您进一步澄清：

1) 1)当 作为引导加载程序的 appimage 喜欢我的情况时、此修复是否应视为权变措施？ SBL 和其他 appimage 仍然应该停留在标准 SDK 上？

或者

2) 2)此修复是否可以视为所有工程的永久修复、包括 SBL、用作 引导加载程序的应用程序 和通用应用程序映像？

3) 3)您是否会建议 TI 在 SDK 的未来版本中提供正式修复？

此致、

James

 Prashant、您好！

我在运行演示代码时又遇到一个问题。 它在 CCS 调试加载下成功运行。 但在 OSPI 和 SBL 负载下无法正常工作。 从 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

为了找到问题所在、我没有使用我自己的硬件、也没有接触我自己的项目。 我完全站在 EVM 板顶部、并看到修改后的 hello_world 和 LED_bLINK 示例代码。

您是否知道什么可能导致 CCS 加载和 SBL 加载之间出现不同行为？ 您是否能够尝试在自己的身边闪烁？

此致、

James

尊敬的 James：

我还没有尝试 SBL OSPI、但我认为它的行为与 SBL OSPI 有任何不同。

该问题可能是由于 UART 损坏。 您是否随机或每次在多个托盘上看到该问题？ 如果在 Hello World 应用程序中将 UART 配置为中断模式、您能否通过 SysConfig 将其配置为轮询模式并查看是否仍发生问题。

此致、

Prashant