:推 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...)，
碰到硬體的機率也很低了~~

點板子我們通常講bring up,很少講start up

以前也是講bring up,一次一個老外講start up也就都講了XD

不是light up嗎

這個的問題在於, 它不屬於 kernel programming 的範圍.hardware 部門的功能很明確, 所以這些都沒錯...然而然而, 這個了不起到 firmware 就要解掉了.波形這種咚咚一路傳到 kernel layer 是非常離譜的事情

Embeded Linux的kernel當然是FW的一部分啊，更何況，驗證用的none OS FW寫成kernel driver的形式並非全然一樣有時候你在none OS可以的東西到了kernel就會有問題,你的工作是FW工程師而非kernel工程師，沒有那種進kernel就不能用示波器的道理，沒示波器，你怎麼知道你的driver沒有問題? 有些ms甚至us等級的問題不是靠printk就可以解還是那句話，遇到就知道XD

呃, 我個人的判斷是...這通常是「把 hardware/firmware 該做的事丟給 CPU. 」所以才會出現 kernel mode 下要考慮 hardware spec.我認真地說, 這不是很健康...會弄到 microsecond 等級的, 我猜大概是 GPS...但是這種咚咚不應該歸為 kernel programming.（因為只有 GPS 硬體夠簡單, 但計時精確度很高... ）至於 kernel 該做什麼哦？google: Linux kernel programming 就有很多答案.這些答案並不會特意區分是不是 embedded linux...

我是不曉得填register不寫CODE靠CPU幫你填要靠什麼XD另外kernel mode絕對會考慮hardware spec，硬體IP出來之後可能會有errata文件出來，你driver就是就是要根據來來改來避，我自己就靠示波器/SD卡分析儀抓到世界大廠的bug，這種bug單靠souce level debug是de不出來的~更有甚著，單純的zImage解壓縮都要多墊幾個nop讓時序正常反正還是那句話，遇到就知道XD再舉個例子，之前debug一個版子，ping大封包會一堆error最後查出來是板子上電路的問題影響到phy，沒有示波器幫你，就算整個kernel的TCP/IP Stack都翻爛也是找不出來~另外，USB測眼圖也是，你FW就是要幫忙填register讓控制器

這些我都知道啊...

根據你的data去產生量測眼圖所需要的波形，最後在儀器上

判定訊號品質，沒過沒拿不到logo咧，這些都是kernel

因為硬體搞成這樣的 bug 也太多了...

總歸一句，你寫kernel code，kernel很大一部分是跟硬體

敝魯隔壁就是做 CPU 的, 他們的 workaround 我也略懂.最常見的就是 lock cpu, disable interrupt, sleep.然後開始 tune sleep time... 一直到會過.

高度相關，LA、示波器、ICE都是不可缺的工具~

但是這些通通都不是 "kernel programming" 哦.所有的 peripheral device 都常被這樣 "workaround".我個人是非常「有概念的」... 科科.

workaround是一回事，寫出來的code沒對data sheet靠示波查又是一回事，不可一概而論基本上自己寫出來的code，沒用示波器看一下波型對照data sheet的timing chart是一件很危險的事。因為有可能你fetch data的點根本是在很margin的位置才會有那種多sleep或是多墊幾個printk就沒事的狀況

ask 兄你也不要那麼激動...你說的那些都是 hardware team 的功能, 這個我也很清楚我只是要說, 那些工作最多就是 driver stack 要做掉.退到 driver layer 已經是很不得以的事情了...不得已, 別字... 科科一下.因為 driver 原則上是提供 functionality/feature API.而不是 workaround/bugfix 這樣的角色.讓 CPU 來管 synchronization/concurrency 是嚴重的錯

A大很中肯阿...淚推...有時候搞了很久才發現是clock

嚴重的設計錯誤... 或者說瑕疵（繼續科科一下. :P）

原PO提到的reset電路, DDR timing, flash旱腳等等的..那些嚴格來說都是驗證的人要處理的事情,這些事情跟kernel programming真的沒什麼關係...寫linux driver也只是kernel programing的一部分而已,

這篇原意是講FW工程師該做的事不是嗎?我原意也是在FW工程師會遇到的問題與工具，Linux Kernel對FW工程師來說接觸最多的就是Driver，也是最大的一部分難到不講Driver debug要講怎麼寫file system or network?另外可能i386公司分工比較細，自己寫的driver還有驗證team來幫你驗，我們比較辛苦，自己的IP或driver要自己驗更別說帶板子起來這種事情還可以勞駕別人來做這麼幸福了~再說一次，我講的是FW工程師職場會遇到的問題，以及Linuxkernel&driver怎麼去Debug與使用工具，很難理解嗎?i386你要不要再看一下我這篇開頭的前兩行?我講DDR timing那些明明是在說明FW工程師會遇到的問題推薦路過的人一本好書<嵌入式系統開發之道>寫FW/嵌入式系統會遇到的問題與職場生活寫照幾乎都有了

