• 状态
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 0 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] AM62P：AM62p 挂起模式导致系统复位

admin
Guru**** 2891530 points

Other Parts Discussed in Thread: SK-AM62P-LP, AM62P

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1642468/am62p-am62p-suspend-mode-causes-system-reset

部件号： AM62P

这是 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1640288/am62p-am62p-clarification-on-expected-power-consumption-in-suspend-deep-sleep-mode 的后续行动

虽然我的同事想 知道应该达到的功耗是多少、但我已经试图弄清楚为什么我们不能达到这个值。

我首先意识到的一点是、我们不会进入最深的暂停模式：

我无法测量 PMIC_LPM_EN0 是否变为低电平、内核 日志上显示：

[ 288.274548] ti-sci 440430.system-controller：TI_sci：wake source：0x80、pin：0xff、mode：0x0

如果我已正确读取了它、MODE：0x0 表示未达到最深的功耗模式。

 

我 仔细地看了一下唤醒源：

root@am62px-var-sm:~# for i in $(find /sys/-iname 'wakeup'| grep -v kernel); do if [！ -d “$i“];然后回显-n “$i:“; cat $i; fi;完成
/sys/devices/platform/bus@f0000/2860000.serial/2860000.serial:0/2860000.serial:0.0/tty/ttyS3/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/2860000.serial/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/20010000.i2c/i2c-2/2-0038/power/wakeup：enabled
/sys/devices/platform/bus@f0000/f900000.usb/f900000.usb:connector/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/f900000.usb/f900000.usb:connector/power_supply/usb-charger/power/wakeup:已启用
/sys/devices/platform/bus@f0000/f900000.usb/power/wakeup:已启用
/sys/devices/platform/bus@f0000/2010000.SPI/SPI_MASTER/spi6/spi6.0/power/wakeup：已启用
/sys/devices/platform/bus@f0000/2820000.serial/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/2820000.serial/2820000.serial:0/2820000.serial:0.0/tty/ttyS1/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/fa20000.MMC/host/mmc2/mmc2：0001/mmc2：0001：1/电源/唤醒：已启用
/sys/devices/platform/bus@f0000/2800000.serial/2800000.serial:0/2800000.serial:0.0/tty/ttyS0/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/2800000.serial/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/2850000.serial/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/2850000.serial/2850000.serial:0/2850000.serial:0.0/serial0/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/f910000.usb/power/wakeup:已启用
/sys/devices/platform/bus@f0000/f910000.usb/31100000.usb/xhci-hcd.0.auto/usb1/power/wakeup:已禁用
/sys/devices/platform/bus@f0000/f910000.usb/31100000.usb/xhci-hcd.0.auto/power/wakeup:已禁用

 

停用两个 USB 后：

回波禁用>/sys/devices/platform/bus@f0000/f900000.usb/power/wakeup

回波禁用>/sys/devices/platform/bus@f0000/f910000.usb/power/wakeup

 

PM-SUSPEND 将（显然）进入更深的挂起模式、因为我可以测量 PMIC_LPM_EN0 变为低电平并持续 11 μ s。

但是、整个系统会进入复位状态。

我能够测量一些电源轨、 虽然 RAM 的电压从未丢失、但 VDD_CORE 从 850mv 降至 0mV、但仅在 PMIC_LPM_EN0 之后经过 1ms 的延迟后才会下降。

您能就如何继续提供建议吗？  接下来是否有需要/应该测量的特定信号？

PMIC 是否向 AM62px 内核发出了错误消息、或者问题是相反的、或者是否有一些额外的电源轨我尚未测量、可能是导致该问题的根本原因？

 

一般而言：

该 PMIC 的集成方式与 SK-AM62P-LP 类似。 对于硬件端和软件集成都应该如此。

我已经意识到 Linux 内核并不能真正“感知“ PMIC、没有 适用于该 PMIC 的器件树。

我假设这是正常现象、因为只有设备管理器将与 PMIC 驱动程序通信。 此假设是否正确？

