枫潇潇

在系统运行过程中，如果内核发生了panic，那么开发人员需要通过内核报错日志来进行定位问题。但是很多时候出现问题的时候没有接调试串口，而报错日志是在内存里面的，重启后就丢失了。所以需要一种方法，可以在系统发生crash时，将crash info保存于非易失存储器中。这对分析那种小概率且没办法抓到现场的问题非常实用，尤其是现在智能互联网的设备逐渐普及的时候，远端的设备可以自己捕抓崩溃日志再通过网络传输到服务器，维护人员就可以根据收集来的日志定位和解决问题，然后通过OTA让设备升级迭代。内核使用。

除了nand本身提供硬件ECC保证一定程度的位翻转纠正，当遇到超过设置的位翻转阈值但还能被ECC纠正的物理块，软件上可以做一次物理块移动动作，把数据拷贝到其他物理块，以避免原来的块一段时间之后出现位翻转超出ECC纠正能力而导致数据丢失的问题。ubi模块设计中，进行块清洗的子模块为磨损平衡子模块，这是因为对块清洗的动作与磨损平衡执行的动作是一致的，同样是把一个物理块的数据移动到另一个块。在了解内核ubi子系统的源码之后，发现内核已经实现了这种处理，下面把这种处理叫做块清洗处理。

这款NOR的擦除算法是先对整个块写0，然后再全部写1，并且写0和写1都是从块的末尾往前写的。因此，当在擦除的过程中断电，由于块的前两页数据有效，ubi把这个块识别成有效物理块，到ubifs挂载时判断文件系统数据损坏而导致挂载失败。从nanddump的报错信息，可以知道data分区中出现ECC error的block地址是0xAA0000，page地址是0xAA8800，该页数据损坏（可以确认该块不是坏块）。在出现问题的板子，手动改写data分区和log分区出问题块的前两页数据，重新挂载即可成功。

上下文分析：在函数update_change_node()打印完 updata_change_node start之后就没报异常了。

概述本文档讲述两种应用死机堆栈的方法，堆栈跟踪可以帮助开发人员快速定位导致死机的代码位置，从而更快地解决问题。方便后续有工程师在其他应用代码出现死机时，可以参考此文档快速的进行代码移植。该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表。参数 size 用来指定buffer中可以保存多少个void* 元素。函数返回值是实际获取的指针个数,最大不超过size大小，为了取得全部的函数调用列表，应保证buffer和size足够大。

而使用ca_backtrace，可以跟踪定位此前更多的调用栈，并且知道了导致崩溃的位置为./demo(glibc_strlen_null+0x1b)[0x11740]代码移植完成，使用backtrace同样的测试程序，glibc使用原生的Linaro的C库（不支持FP指针），再次追踪strlen(NULL)崩溃。cm_backtrace可以支持多种编译器，并不像c库里的backtrace函数依赖于FP指针的编译参数，对于所有的编译器和优化选项都可以通用。再次运行demo程序，得到以下打印。

内核线程无法直接获取到PC等指针，但可获取到其backtrace，来找到对应的PC指针；触发hung的task，其lswc、lswt均不为0；可获取到线程的PC等指针信息；无法获取到应用线程的backtrace，每个进程有独立的地址空间，CPU看到的虚拟地址，通过当前应用线程的PC指针无法获取到其backtrace；

不同于传统的MCU的FLASH ROM，AM890中小核是没有实际意义上的ROM的，小核的所有内存空间均为可读写的RAM区，存访代码的ROM区是软件上认为划分的区域。我们使用到了一些标准C库的函数，这些函数在写代码时虽然仅仅是增加了一个头文件，然后调用了一下，但是实际编译出来的固件可能就会大好几KB，这些问题都是软件开发人员很少注意到的。基于上述情况，可以将ROM区改为可读写，让data段只在ROM区保存一份，对data进行读写时直接操作ROM区。代码结构优化需要各位编写软件的同事进行。

线激光算法使用v4l2_buffer需做较大的计算量，此内存是否带有cache属性，其性能存在较大的差异，现需对此进行分析及优化。1）新加一种内存分配方式 **vb2_dc_alloc_non_coherent，**暂未找到其具体实现的地方。，故此属性为：**L_PTE_MT_BUFFERABLE **| L_PTE_XN。此方案怀疑是cache刷新存在问题，alloc异常的问题，还需进一步分析。，结合内核属性配置可知：此属性是 **MAP_TYPE_NCB，旧版本库，无明显的变化。测试结果一：图像错乱。