[求助]全志V821进入休眠模式，小核跑飞。

粗制乱造_0b1cd9a8 · 今天 11:11:53

一、问题描述

正在学习开发V821的低功耗模式，固件启动介质是TF卡。使用的模板固件是v821-perf2b_fastboot-tina。
开发板是自制的。电源部分原理图参考perf2b，芯片是V821L2-WXX。
硬件未链接摄像头。PL3为配置为唤醒源。
使用SDK为tina-v821-v1.3

1、大核串口日志

root@(none):/# echo 1 > /sys/class/ae350_standby/use_ultra_standby
ac327 send hard syn message: 0x80300202
ac327 receive hard syn message feedback: 0x300202
root@(none):/# poweroff
The system is going down NOW!
Sent SIGTERM to all processes
Requesting system poweroff
ac327 send hard syn message: 0x260202
ac327 receive hard syn message feedback: 0x260202
ac327 send hard syn message: 0x260202
ac327 receive hard syn message feedback: 0x260202
ac327 send hard syn message: 0x280202
ac327 receive hard syn message feedback: 0x280202
[  661.055340] reboot: Power down
ae350_system_reset(): CPU[0] SHUTDOWN
ac327 send hard syn message: 0x80240202
ac327 receive hard syn message feedback: 0x240202

2、小核串口日志

[634.384][PLAT_LOG]STEP_REC_HEAD state: 0x02 attr: 0x02 type: 0x30
[634.385][PLAT_LOG]STEP_REC_LEN cnt: 0x0000 len: 0x0001

[661.080][PLAT_LOG]STEP_REC_HEAD state: 0x02 attr: 0x02 type: 0x26
[661.081][PLAT_LOG]STEP_REC_LEN cnt: 0x0000 len: 0x0001
[661.086][PLAT_LOG]STEP_REC_HEAD state: 0x02 attr: 0x02 type: 0x26
[661.086][PLAT_LOG]STEP_REC_LEN cnt: 0x0000 len: 0x0001
[661.099][PLAT_LOG]STEP_REC_HEAD state: 0x02 attr: 0x02 type: 0x28
[661.100][PLAT_LOG]STEP_REC_LEN cnt: 0x0000 len: 0x0001
[661.112][PLAT_LOG]STEP_REC_HEAD state: 0x02 attr: 0x02 type: 0x24
[661.112][PLAT_LOG]STEP_REC_LEN cnt: 0x0000 len: 0x0001
[661.113][PLAT_LOG]enter ultra standby
[661.116][VIN]csi_link_deinit standby_mode is 1

[661.121][RPBUF_INFO][rpbuf_free_buffer_internal:1391]buffer "isp0_load_rpbuf" (id:2): buffers -> remote_dummy_buffers
[661.132][RPBUF_INFO][rpbuf_free_buffer_internal:1391]buffer "isp0_save_rpbuf" (id:3): buffers -> remote_dummy_buffers
[661.143][RPBUF_INFO][rpbuf_free_buffer_internal:1391]buffer "isp0_ldci_rpbuf" (id:4): buffers -> remote_dummy_buffers
[661.154][ISP]isp0 exit end!!!

[661.157]wlan_fmac_xrlink_deinit start
[661.160]xrlink txrx deinit finish.
[661.164][RPBUF_INFO][rpbuf_free_buffer_internal:1391]buffer "xradio_mtx" (id:0): buffers -> remote_dummy_buffers
[661.174][RPBUF_INFO][rpbuf_free_buffer_internal:1391]buffer "xradio_mrx" (id:1): buffers -> remote_dummy_buffers
[661.185]rpmsg_xradio_deinit
[661.188][RV] [AMP_INFO][rpmsg_unregister_driver:218]Unsupport rpmsg_unregister_driver
[661.874]hal_msgbox_channel_send_data(764): message queue is full for a long time!!!

[661.875][RV] [AMP_ERR][msgbox_ipi_notify:211]rv-vring-ipi: Failed to send message to remote
[661.879][RV] [AMP_ERR][rproc_common_notify:261]rv-vring-ipi (id: 0) notify failed
[662.566]hal_msgbox_channel_send_data(764): message queue is full for a long time!!!

[662.566][RV] [AMP_ERR][msgbox_ipi_notify:211]rv-vring-ipi: Failed to send message to remote
[662.571][RV] [AMP_ERR][rproc_common_notify:261]rv-vring-ipi (id: 0) notify failed
[663.257]hal_msgbox_channel_send_data(764): message queue is full for a long time!!!

[663.257][RV] [AMP_ERR][msgbox_ipi_notify:211]rv-vring-ipi: Failed to send message to remote
[663.262][RV] [AMP_ERR][rproc_common_notify:261]rv-vring-ipi (id: 0) notify failed
[663.270][RV] [AMP_INFO][rproc_common_remove:100]remove rproc...

小核在remove rproc...后，串口循环打印乱码，此时小核应当是跑飞了，电源控制引脚，PL0,PL1,PL2,PL6均未拉低

二、参考资料

[全志在线-V821-Standby-休眠唤醒]https://docs.aw-ol.com/docs/soc/v821/system/standby
参考此资料对代码进行调整。
Tina_Linux_快启功耗管理_开发指南.md.txt

=================分割线===================
请各位大佬有空的时候指导我一下，应当从哪里排查问题。

