解鎖硬體新技能：Advantech 如何讓你的設備閃電更新？

本文章內容係以參考技術文件為基礎，經由人工智慧（AI）技術進行改寫及重整，旨在提供讀者更清晰易懂之內容呈現。如有任何技術細節上的疑義或需進一步確認，建議讀者參考原始技術文件或與相關技術人員聯繫。

想像一下，你手邊有一台搭載最新 Advantech 硬體的設備，需要更新系統或韌體。過去，這可能需要一些特定的工具或複雜的步驟。但如果我們能讓這個過程變得像用 USB 隨身碟一樣簡單，甚至更聰明呢？這正是 Advantech 工程師們最近完成的一項有趣實驗！

這次，我們的研發團隊挑戰了一個特別的硬體情境：當硬體設計上，我們使用了一根「通用輸入輸出腳位」(GPIO) 來充當 USB 的「身份識別腳位」(ID pin)。這個 ID pin 就像是硬體給軟體的一個小暗號，告訴它 USB 應該以哪種模式工作（例如，是作為主機連接其他設備，還是作為裝置被電腦連接）。在這種特定設計下，如何確保我們能順利地使用 UUU (Universal Update Utility) 這個強大的工具來燒錄或更新 Android 作業系統呢？這就是我們實驗的目的！

為什麼這很重要？認識 UUU 與 ID Pin
#

在嵌入式系統的世界裡，「燒錄」(Flashing) 指的是將作業系統或韌體安裝到硬體的儲存空間中，就像你在電腦上安裝 Windows 或 Linux 一樣。UUU 是一個由 NXP 開發的工具，它讓這個燒錄過程變得更快速、更可靠，特別是在開發階段或需要大量部署時。

而 ID pin 則是一個硬體設計上的細節。在某些 USB 接口（特別是 Micro-USB 或 Type-C）中，會有一個專門的 ID pin 來決定 USB 的角色。但有時候，為了硬體設計的彈性或簡化線路，工程師可能會選擇用一個普通的 GPIO pin 來模擬這個 ID pin 的功能。這帶來的好處是硬體設計更靈活，但挑戰在於，軟體（特別是底層的啟動程式和作業系統）必須要能正確地識別並處理這個由 GPIO 模擬出來的 ID pin 狀態。

我們的目標，就是在這種「用 GPIO 當 ID pin」的特定硬體設計下，讓 UUU 燒錄流程在 Android 系統上暢行無阻。

實驗大解密：從啟動到系統核心
#

為了達成這個目標，我們的工程師深入研究了系統的兩個關鍵部分：U-boot 和 Linux Kernel。

第一關：U-boot 啟動程式
#

U-boot 是設備啟動時最先執行的程式，它負責初始化硬體並載入作業系統。如果 U-boot 無法正確識別 USB 接口，後續的燒錄當然就無法進行。

實驗中，我們首先修改了 U-boot 的設定檔 (imx8mp_rsb3720a1_android_4G_uuu_defconfig)，確保相關的 USB 設定是正確的：

# CONFIG_USB_TCPC is not set

同時，也調整了編譯設定 (/\<BSP>/device/fsl 底下的 UbootKernelBoardConfig.mk)，指定使用這個新的設定檔：

TARGET_BOOTLOADER_CONFIG += imx8mp-evk-uuu:imx8mp_rsb3720a1_android_4G_uuu_defconfig

在實驗過程中，我們遇到了 USB 初始化失敗的錯誤訊息 (USB init failed: -22)。這時候，工程師就像偵探一樣，利用 U-boot 提供的指令來檢查 USB 狀態：

u-boot=> usb start
u-boot=> usb info

透過觀察輸出的訊息，例如：

u-boot=> usb start
starting USB...
Bus usb@38100000: Failed to initialize board for imx8m USB
probe failed, error -22
Bus usb@38200000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38200000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

我們發現問題出在 usb@38100000 這個 USB 控制器上。進一步檢查硬體的「設備樹」(Device Tree Blob, DTB) 設定檔，DTB 就像是硬體給軟體看的一份地圖和說明書，告訴軟體各個硬體元件在哪裡、有哪些屬性。我們檢查了對應 38100000 的節點：

		usb_dwc3_0: dwc3@38100000 {
			compatible = "snps,dwc3";
			reg = <0 0x38100000 0 0x10000>;
			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
			phys = <&usb3_phy0>, <&usb3_phy0>;
			phy-names = "usb2-phy", "usb3-phy";
			xhci-no-64bit-support;
			usb3-resume-missing-cas;
			snps,dis-u2-freeclk-exists-quirk;
			snps,soft-itp-sync;
			status = "disabled";
		};

發現 status 被設為 "disabled"！這就是問題所在。修正這個設定後，U-boot 就能正確初始化 USB 了。

最後，使用 UUU 燒錄的指令如下：

$ ./uuu_imx_android_flash.sh -f imx8mp -a -e

這個指令會自動完成後續的燒錄流程。

第二關：Linux Kernel 系統核心
#

光是 U-boot 認識 USB 還不夠，作業系統本身（Linux Kernel）也必須知道如何處理這個由 GPIO 控制的 ID pin，特別是與 OTG (On-The-Go) 和 ADB (Android Debug Bridge) 功能相關的部分。OTG 讓設備可以在主機和裝置模式間切換，而 ADB 則是 Android 開發和除錯常用的工具，兩者都高度依賴 USB 的正確識別。

根據我們在 ROM-5722 專案中的經驗，需要對 Kernel 的程式碼進行修改。具體的修改可以參考這個連結： https://github.com/ADVANTECH-Corp/linux-imx/commit/f35c86e76abf7967b487800602ebf75e097fbf7c

這段程式碼的修改，核心在於告訴 Kernel 如何讀取那個特定的 GPIO pin 的狀態，並根據這個狀態來正確配置 USB 的 OTG 功能，確保 ADB 連接等都能正常工作。

實驗成果與價值
#

經過上述 U-boot 和 Kernel 的修改與驗證，我們成功地在使用了 GPIO 作為 ID pin 的 Advantech 硬體平台上，實現了 UUU 對 Android 系統的順利燒錄！

這項成果代表著：

硬體設計更靈活： 我們的硬體設計師可以更自由地規劃 USB 接口，不必受限於傳統的 ID pin 設計。
軟體支援更全面： Advantech 的 BSP (Board Support Package) 能夠完美支援這種特殊的硬體配置，確保軟體與硬體的無縫協作。
客戶更新更便捷： 對於使用相關 Advantech 產品的客戶來說，這意味著可以使用 UUU 這樣高效的工具來進行系統更新或還原，簡化了維護流程。

這項實驗不僅解決了一個特定的技術挑戰，更展現了 Advantech 在硬體設計、底層軟體開發以及系統整合方面的深厚實力。我們不只提供硬體，更投入資源確保軟體能完美駕馭硬體的每一個細節。