:推 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了