Ciao, 寫給還在韌體底層摸黑仍然沒有放棄的你們 ☕🇮🇹
很開心這段時間我在義大利生活，透過「大大帶我飛」這個平台，有機會認識許多認真準備投入韌體工程師的你們。看著你們努力學習、提問、準備轉職或甚至剛畢業要投入職場，我心裡有一種熟悉的悸動：那些我走過、犯錯過、也摸索過的階段，如果能在記憶還新鮮時，把一些對大家有幫助的經驗分享出來，也許可以縮短大家的疼痛期。
於是某天，坐在佛羅倫斯街角的咖啡館，我就這樣打開電腦，寫下這封電子報。
目前我正在義大利進修 art & design，課業安排比較緊湊，暫時還無法寫長篇的技術文章，但我希望用簡短、實用、專注的內容，陪伴你們在這個學習的路上。By 摸黑了這麼多年還在摸黑還沒有放棄的我 Bonnie ( •̀ᴗ•́ )و ̑̑
- 基礎語言能力
- C
- C++
- Python/Shell scripting
💡 Bonnie 的職場記憶～
U-Boot 和 Linux Kernel 都是使用 C 語言撰寫的，加上我們在免費諮詢時聊過的 OpenBIC，它也是一種基於 RTOS 的韌體，同樣是用 C 語言開發的。對我來說，C 語言是一切系統層開發的基礎，也奠定了後續理解其他程式語言的根本。
因此我會特別建議大家，尤其是跨科系或轉領域的朋友，一定要把 C 語言的基礎打穩。
至於 C++，我就不多說了。如果你曾經打開過 OpenBMC 的程式碼倉庫，會發現其中有不少 Repository（像是 entity-manager、dbus-sensor、bmcweb, phosphor-logging 等）就是用 C++ 撰寫的。這些模組需要較完整的物件導向設計、錯誤處理與資源管理，C++ 在這類結構化服務中非常常見。
最後是 Python 和 Shell Script。OpenBMC 在早期開發階段，為了快速讓韌體具備必要的功能，許多 script 是直接用 Python 或 Shell 撰寫的。這類直譯式語言開發速度快、debug 也方便，非常適合 prototyping。
但隨著功能逐漸複雜，效率問題也開始浮現，因此後來許多原本用 Python 撰寫的功能，會陸續被換成 C 或 C++ 版本，以提升效能與維護穩定度。
那你可能會問：「那 Python 和 Shell Script 現在還有用嗎？」
答案是：當然有！
每一位 Firmware Developer 在完成一項功能後，都需要撰寫 Unit Test，而在整體 Firmware Release 之前，也會進行 Sanity Test、Long-Term Stress Test 等自動化測試。這些測試流程，大多數仍是使用 Python 或 Shell Script 來撰寫的。
所以，即使不是主角，Python 與 Shell 還是每位韌體工程師不可或缺的配角。
- Linux 與開發環境
- Linux kernel and Driver
- U-Boot bootloader 基本使用與修改
- Yocto Project 結構與使用（Poky、BitBake、meta layer）
- Zephry Project 使用
💡 Bonnie 的職場記憶～
實際上，Linux kernel 的驅動程式多半由 IC 廠商或 kernel.org 上的維護者負責開發與維護。然而，不同專案在應用同一顆晶片時，會有各自的客製需求。雖然我們不會要求剛入行的工程師必須對 Linux kernel 有深入了解，或能完全讀懂所有 driver 的實作，但在工作中，確實會遇到需要 debug kernel driver、甚至擴充 driver 功能的情況喔！
值得一提的是，Linux kernel 的版本一直在快速演進 ——現在已經來到 6.x，我剛進公司開始改 driver 的時候，還是2.x 呢（lol）。版本升級帶來許多好處，像是更新的 API、新功能與效能改善，但同時也意味著我們得不斷學習新版 API 的用法，並提防潛藏的 bug…（避雷真的很重要！）
至於U-Boot，被修改的機率相對更低。我目前遇過的修改情境，多數是透過Patch 的形式，放在專案對應的 Project Layer 裡。這種做法的好處是能避免影響其他專案，但壞處是——當 Patch 累積太多，又遇到 U-Boot 的大版本升級時，維護就會變得非常痛苦。因為 Patch 不一定能順利套用回新版，你可能會面臨「10 個 Patch 全部炸掉要一個一個修」的慘況，那絕對是工程師的夢魘之一…。
- 硬體通訊 Bus and Protocol
- I2C、I3C、SPI、UART、eSPI、JTAG、GPIO 等基礎通訊原理與 device 驅動
- Debug 工具使用
- PMBus / IPMB / SMBus / PCIe / NVMe 等常見通訊介面理解
💡 Bonnie 的職場記憶～
看到我列了這麼多通訊協定，你可能會想：「這麼多，我怎麼學得完？」 確實，這是一個很常見的反應。(；・∀・) 但別擔心，我會建議你從一個歷史悠久、幾乎每個專案都會用到的通訊協定開始學起，例如 I2C。 為什麼從它開始？因為它夠穩定、夠普遍，而且網路上的教學與踩雷心得也特別多。前輩們該踩的坑大概都幫你踩過了，你可以一邊讀 SPEC、一邊對照網路教學，來確認自己的理解程度，也順便看看你對這類技術的學習是否感興趣。
如果你已經有一點基礎，我推薦接著看 I3C，它是 I2C 的延伸版本，也是目前越來越多專案會用到的新協定。（我出來國外遊蕩前, 最後一段時間在公司都在處理I3C的各種bug….啊～多麼痛的領悟～ＱＱ）。另外，如果你的專案搭配的是 Intel 的 CPU，那 eSPI 絕對不能錯過，這也是嵌入式系統裡相當重要的一塊。至於像 PMBus、IPMB 等協定，它們本質上都還是走 I2C bus，難度不高，但也是工作中常見的技術，屬於「食之無味、棄之可惜」的類型。有空可以順便了解，沒空也不用太焦慮。
最後是GPIO，其實你只需要知道一件事： **每顆晶片都會有一堆 IO pin，這些就是硬體的輸入／輸出訊號線路。**想要深入理解？**直接去讀你手上那顆 chip 的 SPEC 就對了。**這塊比較特殊，因為實作上很依賴手邊的硬體資源。除非你有像 Raspberry Pi 這樣的設備可以實際動手玩，否則 GPIO 我覺得也沒有非常必要深入學習。
- 管理協定與伺服器平台標準
- IPMI 2.x（SOL、FRU）
- Redfish（RESTful 介面、API 操作以及HTTP methods）
- PLDM / MCTP / SPDM 協議（DMTF 規格理解與應用）
💡 Bonnie 的職場記憶～
這邊的內容並不涉及太多硬體相關的知識與實作，我會留到之後的電子報中再逐步介紹，這邊就不先展開啦～而最常被問到的一個問題是：
IPMI 跟 Redfish 到底有什麼不同啊？？？（黑人問號）
其實這個問題，就有點像你問我：「Linux 的 shell 指令跟滑鼠點兩下操作有什麼不同？」
我的回答會是 —— 他們本質上都是「使用者操作介面」，只是方式不同。
- IPMI：偏向傳統、指令式的操作方式。
- Redfish：則是近年興起、設計得更人性化的介面，屬於 RESTful API 架構，操作上更貼近現代軟體工程的語言和習慣。
目前大多數的大企業客戶，都已經逐漸轉向使用 Redfish，所以如果你打算自學，我會建議從 Redfish 開始了解，會比較符合現在與未來的需求趨勢。
不過如果你是習慣循序漸進、先建立基礎觀念的人，也可以從 IPMI 入門，再來理解 Redfish 如何在它的基礎上做了哪些改進與設計。
- 編譯與 CI/CD 流程工具
- Git / Gerrit 工作流程
- Jenkins / GitHub Actions
- Unit test framework
- Kernel Contribution Rule
- Debug 與系統驗證
- Bring-up 初始測試流程
- IPMI tool / redfish-client 等工具實測操作
- Log 檢查與除錯流程設計
- 自動化測試腳本撰寫與驗證邏輯設計