您 在另一个线程中的功率测量是基于 11.01 完成的。 我目前正在处理 11.09 版本。  该发行版中是否有任何应“强制我“转至 11.01 的更新？ U-Boot ATF 中有什么？

感谢您提供任何帮助。 谢谢

Matthias

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

    您好、

    主题专家将在 5 月 11 日之前离职、请预计回复会延迟。

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

    我还做了一些我想分享的其他测量结果：

    当 PMIC_LPM_EN0 降至 0V 时、PMIC_RESETOUTn (TPS 数据表中的 nRESETOUT) 也需要 11us 才能从 3.3V 降至 0V。

    放大图：

    我的问题仍然存在：

    是否有一些必要的更新（目前在 2009 年 11 月发布）

    PMIC“由 I2C 控制“在某处吗？

    我可以看到它不是由 Linux 驱动的（它不在器件树中）、而是可能来自设备管理器固件？

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

    您好 、Matthias、  

    为了确保、您使用的是从 TI.com 拉取 SDK 还是直接从上游拉取 SDK？ 我知道上游 rproc 驱动程序存在问题、导致 LPM 出现问题。

    [引述 userid=“635897“ url=“~/support/processors-group/processors/f/processors-forum/1642468/am62p-am62p-suspend-mode-causes-system-reset

    我已经意识到 Linux 内核并不能真正“感知“ PMIC、没有 适用于该 PMIC 的器件树。

    我假设这是正常现象、因为只有设备管理器将与 PMIC 驱动程序通信。 此假设是否正确？

    [/报价]

    Linux 不需要知道 PMIC。 PMIC_LPM_EN 信号由硬件控制、其行为将根据发送到 SYSFW 以触发 LPM 序列的 LPM 请求来确定。 理论上、AM62P 的深度睡眠模式应适用于分立式解决方案、因为 SYSFW 在默认情况下不会更改 PMIC_LPM_EN 信号以实现深度睡眠、但 TI 尚未验证这一点。

    vdd_core 从 850mv 降至 0mV、

    这是 VDD_CORE 下降的行为、表示其尝试进入部分 I/O 或 IO + DDR、而不是进入深度睡眠状态。

    您能否共享尝试进入深度睡眠的日志、包括正在使用哪些命令？ 在日志中、是否可以在暂停之前检查“（/sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us）“的 SYSFS 条目？

    我想看看设置了什么约束： https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#tisci-msg-lpm-set-latency-constraint

    您是否还可以共享完整的引导日志？ 启动时、您能否打印内核版本？ 我想检查是否使用了 SPL 引导并且各个元件版本正在匹配。  

    此致、

    Anshu

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

    您好 Anshu、

    感谢您的答复。

    理论上、AM62P 的深度睡眠模式应该适用于分立式解决方案、因为 SYSFW 在默认情况下不会更改 PMIC_LPM_EN 信号以实现深度睡眠、但 TI 尚未验证这一点。
    [/报价]

    因此、PMIC_LPM_EN 不需要变为低电平即可进入暂停模式？

    我们假设我们未达到“完全“暂停模式、因为我们无法测量 PMIC_LPM_EN 以变为低电平。

    [288.274548] ti-sci 44043000. system-controller：TI_sci：wake source：0x80、pin：0xff、mode：0x0

    因此、该行*do*表示已达到暂挂模式。 （模式 0x0）

    在日志中、您是否可以在暂停之前检查'/sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us 的 SYSFS 条目？

    PM_Qose_resume_delay_us 确实是一个有趣的触发点。

    我可以强制使用单个模式、我不知道这一点。

    echo 300000 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us

pm-suspend

    系统重置、大概是因为部分 I/O + RAM 被标为目标？？

    echo 10000 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us

pm-suspend

[..]

[ 3149.265613] ti-sci 44043000.system-controller: ti_sci: wakeup source:0x80, pin:0xff, mode:0x1

    因此、选择了仅 MCU 模式

    echo 120000 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us

pm-suspend

[  212.347304] ti-sci 44043000.system-controller: ti_sci: wakeup source:0x80, pin:0xff, mode:0x0

    因此、这似乎是“正常“暂停模式。

    我  也将在这里附加 e2e.ti.com/.../6886.boot.log 作为引导日志。

    这是 VDD_CORE 丢弃的行为、表示其尝试进入部分 I/O 或 IO + DDR、而不是进入深度睡眠状态。

    是这样吗？

    考虑到我的测量值（不同时，但可能仍然相关）

    PMIC_LPM_EN0 变为低电平

    在 11us 后、PMIC_LPM_EN0 变为高电平。 同时 PMIC_RESETOUTn 变为低电平、会触发复位

    1ms 后、PMIC_LPM_EN0 VDD_CORE 下降后需要等待很长时间。

    问题 1： 我假设 PMIC_RESETOUTn 是恢复到默认状态的“紧急信号“、之后出现的一切都不再是常规暂停/部分 I/O 模式的一部分、而是“我从头开始“。 该假设是否正确？

    在我们点击部分 IO 模式时、系统行为如此是否有任何原因？

    对我来说、下列问题也是相当重要的：

    问题 2： PMIC_LPM_EN0 仅在进入深度睡眠模式时才会变为低电平吗？ （因此不会针对深度睡眠和仅 MCU 进行切换）

    问题 3： 如果我们已经达到深度睡眠（模式 0x0）、我们是否可以在不超过深度睡眠的情况下节省更多功耗？ （此处集思广益：关闭 GPU、关闭更多外围设备。 还是所有这些都已关闭，否则我们将永远不会进入深度睡眠模式）？

    此处还附加了 suspend.log（请注意，从一开始从未启用 RTC 唤醒）。

    e2e.ti.com/.../suspend.log

    此致

    Matthias

    [/quote]
  • 0
    TI__Guru**** 2891530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 、Matthias、

    ]因此 PMIC_LPM_EN 不需要变为低电平即可进入暂停模式？

    正确、PMIC_LPM_EN 在深度睡眠中不需要变为低电平。 在深度睡眠模式或仅 MCU 模式下、预计信号状态不会发生变化。 需要在部分 IO 和 IO + DDR 中将其置为无效。


    pm_qose_resume_delay_us 确实是一个有趣的触发点。

    为了澄清一下、pm_qos_resume_delayation 告诉 SYSFW 我们尝试进入哪种低功耗模式。 默认值 0 应进入 DEEP SLEEP 模式。 请参阅下面的：

    root@am62pxx-evm:~# cat /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us                     
