• 状态 Resolved
  • 已锁定 已锁定
  • 回复 21 回复
  • 订户 0 订户
  • 视图 1192 视图
  • 用户 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.

[参考译文] DM388：使用4.4内核快速启动 Linux

admin
Guru**** 2563960 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/589923/dm388-fast-linux-bootup-with-4-4-kernel

器件型号：DM388
Thread 中讨论的其他器件： DM385

团队、

我们的客户正在使用 DM388进行积极设计、并希望尽可能缩短 Linux 唤醒时间(如果可能、系统启动时间小于1秒)。

首先、我们一起列出了深度睡眠模式功能所需的操作：

1、实施 DVFS、需要更新基于4.4内核的新 SDK 基础

2.在 Linux PSP 中启用 DVFS/cpufreq

3.更改寄存器 DeepSlep_CTRL 的设置以进入深度睡眠模式或从深度睡眠模式唤醒。

由于500msec 的唤醒时间仅适用于 DM388、现在重点关注整个系统唤醒。

由于客户以前实施过深度睡眠模式功能、因此他们可以在系统中以1.1W 的功耗成功进入深度睡眠模式、但随后他们需要在进入深度睡眠模式之前关闭所有应用程序、 然后重新加载所有应用程序(如重新构建视频流、运行 OSD 等)。唤醒后、完成的总时间为6秒。

由于500毫秒仅是 DM388芯片的唤醒时间、而不是整个系统的唤醒时间、因此客户需要在唤醒后1秒甚至更短的时间内完成整个系统的准备工作、那么在我们的新4.4 Linux SDK 中是否可能实现？

在快速启动最新的4.4内核方面有什么经验？

我们意识到有多种专门针对快速唤醒时间进行了优化的 Linux 发行套件、甚至还有为此目的开发了定制 SDK 的第三方公司、 但是、由于客户将使用我们的 TI DM3x Linux SDK、我们更愿意将其用作快速启动的框架。

欢迎评论！

