最近刚好在看这个问题，提供一点自身的经验分享XD。 我们也是大批量生产的时候系统极不稳定， debug会发现出问题的时候有可能连主程式A process的main function都没有进去， 可想而知连main都没进去不是单纯FW没写好的问题， 接着再看系统还有哪只process也没起来，发觉那只process也是连main都没起来。 於是乎比较了一下两只process所用的share library，计算一下各别library file的md5值 与正确的library相比，果然发现某个library file里面错了一两个bytes造成系统有问题。 接着写了一版Auto test的FW，让rootfs跑initramfs，并在开机解完rootfs之後 把系统主要的程式与library files MD5都算过一遍再与本来正确的相比， 如果计算正确之後会再重开机继续测试，一直到出现NG为止。 有了debug的工具，接着就是量DDR timing，果然发现我们DDR brust write参数太margin， 温升之後会让特定的版子出现DDR write fail的情况。 而当初这组参数会让eyepattern张的很漂亮，小批量测试也都没问题， 等到大批量生产这问题才炸开XD 说实在的，Embedded Linux做久了，有时候会不知道自己在写程式还是在当柯南XD ※ 引述《jdward (321)》之铭言： : 讲这个我想起以前隔壁部门的在开发 Embedded Linux : 有一个案子 Code 在公版上开发已经跑很稳了， : 然後试产 10-20 片， : 试产的板子上 burnin 2-3 小时就会 Crash 掉， : Crash 点每次都不太一样... : 当初就怀疑应该是 HW 的问题， : 但 HW 就觉得 SW 要负责厘清是哪边的问题? : 至少要指出 HW 上大概是哪个部份的问题。 : 要不然上面东西这麽多怎麽找? : 投了3-4个人找了快2周才发现是 DRAM 的问题， : DRAM 换掉或是调参数就好了， : DRAM 跟公版同牌子同型号但批号不同... : Schedule 压很紧，又一直逼 SW 快快快... : 然後负责这个案子 SW Leader 就爆气了. : 过不久人就跑掉了。 : 所以我想以前认识很多SW强者都不愿意做 Firmware ， : 就是这个原因吧。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.128.169.29 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1449131204.A.583.html ※ 编辑: askacis (220.128.169.29), 12/03/2015 16:31:26 ※ 编辑: askacis (220.128.169.29), 12/03/2015 16:37:32 ※ 编辑: askacis (220.128.169.29), 12/03/2015 16:45:30