推 hl4: ddr timing是怎麼量的啊 12/03 17:19
→ askacis: 請洽安捷倫或是泰克XD 12/04 10:14
→ realmeat: 當科南 12/04 18:02
推 cobrasgo: 科南這句話太傳神了 12/04 18:12
最近剛好在看這個問題，提供一點自身的經驗分享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://www.ptt.cc/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