0
root@am62pxx-evm:~# rtcwake -m mem -s 10
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:03:50 1970
[  202.801177] PM: suspend entry (deep)
[  202.815917] Filesystems sync: 0.011 seconds
[  202.832031] Freezing user space processes
[  202.838099] Freezing user space processes completed (elapsed 0.001 seconds)
[  202.845112] OOM killer disabled.
[  202.848330] Freezing remaining freezable tasks
[  202.854174] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[  202.861607] printk: Suspending console(s) (use no_console_suspend to debug)
[  202.903568] remoteproc remoteproc0: stopped remote processor 79000000.r5f
[  202.906868] Disabling non-boot CPUs ...
[  202.909132] psci: CPU3 killed (polled 4 ms)
[  202.913127] psci: CPU2 killed (polled 4 ms)
[  202.916205] psci: CPU1 killed (polled 0 ms)
[  202.917781] Enabling non-boot CPUs ...
[  202.918118] Detected VIPT I-cache on CPU1
[  202.918163] GICv3: CPU1: found redistributor 1 region 0:0x00000000018a0000
[  202.918218] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[  202.919410] CPU1 is up
[  202.919663] Detected VIPT I-cache on CPU2
[  202.919696] GICv3: CPU2: found redistributor 2 region 0:0x00000000018c0000
[  202.919742] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[  202.920787] CPU2 is up
[  202.921042] Detected VIPT I-cache on CPU3
[  202.921081] GICv3: CPU3: found redistributor 3 region 0:0x00000000018e0000
[  202.921134] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[  202.922406] CPU3 is up
[  202.923013] ti-sci 44043000.system-controller: ti_sci: wakeup source:0x50, pin:0xff, mode:0x0
[  202.947045] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
[  202.964004] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POL)
[  202.964035] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
[  202.977687] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:01] driver [TI DP83867] (irq=POL)
[  202.977705] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii-rxid link mode
[  203.121189] OOM killer enabled.
[  203.124325] Restarting tasks ... done.
[  203.128954] random: crng reseeded on system resumption
[  203.134357] platform 79000000.r5f: Core is off in resume
[  203.139932] remoteproc remoteproc0: powering up 79000000.r5f
[  203.146868] remoteproc remoteproc0: Booting fw image am62p-mcu-r5f0_0-fw, size 59336
[  203.157258] rproc-virtio rproc-virtio.1.auto: assigned reserved memory node mcu-r5fss-dma-memory-reg0
[  203.168480] virtio_rpmsg_bus virtio0: rpmsg host is online
[  203.168792] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0xd
[  203.174167] rproc-virtio rproc-virtio.1.auto: registered virtio0 (type 7)
[  203.182082] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[  203.188591] remoteproc remoteproc0: remote processor 79000000.r5f is now up
[  203.202835] PM: suspend exit

    您可以在此处阅读有关延迟限制的更多信息： https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#tisci-msg-lpm-set-latency-constraint

    [引述 userid=“635897“ url=“~/support/processors-group/processors/f/processors-forum/1642468/am62p-am62p-suspend-mode-causes-system-reset/6341632
    Anshu Madwesh 说:
    这是 VDD_CORE 下降的行为、表示其尝试进入部分 I/O 或 IO + DDR、而不是进入深度睡眠状态。

    是这样吗？

    [/报价]

    在部分 I/O 和 IO + DDR 中、内核电压电源均由 PMIC 关闭。

    请 参阅表 6-9。 AM62P TRM 中的电压、电源和时钟域状态： www.ti.com/.../spruj83

    PMIC 知道这样做是因为 PMIC_LPM_EN 信号会被置为无效并关闭内核电源。

    问题 1： 我假设 PMIC_RESETOUTn 是恢复到默认状态的“紧急信号“、因此之后出现的所有内容不再是常规暂停/部分 I/O 模式的一部分、而是“我从头开始“模式。 该假设是否正确？

    我不确定 PMIC 内部逻辑、因此需要与其他人讨论。 我会再回来的。

    问题 2： PMIC_LPM_EN0 仅在进入深度睡眠模式时才会变为低电平吗？ （因此不会将其切换为仅 DEEP SLEEP 和 MCU）

    没错。

    问题 3： 如果我们已经进入深度睡眠模式（模式 0x0）、我们是否可以在不超过深度睡眠的情况下节省更多电量？ （此处集思广益：关闭 GPU、关闭更多外围设备。 还是所有这些都已关闭，否则我们将永远不会进入深度睡眠模式）？

    我不完全理解这个问题。 AM62P 的低功耗模式不是动态的、而是开启/关闭。 您可以参阅 表 6-9。 AM62P TRM 中的电压、电源和时钟域状态、其中显示了每种模式下的导通或关断状态。

    从我读过的内容来看、我注意到了几件事：

    1.对于深度睡眠模式、除非更改 WKUP_CTRL_MMR_CFG0_PMCTRL_SYS  寄存器（无需更改该寄存器）、否则 PMIC_LPM_EN 信号不应更改。 但根据您的观察、信号正在发生变化

    2. VDD_CORE 电压下降、这在深度睡眠中是不可预期的。

    但从暂停日志中、我看不到系统会重置的位置。

    那么、您能否尝试将 /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us 设置为 0 看看会发生什么？

    此致、

    Anshu