你說的情況該用試波器去看波型的還是EE,不該是FW

寫FW不會用示波器? EE可以幫你拉線，看訊號還是FW自己來我還以為是common sense~我們Team RD不會用示波器操作看訊號大概回家吃自己了~

這位A大不用太激動...我是說"該不該",不是說"會不會"...該不該跟會不會不同這個應該是common sence吧...本魯剛好是個寫FW(BIOS)的,示波器/訊號產生器/三用電錶從高職電子科時代開始每周至少相處24個小時以上...加上真的不是很難...我相信也不會有啥FW engineer不會用就點是..."會"就等於"該"嗎?小弟在幫客戶bring up板子時遇過幾種開不起來狀況...1.按power buttom沒反應...system power整個沒起來...這種狀況...EE最先查...再來是EC FW查...2.按power buttom電有起來...但沒跑BIOS code...這時BIOS FW要去幫忙看示波器?當然不用...連我的code一行都沒跑到...說是我的code影響波形的嗎?不是吧...在BIOS FW開始跑之前很多東西是hardware strap弄死的...(當然還有些是更前端的FW ex:EC造成的)當這種情況明明就是EE的問題~不需要我們FW去看波形吧?電有起來...SPI ROM上的code沒跑...hardware自己要去量SPI controller出來的clock有沒有振之類的..."確定我們FW code有開始跑後"才是我們接手...現在或許很多情況是要FW去幫忙cover EE的一些issue...因為動EE要成本...FW不用...但不代表那是FW該做的事...我想表達的就這麼簡單囉...還有...FW engineer為什麼不能預期硬體是好的?你在寫FW時一定是以硬體是好的前提下寫的...硬體是EE的責任...control硬體...是FW的責任,硬體要先是好的我們才能控制啊...不然我們register再怎麼照spec填都不會動...也是算在FW頭上?應該是說FW寫code時當然是預期硬體是好的...但不能預設你的control方式一定是對的...兩者有差...就跟寫Windows AP你會要預設OS是爛的~有毒的~crash的嗎?幫EE找root cause或下workaround...那不是FW該做的,也不是FW的責任~只是在幫EE擦屁股罷了...至於為啥現在FW都被逼著做~就是cost考量囉~所以...做歸還是要做...但還是要強調~那不是FW該做的事~也不是FW的責任囉...

本來就要幫忙看啊，不是說責任是FW的，而是說你FW的責任就是要幫忙跑板子帶起來，俾公司chip一tape out回來，都是FW&EE一起量波形看波形，一起弄到能跑為止分是誰該做的事情一點意義也沒有，回到我本來要表達的意也是FW要經手處理這些事而SW原則是不需要的，也是文章問理論上交到FW的硬體要是好的，但是那只是理論，現實就是even電路經過好幾個人review過，板子真正洗出來驗還是會有一堆低級錯誤產生，所以我才說FW不能預設電路是好的，然後一股腦的查自己Code有沒有問題，你要幫忙EE去看電路真正在操作硬體的人是FW，這幾天我才又遇到一次，ECIEHCI controller不會動，底下裝置都被認為是low speed如果你不看電路量訊號只查自己Code有沒有寫好，那永遠都找不出來錯誤在哪裡，畢竟真正讓硬體動起來的是你的code也只有你才知道當下測出來的訊號有沒有問題~我職場看過很資深的EE，它們除了經驗豐富，還會寫組語控制mcu，幾乎就是一整個超強狀態，那也僅只一兩個而已一般你還是要跟EE一起弄，而不是說等EE查好了你再進來y至於cpu reset的Case，我那時遇到的EE可是直接問你為什麼不會動，如果你不叫他勾訊號出來看reset，那事情沒進展，案子的dealine過了，你可以說是EE的責任跟我FW一點關係都沒有，然後空等在那繼續看案子被客人罰錢有的沒的嗎?只能說我的實務經驗跟這棟樓實際相差甚遠XD

我上面有講到一個我所表達的重點和結論...那就是..."確定我們FW code有開始跑後"才是我們接手...當然開始跑我們的code後行為不正常要看波形要對timing當然都ok...但是連FW的code一行都沒跑的到情況...一定是EE那邊的責任~他們本來就該至少弄到code有開始跑吧...你的code都還沒開始跑...當然可以去幫忙...但是..我上面強調過了...幫忙做不等於"該"做...就這麼簡單...基本上我說的情況FW就算不插手也不會有人覺得你有問題..操作硬體也要"EE那邊先確定"HW是好的可以操作的情況下..那是EE的責任...不然HW有問題或layout有問題也要怪FW不幫忙查?這個就太over了