[参考译文] TDA4AEN-Q1：[J722S] J722S 在 OSPI NOR 闪存上支持 XIP 模式

您好、

[引述 userid=“642242" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1587785/tda4aen-q1-j722s-does-j722s-support-xip-mode-on-ospi-nor-flash

我希望 MCU 应用程序在 NOR 闪存中执行。  

[/报价]

您能否请参阅以下文档、了解如何从 NOR 闪存运行 MCU 应用程序。

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j722s/10_01_00_04/exports/docs/mcu_plus_sdk_j722s_10_01_00_22/docs/api_guide_j722s/EXAMPLES_DRIVERS_SBL_OSPI.html 

请帮助了解如何使用 XIP 模式在 NOR 闪存中运行 MCU 应用程序

此外、MCU+ SDK 包含一个专用的 XIP 示例、演示了如何从 OSPI NOR 中启用和验证 XIP。请查看并告诉我们这是否有用。
  
/examples/drivers/ospi/ospi_flash_xip_test

此致、
Karthik

尊敬的 Karthik：

   我已在具有 XIP 模式的 NOR 闪存上运行 MCU 应用程序。 我会发现 MCU UART 将 MCU 应用程序日志输出到 UART 端口。

   但它被滞留在 RPMessage_waitForLinuxReady () API 中。  它似乎卡在  ClockP_usleep() 函数之前。 但如果我在没有 XIP 的情况下修改了 MCU 应用程序 linker.cmd。 这可以正常启动 MCU 应用程序。 在没有 XIP 的情况下、MCU 应用程序将从 NOR 闪存应用程序读取并加载到 DDR 中。 那么,为什么我启用 MCU 应用程序运行在带有 XIP 的 NOR 闪存上发生了卡在 RPMessage_waitForLinuxReady ()?

MCU UART 日志：

[RPMessage_waitForLinuxReady] AAaa 0x3 0x7 0x0 0x1 0x0 0x0 0x0
[RPMessage_waitForLinuxReady] bbb 0 2.
[RPMessage_waitForLinuxReady] aaaaaaaaaa
[RPMessage_waitForLinuxReady] bbbbbbbb
[RPMessage_waitForLinuxReady] CCCCCC
[RPMessage_waitForLinuxReady] dddddddddd.
[RPMessage_waitForLinuxReady] EEeeee

   

void ipc_rpmsg_echo_main(void *args)
{
    int32_t status;

    Drivers_open();
    Board_driversOpen();

    DebugP_log("[IPC RPMSG ECHO] ADAS AutoSAR Version: %s (%s %s):  \r\n", IPC_FW_VERSION, __DATE__, __TIME__);
    DebugP_log("[IPC RPMSG ECHO] 2222ADAS AutoSAR Version: %s (%s %s):  \r\n", IPC_FW_VERSION, __DATE__, __TIME__);
    DebugP_log("[IPC RPMSG ECHO] kkkkkkADAS AutoSAR Version: %s (%s %s):  \r\n", IPC_FW_VERSION, __DATE__, __TIME__);
	DebugP_log("[IPC RPMSG ECHO] 1111ipc_rpmsg_echo_main address 0x%x \r\n", &ipc_rpmsg_echo_main);
	DebugP_log("[IPC RPMSG ECHO] 2222ipc_rpmsg_create_recv_tasks address 0x%x \r\n", &ipc_rpmsg_create_recv_tasks);
	DebugP_log("[IPC RPMSG ECHO] 3333ipc_rpmsg_send_messages address 0x%x \r\n", &ipc_rpmsg_send_messages);
	DebugP_log("[IPC RPMSG ECHO] 44444 RPMessage_waitForLinuxReady address 0x%x \r\n", &RPMessage_waitForLinuxReady);
	DebugP_log("[IPC RPMSG ECHO] 5555 IpcNotify_registerClient address 0x%x \r\n", &IpcNotify_registerClient);
	DebugP_log("[IPC RPMSG ECHO] 77777 a gRPMessage_linuxResourceTable address 0x%x \r\n", &gRPMessage_linuxResourceTable);

    /* This API MUST be called by applications when its ready to talk to Linux */
    status = RPMessage_waitForLinuxReady(SystemP_WAIT_FOREVER);
    DebugP_assert(status==SystemP_SUCCESS);

	DebugP_log("[IPC RPMSG ECHO] xxxxxx ADAS AutoSAR Version: %s (%s %s):	\r\n", IPC_FW_VERSION, __DATE__, __TIME__);

    /* Register a callback for the RP_MBOX messages from the Linux remoteproc driver*/
    IpcNotify_registerClient(IPC_NOTIFY_CLIENT_ID_RP_MBOX, &ipc_rp_mbox_callback, NULL);

    DebugP_log("[IPC RPMSG ECHO] 3333ADAS AutoSAR Version: %s (%s %s):  \r\n", IPC_FW_VERSION, __DATE__, __TIME__);

    /* create message receive tasks, these tasks always run and never exit */
    ipc_rpmsg_create_recv_tasks();

    DebugP_log("[IPC RPMSG ECHO] 444ADAS AutoSAR Version: %s (%s %s):  \r\n", IPC_FW_VERSION, __DATE__, __TIME__);

    /* create AdasLib Task and Clock */
    init_AdasLibTasks();
    DebugP_log("[IPC RPMSG ECHO] 5555ADAS AutoSAR Version: %s (%s %s):  \r\n", IPC_FW_VERSION, __DATE__, __TIME__);

    /* Xcp Init task */
    Xcp_Init(NULL_PTR);
    DebugP_log("[IPC RPMSG ECHO] 6666ADAS AutoSAR Version: %s (%s %s):  \r\n", IPC_FW_VERSION, __DATE__, __TIME__);

    /* wait for all non-Linux cores to be ready, this ensure that when we send messages below
     * they wont be lost due to rpmsg end point not created at remote core
     */
    IpcNotify_syncAll(SystemP_WAIT_FOREVER);

    /* Due to below "if" condition only one non-Linux core sends messages to all other non-Linux Cores
     * This is done mainly to show deterministic latency measurement
     */
    if( IpcNotify_getSelfCoreId() == gIpcInitiatorCoreID )
    {
        ipc_rpmsg_send_messages();
    }
    /* exit from this task, vTaskDelete() is called outside this function, so simply return */

    Board_driversClose();
    /* We dont close drivers since threads are running in background */
    Drivers_close();
}

int32_t RPMessage_waitForLinuxReady（uint32_t 超时）
｛
int32_t 状态= SystemP_Failure；
Volatile RPr Message_Resource 表*rscTable =(Rp Message_Resource 表*)gIpcRpmsgctrl.linuxResourceTable;
DebugP_log（“[%s]输入\r\n“、__func__)；
if(rscTable ！= NULL )
｛
DebugP_log（“[%s] 11111 \r\n“、__func__)；
uint32_t elaspedTicks、startTicks = ClockP_getTicks ()；
应该做
｛
DebugP_log（“[%s] wwww \r\n“、__func__)；
CacheP_inv (void *) rscTable、sizeof（（rp Message_Resource 表）、CacheP_TYPE_ALL)；
DebugP_log（“[%s] AAaa 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x \r\n“、__func__、
rscTable->vdev.type、rscTable->vdev.id、rscTable->vdev.notifyid
rscTable->vdev.dfeatures、rscTable->vdev.gfeatures、rscTable->vdev.config_len)；
DebugP_log（“[%s] bbb %d %d \r\n“、__func__、
rscTable->vdev.status、rscTable->vdev.num_of_vrings);
if (rscTable->vdev.status == 0x7U)
｛
/* Linux 已初始化资源表、请中断*/
状态= SystemP_Success；
}
DebugP_log（“[%s] aaaaaaaaaa \r\n“、__func__)；

