Android BSP调试过程中遇到系统 suspend，reboot死机问题，基础调试

Suspend问题：

1 .不断在后台自动休眠/唤醒，而屏幕又不亮：

   该问题是android上层的alarm list问题， 偶尔出现这个现象是正常的。但是如果频繁出现则有问题，找andorid engineer check下alarm list。

2.休眠后，按唤醒源没有任何反应，一句log都没有输出：
   这个问题往往是唤醒源不对，即新增的唤醒源没有加入唤醒源中，致使系统无法唤醒。还有就是检查32k晶振是否起振。如果起振，各路电是否按预期恢复了。

3.待机唤醒缓慢：
首先查看下kernel log，查看哪个driver在resume的时候用的时间过多。其次，关闭kernel log可以省掉0.5s resume时间。

4.resume唤醒后在亮屏后或者接近亮屏后死机，这个很多时候和wifi有关。请关闭wifi进行排除煲机。

5.suspend过程中死机，并且连ICE无法stop。
   这个原因往往是某个模块在suspend时候gate off后，其它模块由于中断或者什么原因又去访问该模块资源，造成死机，这个一般发生在多媒体部分，如VPU这类的很多模块在共用资源的时候发生。

6.Resume的log停在”restart arm”后就没了，往往也是ddr的问题，需要检查ddr1.5v和ddr自身的稳定性。

Reboot问题

1.随机死机在kernel的启动过程中：

a)分析异常log看是否能找出原因，如果没有异常log打出，则连上ICE去dump log: info os-log。

b)测量死机现场的各路电是否正常，包括vcck，AO_EE，ddr1.5, 3.3v。防止发生PMU引起的跌落问题。如果是瞬间跌落又恢复了当然看不到。

c)排除vcck问题，通过vcck的动态调压表格把vcck定在最高值，并进行reboot煲机，如果不死后，则需要重新调整vcck表格。

d)排除ddr稳定性，可以降频DDR试试，并查看DDR纹波。

e)特定平台出现随机死机，且以上条目都排除后，则需要排查pll patch问题（针对M8/M8baby）。确保该patch已经打入。

2.偶尔死在uboot中，出现ucl解压失败。
该问题一般是ddr问题。

3.reboot准备关机的时候死机
   这个问题往往和一些driver的shut_off的call back有关，需要注意log的位置或者连ICE，一般能看到我们想要的信息。
   我们需要#define CONFIG_ARM_FLUSH_CONSOLE_ON_RESTART这个config来看更多reboot前的log信息。但是打开这个config也会有一定的风险，会出现console的输出清理死锁问题。#define CONFIG_ARM_FLUSH_CONSOLE_ON_RESTART这个config是否打开，包括defconfig的和code中的两个地方。

关于watchdog开关问题

3.10:
amlogic-watchdog{
       compatible = "amlogic,aml-wdt";
status = "okay";       
one-second=<0x100000>;
       min_timeout=<1>;
       max_timeout=<41>;
       default_timeout=<5>;
       reset_watchdog_method=<1>;//0:sysfs,1:kernel
       reset_watchdog_time=<2>;
       shutdown_timeout=<10>;
  };
 
status = "okay";      "okay" :enable this driver,"disable":disable this driver  默认 disable 
one-second=<0x100000>;   watch dog 计时1s 的count 数目。
 
     min_timeout=<1>;  watch dog 的最小超时时间
 
     max_timeout=<41>;watch dog 的最大超时时间
     default_timeout=<5>;watch dog 默认超时时间
     reset_watchdog_method=<1>;//0:sysfs,1:kernel  选择 通过上层喂狗还是kernel 喂狗
     reset_watchdog_time=<2>; kernel喂狗的时间间隔
     shutdown_timeout=<10>;关机的时候 设置watch dog 超时时间

目前aml watch dog 属于硬件watch dog覆盖的死机种类(kernel 喂狗的方式)：

硬件死机：

1 Unable to handle kernel NULL pointer dereference at virtual address 00000000

测试方法：

int *p=NULL;
*p=2;

2 硬件死机，例如bus上的死机。

软件死机 硬件watch dog 无法覆盖，可以打开kernel的相关宏，可以解决部分软件死机的状况：

1 spin_lock 死锁：
CONFIG_LOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_PANIC_TIMEOUT=2

如果发生 spin_lock 死锁，系统20s 后dump stack 2秒后重启系统。

2 mutex 死锁 ，kernel 空间的while(1) 死循环
CONFIG_DETECT_HUNG_TASK=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_PANIC_TIMEOUT=2
 

120 秒后dump stack 2秒后重启系统

对于kernel，只是多开了几个线程，安兔兔 实测 对跑分没有影响。

3.0 boot moniter

CONFIG_BOOT_MONITOR=y 即可