蜗窝科技

@xiaoxie：OOB一般是指蓝牙之外的其他物理信道来交换配对所需要的信息，这个信道同时也用来发现设备，比如NFC。从云端来交换信息广义来说也算OOB，信道是802.11的WiFi，不过似乎没有这样用的。

@wangyunqian：分享下通过psci处理suspend_ops->enter的流程： PSCI(power supply control interface), 是arm定义的一套处理cpu on/off/suspend等的协议， 比如Linux-kernel发送相应的cpu operation到和Trust-Zone（EL3 by smc）或Hypervirsor(EL2 by hvc)，再由TZ或Hyp做对应的操作： 比如： Linux-kernel 要offline、suspend一个cpu，Hypervisor只是把这个cpu给其它的OS使用。 回到suspend： 1， psci初始化：suspend_set_ops(&psci_suspend_ops); static const struct platform_suspend_ops psci_suspend_ops = { .enter = psci_system_suspend_enter, }; 2， psci_system_suspend： static int psci_system_suspend(unsigned long unused) { return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND), __pa_symbol(cpu_resume), 0, 0); } 2.1，这里通过psci组装smc指令，跳转到TZ执行； 2.2 cpu_resume是物理地址； 2.3 Qualcom中TZ会和PMIC通信 power down此cpu； 2.4 唤醒cpu重新power-up时，第一步执行cpu_resume； 因为此时mmu还未打开，所以2.2必须传入cpu_resume的物理地址； cpu_resume中会打开mmu； 3， suspend_ops->enter，即 static int psci_system_suspend_enter(suspend_state_t state) { return cpu_suspend(0, psci_system_suspend); } arch/arm64/kernel/suspend.c int cpu_suspend(unsigned long arg, int (*fn)(unsigned long)) { struct sleep_stack_data state; if (__cpu_suspend_enter(&state)) { ret = psci_system_suspend(arg); } 4， arch/arm64/kernel/sleep.S ENTRY(__cpu_suspend_enter) 第一步保存当前lr到state中 stp x29, lr, [x0, #SLEEP_STACK_DATA_CALLEE_REGS] ... mov x0, #1 //这里返回1 ret ENDPROC(__cpu_suspend_enter) ENTRY(cpu_resume) bl el2_setup // if in EL2 drop to EL1 cleanly bl __cpu_setup /* enable the MMU early - so we can access sleep_save_stash by va */ bl __enable_mmu ldr x8, =_cpu_resume br x8 ENDPROC(cpu_resume) ENTRY(_cpu_resume) ... ldp x29, lr, [x29] //从之前的state中恢复lr mov x0, #0 //返回值为0 ret //return到__cpu_suspend_enter下一行 ENDPROC(_cpu_resume) 5， __cpu_suspend_enter/cpu_resume类似fork，有返回两次的效果： power-on-cpu时第一步会call cpu_resume； 而cpu_resume返回时会返回到__cpu_suspend_enter的下一行。 if (__cpu_suspend_enter(&state)) { /* 第一次返回1， 执行psci_system_suspend*/ ret = psci_system_suspend(arg); } else { //由于cpu_resume返回值为0，那么resume后执行这一步： __cpu_suspend_exit(); }

@wangyunqian：是的，比附 使用PSCI协议通过TrustZone（EL3/Secure-EL1）处理cpu_suspend时：https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#L306 cpu重新上电后，第一步会执行__pa_symbol(cpu_resume)，这里必须是物理地址。

@chenlifu2015：我让你看的目的不是为了让你确认是不是宏确认编译。而是让你看怎么根据CPU feature检测，动态替换代码的。默认情况下本身就是宏唯一确定了使用LL/SC的方式，只不过boot的时候会检测feature，如果支持LSE，就会把LSE的指令替换了LL/SC的方式。你通过编译是无法确定的。 另外你在arm32上测试有什么意义呢？CPU feature检测替换这块是arm64实现的，arm32是否实现了类似机制都不确定，你的测试能说明什么呢？ 你应该去看看这个宏定义的作用 #define ALTERNATIVE(oldinstr, newinstr, ...)

@smcdef：我看了下我使用的SDK中内核关于atomic的代码实现，可以确定这部分是通过编译宏来决定的，并且kprobe特性在编译时也没有被打开，因此可以排除kprobe和LSE的原因导致内核代码段hash发生变化，博主，还有其它的思路么，因为我在4.12的arm32位上计算内核hash是不会发生变化的，也就是说是可以关闭掉cpu feature带来的影响，博主，我猜测了一下，这种动态检测的特性能否通过配置宏来关闭呢

@callme_friend：.incbin伪指令用于将一个目标文件或数据文件包含到当前的源文件中，被包含的文件不作任何变动的存放在当前文件中，编译器从其后开始继续处理,"dts/dt.dtb"设备树文件，本质就是一二进制文件，且汇编指令中标签"_dtb_dt_begin"就表示地址，不用赋值的。。。

赞，解答了很多疑惑

很详细！花了很多时间看完

@chenlifu2015：例如atomic实现有2种方式，LSE和LL/SC。印象中LSE是armv8.2以后支持的特性。LL/SC是老的实现方式。你看看atomic实现的2个文件吧。

@smcdef：感谢博主的回复，我今天去了解了一下kprobe机制，确实可能会导致内核代码段被篡改，但您说的第一点我确实没找到相关资料，能方便一点一下么，比如说一个具体的机制我能够去熟悉，或许这个动态监测的机制能够通过配置宏关闭