推 waterdisney: 點板子我們通常講bring up,很少講start up 10/27 14:48
→ askacis: 以前也是講bring up,一次一個老外講start up也就都講了XD 10/27 16:52
推 ccccboom: 不是light up嗎 10/27 18:46
推 sedgewick: 這個的問題在於, 它不屬於 kernel programming 的範圍. 10/28 00:10
→ sedgewick: hardware 部門的功能很明確, 所以這些都沒錯... 10/28 00:13
→ sedgewick: 然而然而, 這個了不起到 firmware 就要解掉了. 10/28 00:13
→ sedgewick: 波形這種咚咚一路傳到 kernel layer 是非常離譜的事情 10/28 00:14
→ askacis: Embeded Linux的kernel當然是FW的一部分啊，更何況， 10/28 00:38
→ askacis: 驗證用的none OS FW寫成kernel driver的形式並非全然一樣 10/28 00:39
→ askacis: 有時候你在none OS可以的東西到了kernel就會有問題, 10/28 00:39
→ askacis: 你的工作是FW工程師而非kernel工程師，沒有那種進kernel 10/28 00:40
→ askacis: 就不能用示波器的道理，沒示波器，你怎麼知道你的driver 10/28 00:42
→ askacis: 沒有問題? 有些ms甚至us等級的問題不是靠printk就可以解 10/28 00:43
→ askacis: 還是那句話，遇到就知道XD 10/28 00:45
推 sedgewick: 呃, 我個人的判斷是... 10/28 00:47
→ sedgewick: 這通常是「把 hardware/firmware 該做的事丟給 CPU. 」 10/28 00:48
→ sedgewick: 所以才會出現 kernel mode 下要考慮 hardware spec. 10/28 00:49
→ sedgewick: 我認真地說, 這不是很健康... 10/28 00:49
→ sedgewick: 會弄到 microsecond 等級的, 我猜大概是 GPS... 10/28 00:49
→ sedgewick: 但是這種咚咚不應該歸為 kernel programming. 10/28 00:50
→ sedgewick: （因為只有 GPS 硬體夠簡單, 但計時精確度很高... ） 10/28 00:51
→ sedgewick: 至於 kernel 該做什麼哦？ 10/28 00:52
→ sedgewick: google: Linux kernel programming 就有很多答案. 10/28 00:53
→ sedgewick: 這些答案並不會特意區分是不是 embedded linux... 10/28 00:53
→ askacis: 我是不曉得填register不寫CODE靠CPU幫你填要靠什麼XD 10/28 01:38
→ askacis: 另外kernel mode絕對會考慮hardware spec，硬體IP出來 10/28 01:38
→ askacis: 之後可能會有errata文件出來，你driver就是就是要根據來 10/28 01:40
→ askacis: 來改來避，我自己就靠示波器/SD卡分析儀抓到世界大廠的 10/28 01:41
→ askacis: bug，這種bug單靠souce level debug是de不出來的~ 10/28 01:42
→ askacis: 更有甚著，單純的zImage解壓縮都要多墊幾個nop讓時序正常 10/28 01:45
→ askacis: 反正還是那句話，遇到就知道XD 10/28 01:45
→ askacis: 再舉個例子，之前debug一個版子，ping大封包會一堆error 10/28 01:52
→ askacis: 最後查出來是板子上電路的問題影響到phy，沒有示波器幫你 10/28 01:53
→ askacis: ，就算整個kernel的TCP/IP Stack都翻爛也是找不出來~ 10/28 01:54
→ askacis: 另外，USB測眼圖也是，你FW就是要幫忙填register讓控制器 10/28 01:56
推 sedgewick: 這些我都知道啊... 10/28 01:57
→ askacis: 根據你的data去產生量測眼圖所需要的波形，最後在儀器上 10/28 01:57
→ sedgewick: 它們證明「寫 kernel 還要動示波器的話最好快逃吧」 10/28 01:57
→ askacis: 判定訊號品質，沒過沒拿不到logo咧，這些都是kernel 10/28 01:58
→ sedgewick: 因為硬體搞成這樣的 bug 也太多了... 10/28 01:58
→ askacis: 總歸一句，你寫kernel code，kernel很大一部分是跟硬體 10/28 01:59
→ sedgewick: 敝魯隔壁就是做 CPU 的, 他們的 workaround 我也略懂. 10/28 01:59
→ sedgewick: 最常見的就是 lock cpu, disable interrupt, sleep. 10/28 01:59
→ sedgewick: 然後開始 tune sleep time... 一直到會過. 10/28 01:59
→ askacis: 高度相關，LA、示波器、ICE都是不可缺的工具~ 10/28 02:00
→ sedgewick: 但是這些通通都不是 "kernel programming" 哦. 10/28 02:00
→ sedgewick: 所有的 peripheral device 都常被這樣 "workaround". 10/28 02:01
→ sedgewick: 我個人是非常「有概念的」... 科科. 10/28 02:02
→ askacis: workaround是一回事，寫出來的code沒對data sheet靠示波 10/28 02:03
→ askacis: 查又是一回事，不可一概而論 10/28 02:04
→ askacis: 基本上自己寫出來的code，沒用示波器看一下波型對照 10/28 02:06
→ askacis: data sheet的timing chart是一件很危險的事。 10/28 02:06
→ askacis: 因為有可能你fetch data的點根本是在很margin的位置 10/28 02:08
→ askacis: 才會有那種多sleep或是多墊幾個printk就沒事的狀況 10/28 02:09
推 sedgewick: ask 兄你也不要那麼激動... 10/28 02:15
→ sedgewick: 你說的那些都是 hardware team 的功能, 這個我也很清楚 10/28 02:15
→ sedgewick: 我只是要說, 那些工作最多就是 driver stack 要做掉. 10/28 02:17
→ sedgewick: 退到 driver layer 已經是很不得以的事情了... 10/28 02:18
→ sedgewick: 不得已, 別字... 科科一下. 10/28 02:18
→ sedgewick: 因為 driver 原則上是提供 functionality/feature API. 10/28 02:18
→ sedgewick: 而不是 workaround/bugfix 這樣的角色. 10/28 02:19
→ sedgewick: 讓 CPU 來管 synchronization/concurrency 是嚴重的錯 10/28 02:20
推 clarkman: A大很中肯阿...淚推...有時候搞了很久才發現是clock 10/28 02:21
→ sedgewick: 嚴重的設計錯誤... 或者說瑕疵（繼續科科一下. :P） 10/28 02:21
→ clarkman: timing跑掉了，不然就是有些硬體問題造成板子掛掉 10/28 02:21
→ clarkman: 真的超難查找的，還遇過板子上面標反，結果很久才發現 10/28 02:22
推 clarkman: print的問題也不好查，有時候得找ic team拉訊號出來看 10/28 02:25
→ clarkman: 才會發現，只是因為下個print讓訊號剛好時間對了 10/28 02:25
→ i386: 原PO提到的reset電路, DDR timing, flash旱腳等等的.. 10/28 14:59
→ i386: 那些嚴格來說都是驗證的人要處理的事情,這些事情跟 10/28 15:00
→ i386: kernel programming真的沒什麼關係... 10/28 15:00
→ i386: 寫linux driver也只是kernel programing的一部分而已, 10/28 15:02
→ askacis: 這篇原意是講FW工程師該做的事不是嗎? 10/28 15:27
→ askacis: 我原意也是在FW工程師會遇到的問題與工具，Linux Kernel 10/28 15:30
→ askacis: 對FW工程師來說接觸最多的就是Driver，也是最大的一部分 10/28 15:31
→ askacis: 難到不講Driver debug要講怎麼寫file system or network? 10/28 15:31
→ askacis: 另外可能i386公司分工比較細，自己寫的driver還有驗證 10/28 15:33
→ askacis: team來幫你驗，我們比較辛苦，自己的IP或driver要自己驗 10/28 15:34
→ askacis: 更別說帶板子起來這種事情還可以勞駕別人來做這麼幸福了~ 10/28 15:35
→ askacis: 再說一次，我講的是FW工程師職場會遇到的問題，以及Linux 10/28 15:39
→ askacis: kernel&driver怎麼去Debug與使用工具，很難理解嗎? 10/28 15:40
→ askacis: i386你要不要再看一下我這篇開頭的前兩行? 10/28 15:41
→ askacis: 我講DDR timing那些明明是在說明FW工程師會遇到的問題 10/28 15:42
→ askacis: 推薦路過的人一本好書<嵌入式系統開發之道> 10/28 15:54
→ askacis: 寫FW/嵌入式系統會遇到的問題與職場生活寫照幾乎都有了 10/28 15:55
→ u9654802: 你說的情況該用試波器去看波型的還是EE,不該是FW 10/29 09:39
→ askacis: 寫FW不會用示波器? EE可以幫你拉線，看訊號還是FW自己來 10/29 11:29
→ askacis: 我還以為是common sense~ 10/29 11:30
→ askacis: 我們Team RD不會用示波器操作看訊號大概回家吃自己了~ 10/29 11:33
→ u9654802: 這位A大不用太激動...我是說"該不該",不是說"會不會"... 10/30 02:03
→ u9654802: 該不該跟會不會不同這個應該是common sence吧... 10/30 02:03
→ u9654802: 本魯剛好是個寫FW(BIOS)的,示波器/訊號產生器/三用電錶 10/30 02:04
→ u9654802: 從高職電子科時代開始每周至少相處24個小時以上... 10/30 02:04
→ u9654802: 加上真的不是很難...我相信也不會有啥FW engineer不會用 10/30 02:05
→ u9654802: 就點是..."會"就等於"該"嗎? 10/30 02:05
→ u9654802: 小弟在幫客戶bring up板子時遇過幾種開不起來狀況... 10/30 02:05
→ u9654802: 1.按power buttom沒反應...system power整個沒起來... 10/30 02:06
→ u9654802: 這種狀況...EE最先查...再來是EC FW查... 10/30 02:06
→ u9654802: 2.按power buttom電有起來...但沒跑BIOS code... 10/30 02:07
→ u9654802: 這時BIOS FW要去幫忙看示波器?當然不用...連我的code一 10/30 02:07
→ u9654802: 行都沒跑到...說是我的code影響波形的嗎?不是吧... 10/30 02:08
→ u9654802: 在BIOS FW開始跑之前很多東西是hardware strap弄死的... 10/30 02:08
→ u9654802: (當然還有些是更前端的FW ex:EC造成的) 10/30 02:09
→ u9654802: 當這種情況明明就是EE的問題~不需要我們FW去看波形吧? 10/30 02:09
→ u9654802: 電有起來...SPI ROM上的code沒跑...hardware自己要去量 10/30 02:09
→ u9654802: SPI controller出來的clock有沒有振之類的... 10/30 02:10
→ u9654802: "確定我們FW code有開始跑後"才是我們接手... 10/30 02:10
→ u9654802: 現在或許很多情況是要FW去幫忙cover EE的一些issue... 10/30 02:10
→ u9654802: 因為動EE要成本...FW不用...但不代表那是FW該做的事... 10/30 02:11
→ u9654802: 我想表達的就這麼簡單囉... 10/30 02:11
→ u9654802: 還有...FW engineer為什麼不能預期硬體是好的?你在寫FW 10/30 02:16
→ u9654802: 時一定是以硬體是好的前提下寫的...硬體是EE的責任... 10/30 02:16
→ u9654802: control硬體...是FW的責任,硬體要先是好的我們才能控制 10/30 02:17
→ u9654802: 啊...不然我們register再怎麼照spec填都不會動...也是算 10/30 02:17
→ u9654802: 在FW頭上?應該是說FW寫code時當然是預期硬體是好的... 10/30 02:18
→ u9654802: 但不能預設你的control方式一定是對的...兩者有差... 10/30 02:18
→ u9654802: 就跟寫Windows AP你會要預設OS是爛的~有毒的~crash的嗎? 10/30 02:19
→ u9654802: 幫EE找root cause或下workaround...那不是FW該做的,也不 10/30 02:20
→ u9654802: 是FW的責任~只是在幫EE擦屁股罷了...至於為啥現在FW都被 10/30 02:21
→ u9654802: 逼著做~就是cost考量囉~所以...做歸還是要做...但還是要 10/30 02:21
→ u9654802: 強調~那不是FW該做的事~也不是FW的責任囉... 10/30 02:21
→ askacis: 本來就要幫忙看啊，不是說責任是FW的，而是說你FW的責任 10/31 14:22
→ askacis: 就是要幫忙跑板子帶起來，俾公司chip一tape out回來，都 10/31 14:23
→ askacis: 是FW&EE一起量波形看波形，一起弄到能跑為止 10/31 14:25
→ askacis: 分是誰該做的事情一點意義也沒有，回到我本來要表達的意 10/31 14:26
→ askacis: 也是FW要經手處理這些事而SW原則是不需要的，也是文章問 10/31 14:26
→ askacis: 理論上交到FW的硬體要是好的，但是那只是理論，現實就是 10/31 14:28
→ askacis: even電路經過好幾個人review過，板子真正洗出來驗還是會 10/31 14:28
→ askacis: 有一堆低級錯誤產生，所以我才說FW不能預設電路是好的， 10/31 14:29
→ askacis: 然後一股腦的查自己Code有沒有問題，你要幫忙EE去看電路 10/31 14:30
→ askacis: 真正在操作硬體的人是FW，這幾天我才又遇到一次，ECI 10/31 14:31
→ askacis: EHCI controller不會動，底下裝置都被認為是low speed 10/31 14:31
→ askacis: 如果你不看電路量訊號只查自己Code有沒有寫好，那永遠都 10/31 14:32
→ askacis: 找不出來錯誤在哪裡，畢竟真正讓硬體動起來的是你的code 10/31 14:35
→ askacis: 也只有你才知道當下測出來的訊號有沒有問題~ 10/31 14:35
→ askacis: 我職場看過很資深的EE，它們除了經驗豐富，還會寫組語 10/31 14:38
→ askacis: 控制mcu，幾乎就是一整個超強狀態，那也僅只一兩個而已 10/31 14:38
→ askacis: 一般你還是要跟EE一起弄，而不是說等EE查好了你再進來y 10/31 14:39
→ askacis: 至於cpu reset的Case，我那時遇到的EE可是直接問你為什麼 10/31 14:40
→ askacis: 不會動，如果你不叫他勾訊號出來看reset，那事情沒進展， 10/31 14:42
→ askacis: 案子的dealine過了，你可以說是EE的責任跟我FW一點關係都 10/31 14:43
→ askacis: 沒有，然後空等在那繼續看案子被客人罰錢有的沒的嗎? 10/31 14:45
→ askacis: 只能說我的實務經驗跟這棟樓實際相差甚遠XD 10/31 14:47
→ u9654802: 我上面有講到一個我所表達的重點和結論...那就是... 10/31 17:55
→ u9654802: "確定我們FW code有開始跑後"才是我們接手... 10/31 17:55
→ u9654802: 當然開始跑我們的code後行為不正常要看波形要對timing 10/31 17:56
→ u9654802: 當然都ok...但是連FW的code一行都沒跑的到情況... 10/31 17:56
→ u9654802: 一定是EE那邊的責任~他們本來就該至少弄到code有開始跑 10/31 17:57
→ u9654802: 吧...你的code都還沒開始跑...當然可以去幫忙...但是.. 10/31 17:57
→ u9654802: 我上面強調過了...幫忙做不等於"該"做...就這麼簡單... 10/31 17:58
→ u9654802: 基本上我說的情況FW就算不插手也不會有人覺得你有問題.. 10/31 17:58
→ u9654802: 操作硬體也要"EE那邊先確定"HW是好的可以操作的情況下.. 10/31 17:59
→ u9654802: 那是EE的責任...不然HW有問題或layout有問題也要怪FW不 10/31 17:59
→ u9654802: 幫忙查?這個就太over了 10/31 18:00