-
Bootloader的见鬼故障
【前面的话】在近几年的嵌入式社区中，流传着不少关于面相Cortex-M的Bootloader科普文章，借助这些文章，一些较为经典的代码片断和技巧得到了广泛的传播。 在从Bootloader跳转到用户APP的过程中，使用函数指针而非传统的汇编代码则成了一个家喻户晓的小技巧。相信类似下面 JumpToApp() 函数，你一定不会感到陌生： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 为了读懂这段代码，需要一些从事Cortex-M开发所需的“热知识”： 向量表是一个由 32bit 数据构成的数组 数组的第一个元素是 uintptr_t 类型的指针，保存着复位后主栈顶指针（MSP）的初始值。 从数组第二个元素开始，保存的是 (void (*)(void)) 类型的异常处理程序地址（BIT0固定为1，表示异常处理程序使用Thumb指令集进行编码） 数组的第二个元素保存的是复位异常处理程序的地址（Reset_Handler） 从理论上说，要想保证APP能正常执行，Bootloader通常要在跳转前“隐藏自己存在过的事实”——需要“对房间进行适度的清理”，并模拟芯片硬件的一些行为——假装芯片复位后是直接从APP开始执行的。 总结来说，Bootloader在跳转到App之前需要做两件事： 1. 清理房间——仿佛Bootloader从未执行过一样 2. 模拟处理器的硬件的一些复位行为——假装芯片从复位开始就直接从APP开始执行 一般来说，做到上述两点，就可以实现App将Bootloader视作黑盒子的效果，从而带来极高的兼容性。甚至在App注入了“跳床（trumpline）”的情况下，实现App既可以独立开发、调试和运行，也可以不经修改的与Bootloader一起工作的奇效。 如何在App中加入“跳床（trumpline）”值得专门再写一篇独立的文章，不是本文所需关注的重点，请允许我暂且略过。 这里，“清理房间”的步骤与Bootloader具体“弄脏了什么”（或者说使用了什么资源）有关；而“模拟处理器硬件的一些复位行为”就较为简单和具体：即，从Bootloader跳转到App前的最后两个步骤为： 从APP的向量表中读取MSP的初始值并以此来初始化MSP寄存器； 从APP的向量表中读取Reset_Handler的值，并跳转到其中去执行——完成从Bootloader到APP的权利交接。 结合前面的例子代码，值得我们关注的部分是： 1. 使用自定义的函数指针类型 pFunction 定义一个局部变量： pFunction Jump_To_Application; 2. 根据向量表的首地址 addr 读取第一个元素——作为MSP的初始值暂时保存在局部变量 StackAddr 中： StackAddr = *(__IO uint32_t*)addr; 3. 根据向量表的首地址 addr 读取第二个元素——将Reset_Handler的首地址保存到局部变量 ResetVector 中： ResetVector = *(__IO uint32_t *)(addr + 4); 4. 设置栈顶指针MSP寄存器： __set_MSP(StackAddr); 5. 通过函数指针完成从Bootloader到App的跳转： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 其实，无论具体的代码如何，只要实现步骤与上述类似，就存在一个隐藏较深的漏洞，而漏洞的“触发与否”则完全“看脸”——简单来说： 只要你是按照上述方法来实现从Bootloader到App的跳转的，那么就一定存在问题——而“似乎可以正常工作”就只是你运气较好，或者“由此引发的问题暂时未能引发注意”罢了。 在你试图争辩“老子代码已经量产了也没有什么不妥”之前，我们先来看看漏洞的原理是什么——在知其所以然后，如何评估风险就是你们自己的事情了。 【C语言基础设施是什么】 嵌入式系统的信息安全（Security）建立在基础设施安全（Safety）的基础之上。 由于“确保信息安全的很多机制”本质上是一套建立在“基础设施能够正常工作”这一前提之上的规则和逻辑，因此很多针对信息安全的攻击往往会绕开信息安全的“马奇诺防线”，转而攻击基础设施。芯片数字逻辑的基础设施是时钟源、供电、总线时序、复位时序等等，因此，针对硬件基础设施的攻击通常也就是针对时钟源、电源、总线时序和复位时序的攻击。此时，好奇的小伙伴会产生疑问：固件一般由C语言进行编写，那么C语言所依赖的基础设施又是什么呢？ 对C语言编译器来说，栈的作用是无可替代的： 函数调用 函数间的参数传递 分配局部变量 暂时保存通用寄存器中的内容 …… 可以说，离开了栈C语言寸步难行。因此对很多芯片来说，复位后为了执行用户使用C语言编译的代码，第一个步骤就是要实现栈的初始化。 作为一个有趣的“冷知识”，Cortex-M在宣传中一直强调自己“支持完全使用C语言进行开发”，这让很多人“丈二和尚摸不着头脑”甚至觉得“非常可笑”——因为这年月连51都支持用户使用C语言进行开发了，你这里说的“Cortex-M支持使用C语言进行开发”有什么意义呢？ 其实门道就在这里： 由于Cortex-M处理器会在复位时由硬件完成对C语言基础设施（也就是栈顶指针MSP）的初始化，因此无论是理论上还是实践中，从复位异常处理程序Reset_Handler开始用户就可以完全可以使用C语言进行开发了，而整个启动代码（startup）也可以全然不涉及任何汇编； 由于Cortex-M的向量表是一个完全由 32位整数（uintptr_t）构成的数组——保存的都是地址而非具体代码，可以使用C语言的数据结构直接进行描述——因此也完全不需要汇编语言的介入。 这种从复位一开始就完全不需要汇编介入的友好环境才是Cortex-M声称自己“支持完全使用C语言进行开发”的真实意义和底气。从这一角度出发，只要某个芯片架构复位后必须要通过软件来初始化栈顶指针，就不符合“从出生的那一刻就可以使用C语言”的基本要求。 【C语言编译器的约定】 栈对C语言来说如此重要，以至于编译器一直有一条默认的约定，即： 栈必须完全交由C语言编译器进行管理（或者用户对栈的操作必须符合对应平台所提供的调用规约，比如Arm的AAPCS规约）。 简而言之，如果你“偷偷摸摸”的修改了栈顶指针，C语言编译器是会“假装”完全不知道的，而此时所产生的后果C语言编译器会默认自己完全不用负责。 回头再看这段代码： StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 虽然我们觉得自己“正大光明”的使用了 __set_MSP() 来修改了栈顶指针，但它实际上是一段C语言编译器并不理解其具体功能的在线汇编——在编译器看来，无论是谁提供的 __set_MSP()，只要是在线汇编，这就算是用户代码——是编译器管不到的地带。 /** \brief Set Priority Mask \details Assigns the given value to the Priority Mask Register. \param [in] priMask Priority Mask */__STATIC_FORCEINLINE void __set_PRIMASK(uint32_t priMask){ __ASM volatile ("MSR primask, %0" : : "r" (priMask) : "memory");} 或者说：C语言编译器一般情况下会默认你“无论如何都不会修改栈顶指针”——它不仅管不着，也不想管。 从这点来看，上述代码的确打破了这份约定。即便如此，很多小伙伴会心理倔强的认为：我就这么改了，怎么DE了吧？！ 【问题的分析】 从原理上说，开篇那个典型的Bootloader跳转代码所存在的问题已经昭然若揭： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 我们不妨结合上述代码反汇编的结果进行深入解析： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC000000 b082 SUB sp,sp,#8000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0]000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4]00001e b002 ADD sp,sp,#8000020 4700 BX r0 |L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lr ENDP 000026 0000 DCW 0x0000 |L2.40| DCD 0x2fff0000 注意这里，StackAddr、ResetVector是两个局部变量，由编译器在栈中进行分配。汇编指令将SP指针向栈底挪动8个字节就是这个意思： 000000 b082 SUB sp,sp,#8 虽然 JumpMask 也是局部变量，但编译器根据自己判断认为它“命不久矣”，因此直接将它分配到了通用寄存器r2中，并配合r1和sp完成了后续运算。这里： __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { ... } 对应： 000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|...|L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lrENDP 000026 0000 DCW 0x0000|L2.40|DCD 0x2fff0000 考虑到JumpMask的内容与本文无关，不妨暂且跳过。 接下来就是重头戏了： 编译器按照用户的指示读取栈顶指针MSP的初始值，并保存在StackAddr中： StackAddr = *(__IO uint32_t*)addr; 对应的汇编是： 000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0] 根据Arm的AAPCS调用规约，编译器在调用函数时会使用R0~R3来传递前4个符合条件的参数（这里的条件可以简单理解为每个参数的宽度要小于等于32bit）。根据函数原型 void JumpToApp(uint32_t addr); 可知，r0 中保存的就是形参 addr 的值。所以第一句汇编的意思就是：根据 （addr + 0）作为地址读取一个uint32_t型的数据保存到r1中。 第二句汇编中，栈顶指针sp此时实际上指向局部变量 StackAddr，因此其含义就是将通用寄存器r1中的值保存到局部变量 StackAddr 中。 对于局部变量 ResetVector 的读取操作，编译器的处理如出一辙： ResetVector = *(__IO uint32_t *)(addr + 4); 对应： 000016 6840 LDR r0,[r0,#4]00001c 9001 STR r0,[sp,#4] 其实就是从 (addr + 4) 的位置读取 32bit 整数，然后保存到r0里，并随即保存到sp所指向的局部变量 ResetVector 中。到这里，细心地小伙伴会立即跳起来说“不对啊，原文不是这样的！”。是的，这也是最有趣的地方。实际的汇编原文如下： 000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4] 作为提醒，它对应的C代码如下： ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); 后面的 __set_MSP(StackAddr) 所对应的汇编代码 MSR MSR,r1 居然插入到了ResetVector赋值语句的中间？！ “C语言编译器这么自由的么？” “在我使用sp之前把栈顶指针更新了？！” 先别激动，还记得我们和C语言编译器之间的约定么？C语言编译器默认我们在任何时候都不应该修改栈顶指针。因此在他看来，“你 MSR 指令操作的是r1，关我sp和r0啥事”？“我就算随意更改顺序应该对你一毛钱影响都没有！（因为我不关心、也没法知道用户线汇编语句的具体效果，因此我只关心涉事的通用寄存器是否存在冲突）” 上述“骚操作”的后果是：保存在r0中的Reset_Handler地址值被保存到了新栈中（MSP + 4）的位置。这立即带来两个潜在后果： 由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+4）实际上已经超出栈的合法范围了。 这一操作与其说是会覆盖栈后续的存储空间，倒不如说风险主要体现在BusFault上——因为相当一部分人习惯将栈放到SRAM的最末尾，而MSP+4直接超出SRAM的有效范围。 我们以为的ResetVector其实已经不在原本C编译器所安排的地址上了。 精彩的还在后面： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 对应的翻译是： 00001e b002 ADD sp,sp,#8000020 4700 BX r0 通过前面的分析，我们知道，此时r0中保存的是Reset_Handler的地址，因此 BX r0 能够成功完成从Bootloader到APP的跳转——也许你会松一口气——好像局部变量ResetVector的错位也没引起严重的后果嘛。 看似如此，但真正吓人的是C语言编译器随后对局部变量的释放： 00001e b002 ADD sp,sp,#8 它与一开始局部变量的分配形成呼应： 000000 b082 SUB sp,sp,#8...00001e b002 ADD sp,sp,#8 好借好还，再借不难。但此sp非彼sp了呀！ 这里由于JumpToApp没有加上__NO_RETURN的修饰，因此C编译器并不知道这个函数是有去无回的，因此仍然会像往常一样在函数退出时释放局部变量。 就像刚才分析的那样：由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+8）实际上已经超出栈存储空间的合法范围了。 考虑到相当一部分人习惯将栈放到SRAM的最末尾，而MSP+8直接超出SRAM的有效范围，即便刚跳转到APP的时候还不会有事，但凡APP用了任何压栈操作，（无论是BusFault还是地址空间绕回）就很有可能产生灾难性的后果。 【宏观分析】 就事论事的讲，单从汇编分析来看，上述代码所产生的风险似乎是可控的，甚至某些人会觉得可以“忽略不计”。但最可怕的也就在这里，原因如下： 从原理上说，将关键信息保存在依赖栈的局部变量中，然后在编译器不知情的情况下替换了栈所在的位置，此后只要产生对相关局部变量的访问就有可能出现“刻舟求剑”的数据错误。这种问题是“系统性的”、“原理性的”。 （此图由GorgonMeducer借助GPT4进行一系列关键词调校、配上台词后获得） 不同编译器、同一编译器的不同版本、同一版本的不同优化选项都有可能对同一段C语言代码产生不同的编译结果，因此哪怕我们经过上述分析得出某一段汇编代码似乎不会产生特别严重的后果，在严谨的工程实践上，这也只能算做是“侥幸”，是埋下了一颗不知道什么时候以什么方式引爆的定时炸弹。 根据用户Bootloader代码在修改 MSP 前后对局部变量的使用情况不同、考虑到用户APP行为的不确定性、由上述缺陷代码所产生的Bootloader与APP之间配合问题的组合多种多样、由于涉及到用户栈顶指针位置的不确定性以及新的栈存储器空间中内容的随机性，最终体现出来的现象也是完全随机的。用人话说就是，经常性的“活见鬼” 【解决方案】 既然我们知道不能对上述缺陷代码抱有侥幸心理，该如何妥善解决呢？第一个思路：既然问题是由栈导致的，那么直接让编译器用通用寄存器来保存关键局部变量不就行了？修改代码为： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; register uint32_t StackAddr; register uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 相同编译环境下得出的结果为： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC 000002 6801 LDR r1,[r0,#0]000004 4011 ANDS r1,r1,r2000006 2201 MOVS r2,#1000008 0752 LSLS r2,r2,#2900000a 4291 CMP r1,r200000c d104 BNE |L2.24| 00000e 6801 LDR r1,[r0,#0]000010 6840 LDR r0,[r0,#4]000012 f3818808 MSR MSP,r1 000016 4700 BX r0 |L2.24|000018 4770 BX lr ENDP 00001a 0000 DCW 0x0000 |L2.28| DCD 0x2fff0000 可见，上述汇编中半个 sp 的影子都没看到，问题算是得到了解决。 然而，需要注意的是 register 关键字对编译器来说只是一个“建议”，它听不听你的还不一定。加之上述例子代码本身相当简单，涉及到的局部变量数量有限，因此问题似乎得到了解决。 倘若编译器发现你大量使用 register 关键字导致实际可用的通用寄存器数量入不敷出，大概率还是会用栈来进行过渡的——此时，哪些局部变量用栈，哪些用通用寄存器就完全看编译器的心情了。 进一步的，不同编译器、不同版本、不同优化选项又会带来大量不可控的变数。 因此就算使用 register 修饰关键局部变量的方法可以救一时之疾（“只怪老板催我催得紧，莫怪我走后洪水滔天”），也算不得妥当。 第二个思路：既然问题出在局部变量上，我用静态（或者全局）变量不就可以了？修改源代码为： #include "cmsis_compiler.h" typedef void (*pFunction)(void); __NO_RETURNvoid JumpToApp(uint32_t addr){ pFunction Jump_To_Application; static uint32_t StackAddr; static uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 这种方法看似稳如老狗，实际效果可能也不差，但还是存在隐患，因为它“没有完全杜绝编译器会使用栈的情况”，只要我们还会通过 __set_MSP() 在C语言编译器不知道的情况下更新栈顶指针，风险自始至终都是存在的。 对某些连warning都要全数消灭的团队来说，上述方案多半也是不可容忍的。 第三个思路：完全用汇编来处理从Bootloader到App的最后步骤。对此我只想说：稳定可靠，正解。 只不过需要注意的是：这里整个函数都需要用纯汇编打造，而不只是在C函数内容使用在线汇编。 原因很简单：既然我们已经下定决心要追求极端确定性，就不应该使用线汇编这种与C语言存在某些“暧昧交互”的方式——因为它仍然会引入一些意想不到的不确定性。 本着一不做二不休的态度，完全使用汇编代码来编写跳转代码才是万全之策。 【说在后面的话】 在使用栈的情况下，on-fly 的修改栈顶指针就好比在飞行途中更换引擎——不是不行，只是要求有亿点点高。 我在微信群中帮读者分析各类Bootloader的见鬼故障时，经常在大费周章的一通分析和调试后，发现问题的罪魁祸首就是跳转代码。可怕的是，几乎每个故障的具体现象都各不相同，表现出的随机性也常常让人怀疑是不是硬件本身存在问题，亦或是产品工作现场的电磁环境较为恶劣。最要命的当数那种“偶尔出现”而复现条件颇为玄学的情形，甚至在办公室环境下完全无法重现的也大有人在。同样的问题出的多了，我几乎在每次帮人调试Bootloader时都会习惯性的先要求检查跳转代码——虽然不会每次都能猜个正着，但也有个恐怖的十之七八。这也许是某种幸存者偏差吧——毕竟大部分普通问题大家自己总能解决，到我这里的多半就是“驱鬼”了。见得多了，我突然发现，出问题的代码大多使用函数指针来实现跳转——而用局部变量来保存函数指针又成了大家自然而然的选择。加之此前很多文章都曾大规模科普上述技巧，甚至是直接包含一些存在缺陷的Bootloader范例代码，实际受影响的范围真是“细思恐极”。特此撰文，为您解惑。
01-03 13浏览 -
脑洞有多大，MCU就能玩得有多花
都说MCU本身不算什么高级东西，在MCU开发过程中，需要按照一定的标准化来执行，比如对变量，函数的定义，要确定他的生命周期，调用范围，访问条件等；常用的通信协议读写的协议往往应该抽象化，规定固定的输入输出，方便产品移植。 但实际上，很多时候，针对同一个需求其实有多种实现方案，但总有一个最优解。所以在这个过程中，总会有一些“脑洞大开”的操作，为人提供很多思路，今天就举几个例子给大家作为参考。 那些很惊艳的用法 当需要通过串口接收一串不定长数据时，可以使用串口空闲中断；这样就可以避免每接收到一个字符就需要进入中断进行处理，可以减少程序进入中断次数从而提高效率。 当需要测量一个波形的频率时，很多人会选择外部中断，其实通过定时器的外部时钟输入计数波形边沿，然后定时读取计数值计算频率的方式可以大大减少中断触发频率，提高程序执行效率。 在处理复杂的多任务场景时，可以利用实时操作系统（RTOS）来管理任务调度，提高系统的响应性和资源利用率。 对于需要低功耗运行的场景，可以采用动态电压频率调整（DVFS）技术，根据系统负载实时调整 MCU 的工作电压和频率，以降低功耗。 在进行数据存储时，采用闪存的磨损均衡算法，延长闪存的使用寿命。 利用硬件加密模块（如 AES 加密引擎）来保障数据的安全性和保密性，而不是通过软件实现加密，提高加密效率和安全性。 对于传感器数据的处理，采用数字滤波算法（如卡尔曼滤波），提高数据的准确性和稳定性。 当需要与多个设备进行通信时，采用总线仲裁机制和优先级设置，确保通信的高效和稳定。 在进行电源管理时，通过监测电源电压和电流，实现智能的电源管理策略，例如在低电量时进入低功耗模式。 对于实时性要求极高的控制任务，采用硬件直接触发中断，而不是通过软件轮询，减少响应延迟。 在单片机上跑的任何非线性系统的动态控制，都是高级用法。 用单片机去实现某种特殊的运动控制，赚很多钱，就是高级用法。 GPIO模拟一切 名为ShiinaKaze的网友，就非常“勇”，做了一个很折磨的事。 他用STM32F1利用GPIO模拟摄像头接口驱动OV2640摄像头模块。他表示，这是一个很折磨人的过程，我最多优化到了 1.5 FPSQ，所以选型一定要选好，不要折磨自己。设备采用STM32F103C8T6，OV2640，实现效果如下： OV2640实际时序图： 这个项目难点在于： 1.SCCB 模拟:SCCB 是12C-bus 的改版，主要是 OV2640 模块没有上拉电阻，无法进行通信，花了好长时间才发现这个问题； 2.并行接口的模拟:如果使用 IO 模拟的话，只能达到1FPS，但是使用了 Timer 和 DMA，就可以达到 1.5～2 FPS。 关于 image sensor 的数据接收和处理的问题背景：现有 ov2640 image sensor，接口为 DCMI（并行接口）问题：现有 STM32H7 想获取 OV2640 的 mjpeg 流数据，并通过传输数据到 PC 软件 1.采用 USART 还是 USB？ 2.接收数据选择哪种中断，Line interrupt 还是 Frame interrupt ？ 3.DCMI 通过 DMA 将数据转到 RAM 中的 Buffer，那么 Buffer 该如何设计，是设置一块大的连续 buffer？还是需要做一个 ring buffer，避免数据覆盖和数据顺乱？ 4.触发中断后，是否关闭 DCMI 和 DMA ？ 嵌入式软件架构挺重要的，特别是大型项目。这是 STM32 的软件架构，不知道各位还有没有其他架构。 有网友吐槽，你要是在学校，我敬你是条汉子，你要是在工作岗位上干这鸟事，那你们的架构也太坏了。而他也表示——“我错了，再也不模拟了。” 关于MCU不一样的观点 虽然如此，很多人还是认为，MCU不高级，使用单片机也不高级。高级的内容都是可以发论文的，使用单片机发不了论文。但使用单片机解决指定的任务，这很高级。 尤其是上面所说的一些例子，确实是MCU外设的一些高端玩法。只不过，这些机制可能只是一种标准用法。名为lion187的网友就表示，毕竟许多硬件机制有实际需求后才添加进来的，比如接收不定长数据，最初没有超时中断的情况下只能软件实现，极大的浪费了CPU的效率，所以才设计了超时中断来减少软件工作量，进而形成了一种标准使用方法。 当然，这也是芯片设计和制造工艺的提升带来的红利，早期芯片设计和工艺无法满足复杂外设电路时，谁也不敢会去想用硬件来实现这么复杂的功能，任何产品的开发，都离不开具体业务需求，MCU也不例外， 对产品来说，MCU外设的驱动只是完成开发的基本要素，更多的工作是围绕着业务逻辑展开的应用程序的开发。这时候数据结构与算法，各种控制算法和数值计算方法，设计模式，软件工程和设计理念成了高级的东西。 比如说，Linux 内核中的各驱动子系统的设计，设备对象和驱动对象这些沿用了 C++ 面向对象编程的思路，其实也可以沿用到 MCU的开发中，将设备与驱动分离，就可以使用同一套驱动算法来实现同类设备的不同驱动方法， 比如:同一个 UART 驱动可以根据配置的不同来驱动 UARTO，也可以驱动 UART1，而且波特率也可以不同(只要为 UART 类创建不同的实例对象就可以了，用 C 语言就行)，这就是 C++ 中方法与属性分离带来的好处。 同样在业务应用部分，单件模式、工厂模式等设计模式，状态机模型的使用也会给开发带来很多便利，使系统结构清晰，有效减少Bug数量，且易于维护和扩展。 当然，也有人认为，论高级还得是FPGA。就比如AMD（赛灵思）的ZYNQ，当你需要通过串口接收一串不定长数据时，可以直接用Programmable Logic部分写一个专用的，最终结果放到DRAM里，发个信号通知ARM处理器来读就好了；当你需要测量一个波形的频率时，可以直接用Programmable Logic部分写一个专用的，实时不间断测量。这就很高级。 所以，对此你有什么看法，你有什么很“高级”的用法想要分享？
01-03 44浏览 -
-
STM32最小系统板电路知识学习
STM32最小系统板电路知识学习 单片机最小系统是指用最少的电路组成单片机可以工作的系统，通常最小系统包含：电源电路、时钟电路、复位电路、调试/下载电路，对于STM32还需要启动选择电路。总之，刚开始如果不太懂电路的话，就抄别人的电路，然后自己拼凑。下图为stm32c8t6经典电路原理图 文章目录 STM32最小系统板电路知识学习 一、电源转换电路 二、JTAG/SWD调试接口电路 三、时钟电路 四、复位电路 提示：以下是本篇文章正文内容，下面案例可供参考 一、电源转换电路 开发板通常采用USB供电，通常USB都为5V，因此需要将5V转换成3.3V，使用TPS73633或者AMS1117芯片电源芯片即可实现。 首先设计电源入口部分，现在大多数开发板所使用的都是USB的5V供电，所以我们本次设计也采用USB接口供电，所以我们电源接口就采用5Pin的mini贴片的USB，将5V的电源引入开发板使用，其电路图如下，1脚为电源正极，5脚为负极，串接的二极管是为了保护我们的开发板，防止有个别的连接线极性不对烧坏板子，保护电路在我们设计任何电路时都要考虑到，这个大家以后自己设计时也要注意。这样我们就可以通过连接线将5V的USB电源引入到开发板中进行使用了。 接下来便是电源电路，STM32工作电压是DC3.3V，所以我们需要一个能将大于3.3V电压转换为稳定的3.3V电压的芯片，这里我们使用的是TPS73633或者AMS1117芯片电源芯片即可实现。 下图为TPS73633芯片的相关说明，TPS73633DBVR是一款3.3V固定输出低压降（LDO）线性稳压器，采用了一种新的拓扑-电压跟随器配置中的NMOS调整元件。使用具有低ESR的输出电容器，这种拓扑是稳定的，甚至可以在没有电容器的情况下运行。它还提供高反向阻塞（低反向电流）和接地引脚电流，该电流在所有输出电流值上都几乎恒定。该器件使用先进的BiCMOS工艺来产生高精度，同时提供非常低压降（LDO）的电压和低接地引脚电流。未启用时，电流消耗低于1uA，非常适合便携式应用。极低的输出噪声非常适合为VCO供电。该器件受热关断和折返电流限制保护。 二、JTAG/SWD调试接口电路 JTAG/SWD调试接口电路采用了标准的JTAG接法，这种接法兼容SWD接口，因为SWD只需要四根线（SWCLK、SWDIO、VCC和GND）。需要注意的是，该接口电路为JLINK或ST-Link提供3.3V的电源，因此，不能通过JLINK或ST-Link对STM32核心板进行供电，而是STM32核心板为JLINK或ST-Link供电。JLINK和ST-Link不仅可以下载程序，还可以对STM32微控制器进行在线调试。 三、时钟电路 MCU是一个集成芯片，由非常复杂的数字电路和其它电路组成，需要稳定的时钟脉冲信号才能保证正常工作。时钟如同人体内部的心脏一样，是芯片的“动力”来源。时钟产生一次，就推动处理器执行一下指令。除了CPU，芯片上所有的外设(GPIO、I2C、SPI等)都需要时钟，由此可见时钟的重要性。芯片运行的时钟频率越高，芯片处理的速度越快，但同时功耗也越高。为了功耗和性能兼顾，微处理器一般有多个时钟源，同时还将时钟分频为多个大小，适配不同需求的外设。下图为stm32的时钟树 这里我们将两个晶振电路，电源，以及各引脚的网络符号对应连接好即可，除去晶振和电源，其余的标号都是连接在我们引出的排针上边的，晶振电路这里包含了一个8MHz的主晶振，以及一个32.768kHz的内部RTC实时时钟晶振，这里时钟晶振作为预留，如果有用到时钟的小伙伴直接焊接上即可，方便使用，每个晶振后边并联的为起振电容，方便晶振起振，电源部分的电容C3-C7组成了一个低通滤波电路，目的是为了让32更好的工作 四、复位电路 嵌入式系统中，由于外界环境干扰，难免出现程序跑飞或死机，这时就需要复位让MCU重新运行。该电路将一个按键接在了NRST引脚，一旦按键按下，NRST就会接地，拉低NRST，实现复位。
01-03 93浏览 -
kprobes的技术实现原理，实现方式及应用
Linux kprobe调试技术是内核开发者专门为了编译跟踪内核函数执行状态所涉及的一种轻量级内核调试技术，利用kprobe技术，内核开发人员可以在内核的绝大多数指定函数中动态插入探测点来收集所需的调试状态信息而基本不影响内核原有的执行流程。本章的是基于5.15内核来学习kprobe的相关内容，主要包括以下内容 kprobe技术产生的背景 主要针对ARM64 kprobes的技术实现原理，实现方式 对于ftrace中的kprobe是如何实现的 kpobe可以做什么，可以解决哪些问题 1 kprobe技术背景 对于开发者，我们在内核或者模块的调试过程中，往往需要知道一些函数的执行流程，何时被调用，执行过程中的入参和返回值是什么等等，比较简单的做法就是在内核代码对应的位置添加日志信息，但是这种方式往往需要重新编译内核或者模块，烧写或者替换模块，操作较为复杂甚至可能会破坏原有的代码执行过程。 所以针对这种情况，内核提供了一种调试机制kprobe，提供了一种方法，能够在不修改现有代码的基础上，灵活的跟踪内核函数的执行。 它的基本工作原理是：用户指定一个探测点，并把一个用户定义的处理函数关联到该探测点，当内核执行到该探测点时，相应的关联函数被执行，然后继续执行正常的代码路径。 kprobe 是一种动态调试机制，用于debugging，动态跟踪，性能分析，动态修改内核行为等，2004年由IBM发布，是名为Dprobes工具集的底层实现机制，2005年合入Linux kernel。probe的含义是像一个探针，可以不修改分析对象源码的情况下，获取Kernel的运行时信息。kprobe一直在X86系统上使用，ARM64的平台支持在2015年合入kernel ，kprobe提供了三种形式的探测点 一种最基本的kprobe：能够在指定代码执行前，执行后进行探测，但此时不能访问被探测函数内的相关变量信息，内核代码的任何指令处 一种是jprobe：用于探测某一个函数的入口，并且能够访问对应的函数参数，这个目前已经不再使用 一种是kretprobe：用于完成指定函数返回值的探测功能，内核函数的退出点 其中最基本的就是kprobe机制，jprobe以及kretprobe的实现都依赖于kprobe，kprobe是linux内核的一个重要的特性，是其他内核调试工具(perf，systemtap)的基础设施，同时内核BPF也是依赖于kprobe，它是利用指令插桩原理，截获指令流，并在指令执行前后插入hook函数，其如下： 所以kprobe的实现原理是把制定地址(探测点)的指令替换成一个可以让cpu进入debug模式的指令，使执行路径暂停，跳转到probe处理函数后收集，修改信息，然后再跳转回来继续执行的过程。 如果需要知道内核函数是否被调用、被调用上下文、入参以及返回值，比较简单的方式是加printk，但是效率低，利用kprobe技术，用户可以自定义自己的回调函数，可以再几乎所有的函数中动态插入探测点。 首先kprobe是最基本的探测方式，是实现后两种的基础，它可以再任意的位置放置探测点(就连函数内部的某条指令处也可以)，提供了探测点的调用前，调用后和内存访问出错3种回调方式，分别是- - per_handler：将在被探测指令执行前回调 post_handler：将在被探测指令执行完毕后回调(注意不是被探测函数) 对于kretprobe从名字就可以看出，它同样是基于kprobe实现，用于获取被探测函数的返回值 2 ARM64 kprobe的工作原理 实现kprobes 接口的数据结构和函数已在文件中定义。下面的数据结构描述了一个 kprobe struct kprobe { struct hlist_node hlist; /* 所有注册的kprobe都会添加到kprobe_table哈希表中，hlist成员用来链接到某个槽位中 */ /* list of kprobes for multi-handler support */ struct list_head list; /* 链接一个地址上注册的多个kprobe */ /*count the number of times this probe was temporarily disarmed */ unsigned long nmissed; /* 记录当前的probe没有被处理的次数 */ /* 一个是用户在注册前指定探测点的基地址（加上偏移得到真实的地址）， * 另一个是在注册后保存探测点的实际地址, 如果没有指定，必须指定探测的位置的符号信息 */ /* location of the probe point */ kprobe_opcode_t *addr; /* 探测点地址 */ /* 名称和地址不能同时指定，否则注册时会返回EINVAL错误 */ /* Allow user to indicate symbol name of the probe point */ const char *symbol_name; /* 探测点函数名 */ /* Offset into the symbol */ unsigned int offset; /* 探测点在函数内的偏移 */ /* 断点异常触发之后，开始单步执行原始的指令之前被调用 */ /* Called before addr is executed. */ kprobe_pre_handler_t pre_handler; /* 在单步执行原始的指令后会被调用 */ /* Called after addr is executed, unless... */ kprobe_post_handler_t post_handler; /* 后处理函数 */ /* 原始指令，在被替换为断点指令（X86下是int 3指令）前保存。*/ /* Saved opcode (which has been replaced with breakpoint) */ kprobe_opcode_t opcode; /* copy of the original instruction */ struct arch_specific_insn ainsn; /* 保存平台相关的被探测指令和下一条指令 */ /* * Indicates various status flags. * Protected by kprobe_mutex after this kprobe is registered. */ u32 flags; /* 状态标记 */}; 所以对于kprobe的使用比较简单，只需要指定探测点地址，或者使用符号名+偏移的方式，定义xxx_handler，注册即可，注册后，探测指令被替换，可以使用kprobe_enable/disable函数动态开关 2.1 kprobe初始化 下面我们来看看 kprobe 的初始化过程，kprobe 的初始化由 init_kprobes() 函数kernel/kprobes.c实现： static int __init init_kprobes(void){ int i, err = 0; /* 初始化用于存储 kprobe 模块的哈希表 */ /* FIXME allocate the probe table, currently defined statically */ /* initialize all list heads */ for (i = 0; i < KPROBE_TABLE_SIZE; i++) INIT_HLIST_HEAD(&kprobe_table[i]); /* 初始化 kprobe 的黑名单函数列表(不能被 kprobe 跟踪的函数列表) */ err = populate_kprobe_blacklist(__start_kprobe_blacklist, __stop_kprobe_blacklist); if (err) { pr_err("kprobes: failed to populate blacklist: %d\n", err); pr_err("Please take care of using kprobes.\n"); } if (kretprobe_blacklist_size) { /* lookup the function address from its name */ for (i = 0; kretprobe_blacklist[i].name != NULL; i++) { kretprobe_blacklist[i].addr = kprobe_lookup_name(kretprobe_blacklist[i].name, 0); if (!kretprobe_blacklist[i].addr) printk("kretprobe: lookup failed: %s\n", kretprobe_blacklist[i].name); } } /* By default, kprobes are armed */ kprobes_all_disarmed = false; #if defined(CONFIG_OPTPROBES) && defined(__ARCH_WANT_KPROBES_INSN_SLOT) /* Init kprobe_optinsn_slots for allocation */ kprobe_optinsn_slots.insn_size = MAX_OPTINSN_SIZE;#endif /* 初始化CPU架构相关的环境（x86架构的实现为空） */ err = arch_init_kprobes(); if (!err) err = register_die_notifier(&kprobe_exceptions_nb); /* 注册die通知链*/ if (!err) err = register_module_notifier(&kprobe_module_nb); /* 注册模块通知链 */ kprobes_initialized = (err == 0); if (!err) init_test_probes(); return err;}early_initcall(init_kprobes); 2.2 注册一个kprobe实例 内核是通过register_kprobe完成一个kprobe实例的注册，其详细实现过程在kernel/kprobes.c，如下所示 /* struct kprobe结构体，里面包含指令地址或者函数名地址和函数内偏移 */int register_kprobe(struct kprobe *p){ int ret; struct kprobe *old_p; struct module *probed_mod; kprobe_opcode_t *addr; /* 获取被探测点的地址，指定了sysmbol name，则kprobe_lookup_name从kallsyms中获取； * 指定了offsete + address，则返回address + offset */ /* Adjust probe address from symbol */ addr = kprobe_addr(p); if (IS_ERR(addr)) return PTR_ERR(addr); p->addr = addr; /* 判断同一个kprobe是否被重复注册 */ ret = warn_kprobe_rereg(p); if (ret) return ret; /* User can pass only KPROBE_FLAG_DISABLED to register_kprobe */ p->flags &= KPROBE_FLAG_DISABLED; p->nmissed = 0; INIT_LIST_HEAD(&p->list); /* 1. 判断被注册的函数是否位于内核的代码段内，或位于不能探测的kprobe实现路径中 * 2. 判断被探测的地址是否属于某一个模块，并且位于模块的text section内 * 3. 如果被探测的地址位于模块的init地址段内，但该段代码区间已被释放，则直接退出 */ ret = check_kprobe_address_safe(p, &probed_mod); if (ret) return ret; mutex_lock(&kprobe_mutex); /* 判断在同一个探测点是否已经注册了其他的探测函数 */ old_p = get_kprobe(p->addr); if (old_p) { /* Since this may unoptimize old_p, locking text_mutex. */ /* 如果已经存在注册过的kprobe，则将探测点的函数修改为aggr_pre_handler * 将所有的handler挂载到其链表上，由其负责所有handler函数的执行 */ ret = register_aggr_kprobe(old_p, p); goto out; } cpus_read_lock(); /* Prevent text modification */ mutex_lock(&text_mutex); /* 分配特定的内存地址用于保存原有的指令 */ ret = prepare_kprobe(p); mutex_unlock(&text_mutex); cpus_read_unlock(); if (ret) goto out; /* 将kprobe加入到相应的hash表内 */ INIT_HLIST_NODE(&p->hlist); hlist_add_head_rcu(&p->hlist, &kprobe_table[hash_ptr(p->addr, KPROBE_HASH_BITS)]); /* 将探测点的指令码修改为arm_kprobe */ if (!kprobes_all_disarmed && !kprobe_disabled(p)) { ret = arm_kprobe(p); if (ret) { hlist_del_rcu(&p->hlist); synchronize_rcu(); goto out; } } /* Try to optimize kprobe */ try_to_optimize_kprobe(p);out: mutex_unlock(&kprobe_mutex); if (probed_mod) module_put(probed_mod); return ret;} 其主要包括以下几个步骤： 探测点地址的计算：该函数主要用来指定位置注册探测点，首先使用kprobe_addr计算需要插入探测点的地址，这个会设置到kprobe的addr成员，注册后通过这个成员和offset就可以拿到探测位置的地址。利用这个特性，你可以通过kprobe来获取内核中某一个函数的运行时地址 如果没有指定探测地址，而是指定了符号信息，则调用kprobe_lookup_name在内核符号表中查找符号对应的地址，在找到对应的符号地址后，加上偏移就得到探测点的实际位置 如果只是指定了探测点的地址，则会将这个地址直接加上偏移返回 检测探测点地址：计算探测点的地址后，接下来就需要检查这个地址是否可以被探测 跟踪点是否已经被 ftrace 跟踪，如果是就返回错误（kprobe 与 ftrace 不能同时跟踪同一个地址） kprobe只能用作内核函数的探测，所以在注册前必须检查探测点的地址是否是在内核地址空间中，探测点的地址要么在内核影响中(_stext 和 etext之间，如果是在相同启动阶段(sinittext 和_einittext之间)，具体实现在kernel_text_address代码中 跟踪点是否在 kprobe 的黑名单中，如果是就返回错误 如果探测点的地址在一个内核模块中，需要增加对该模板的引用，以防止模块提前卸载，如果模块已经开始卸载，此时也是不能注册探测点 保存被跟踪指令的值： 内核通过调用prepare_kprobe函数来保持被跟踪的指令，而 prepare_kprobe() 最终会调用 CPU 架构相关的 arch_prepare_kprobe() 函数来完成任务 注册kprobe：系统中所有的kprobe实例都保存在kprobe_table这个哈希表中 如果调用get_kprobe()能找到一个kprobe实例，说明已经在当前的探测点注册了一个kprobe，这种情况下会调用register_aggr_kprobe()来处理。 如果当前的探测点没有注册过kprobe，则调用arm_kprobe将被探测位置的指令保持到kprobe的ainsn成员中，并且被探测位置的第一条指令保存到opcode成员中 对于arch_prepare_kprobe，看指令是否是一些分支等特殊指令，需要特别处理。如果是正常可以probe的指令，调用arch_prepare_ss_slot把探测点的指令备份到slot page里，把下一条指令存入struct arch_probe_insn结构的restore成员里，在post_handler之后恢复执行。 arch_prepare_krpobe无误后把kprobe加入kprobe_table哈希链表。 然后调用arch_arm_kprobe替换探测点指令为BRK64_OPCODE_KPROBES指令。 int __kprobes arch_prepare_kprobe(struct kprobe *p){ unsigned long probe_addr = (unsigned long)p->addr; /* 地址应该为4的整数倍 */ if (probe_addr & 0x3) return -EINVAL; /* copy instruction */ p->opcode = le32_to_cpu(*p->addr); /* 大端小端转换,将地址进行转换成PC能识别的地址 */ /* 检测地址是否在异常代码段中 */ if (search_exception_tables(probe_addr)) return -EINVAL; /* 取出探测点的汇编指令 */ /* decode instruction */ switch (arm_kprobe_decode_insn(p->addr, &p->ainsn)) { case INSN_REJECTED: /* insn not supported */ return -EINVAL; /* 异常处理 */ case INSN_GOOD_NO_SLOT: /* insn need simulation */ p->ainsn.api.insn = NULL; break; case INSN_GOOD: /* instruction uses slot */ p->ainsn.api.insn = get_insn_slot(); if (!p->ainsn.api.insn) return -ENOMEM; break; } /* prepare the instruction */ if (p->ainsn.api.insn) arch_prepare_ss_slot(p); /* 将指令存放到slot中，记录吓一条指令到p->ainsn.api.insn */ else arch_prepare_simulate(p); /* 异常处理，如分支指令特殊处理 */ return 0;} 整个过程如下图所示： 最终会调用arm_kprobe，将指令3替换成一条BRK64异常处理指令，当CPU执行到这个跟踪点的时候，将会触发断点中断，这时候就会走到异常处理函数中，对于x86，这个是一条int 3指令，我们来看看针对ARM64，是如何处理的，其最终会调到arch_arm_kprobe，最终会替换成BRK64_OPCODE_KPROBES指令。 /* arm kprobe: install breakpoint in text */void __kprobes arch_arm_kprobe(struct kprobe *p){ void *addr = p->addr; /* 原地址 */ u32 insn = BRK64_OPCODE_KPROBES; /* 替换后的指令 */ aarch64_insn_patch_text(&addr, &insn, 1);} 2.3 触发kprobe探测和回调 kprobe的触发和处理是通过brk exception和single step单步exception执行的，每次的处理函数中会修改被异常中断的上下文（struct pt_regs）的指令寄存器，实现执行流的跳转。ARM64对于异常处理的注册在arch/arm64/kernel/debug-monitors.c， 是arm64的通用debug模块，kgdb也基于这个模块。 void __init debug_traps_init(void){ /* 单步异常处理 */ hook_debug_fault_code(DBG_ESR_EVT_HWSS, single_step_handler, SIGTRAP, TRAP_TRACE, "single-step handler"); /* 断点异常处理 */ hook_debug_fault_code(DBG_ESR_EVT_BRK, brk_handler, SIGTRAP, TRAP_BRKPT, "BRK handler");} 通过hook_debug_fault_code动态定义了异常处理的钩子函数brk_handler，它将在断点异常处理函数中被调用 hook_debug_fault_code是替换arch/arm64/mm/fault.c 中的debug_fault_info异常表项： 对于ARM64的异常处理，当brk断点异常触发后悔执行不同的回调处理，进入异常会跳转到arch/arm64/kernel/entry.S的sync异常处理，此处会跳转到el1_sync 将 entry_handler 1, t, 64, sync宏展开得到调用el1t_64_sync_handler的处理函数，在arch/arm64/kernel/entry-common.c中处理，是通过read_sysreg(esr_el1)来处理对应的异常 最终会调用do_debug_exception处理debug异常 sr_el1的bit27~bit29指示了debug异常类型，对应debug_fault_info数组的索引，此处可知debug异常类型为0x6，对应DBG_ESR_EVT_BRK，由初始化函数debug_traps_init可知inf->fn为brk_handler brk_handler会调用call_break_hook，它实际是根据具体的某种断点异常类型来回调不同的hook，主要是根据ESR_EL1.ISS.Comment进行区分，也就是不同的ESR_EL1.ISS.Comment对应不同的hook。 在初始化时register_kernel_break_hook会向kernel_break_hook链表注册不同的hook，这包括kprobes_break_hook和kprobes_break_ss_hook。list_for_each_entry_rcu(hook, list, node)主要通过遍历kernel_break_hook链表，根据debug断点异常类型找到匹配的hook。 可以看出kprobe_handler里先是进入pre_handler，然后通过setup_singlestep设置single-step相关寄存器，为下一步执行原指令时发生single-step异常做准备 2.4 单步执行 进入异常态后，首先执行pre_handler，然后利用CPU提供的单步调试（single-step）功能，设置好相应的寄存器，将下一条指令设置为插入点处本来的指令，从异常态返回 这个里面使用reenter检查机制，对于SMP，中断等可能有kprobe的重入，允许kpobe发生嵌套 setup_singlestep() 执行完毕后，程序继续执行保存的被探测点的指令，由于开启了单步调试模式，执行完指令后会继续触发异常，单步执行探测点的指令后，会触发单步异常，进入single_step_handler，调用kprobe_breakpoint_ss_handler，主要任务是恢复执行路径，调用用户注册的post_handler kprobe的实现原理是把指定地址（探测点）的指令替换成一个可以让cpu进入debug模式的指令，使执行路径暂停，跳转到probe 处理函数后收集、修改信息，再跳转回来继续执行。 X86中使用的是int3指令，ARM64中使用的是BRK指令进入debug monitor模式。 3 kprobe event实现原理 首先我们跟function一样，从我们的配置开始，krpobe event和功能一样，那么大部分的实现是一样的，最关键的不同就是怎么使用新的插桩方法来创建event。使用向“/sys/kernel/debug/tracing/kprobe_events”文件中echo命令的形式来创建krpobe event。来查看具体的代码实现： 经过层层调用，最终到__trace_kprobe_create函数，其主要的实现如下： 对于alloc_trace_kproe，可以看到kretprobe模式下的桩函数：kretprobe_dispatcher()，而kprobe模式下的插桩函数为kprobe_dispatcher 其最终也会通过__register_trace_kprobe注册kprobe和kpretprobe，其最终的原理也是基本类似 4 kprobe的使用方法 最早的时候，使用kprobe一般都是编写内核驱动，在模块中定义pre-handler和post-handler函数，然后调用kprobe的API(register_kprobe)来进行注册kprobe。加载模块后，pre-handler和post-handler中的printk就会打印定制的信息到系统日志中，目前有三种使用kporbe的接口 kprobe API：使用register_kprobe 基于Ftrace的/sys/kernel/debug/tracing/kprobe_events接口，通过写特定的配置文件 perf_event_open：通过perf工具，perf 的probe命令提供了添加动态探测点的功能， 参看 kernel/tools/perf/Documentation/perf-probe.txt， 在最新的内核上，BPF tracing也是通过这种方式，后面再学习这种方法 kprobes的最大使用者都是一些tracer的前端工具，比如perf、systemtap、BPF 跟踪(BCC和bpftrace) 由于第一种方式灵活而且功能更为强大，对于方法一，大家请参考示例 kprobe：请参考samples/kprobes/kprobe_example.c kretprobe：请参考sample/kprobe/kretprobe_example.c 要编写一个 kprobe 内核模块，可以按照以下步骤完成： 第一步：根据需要来编写探测函数，如 pre_handler 和 post_handler 回调函数。 第二步：定义 struct kprobe 结构并且填充其各个字段，如要探测的内核函数名和各个探测回调函数。 第三步：通过调用 register_kprobe 函数注册一个探测点。 第四步：编写 Makefile 文件。 第五步：编译并安装内核模块。 对于方式二，用户通过/sys/kernel/debug/tracing/目录下的trace等属性文件来探测用户指定的函数，用户可添加kprobe支持的任意函数并设置探测格式与过滤条件，无需再编写内核模块，使用更为简便，但需要内核的debugfs和ftrace功能的支持，详细的请参考内核文档kprobetrace 使用前确定内核CONFIG打开：CONFIG_KPROBE_EVENT=y /sys/kernel/tracing/kprobe_events：添加断点接口 /sys/kernel/tracing/events/kprobes/enabled：断点使能开关 /sys/kernel/tracing/trace：查看trace日志接口 4.1 查看"vfs_open"当前打开文件名 如果你使用了“‘p:’ or ‘r:’+event name” > kprobe_events命令，新的kprobe event将会被添加，可以看到新events对应的文件夹tracing/events/kprobes/，包含‘id’, ‘enabled’, ‘format’ and ‘filter’文件。 enable：使能 filter：过滤想要的信息 trigger：事件发生时触发其他功能，例如function功能 format：环形队列缓冲区的格式 id: event对应的id echo 1 > /sys/kernel/tracing/events/kprobes/myprobe/enable echo 1 > /sys/kernel/tracing/tracing_on 要查看哪些进程触发了这些kprobe，可以通过trace、trace_pipe接口查看，输出格式如下，最左边是进程名，如果是<…>，可能是因为cat的时候，那个进程号对应的进程已经不存在了，第二个是进程PID，触发kprobe的时候记录的。FUNCTION就是触发的那个kprobe的名字，后面括号里是触发的时候代码位置，如果是“r”类型的kprobe，会显示返回到了什么代码位置。代码位置中的行号是反汇编对应的行号。 # 设置kprobe规则，获取vfs_open函数第一个参数path中的文件name cd /sys/kernel/tracingecho 'p vfs_open name=+0x38(+0x8($arg1)):string namep=+0(+0x28(+0x8($arg1))):string' > ./kprobe_events # 使能上述的kprobe echo 1 > ./events/kprobes/p_vfs_open_0/enable # 使能数据写入到 Ring 缓冲区 echo 1 > tracing_on 通过offset和类型打印，实现结构体内部成员的打印，但是需要知道寄存器和参数的对应关系和结构体成员的偏移。 https://www.notion.so/Kprobe-on-ARM64-d6d43e398a5e42b48e752f0f06aa0053#27fdb6f9b3c94d398f9220b495e04107 提到了新的function_event机制，可以直接传递参数名。例如我们想获取net_device的stats信息，获取数据结构偏移的例子：打印ip_rcv的网络设备名和收发包数 $ aarch64-linux-gnu-gdb vmlinux (gdb) ptype/o struct net_device gdb) print (int)&((struct net_device *)0)->stats$7 = 296 cd /sys/kernel/debug/tracing/echo 'p:net ip_rcv name=+0(%x1):string rx_pkts=+296(%x1):u64 tx_pkts=+280(%x1):u64 ' > kprobe_eventsecho 1 > events/kprobes/enable 4.2 设置了一个kretprobe，用来记录返回值 root@rlk:/sys/kernel/tracing# echo 0 > tracing_onroot@rlk:/sys/kernel/tracing# echo 0 > ./events/kprobes/p_vfs_open_0/enableroot@rlk:/sys/kernel/tracing# echo 'p vfs_open name=+0x38(+0x8($arg1)):string namep=+0(+0x28(+0x8($arg1))):string' > ./kprobe_eventsroot@rlk:/sys/kernel/tracing# echo 'r vfs_open ret_val=$retval' >> kprobe_eventsroot@rlk:/sys/kernel/tracing# echo 1 > events/kprobes/p_vfs_open_0/enableroot@rlk:/sys/kernel/tracing# echo 1 > events/kprobes/r_vfs_open_0/enableroot@rlk:/sys/kernel/tracing# echo 1 > tracing_onroot@rlk:/sys/kernel/tracing# echo 0 > tracing_onroot@rlk:/sys/kernel/tracing# cat trace_pipe 4.3 filter：捕获"vfs_open"查看指定文件的信息的事件 # 设置过滤条件，name中包含test字段 echo 'name ~ "*test*"' > ./events/kprobes/p_vfs_open_0/filter 4.4 trigger：包含"test"字段的文件的事件会触发"stacktrace"堆栈打印 # 包含"test"字段的文件的事件会触发"stacktrace"堆栈打印echo 'stacktrace if name ~ "*test*"' > ./events/kprobes/p_vfs_open_0/trigger 5 总结 至此，我们知道Kprobe实现的本质是breakpoint和single-step的结合，这一点和大多数调试工具一样，比如kgdb/gdb。实现动态内核的注入，其主要流程如下： 当 kprobe 被注册后，内核会将对应地址的指令进行拷贝并替换为断点指令(比如 X86 中的 int 3) 随后当内核执行到对应地址时，中断会被触发从而执行流程会被重定向到我们注册的 pre_handler 函数 当对应地址的原始指令执行完后，内核会再次执行 post_handler从而实现指令级别的内核动态监控。也就是说，kprobe 不仅可以跟踪任意带有符号的内核函数，也可以跟踪函数中间的任意指令。
2024-12-20 246浏览 -
如何减少嵌入式软件代码bug？看看这些问题
在嵌入式开发软件中查找和消除潜在的错误是一项艰巨的任务。通常需要英勇的努力和昂贵的工具才能从观察到的崩溃，死机或其他计划外的运行时行为追溯到根本原因。在最坏的情况下，根本原因会破坏代码或数据，使系统看起来仍然可以正常工作或至少在一段时间内仍能正常工作。工程师常常放弃尝试发现不常见异常的原因，这些异常在实验室中不易再现，将其视为用户错误或“小故障”。然而，机器中的这些鬼魂仍然存在。这是难以重现错误的最常见根本原因指南。每当您阅读固件源代码时，请查找以下五个主要错误。并遵循建议的最佳做法，以防止它们再次发生在您身上。错误1：竞争条件竞争条件是指两个或多个执行线程（可以是RTOS任务或main（） 和中断处理程序）的组合结果根据交织指令的精确顺序而变化的任何情况。每个都在处理器上执行。例如，假设您有两个执行线程，其中一个规则地递增一个全局变量（g_counter + = 1; ），而另一个偶然将其归零（g_counter = 0; ）。如果不能始终以原子方式（即，在单个指令周期内）执行增量，则存在竞争条件。 如图1所示，将任务视为汽车接近同一十字路口。计数器变量的两次更新之间的冲突可能永远不会发生，或者很少会发生。但是，这样做的时候，计数器实际上不会在内存中清零。其值至少在下一个清零之前是损坏的。这种影响可能会对系统造成严重后果，尽管可能要等到实际碰撞后很长一段时间才会出现。最佳实践：可以通过必须以适当的抢先限制行为对原子地执行代码的关键部分，来避免竞争条件。为防止涉及ISR的争用情况，必须在另一个代码的关键部分持续时间内至少禁止一个中断信号。对于RTOS任务之间的争用，最佳实践是创建特定于该共享库的互斥体，每个互斥体在进入关键部分之前必须获取该互斥体。请注意，依靠特定CPU的功能来确保原子性不是一个好主意，因为这只能防止争用情况发生，直到更换编译器或CPU。共享数据和抢占的随机时间是造成竞争状况的元凶。但是错误可能并不总是会发生，这使得从观察到的症状到根本原因的种族状况跟踪变得异常困难。因此，保持警惕以保护所有共享对象非常重要。每个共享对象都是一个等待发生的事故。 最佳实践：命名所有潜在共享的对象（包括全局变量，堆对象或外围寄存器和指向该对象的指针），以使风险对于所有将来的代码阅读者而言都是显而易见的；在Netrino嵌入式C编码标准提倡使用“的G_ 为此，”前缀。查找所有可能共享的对象将是争用条件代码审核的第一步。 错误2：不可重入功能从技术上讲，不可重入功能的问题是争用状况问题的特例。而且，由于相关原因，由不可重入函数引起的运行时错误通常不会以可重现的方式发生-使它们同样难以调试。不幸的是，非重入功能也比其他类型的竞争条件更难在代码审查中发现。图2 显示了一个典型的场景。在这里，要抢占的软件实体也是RTOS任务。但是，它们不是通过直接调用共享对象而是通过函数调用间接操作。例如，假设任务A调用套接字层协议功能，该套接字功能调用TCP层协议功能，调用IP层协议功能，该功能调用以太网驱动程序。为了使系统可靠地运行，所有这些功能都必须是可重入的。但是，以太网驱动程序的所有功能都以以太网控制器芯片的寄存器形式操作相同的全局对象。如果在这些寄存器操作期间允许抢占，则任务B可以在将数据包A排队之后但在发送开始之前抢占任务A。然后，任务B调用套接字层功能，该套接字层功能调用TCP层功能，再调用IP层功能，该功能调用以太网驱动程序，该队列将数据包B排队并传输。当CPU的控制权返回到任务A时，它将请求传输。根据以太网控制器芯片的设计，这可能会重传数据包B或产生错误。数据包A丢失，并且不会发送到网络上。为了可以同时从多个RTOS任务中调用此以太网驱动程序的功能，必须使它们可重入。如果它们每个仅使用堆栈变量，则无事可做。因此，C函数最常见的样式固有地是可重入的。但是，除非精心设计，否则驱动程序和某些其他功能将是不可重入的。使函数可重入的关键是暂停对外围设备寄存器，包括静态局部变量，持久堆对象和共享内存区域在内的全局变量的所有访问的抢占。这可以通过禁用一个或多个中断或获取并释放互斥锁来完成。问题的细节决定了最佳解决方案。最佳实践：在每个库或驱动程序模块中创建和隐藏一个互斥量，这些互斥量不是本质上可重入的。使获取此互斥锁成为操作整个模块中使用的任何持久数据或共享寄存器的前提。例如，相同的互斥锁可用于防止涉及以太网控制器寄存器和全局或静态本地数据包计数器的竞争情况。在访问这些数据之前，模块中访问此数据的所有功能必须遵循协议以获取互斥量。注意非重入功能可能会作为第三方中间件，旧版代码或设备驱动程序的一部分进入您的代码库。 令人不安的是，不可重入函数甚至可能是编译器随附的标准C或C ++库的一部分。 如果您使用GNU编译器来构建基于RTOS的应用程序，请注意您应该使用可重入的“ newlib”标准C库，而不是默认库。 错误3：缺少volatile关键字如果未使用C的volatile 关键字标记某些类型的变量，则可能导致仅在将编译器的优化器设置为低级或禁用编译器才能正常工作的系统中出现许多意外行为。该挥发性预选赛期间变量声明，其中它的目的是为了防止优化的读取和变量的写入使用。例如，如果您编写清单1所示的代码，则优化器可能会通过消除第一行来尝试使程序更快速，更小，从而损害患者的健康。但是，如果将g_alarm 声明为volatile ，那么将不允许这种优化。最佳实践：将挥发 的关键字应该用于声明每个：由ISR和代码的任何其他部分访问的全局变量，由两个或多个RTOS任务访问的全局变量（即使已阻止了这些访问中的竞争条件），指向内存映射外设寄存器（或一组或一组寄存器）的指针，以及延迟循环计数器。 请注意，除了确保所有读写操作都针对给定变量之外，使用volatile 还通过添加其他“序列点”来限制编译器。除易失性变量的读取或写入之外的其他易失性访问必须在该访问之前执行。 错误4：堆栈溢出每个程序员都知道堆栈溢出是很不好的事情。但是，每次堆栈溢出的影响都各不相同。损坏的性质和不当行为的时机完全取决于破坏哪些数据或指令以及如何使用它们。重要的是，从堆栈溢出到它对系统的负面影响之间的时间长短取决于使用阻塞位之前的时间。不幸的是，堆栈溢出比台式计算机更容易遭受嵌入式系统的困扰。这有几个原因，其中包括：（1）嵌入式系统通常只能占用较少的RAM；（2）通常没有虚拟内存可回退（因为没有磁盘）；（3）基于RTOS任务的固件设计利用了多个堆栈（每个任务一个），每个堆栈的大小都必须足够大，以确保不会出现唯一的最坏情况的堆栈深度；（4）中断处理程序可能会尝试使用这些相同的堆栈。使该问题进一步复杂化的是，没有大量的测试可以确保特定的堆栈足够大。您可以在各种加载条件下测试系统，但是只能测试很长时间。仅在“半个蓝月亮”中运行的测试可能不会见证仅在“一次蓝月亮”中发生的堆栈溢出。在算法限制（例如无递归）下，可以通过对代码的控制流进行自上而下的分析来证明不会发生堆栈溢出。但是，每次更改代码时，都需要重做自上而下的分析。最佳实践：启动时，在整个堆栈上绘制不太可能的内存模式。（我喜欢使用十六进制23 3D 3D 23，它看起来像ASCII内存转储中的篱笆' ＃==＃ '。）在运行时，让管理员任务定期检查是否没有任何涂料在预先设定的高水位上方标记已更改。 如果发现某个堆栈有问题，请在非易失性内存中记录特定的错误（例如哪个堆栈以及洪水的高度），并为产品的用户做一些安全的事情（例如，受控关闭或重置）可能会发生真正的溢出。这是添加到看门狗任务中的一项不错的附加安全功能。 错误5：堆碎片化嵌入式开发工程师并没有很好地利用动态内存分配。其中之一是堆碎片的问题。通过C的malloc（） 标准库例程或C ++的new 关键字创建的所有数据结构都驻留在堆中。堆是RAM中具有预定最大大小的特定区域。最初，堆中的每个分配都会减少相同字节数的剩余“可用”空间。例如，特定系统中的堆可能从地址0x20200000开始跨越10 KB。一对4 KB数据结构的分配将留下2 KB的可用空间。可以通过调用free（） 或使用delete 关键字将不再需要的数据结构的存储返回到堆中。从理论上讲，这使该存储空间可用于后续分配期间的重用。但是分配和删除的顺序通常至少是伪随机的，这导致堆变成一堆更小的碎片。若要查看碎片可能是一个问题，请考虑如果上述4 KB数据结构中的第一个空闲时会发生什么情况。现在，堆由一个4 KB的空闲块和另一个2 KB的空闲块组成。它们不相邻，无法合并。所以我们的堆已经被分割了。尽管总可用空间为6 KB，但超过4 KB的分配将失败。碎片类似于熵：两者都随时间增加。在长时间运行的系统（换句话说，曾经创建的大多数嵌入式系统）中，碎片最终可能会导致某些分配请求失败。然后呢？您的固件应如何处理堆分配请求失败的情况？最佳实践：避免完全使用堆是防止此错误的肯定方法。但是，如果动态内存分配在您的系统中是必需的或方便的，则可以使用另一种结构化堆的方法来防止碎片。 关键观察是问题是由大小可变的请求引起的。如果所有请求的大小都相同，则任何空闲块都将与其他任何块一样好，即使它恰巧不与任何其他空闲块相邻。图3 显示了如何将多个“堆”（每个用于特定大小的分配请求）的使用实现为“内存池”数据结构。许多实时操作系统都具有固定大小的内存池API。如果您可以访问其中之一，请使用它代替malloc（） 和free（） 。或编写自己的固定大小的内存池API。您只需要三个函数：一个用于创建新的池（大小为M 块N 字节）；另一个分配一个块（来自指定的池）；三分之一代替free（） 。代码审查仍然是最佳实践，可以通过首先确保系统中不存在这些错误来避免许多调试麻烦。最好的方法是让公司内部或外部的人员进行全面的代码审查。强制使用我在这里描述的最佳实践的标准规则编码也应该会有所帮助。如果您怀疑现有代码中存在这些讨厌的错误之一，那么执行代码审查可能比尝试从观察到的故障追溯到根本原因要快。 原文：https://blog.csdn.net/weixin_44059661/article/details/107839764 文章来源于网络，版权归原作者所有，如有侵权，请联系删除。
2024-12-19 210浏览 -
IAR单片机编程软件之新建软件工程
单片机编程软件数量不多，Keil和IAR为当前主流的单片机编程软件。对于每门单片机编程软件的学习，总需耗费一定必要的时间。为最大化减少大家对单片机编程软件学习时间的投入，本文特地带来IAR单片机编程软件相关教程...
2024-12-12 191浏览 -
单片机编程软件，IAR单片机编程软件之基础教程
好的单片机编程软件受到众多开发人员青睐，而对单片机编程软件了解较多的朋友都知道，目前市场上主要流通的单片机编程软件为Keil和IAR。本文中，主要为大家讲解IAR单片机编程软件的基础教程。如果你对IAR存在一定兴...
2024-12-12 93浏览 -
Keil5如何生成bin文件
方法一： 直接使用Keil自带的fromelf 工具 比如用命令行根据axf，生成bin： "D:\Program Files\Keil\ARM\ARMCC\bin\fromelf" --bin --output ./Objects/Led_Reg.bin ./Objects/Led_Reg.axf 或者在编译器配置中添加： fromelf --bin --output ./Objects/Led_Reg.bin ./Objects/Led_Reg.axf 如果需要srce文件，方法也是类似： "D:\Program Files\Keil\ARM\ARMCC\bin\fromelf" --bin --output ./Objects/Led_Reg.srec ./Objects/Led_Reg.axf 方法二： 使用专用的工具，很多工具都支持不同格式的转换。 比如Hex2bin，可以将hex转换为bin 使用Hex2bin-2.5软件，只需将需要转换的hex文件，拖动到这个小软件上面就会生产所需的bin文件。 生产的bin文件与hex文件在同一个路径下，注意路径不要有中文。 https://sourceforge.net/projects/hex2bin
2024-11-25 158浏览 -
数字滤波器在实际工程中的应用有哪些？
数字滤波器可以分为两大部分：即经典滤波器和现代滤波器。经典滤波器就是假定输入信号x(n)中的有用成分和希望滤除成分分别位于不同的频带，因而我们通过一个线性系统就可以对噪声进行滤除，如果噪声和信号的频谱相...
2024-09-12 529浏览
-
精密半导体参数测试解决方案 直播时间：01月08日 10:00
- AI需求强劲增长，富士康第四季度营收超预期
- 又有11家中企被纳入实体清单，涉及光刻机…
- 苹果A系列芯片十年进化：晶体管数量激增19倍，晶圆成本跃升300%
- 豪掷800亿美元！微软宣布加码AI数据中心
- 11家中国实体被纳入实体清单，美资禁止投资中国三个行业
- 不跟风2纳米，联发科下一代天玑9500芯片采用台积电N3P工艺
- 华勤技术收购豪成智能科技，强化机器人业务领域布局
- “超越EUV”时代：美国研发拍瓦级铥激光器有望大幅提升芯片制造效率
- 关注我们
-
扫码关注面包板社区
