最近剛好在看這個問題，提供一點自身的經驗分享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/m.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