IF(status ！= SystemP_Success )
｛
DebugP_log（“[%s] bbbbbbb \r\n“、__func__)；
elaspedTicks = ClockP_getTicks ()- startTicks ;
DebugP_log（“[%s] CCCC \r\n“、__func__)；
if（ elaspedTicks >=超时）
｛
/*超时、Linux 未在用户特定的超时时间内初始化资源表*/
状态= SystemP_TIMEOUT；
}
DebugP_log（“[%s] dddddddd \r\n“、__func__)；
if(status ！= SystemP_timeout)
｛
DebugP_log（“[%s] eeee \r\n“、__func__)；
/*睡眠一个节拍*/
//ClockP_usleep (ClockP_ticksToUsec (1))；
ClockP_USleep (2000)；
}
DebugP_log（“[%s] fffffff \r\n“、__func__)；
}
} while (status == SystemP_FAILURE)；

}
返回状态；
}

   

尊敬的  Karthik：

  在我的案例中：

    要将引导加载程序作为 SBL 运行。 （完成）

    2.希望 SBL 引导包含 HLOS 和 u-boot。 （完成）

    3.从 OSPI NOR 闪存引导

    4. MCU 应用具有 IPC/ADAS/CAN 等功能。 （完成）

    上述情况可以在 DDR 上很好地运行 MCU 执行。

    5. MCU 应用程序更改 XIP 中的文本/ rodata。  

   上述条件从 1~5 开始、我可以看到 MCU 应用程序 UART 日志输出。 MCU 应用程序已在 XIP 模式下运行。 但在初始 IPC 阶段、调用 RPMessage_waitForLinuxReady 函数 was stuck!

   我对 A53 保持在 u-boot 模式有一些不屑一顾、似乎 MCU 应用程序仍 在 RPMessage_waitForLinuxReady () while 循环中运行。 但是、如果引导至 Linux 操作系统、MCU 应用程序将停止输出我添加的任何日志。 那么、如果启用 NOR XIP 模式、Linux OS 上是否需要进行任何更改？

