问题1：MTS请教各位: 软件能判断ARM系统是上电冷启动复位还是运行中热复位吗?
问题2: 请教:为什么上电冷启动复位时RAM中的内容是随机的? 而当热复位时RAM中的内容却一定保持在热复位前的内容状态? (所说RAM是指复位后未被启动程序覆盖的RAM区)
微信群中的讨论摘要：
1：@Terry 通过查看RAM中预设的复位标记位来判断是上电复位还是热复位，似乎不可靠? 因为上电冷复位后RAM中的内容是随机的，不能做为判断依据。
2：系统运行中的复位，都是热复位，包括看门狗
3：@MTS 你先指明是ARM的哪类产品？AP还是MCU
4：@SimonLuk 主要是集成ARM内核的SOC，包括McU。那个问题是否由RAM内存控制器的硬件设计决定? 各个系统都是一样的?
5：有人写过这样的博客，你的问题应该和ram,及arm的设计有关，至于为何得细看了
6：@Terry 那篇博客我看到了，它是通过在RAM中设置标志位来判断是上电冷启动复位还是热复位。我觉得有点问题，就像它博客中所说的“上电复位冷启动后内外RAM的内容是随机的"，但它却以这个随机不确定的RAM标志位作为判断依据?
7：@MTS 在实际应用中，好像没有不对ram进行初始化，而使用其中的内容。纠结这个问题的应用背景是什么呢？
8：无论是热启动还是冷启动。程序开始执行，肯定首先是对ram进行初始化。
9：不用纠结热复位还是冷启动，对于reset，要搞清的是，无论通过何种方式触发的reset，作用域在哪?
10：SRAM的原理，参考RS触发器。AP那边的结构我不清楚，MCU这边很简单，图我上次都给你看过了，无论什么形式的系统复位，最后执行的动作都是相同一个（备份域复位例外）。复位后，寄存器恢复复位值，RAM也会在初始化代码的作用下清空。
11：@MTS 我不明白你纠结复位后保留RAM内容的目的是什么。复位原本的目的，就是让芯片重新开始。如果只是要“从头”开始，写段asm代码，改变寄存器的值就可以了
12：@SimonLuk 复位后保留RAM内容的目的是“程序重运行，但RAM中指定位置的数据要保留不变，可被重新调用。(RAM中指定位置的数据不能初始化清0)
13：@MTS 写代码要假设复位后ram是随机内容，既不是0，也不是原来的内容不变。其他免谈。否则可靠性就是儿戏。
14：@傻孩子 对于DRAM，由于复位保持时间和刷新时间等问题，内容可能会丢失。对于SRAM，只要保持不断电、不写，内容就不会变，这是RS触发器的原理。
15：@SimonLuk 硬件是硬件，软件要可靠，要逻辑确定就，要可移植性强，要偷懒，就必须做这种假设。太依赖具体某一平台的硬件特性，就是给软件工程师自己找麻烦。
16：@MTS 你的编程思想值得商榷。你是要把地球用原子弹炸掉，然后只留一片诺亚方舟？
17：@MTS 那就使用带电ram
18：@MTS 想要检查是否复位，不用检查RAM的内容，那是20年前单片机的做法。现在只要检查Systick就够了，只要复位，Systick必定从0开始。
19：@SimonLuk 还有，Systick是否为0貌似不一定的……我要找菜式家族确认下
20：@傻孩子 Systick的Val寄存器，复位后会清零的
21：@SimonLuk 真的不一定的，有一个掉电保护模式，不太常见，但真的有
22：@傻孩子 噢，那可能是AP吧，MCU没有
23：@SimonLuk MCU有的，我去确认过的
24：@傻孩子 MCU只有备份域吧
25：@SimonLuk 嗯，类似。但醒来的时候和复位大体类似。但部分寄存器可能不为0
26：@Williamgao systick的计数值，在复位后是否清零？Cortex-M的SysTick寄存器，复位后一定是0么？
27：@傻孩子 备份域的寄存器是不清零的
28：@傻孩子 systick 文档写的是unkown
29：@SimonLuk 结论有了，所以，不能依赖这个值。你依赖，出问题，arm只能一脸懵逼。经验结论和design spec（TRM）你信谁？——ARM说我不管。如果你不相信今天的讨论，请发邮件到support-core@arm.com
30：@傻孩子 我回去翻手册，有写的。这个值我是确认过的
31：@SimonLuk 具体核确认过其实是两回事……因为spec写unknown ，所以，做实现的人可以给他0，也可以不管（悬浮）
32：@傻孩子 复位后，Systick VAL值硬件上确实是Unknow，但是只要没有另外定义，初始化的时候，就会清零。
上面继续讨论的摘要:
37: MTS: 昨天关于冷热复位的讨论, 还有问题再请教下: 系统上电或复位时对RAM内存初始化清0, 是否一定必要? (加载的程序数据反正要覆盖RAM原始数据, 似乎初始化不初始化可靠性一样? RAM内存为什么要初始化清0 ? )
38: 姚家湾: 不一定要初始化成零。有的编译器如果不初始化就引用会报错
39: 苏州盛科网络-JAY: @MTS ，完全是和SoC实现强相关的，没有所谓的必要，只是不同厂家的不同做法而已
40: MTS :怎么会和SOC设计强相关呢? 内存RAM初始化或不初始化是软件问题,
41: 苏州盛科网络-JAY: 我说的是reset后硬件来做这个事情. 软件来刷这个效率太低.
现在的设备ddr容量动辄几个GB.
42: MTS: SOC有硬件在复位时固定来做RAM内存初始化? RAM内存是可扩充可变的, 硬件如何识别RAM大小变化?
43: 苏州盛科网络-JAY: 硬件层面的bist. 芯片有这样的应用场景，设计时考虑了，做起来不复杂，大小的判断这些都简单
44: SimonLuk : 分开看内置的SRAM和外部的DRAM的处理方法
45: MTK驱动小子: 刚咨询了DRAM同事，SOC在上电的时候会做DRAM颗粒的reset,如果不做可能会有上电时序问题。
DRAM 做reset 动作就会把所有memory都清零，这个是HW实现的，非常快.
46: bunny：内置SRAM 不同的soc design采用的策略不尽相同，是reset成0 还是直接不管，对于软件来说不要去做这个假设，软件改该怎么写还是怎么写，该初始化的局部变量，全局变量，按编程规范来. 不要假定RAM当前是什么值.
47：苏州盛科网络-JAY: 不同的ddr接口类型其实也是不同的。
48：bunny：对于DRAM，要走一个严格的硬件流程，要做PHY 的training和calibration，配置DDR 控制器的timing参数. DDR memory 的内容会被init 成一个既定的pattern，可以是全0. 也可以是一个有规律的数值，取决于用的PHY，controller和DDR chip.
49：苏州盛科网络-JAY: 谁用谁负责
50：bunny：对于提到的RAM 大小可变带来的init 问题，如果硬件不操心的事，软件操这心干嘛. 软件只要保证访问的地址空间是有效，不要做变量未初始化访问就够了.
51：MTS： 1: 若系统及DRAM都正常运行后, 进行热复位, 是否就没必要再对内存RAM进行初始化了 ? 目前热复位仍然初始化只是为简单重复调用? 2: 热复位对DRAM的保持和刷新及时序是否应没影响? 若不初始化, 热复位后RAM中数据是否应是保持不变?
52：bunny： 1. 取决于你热复位的作用范围; 2 如果只reset soc 本身，不reset DRAM chip，就目前来看，LPDDRx 类型的chip 可能会calibration 和访问异常; 3. DRAM 刷新要分情况，是self refresh 还是正常工作模式的下的refresh, 如果ddr 不在self refresh mode, soc 热复位过程中数据丢失不可避免.
53：bunny： DRAM 是稳定系统稳定性的一个黑洞，不要做这种只复位SOC还想保持DRAM 内容不变的需求. DRAM 的稳定性的问题一般都非常棘手.
54：bunny：要想SOC 掉电（？是:热复位），DRAM 保持内容不变，这需要非常好的SOC 设计和 电路板级设计.
55: bunny：如果SOC 的初始定义的时候就能满足这样的需求，一切都好办，如果满足不了，是给自己掘坟.
56: SimonLuk : 动手做一次就知道的事情，其实没必要如此讨论
57: MTS: @SimonLuk 在ST32上有人这么做过, 热复位后查看未初始化的RAM数据,是没有变化, 但对可靠性没底, 所以想从硬件原理上分析证明下.
58: JIZHAOLIN: @MTS 热复位，如果没有断电，而且你期间没有操作，RAM里面数据应该是不变的。
59: MTS: @MTK 驱动小子 请问下:你说的DRAM Reset初始化信号，是否是RoM软件驱动控制输出的? 不是纯硬件Reset信号?
60: MTK 驱动小子 ：@MTS 咨询了下更资深的DRAM同事，dram如果要保持数据不丢失，需要周期性的进行fresh，刷新的目的是保持dram电容一直有电。正常工作的时候，fresh是cpu中的dram ctrl来做的，在reset的时候，例如reboot,cpu会断电，dram ctrl就没机会再刷新dram了，电容无法及时通过刷新保持数据，数据全部为0。冷启动的时候，DRAM颗粒电容也没电，数据也是0
61：MTK 驱动小子 ：@MTS 我们公司有做过一种solution,在suspend的时候为了节省功耗，vcore会断电，但是dram会进入self refresh且保持有电，把vcore的状态全部保存在dram中，resume的时候再从dram恢复vcore，
62：YANGLIWEI-And8：@MTK 驱动小子 vcore的状态是指的cpu的状态么？
63：MTK 驱动小子 ：vcore说的是cpu
64：YANGLIWEI-And8：@MTK 驱动小子 再多问一句的，因为自己没想明白，l2 cache里面的内容在vcore保存的ram的时候有什么特别处理么？
65：MTK 驱动小子 ：不会保存cache内容，只会保存cpu的状态，这部分都是汇编，看不懂。
66：YANGLIWEI-And8：能看懂的都是大神，我也是纯好奇。
67：MTS: @MTK 驱动小子 谢谢. 下面是我的理解,请大家指正: 1、CPU软件驱动可按需设置DRAM的reset初始化、DRAM的dram controler刷新模式、和软件设置DRAM自己的self refresh模式； 2、CPU在进入suspend节电模式前, CPU先要设置DRAM进入自己的self refresh模式; 而后CPU再断电, 进入suspend节电模式; 此时DRAM内的数据是保持不变的；当CPU恢复正常模式时，DRAM内未被覆盖区域的数据是保持不变的，并可被正常调用；3、按上面SOC的设计功能，则可设计实现“热复位后不对DRAM初始化、并在热复位后保持DRAM内未被覆盖区域的数据是不变的，并可被正常调用”，即：在热复位前CPU先要设置DRAM进入自己的self refresh模式；而后热复位，跳过DRAM初始化步骤完成重启流程；此时，DRAM内未被覆盖区域的数据是保持不变的，并可被正常调用；4、CPU的suspend节电模式是目前系统常用的节电模式，其硬件软件都经过长期验证、成熟可靠，所以，“热复位后不对DRAM初始化、并在热复位后保持DRAM内未被覆盖区域的数据是不变的，并可被正常调用”功能设计也是可实现稳定可靠的。
68：不做咸鱼：os在申请内存给进程的时候，都会fill0的。可以减少泄密，并保证程序正常运行。
69：孙辉: @不做咸鱼 但是进程有自己的堆管理器 重用之前未必会置0
70: 不做咸鱼：memory 管理器一般都会做. 不敏感的可以不做，不影响系统运行.
71: MTS：@不做咸鱼 若做“热复位后不对DRAM初始化…”功能设计,肯定要对现有软件流程做相应修改, 匹配; 有风险, 要慎重; 但从上面的讨论看,应肯定能设计实现,并能做到稳定可靠.
72: bunny：讨论好几天了, 我始终没理解你热复位到底是复位cpu core 还是整个soc?
73: bunny：一个一年1/3 时间都在搞cpu 低功耗和 dram 低功耗的人表示已经阵亡
74: MTS: @bunny 热复位，就是在系统运行过程中的复位，软件系统从开始重新装载运行一次。目前想实现的就是：热复位时，DRAM中未被覆盖区域的数据不丢失，可重新调用。
75: MTK 驱动小子 ：这样相比DRAM数据全reaet,会有哪个好处？
76: claud：可以实现快速启动
77：PrTs：那这样看，可以热复位，说明系统没有 KASLR。
78：MTS：@MTK 驱动小子 DRAM中未被覆盖区域的数据，可重新调用，用于分析。
79：PrTs：从攻击者的角度看，也比较喜欢热复位。
80：bunny： 目前讨论这个问题，1. case 不清，2 热复位太笼统，一块soc 有多个power domain，clock domain 和 reset domain, 热复位到底要复位core 还是soc上其他domain 也要一起?
81：MTS：@bunny 我们还在继续研究， 还说不完整， 后面会继续请教大家
82：bunny：low power的case我估计和你目前描述的不是一个场景.
83：mts：@PrTS 请问KASLR是指什么？
84：PrTs：Kernel address space layout randomization
85：SimonLuk : 这个话题，实际上是要研究DRAM的控制和工作模式，跟CPU关系不是很大。
而且，已经接近钻牛角尖的范围了
86：MTS：目前想实现的就是：热复位时DRAM整体或部分区域不初始化，DRAM中未被覆盖区域的数据不丢失，可重新调用。 后面会做些尝试。
87：MTS：@Terry通过上面的讨论，你说的那篇博客
blog.csdn.net/.../8950593中，判断上电冷启动复位和热复位的方法，就是正确的。 当时我没理解清楚。
非常感谢MTS的总结，利人利己，赞