Ty、
是的

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

    您好！

    我将通知我的团队研究此问题。

    此致、

    Anuj

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

    前面的问题中的 AFAIK、项目符号1和2已经在4.4内核中进行了处理、它可以与启用某些内核配置一起工作。
    但是、DVFS 可能需要根据目标器件使用的器件和外设进行定制。

    4.4内核的冷启动时间大约为20-30秒。 但这没有太多的优化、因此有很大的空间可以改善启动时间。 尽管许多其他 Linux 发行版支持快速启动、但这些发行版可能不包括(大部分不包括)对您所寻找的平台的支持。 因此、这可能需要您的客户在特定发行版上移植最新内核、并进行必要的更改。

    此外、他还可以选择使用休眠、快照启动等标准技术来优化 Linux 启动时间、并进行必要的优化。 但是，目前内核4.4不支持此功能！
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    PathPartner 已实现休眠和恢复。 我们通过 Android 等更复杂的操作系统实现了3.5秒的启动时间。 此外、我们还在存储器中实现了 DM38x 视频的流水线、这可以节省我们大量的时间。 但是、这需要相当长的时间才能实现。 要加快此过程、您可以通过 sales@pathpartnertech.com 与我们联系。 我们是 TI 的合作伙伴之一、也是 TI DM 系列的维护人员
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    我现在可以启动 DM388板、以查看内核4.4 (IPNC_RDK_3.9.0)的外壳层。

    我测试深度睡眠功能(echo -n"mem">/sys/power/state)。

    它可以休眠、但无法从 OSC_WAKE 引脚唤醒。 (IPNC_RDK_3.8正常。)

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

    Arago 2016.05 DM388_CSK ttyS0

    DM388_CSK 登录：root
    root@DM388_CSK：~# echo -n "m[ 47.740930] autorun-usecase.sh[110]：boot_proc 中发生超时。
    [47.741699] autorun-usecase.sh[110]：程序退出。
    em">[51.758718] autorun-usecase.sh[110]：boot_proc 中发生超时。
    [51.759473] autorun-usecase.sh[110]：程序退出。
    /sys/power/state
    [59.757011] PM：正在同步文件系统... 完成。
    [59.772217]冻结用户空间进程... (已用0.001秒)。
    [59.780593]冻结剩余可自由运行的任务... (已用0.001秒)。
    [59.789221]暂停控制台(使用 NO_console_suspend 进行调试)

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

    你有什么建议吗？

    谢谢。

    此致、

    S.K.

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

    引脚多路复用似乎没有完成。

    您能转储一下
    # devmem2 0x48140818

    如果可能、将其设置为0x01并进行检查。
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    我可以确认 U28引脚是 DEVOSC_WAKE 模式(0x01)。
    --------------------------------------------------
    root@DM388_CSK：~# devmem2 0x48140818
    /dev/mem 已打开。
    映射到地址 bb6f24000的内存。
    在地址0x48140818 (bb6f24818)：0x000E0001处读取
    --------------------------------------------------

    当我按下按钮时、我可以看到从逻辑1 (3.24v)到逻辑0 (0v)的正确操作。

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

    现在、我怀疑 IPNC 3.9是否启用了深度睡眠。 您能否检查是否启用了深度睡眠模式并设置了正确的极性0x481C5324？ 您是否还可以通过 IPNC 3.8中的 debugfs 条目显式启用深度睡眠(如果不能，则可以检查 IPNC 3.8中的0x481C5324和/sys/kernel/debug/enable_deep_sleep 的值)？
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    1。
    root@DM388_CSK：/sys/kernel/debug devmem2 0x481C5324
    /dev/mem 已打开。
    映射到地址 bb6f2a000的内存。
    在地址0x481C5324 (bb6f2a324)：0x00016A75处读取
    [host]388_CSK：/sys/kernel/debug

    (PS：我尝试使用 devmem2更改值、但它无法正常工作。 我再次读取它-> 0x00016A75)


    2、IPNC_RDK_3.9的定时器唤醒源可以成功。
    a. mount -t debugfs debugfs /sys/kernel/debug
    b. echo 5 >/sys/kernel/debug/pm_debug/wakeup_timer_seconds
    c. echo -n"mem">/sys/power/state
    --------------------------------------
    root@DM388_CSK：/sys/kernel/debug echo -n "mem">/sys/power/state
    [1579.896746] PM：正在同步文件系统... 完成。
    [1579.902703]冻结用户空间进程... (已用0.001秒)。
    [1579.911125]冻结剩余可自由执行的任务... (已用0.001秒)。
    [1579.919793]暂停控制台(使用 NO_console_suspend 进行调试)
    [1579.931636] PM：4.306毫秒后设备挂起完成
    [1579.933527] PM：1.873毫秒后器件延迟挂起完成
    [1579.935265] OMAP-RTC 480c0000.RTC：OMA_DEVICE_IDLE ()从无效状态调用2.
    [1579.935321] PM：在1.781ms 后器件挂起完成
    [1579.935325] PM：5.000秒内恢复计时器(20000000个周期/秒时、100000000个周期)
    [1579.939032] OMAP-hwmod：rtc：_wait_target_ready 失败：-16
    [1579.954311] PM：18.811毫秒后器件恢复完成
    [1579.955842] PM：在1.395毫秒后完成设备的早期恢复
    [1579.956268] Net eth0：正在初始化 cpsw 版本1.10 (0)
    [1579.956279] net eth0：已初始化 cpsw ale 版本1.3
    [1579.958174] net eth0：从机0上找不到 PHY"/ocp/ethernet@4a100000/MDIO@4a100800/ethernet-phy@25"
    [1579.958188] libphy：找不到 PHY
    [1579.958196] net eth0：PHY ""未在从站1上找到、错误-19
    [1580.020092] PM：64.222m 秒后完成设备恢复
    [1580.1088854]正在重新启动任务... 完成。
    root@DM388_CSK：/sys/kernel/debug
    --------------------------------------

    3.在 IPNC_RDK_3.8中，我不需要运行"mount -t debugfs gfs /sys/kernel/debug。
    我只需运行"echo -n"mem">/sys/power/state、然后按 OSC_WAKE PIN 的按钮。 器件唤醒。
    (我将返回3.8以读取0x481C5324的值。)

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

    您好，

    我仍在调试 OSC_WAKE 引脚问题。

    a.)我需要确认一件事。 在 IPNC_RDK_3.9中、我是否绝对必须将 AUX OSC 的电路用于深度睡眠模式？  

    b.)我还能问一个有关 深度睡眠模式功耗的扩展问题吗？

    我移除了所有外设、并使用电源来测量电流。

    (您可以将电路板的图像非常干净。 只有 DM388芯片、DDR3 DRAM、 NAND 闪存和 SD 卡。)

    运行"echo -n"mem" >/sys/power/state 后、电流为387mA@4.2V。  (590mA -> 387mA)

    (从 DM385 PowerSpreadSheet Ver1 00 Release.zip 文件中、深度睡眠为107mW。)

    我的电流是否合理？ 您知道如何实现107mW 吗？

    谢谢。

    S.K.

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

    a.)我需要确认一件事。 在 IPNC_RDK_3.9中、我是否绝对必须将 AUX OSC 的电路用于深度睡眠模式？
    答案：这是可选的。 例如、如果需要精确的音频频率、则会使用该频率、该频率无法从 DEV OSC 导出。 如果不使用该器件、则无需对其进行控制即可实现深度睡眠。

    b.)我还能问一个有关深度睡眠模式功耗的扩展问题吗？
    答案：我们需要确保 DM38x 是否实际位于深度睡眠模式中。 我们需要确认这一点，因为我有以前的职务中提到的疑问。
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Dwarakesh、

    我可以为 OSC_WAKE 引脚解决此问题。

    我使用旧文件"slep81xx.S"检查流程。

    它可以唤醒、深度睡眠的电流为125mA@3.8V。(我认为我仍然有 PLL 问题。)

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

    知道您解决了这个问题。 IPNC RDK 3.9中是否缺少 sleep81xx.S 或它不正确？
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Dwarakesh、

    新的 sleep81xx.S 在   IPNC_RDK 3.9中的"entry (ti814x_cpu_suspend)"函数处具有一些不同的流程。

    我尝试使用旧流程、因为它对我们的电路板来说很好。

    最后、对于3.9、旧流程也是可以的。

    再次感谢。

    S.K.

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

    您好、SK Huang、

    最好知道您已自行确定修复程序。

    3.9 RDK 中的 Slepti81xx.S 会因类似的原因而发生变化

    1. 内核4.4兼容性  
    2. WFI  
    3. 时钟

    我建议使用新的睡眠文件并向其中添加新功能、例如 OSC 唤醒。  

    如果您认为这不是您想要做的事情、请确保使用旧的睡眠文件时不会遇到随机问题、例如长时间挂起或崩溃。  

    谢谢

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

    尊敬的 Ravikiran：

    如果我添加 ARM WFI 指令(slep81xx.c 中的新流程之一)、则无法使用 OSC_WAKE 引脚将其唤醒。

    它是否是 ARM 的中断引脚？   

    谢谢。

    S.K.

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

    您好！

    您是否已经查看了 spruhg1b.pdf -第279页中的 OSC 唤醒功能？
    请注意，在3.9 RDK 版本中未验证 OSC 唤醒：)

    是的、这是一个在器件进入深度睡眠之前对要配置的事件进行 ARM 和类型配置的事件。

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

    对于深度睡眠流程、不会执行 WFI 指令。

    如果启用了深度睡眠-输入深度睡眠
    否则、WFI (ARM/A8 CPU 等待中断)

    请参阅 ：processors.wiki.ti.com/.../TI81XX_PSP_PM_SUSPEND_RESUME_User_Guide

    OSC_WAKE 不是通过中断控制器产生的通用中断机制。 它特定于唤醒 osc。 它看起来不是 WFI 的唤醒源

    是否可以尝试仅禁用 WFI 的3.9代码？ 尝试此方法比使用3.8 sleepti81xx.S 更安全
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Ravikiran：

    在我尝试之后、它对于 IPNC_RDK_3.9中的深度睡眠模式是不可行的。

    如果我移除"WFI"、流 速将立即唤醒。 它不执行深度睡眠操作。

    谢谢。

    S.K.

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

    我们将在内部对此进行尝试、然后返回给您。 您能否提供您所做的所有更改？ 是否已将 sleepti8xx.S 文件从3.8更改为3.9。 这是您所做的唯一更改，它是否能够成功工作？

    您提到过"如果我添加了 ARM WFI 指令(slep81xx.c 中的新流程之一)、则无法使用 OSC_WAKE 引脚唤醒。" 您能指向代码中的此更改吗？

    现在、您说"如果我移除了"WFI"、流程将立即唤醒。 它不执行深度睡眠操作。" 这条语句与前一条语句之间的区别是什么？"如果我添加了 ARM WFI 指令(slep81xx.c 中的新流程之一)、则无法使用 OSC_WAKE 引脚唤醒。" 在代码中尝试的更改方面？
  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Dwarakesh、

    关于 IPNC_RDK_3.9  中 sleep81xx.S 的以下函数"条目(ti814x_cpu_suspend)"：

      请   在 IPNC_RDK_3.8中使用 sleep81xx.S 替换该函数。

    2.如果我在此文件中添加了 WFI、则无法通过 OSC_WAKE 引脚唤醒。 因为它不是中断引脚、所以它总是在这里阻断。

      我知道深度睡眠模式不使用 WFI。

    3.如果我从   IPNC_RDK_3.9中的原始 sleep81xx.S 中删除了 WFI、它将不会进入睡眠模式。

      IPNC_RDK_3.9中的原始文件(sleep81xx.S)  对于深度睡眠模式不起作用。  

    谢谢。

    S.K.

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

    您好、黄

    请查找随附的 pm-debug.c 它为深度睡眠启用 debfugfs 条目。 我们在这里使用 DM38x CSK 和 IPNC RDK 3.9封装进行了测试。 我们可以使用 IPNC 3.9包中的 sleep81xx.S 通过 OSC_WAKEUP 从深度睡眠模式唤醒、而无需任何更改。 恢复所有更改。 在 arch/arm/mach-omap2/中添加 pm-debug.c

    # mount -t debugfs debugfs /sys/kernel/debug

    # echo "1">/sys/kernel/debug/pm_debug/enable_deep_sleep

    # echo -n"mem">/sys/power/state

    感谢@vishwanath Patil 的帮助

    e2e.ti.com/.../3666.pm_2D00_debug.c