This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM3517:PRM_RSTST 寄存器显示错误值

Guru**** 2931860 points

Other Parts Discussed in Thread: AM3517

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/636974/am3517-prm_rstst-register-showing-wrong-value

器件型号:AM3517

您好!

软件复位后、AM3517 (客户专用电路板)的 PRM_RSTST 寄存器(物理地址0x48307258)显示错误值:

0x00000001

而不是

0x00000002

如果复位由看门狗触发、则寄存器中的值为

0x00000011.

这符合我的理解。

如果我尝试从引导加载程序或 Linux 用户空间(devmem 0x48307258)读取寄存器值、这一点无关紧要。  

您是否知道什么会导致错误值?

谢谢、此致、

Börje 缝合

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    如何触发软件复位?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    另一个问题:您是否检查过软件复位实际上不会导致电路板上的硬件冷复位?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Biser、

    我已经问硬件人员:软件复位不会导致我们板上的硬件冷资源。
    软件复位由 Linux 用户空间命令/sbin/reboot.触发

    此致、
    Börje μ A
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Boerje、

    通过"重新启动"控制台命令重新启动软件后、我确认 PRM_RSTST 寄存器的值为0x00000001。
    我们将进一步调查此问题。

    BR
    Tsvetolin Shulev
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Tsvetolin:

    感谢您进一步调查此问题。  您是否已经知道问题可能是什么?

    此致、

    Börje 缝合

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    此问题有什么新问题吗?

    此致、
    Börje 缝合
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好 Börje、

    很抱歉耽误你的时间。
    我对 PRM_RSTST 寄存器执行了一些测试、重点是软件复位、并观察预期结果:
    上电后、PRM_RSTST 寄存器的值为0x00000001。
    在全局软件复位(通过向 PRM_RSTCTRL 寄存器的 RST_GS 字段写入1来触发)之后、PRM_RSTST 寄存器的值为0x00000002。
    您能否进行相同的测试并分享测试结果?

    BR
    Tsvetolin Shulev
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Tsvetolin:

    在我的机器上也是如此:触发热复位
    devmem 0x48307250 8 0x2
    导致 PRM_RSTST 寄存器值0x00000002。
    由"reboot"控制台命令触发的复位会导致 PRM_RSTST 寄存器值0x00000001。

    我认为我必须调查 AM35XX 平台上的 Linux 重启代码出现了什么问题。 非常感谢您的帮助。

    此致、
    Börje 缝合
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Tsvetolin:

    事实证明、通过写入 DPLL3位(PRM_RSTCTRL 寄存器中的 RST_DPLL3)可复位所有与 am3xxx 兼容的 SoC (am33xx 除外)-
    正在考虑勘误表 i520。 对于 am35xx、如果通过"reboot"控制台命令触发复位、这会导致 PRM_RSTST 寄存器设置为冷启动。

    arch/arm/mach-omap2/prm3xxx.c
    133/**
    134 * omap3xxx_prm_dl3_reset -使用 DPLL3重置重启 OMAP SoC
    135 *
    136 *设置 DPLL3复位位位位、该位应重新启动 SoC。 这是
    137 *考虑勘误表 i520、建议重新启动 SoC 的方法。 否
    138 *返回值。
    139 */
    140静态空 omap3xxx_prm_dl3_reset (空)
    141{
    142 OMAP2_PRM_SET_MOD_REG_BITS (OMAP-RST_DPLL3_MASK、OMAP3430_GR_MOD、
    143 OMAP2_RM_RSTCTRL);
    144 /* OCP 屏障*/
    145 OMAP2_PRM_READ_MOD_reg (OMAP3430_GR_MOD、OMAP2_RM_RSTCTRL);
    146}

    更多信息: patchwork.kernel.org/.../

    在哪里可以找到有关勘误表 i520的更多详细信息?

    此致、
    Börje 缝合

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    链接的修补程序中描述的变通办法很有用、但很遗憾、我没有关于勘误表 i520的其他信息。

    BR
    Tsvetolin Shulev
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Tsvetolin:

    我在任何文档中都找不到勘误表 i520。 在 AM35XX 勘误文档中找不到类似的内容。

    引用的补丁适用于整个 am3xxx 系列、但令人恼火的是、am33xx 不受此错误的影响。 它有自己的重新启动代码。

    现在、我想知道 am35xx 系列是否也不受影响?

    此致、

    Börje 缝合

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Borje、
    AM35x 勘误表中的 Advisory 1.1.22中描述了 AM35x 上的热复位问题

    热复位的预期操作是当它被启动时、EMIF 将 DDR 置于自刷新状态、然后在热复位完成时、不需要重新配置 EMIF (只需退出自刷新状态)

    但是、正如勘误表所描述的那样、EMIF 的内容不会被维护、所以每次热复位时需要 EMIF 的完全重新初始化。 本质上、这会使热复位无法运行、因此热复位和冷复位之间实际上没有区别。 因此、Linux 补丁只会将一个'boot'命令映射到冷复位

    i520勘误表实际上指的是不同的勘误表(您可以在类似的器件中看到此勘误表的文本、AM37x 勘误表中的 Advisory 1.51)、但是该解决方法是相同的、基本上消除了热复位和冷复位之间的差异。

    此致、
    James