[参考译文] TDA4VH-Q1：MCU10能否复位 A72并使 Linux 再次运行、而无需系统复位

你(们)好

在 TDA4VM 中、我们发现 LPM 可以做到这一点、但我们在 TDA4VH 中找不到 LPM、TDA4VH 中有类似的演示、或者未来的 SDK 版本是否支持 TDA4VH

2.顺便说一下,在 SBL boot_app 模式下,我们可以通过反复运行 MCU10 app 中的3572n 任务来重新启动 App_Task 72

您好！

Unknown 说：

支持

它只应该在 j721e 中。 TDA4VH 没有明确的计划。 请查看发行说明。  

Unknown 说：

在 SBL boot_app 模式下、我们可以通过重复运行

中的 App_Task x52n 任务来重新启动 A72吗？

这里的用例是什么？

此致、

基尔西  

你(们)好

Unknown 说：

这里有什么用例？

我们在 pdk\mcusw\mcuss_demos\boot_app ccu_rtos 下找到了演示程序、其中 App_Task x387n 提供了在 MCU10中加载和运行主域的方法

那么、我们可以在 boot_app 演示中进行一些修改、以帮助我们实施 MCU10的功能来重新启动 A72、这是否可行？

目前、combined_dev.appimage 已成功重新加载并解析、并且所有 SCI 操作均未报告错误、但当执行 SBL_SlaveCoreBoot 时、A72未按预期显示 ATF 日志

启动过程如下

您好！  

我将在内部进行检查、看看是否有方法可以重置 A72内核/主域并返回给您。

此致、

Josiitaa.

您好！

您可以使用 Sciclient_pmSetModuleRst API 来复位 A72模块。

此致、

Josiitaa.

你(们)好

加载并解析 combined_dev.appimage 后,我将 SBL_SlaveCoreBoot 替换为 Sciclient_pmSetModuleRst  , ATF 打印"注意: BL31: " ,它 卡住了

有。 我们随机重置 A72。 现在、ATF 需要执行、然后跳转到 OPTEE。 您能否查看在 ATF 停止/崩溃的情况下使用调试器？

另外、 DDR 中也应该有 OPTEE。 您能否确保它已加载。 然后、应加载 A72 SPL、U-Boot 或基于您引导流程的 Linux。

-基尔西

你(们)好

很抱歉这么晚才回复、现在我们 单独放弃重置 A72、 尝试在重新启动 A72之前重置主域。 幸运的是、A72 (Linux)正在成功运行

但该系统有些奇怪

1. Linux 的实际启动时间越来越长,过去大约是10秒,但现在需要100秒或更长时间

2.我们发现 GTC 有一些问题。 Sciclient_pmGetModuleClkFreq 未能获得 GTC 的时钟频率、而 Sciclient_pmGetModuleState 获得了 GTC 的关闭状态

我们转储 GTC 和处理器时钟使用 k3conf

您好！

您能否共享日志？

-基尔西

[报价用户 id="533595" url="~/support/processors-group/processors/f/processors-forum/1436627/tda4vh-q1-can-mcu10-reset-a72-and-get-linux-run-again-without-a-system-reset/5520533 #5520533"]

1. Linux 的实际启动时间越来越长,过去大约是10秒,但现在需要100秒或更长时间

2.我们发现 GTC 有一些问题。 Sciclient_pmGetModuleClkFreq 未能获得 GTC 的时钟频率、而 Sciclient_pmGetModuleState 获得了 GTC 的关闭状态

[报价]

GTC 似乎是罪魁祸首。 会使用慢10倍的旁路时钟运行。 通常、R5 SPL/SBL 是设置时钟的函数。 我将在内部检查该行为。

-基尔西

你(们)好

我们有一个新的发现,目前我们的 SDK 版本是0900,但我链接到 SDK1000下的 sciclient 库当我编译 MCU10,系统变得正常, GTC 和处理器工作正常

但是、系统仍然存在一些问题。 如果我们重复复位主域并重新启动主域、Board_init (BOARD_INIT_PLL)每次第二次重新启动时将失败。

谢谢。 所以 GTC 问题已得到解决、但无法多次启动？  

此致、

基尔西  

你(们)好

Unknown 说：

因此 GTC 问题已解决

是的、SDK 的最新版本似乎解决了此问题

Unknown 说：

无法多次启动此命令？

是、每次重新启动都失败。  似乎无法成功执行 PLL 相关的 SCI 接口、或者 PLL 本身异常