尊敬的  Karthik：

   我发现问题可能出在 u-boot-spl 部分。 下面的显示了 SBL 和 u-boot 命令、用于查询 OSPI 控制器的 DAC 模式信息。  

   我发现 u-boot 模式查询 DAC 设置已更改。  

   我还尝试缩小哪个器件会影响 MCU 应用停止运行。  

   的示例包括 MCU 应用、A53 (bl31、bl32、u-boot-spl)。 如果我从 appimage 中移除 u-boot-spl 器件、 我看到我的 MCU 应用程序在 RPMessage_waitForLinuxReady () 中以 XIP 模式和 wile 循环运行。 因为 Linux 操作系统尚未就绪。 但我可以看到日志输出到 MCU UART 端口。 （我在 RPMessage_waitForLinuxReady () 中添加了一些日志。 但如果 A53 已运行 u-boot-SPI 导致 MCU 应用程序停止在 XIP 模式下运行。 u-boot-sp 似乎已重新配置 NOR 闪存控制器。  你有什么理想吗?

在 SBL 日志中显示：
&preg->CONFIG_REG = 0xfc40000
&preg->IND_AHB_ADDR_TRIGGER_REG = 0xfc4001c
IND_AHB_ADDR_TRIGGER_REG = 0x0
666666aCONFIG_REG = 0x80083801
IND_AHB_ADDR_TRIGGER_REG = 0x4000000
CONFIG_REG = 0x80083881

在 u-boot 查询中、ospi 寄存器：
[CMD] Md.l 0xfc40000 1.
0fc40000：c1183881 .8.
=> Md.l 0xfc4001c 1
[CMD] Md.l 0xfc4001c 1.
0fc4001c：00000000

尊敬的  Karthik：

   我的问题不在 u-boot 中。 它处于 u-boot-spl 映像阶段。 我的平台是 J722S。 u-boot-spl 在 A53 内核中运行。  

   但在 u-boot-spl 映像中、需要通过读取 NOR 闪存来加载 u-boot。 这就是 u-boot-spl 重新初始化 OSPI 接口的问题。 则会导致 MCU 应用程序在 XIP 模式下运行停止。 是由 u-boot-spl 引起的。  

您好、

如果您从 u-boot-spl 禁用 OSPI、该问题是否会得到解决？ 还来自内核的吗？

为此、您可以 status = "disabled";在设备树的“ospi0"节点“节点中添加（“DTS/上游/ src /arm64/ti/k3-j722s-evm.dts“）。 则表示不会更改 OSPI 控制器。

您必须在 PROCESSOR-SDK Linux 中执行此操作 并重新编译 u-boot。 要构建 u-boot、您只需从已安装的处理器 SDK Linux 的顶层目录运行“make u-boot“。

此致、
Tanmay

您好、Tanmay：

   我将尝试执行 ospi0 以禁用设备中的节点。 但我有一个问题、如果我从 u-boot-sp 中禁用 ospi0、u-boot-spl 如何从 NOR 闪存加载 u-boot.img？  

  下面显示了我的 NOR 闪存分区列表。 我将 u-boot.img 放在地址 0x00880000 中。 u-boot-spl 将从 NOR 闪存加载 u-boot.img。 但是、如果我从 u-boot-spl 中禁用 ospi0、如何加载 u-boot？