最近编辑记录粗制乱造_0b1cd9a8 (今天 11:58:57)

陆苹果 · 今天 19:09:18

看日志的话，我觉得重点不在 poweroff 本身，而是在小核进入 ultra standby 以后，仍然有 AMP/rpmsg/rproc 相关路径在试图和“大核/远端”通信，最后卡在 msgbox 队列满，然后走到 rproc_common_remove() 后异常。这个更像是 standby 收尾顺序或某个外设/AMP 资源没有正确静默，而不是单纯 GPIO 配置问题。

可以按下面几条线排：

先把 WiFi / ISP / VIN / camera 相关功能彻底裁掉验证

你硬件没有接摄像头，但小核日志里仍然有：

[VIN]csi_link_deinit standby_mode is 1
buffer "isp0_load_rpbuf" ...
[ISP]isp0 exit end!!!
wlan_fmac_xrlink_deinit start
rpmsg_xradio_deinit

这说明小核的低功耗流程里还在跑 ISP/VIN/WLAN/XRadio 相关 deinit。自制板如果没有摄像头、没有 WiFi，建议先做一个“最小系统 standby”镜像：

dts 里 disable vin/isp/csi 相关节点；
disable wlan/xradio 相关节点和固件加载；
Tina menuconfig 里能关的 ISP/VIN/WLAN/RPBUF demo 先关掉；
小核工程里如果有对应模块初始化，也先裁掉或让 deinit 直接返回。

如果裁掉后能正常拉低 PL0/PL1/PL2/PL6，说明问题就在这些 AMP 外设资源释放顺序上。

重点查 hal_msgbox_channel_send_data queue is full 的发送方

这条日志很关键：

hal_msgbox_channel_send_data(764): message queue is full for a long time!!!
rv-vring-ipi: Failed to send message to remote
rproc_common_notify: notify failed

进入 ultra standby 后，大核已经在关机/停 remoteproc 流程里了，但小核还在通过 vring/msgbox 发 notify。正常低功耗流程应该先停止业务线程、停止 rpmsg/rpbuf 发送，再关 IPI/msgbox/rproc。如果顺序反了，就会出现发送队列满、notify failed，后面 remove rproc 时更容易跑飞。

建议在小核代码里给以下函数加调用栈/模块名 log：

hal_msgbox_channel_send_data()
msgbox_ipi_notify()
rproc_common_notify()
rproc_common_remove()
rpmsg_xradio_deinit()
rpbuf_free_buffer_internal()

目标是确认到底是谁在 standby 期间最后还在发 IPI。尤其是 rpbuf_free_buffer_internal() 释放 buffer 时是否会通知 remote，如果 remote 已经停了，这里就不应该继续 notify。

确认 standby 命令和电源模式是否匹配

你现在是：

echo 1 > /sys/class/ae350_standby/use_ultra_standby
poweroff

这条路径走的是“关机 + ultra standby”的组合，和普通 mem suspend 不是一回事。建议对照文档确认当前 SDK 推荐入口，是不是还需要配置 standby bin / cpusys / wakeup source / power domain。可以分别测：

echo mem > /sys/power/state

以及你现在的 poweroff 路径，看是哪一条会触发跑飞。如果 mem 正常、poweroff 异常，那问题基本就在 fastboot/poweroff ultra standby 的收尾流程；如果两条都异常，再看小核通用 standby 流程。

PL0/PL1/PL2/PL6 未拉低，可能是流程还没走到 PMIC/GPIO poweroff 阶段

现在日志停在：

remove rproc...

后面乱码，说明还没完成最终电源控制动作。也就是说 PL0/PL1/PL2/PL6 没拉低不一定是 pinmux 配错，而可能是小核在执行电源控制前已经异常了。

建议在小核控制 PL0/PL1/PL2/PL6 的函数前后加 log，例如：

printf("standby: before power gpio off
");
printf("standby: set PL0/PL1/PL2/PL6 low
");
printf("standby: after power gpio off
");

如果这些 log 没出现，先解决前面的 rpmsg/msgbox/rproc；如果出现了但电平没变，再查 pinmux、gpio bank 电源域、是否被其它功能复用。

自制板还要核对 RTC/PL 电源域和唤醒脚

PL3 配唤醒源时，需要确认：

PL bank 在 ultra standby 下是否仍有供电；
PL3 的上下拉和有效电平是否正确；
唤醒源配置是否写入小核/standby 固件实际使用的配置，而不仅是 Linux dts；
参考板上由 PMIC 或外部电源控制的 rail，你的板子是否等价。

不过从你当前日志看，优先级还是 msgbox queue full -> rproc remove -> 乱码 这条链。

我建议先做一个最小化实验：

关闭 VIN/ISP/WLAN/XRadio；
保留串口、PL3 唤醒、必要电源 GPIO；
重新测 use_ultra_standby + poweroff；
在 rproc_common_remove() 后面、真正拉 GPIO 前后加 log。

如果最小系统可以进休眠，再逐个打开 ISP/WLAN 等模块，就能定位是哪一个 deinit 阶段把 msgbox/rpmsg 搞挂。现在这份日志里最可疑的是 WLAN/XRadio 的 rpmsg 注销和 rpbuf 释放顺序。

哇酷®开发者社区(WhyCan® Forum)

楼主 # 今天 11:11:53 分享评论