Re: [請益] MFC寫應用程式 vs 嵌入式系統 vs FW

看板Soft_Job作者 (ASKA)時間11年前 (2014/10/27 13:17), 編輯推噓8(8推 0噓 146→)
留言154則, 7人參與, 最新討論串4/4 (看更多)
:推 sedgewick: 路過提一句, 寫 kernel 還要動示波器的話最好快逃吧... 10/27 01:30 :→ sedgewick: 這表示硬體層面的 bug 也太多了. 推文有位大大講到寫kernel動用示波器表示硬體層面的BUG太多， 這剛好可以拿來說明FW工程師可能會遇到的問題。 與SW相比，一樣是寫CODE，但基本上跟硬體打交道是FW工程師的宿命， 換言之FW工程師不能預期你的硬體是好的，當硬體有問題的時候 你要協助E.E.去查問題，甚至做workaround solution。 尤其是chip/板子剛回來準備start up的時候， 一上電你的uart console沒有輸出是常有的事。 不會動的原因可能是CPU reset電路沒做好， 或是DDR timing參數沒調好導致記憶體存取有問題， 扯一點可能Flash接腳沒焊好，最慘的是可能IC開回來 某些function根本就fail(FPGA跑的時候明明就是好的T.T) 像上述的這些情況發生時就需要示波器來協助FW工程師尋找/解決問題。 當然現在系統越長越大，FW工程師分工也越來越細， 有些工程師專長在kernel以及周邊硬體界面的驅動(I2C,SPI,USB,LCD,GMAC...) ；有些則是專精在user space應用程式(WEB,QT,android,socket...)， 碰到硬體的機率也很低了~~ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 210.242.52.37 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1414387065.A.229.html
推
10/27 14:48, , 1F
點板子我們通常講bring up,很少講start up
10/27 14:48, 1F
→
10/27 16:52, , 2F
以前也是講bring up,一次一個老外講start up也就都講了XD
10/27 16:52, 2F
推
10/27 18:46, , 3F
不是light up嗎
10/27 18:46, 3F
推
10/28 00:10, , 4F
這個的問題在於, 它不屬於 kernel programming 的範圍.
10/28 00:10, 4F
→
10/28 00:13, , 5F
hardware 部門的功能很明確, 所以這些都沒錯...
10/28 00:13, 5F
→
10/28 00:13, , 6F
然而然而, 這個了不起到 firmware 就要解掉了.
10/28 00:13, 6F
→
10/28 00:14, , 7F
波形這種咚咚一路傳到 kernel layer 是非常離譜的事情
10/28 00:14, 7F
→
10/28 00:38, , 8F
Embeded Linux的kernel當然是FW的一部分啊，更何況，
10/28 00:38, 8F
→
10/28 00:39, , 9F
驗證用的none OS FW寫成kernel driver的形式並非全然一樣
10/28 00:39, 9F
→
10/28 00:39, , 10F
有時候你在none OS可以的東西到了kernel就會有問題,
10/28 00:39, 10F
→
10/28 00:40, , 11F
你的工作是FW工程師而非kernel工程師，沒有那種進kernel
10/28 00:40, 11F
→
10/28 00:42, , 12F
就不能用示波器的道理，沒示波器，你怎麼知道你的driver
10/28 00:42, 12F
→
10/28 00:43, , 13F
沒有問題? 有些ms甚至us等級的問題不是靠printk就可以解
10/28 00:43, 13F
→
10/28 00:45, , 14F
還是那句話，遇到就知道XD
10/28 00:45, 14F
推
10/28 00:47, , 15F
呃, 我個人的判斷是...
10/28 00:47, 15F
→
10/28 00:48, , 16F
這通常是「把 hardware/firmware 該做的事丟給 CPU. 」
10/28 00:48, 16F
→
10/28 00:49, , 17F
所以才會出現 kernel mode 下要考慮 hardware spec.
10/28 00:49, 17F
→
10/28 00:49, , 18F
我認真地說, 這不是很健康...
10/28 00:49, 18F
→
10/28 00:49, , 19F
會弄到 microsecond 等級的, 我猜大概是 GPS...
10/28 00:49, 19F
→
10/28 00:50, , 20F
但是這種咚咚不應該歸為 kernel programming.
10/28 00:50, 20F
→
10/28 00:51, , 21F
（因為只有 GPS 硬體夠簡單, 但計時精確度很高... ）
10/28 00:51, 21F
→
10/28 00:52, , 22F
至於 kernel 該做什麼哦？
10/28 00:52, 22F
→
10/28 00:53, , 23F
google: Linux kernel programming 就有很多答案.
10/28 00:53, 23F
→
10/28 00:53, , 24F
這些答案並不會特意區分是不是 embedded linux...
10/28 00:53, 24F
→
10/28 01:38, , 25F
我是不曉得填register不寫CODE靠CPU幫你填要靠什麼XD
10/28 01:38, 25F
→
10/28 01:38, , 26F
另外kernel mode絕對會考慮hardware spec，硬體IP出來
10/28 01:38, 26F
→
10/28 01:40, , 27F
之後可能會有errata文件出來，你driver就是就是要根據來
10/28 01:40, 27F
→
10/28 01:41, , 28F
來改來避，我自己就靠示波器/SD卡分析儀抓到世界大廠的
10/28 01:41, 28F
→
10/28 01:42, , 29F
bug，這種bug單靠souce level debug是de不出來的~
10/28 01:42, 29F
→
10/28 01:45, , 30F
更有甚著，單純的zImage解壓縮都要多墊幾個nop讓時序正常
10/28 01:45, 30F
→
10/28 01:45, , 31F
反正還是那句話，遇到就知道XD
10/28 01:45, 31F
→
10/28 01:52, , 32F
再舉個例子，之前debug一個版子，ping大封包會一堆error
10/28 01:52, 32F
→
10/28 01:53, , 33F
最後查出來是板子上電路的問題影響到phy，沒有示波器幫你
10/28 01:53, 33F
→
10/28 01:54, , 34F
，就算整個kernel的TCP/IP Stack都翻爛也是找不出來~
10/28 01:54, 34F
→
10/28 01:56, , 35F
另外，USB測眼圖也是，你FW就是要幫忙填register讓控制器
10/28 01:56, 35F
推
10/28 01:57, , 36F
這些我都知道啊...
10/28 01:57, 36F
→
10/28 01:57, , 37F
根據你的data去產生量測眼圖所需要的波形，最後在儀器上
10/28 01:57, 37F
→
10/28 01:57, , 38F
它們證明「寫 kernel 還要動示波器的話最好快逃吧」
10/28 01:57, 38F
→
10/28 01:58, , 39F
判定訊號品質，沒過沒拿不到logo咧，這些都是kernel
10/28 01:58, 39F
還有 75 則推文
→
10/30 02:18, , 115F
在FW頭上?應該是說FW寫code時當然是預期硬體是好的...
10/30 02:18, 115F
→
10/30 02:18, , 116F
但不能預設你的control方式一定是對的...兩者有差...
10/30 02:18, 116F
→
10/30 02:19, , 117F
就跟寫Windows AP你會要預設OS是爛的~有毒的~crash的嗎?
10/30 02:19, 117F
→
10/30 02:20, , 118F
幫EE找root cause或下workaround...那不是FW該做的,也不
10/30 02:20, 118F
→
10/30 02:21, , 119F
是FW的責任~只是在幫EE擦屁股罷了...至於為啥現在FW都被
10/30 02:21, 119F
→
10/30 02:21, , 120F
逼著做~就是cost考量囉~所以...做歸還是要做...但還是要
10/30 02:21, 120F
→
10/30 02:21, , 121F
強調~那不是FW該做的事~也不是FW的責任囉...
10/30 02:21, 121F
→
10/31 14:22, , 122F
本來就要幫忙看啊，不是說責任是FW的，而是說你FW的責任
10/31 14:22, 122F
→
10/31 14:23, , 123F
就是要幫忙跑板子帶起來，俾公司chip一tape out回來，都
10/31 14:23, 123F
→
10/31 14:25, , 124F
是FW&EE一起量波形看波形，一起弄到能跑為止
10/31 14:25, 124F
→
10/31 14:26, , 125F
分是誰該做的事情一點意義也沒有，回到我本來要表達的意
10/31 14:26, 125F
→
10/31 14:26, , 126F
也是FW要經手處理這些事而SW原則是不需要的，也是文章問
10/31 14:26, 126F
→
10/31 14:28, , 127F
理論上交到FW的硬體要是好的，但是那只是理論，現實就是
10/31 14:28, 127F
→
10/31 14:28, , 128F
even電路經過好幾個人review過，板子真正洗出來驗還是會
10/31 14:28, 128F
→
10/31 14:29, , 129F
有一堆低級錯誤產生，所以我才說FW不能預設電路是好的，
10/31 14:29, 129F
→
10/31 14:30, , 130F
然後一股腦的查自己Code有沒有問題，你要幫忙EE去看電路
10/31 14:30, 130F
→
10/31 14:31, , 131F
真正在操作硬體的人是FW，這幾天我才又遇到一次，ECI
10/31 14:31, 131F
→
10/31 14:31, , 132F
EHCI controller不會動，底下裝置都被認為是low speed
10/31 14:31, 132F
→
10/31 14:32, , 133F
如果你不看電路量訊號只查自己Code有沒有寫好，那永遠都
10/31 14:32, 133F
→
10/31 14:35, , 134F
找不出來錯誤在哪裡，畢竟真正讓硬體動起來的是你的code
10/31 14:35, 134F
→
10/31 14:35, , 135F
也只有你才知道當下測出來的訊號有沒有問題~
10/31 14:35, 135F
→
10/31 14:38, , 136F
我職場看過很資深的EE，它們除了經驗豐富，還會寫組語
10/31 14:38, 136F
→
10/31 14:38, , 137F
控制mcu，幾乎就是一整個超強狀態，那也僅只一兩個而已
10/31 14:38, 137F
→
10/31 14:39, , 138F
一般你還是要跟EE一起弄，而不是說等EE查好了你再進來y
10/31 14:39, 138F
→
10/31 14:40, , 139F
至於cpu reset的Case，我那時遇到的EE可是直接問你為什麼
10/31 14:40, 139F
→
10/31 14:42, , 140F
不會動，如果你不叫他勾訊號出來看reset，那事情沒進展，
10/31 14:42, 140F
→
10/31 14:43, , 141F
案子的dealine過了，你可以說是EE的責任跟我FW一點關係都
10/31 14:43, 141F
→
10/31 14:45, , 142F
沒有，然後空等在那繼續看案子被客人罰錢有的沒的嗎?
10/31 14:45, 142F
→
10/31 14:47, , 143F
只能說我的實務經驗跟這棟樓實際相差甚遠XD
10/31 14:47, 143F
→
10/31 17:55, , 144F
我上面有講到一個我所表達的重點和結論...那就是...
10/31 17:55, 144F
→
10/31 17:55, , 145F
"確定我們FW code有開始跑後"才是我們接手...
10/31 17:55, 145F
→
10/31 17:56, , 146F
當然開始跑我們的code後行為不正常要看波形要對timing
10/31 17:56, 146F
→
10/31 17:56, , 147F
當然都ok...但是連FW的code一行都沒跑的到情況...
10/31 17:56, 147F
→
10/31 17:57, , 148F
一定是EE那邊的責任~他們本來就該至少弄到code有開始跑
10/31 17:57, 148F
→
10/31 17:57, , 149F
吧...你的code都還沒開始跑...當然可以去幫忙...但是..
10/31 17:57, 149F
→
10/31 17:58, , 150F
我上面強調過了...幫忙做不等於"該"做...就這麼簡單...
10/31 17:58, 150F
→
10/31 17:58, , 151F
基本上我說的情況FW就算不插手也不會有人覺得你有問題..
10/31 17:58, 151F
→
10/31 17:59, , 152F
操作硬體也要"EE那邊先確定"HW是好的可以操作的情況下..
10/31 17:59, 152F
→
10/31 17:59, , 153F
那是EE的責任...不然HW有問題或layout有問題也要怪FW不
10/31 17:59, 153F
→
10/31 18:00, , 154F
幫忙查?這個就太over了
10/31 18:00, 154F
‣ 更多 askacis 的文章
文章代碼(AID): #1KJTLv8f (Soft_Job)
‣ 更多 askacis 的文章
文章代碼(AID): #1KJTLv8f (Soft_Job)