幾秒之后，界面也許才會亮起，顯示一個臨時啟動畫面，在初始化過程中閃爍幾下，最后才進入真正的應用界面。即使在性能很快的系統上，這個過程依然顯得不穩定，因為問題通常并不在于算力性能，而在于啟動期間“誰在控制顯示輸出”。

GraphLab Boot 采用了不同的思路。實時核心在上電瞬間就激活顯示器，在 Linux 啟動期間持續維持顯示，并讓 Linux 直接渲染到這條已經處于活動狀態的顯示路徑中，而不會觸發一次肉眼可見的覆蓋。

根本原因很簡單：在傳統的嵌入式 Linux 啟動流程中，并不存在一個組件從頭到尾一直擁有顯示控制權。

即使每個階段單獨來看都運行正常，它們之間的切換仍然可能帶來黑幀、閃爍，或者與時序相關的不穩定行為。從工程視角看，這很常見；但從產品視角看，這并不理想。

GraphLab Boot 如何在第一時間顯示第一個像素？

在默認配置中，這第一幀可以是一個啟動畫面，并帶有可配置的狀態文本，而不是一張靜態圖片。顯示出來的消息可以對應真實的系統狀態，例如顯示 pipeline 初始化、切換準備就緒，或 Linux DRM 的關鍵里程碑，同時又能針對不同項目做定制。

如果項目需求不止于啟動畫面，GraphLab 還可以把實時核心階段的渲染擴展成更豐富的早期 UI，包括動畫、文字、圖片以及來自 I2C、SPI、CAN 等外設的實時數據。不過文中強調，這類能力目前應被視為 GraphLab 提供的項目級擴展，而不是今天就能由客戶自助啟用的標準功能。

第二個挑戰是向 Linux 圖形棧切換的過程。在傳統方案中，Linux 會接管顯示pipeline，重新初始化 DRM 狀態，而控制權變更期間很容易出現可見的熄屏或空白。

在 Torizon 環境中，Linux 圖形棧、合成器和 UI 容器仍然可以在后臺啟動，而用戶可見的輸出始終由實時核心控制。只有到了選定的交接點，才會切換到 Linux 渲染的輸出，因此用戶不需要在屏幕上看到 Linux 啟動過程中的中間階段。

Linux UI 如何在沒有可見切換的情況下變得可交互？

這種切換可以通過連續幀檢測自動發生，也可以通過一個 sysfs 開關，由應用程序在確認 Linux 輸出已經準備好時顯式觸發。

從用戶視角來看，系統就像是直接啟動進入應用的就緒狀態。由于底層顯示 pipeline 始終保持活動，整個切換過程可以在沒有可見重置、空白幀或模式切換的情況下完成。

這種“無切換”架構是如何工作的？

通俗地說，Linux 并不是把每次顯示更新都通過 Cortex-M 核心“轉發”，從而形成瓶頸。相反，Cortex-M 只負責讓顯示引擎保持激活并持續擁有控制權，而 Linux 則把內容渲染到已經連接到活動顯示 pipeline 的共享幀緩沖區中。

隨后，一個定制 DRM 驅動會把這條現有顯示 pipeline 暴露給 Linux，但不會轉移其所有權。Linux 仍然可以通過熟悉的圖形路徑進行渲染，只不過它所依賴的顯示 pipeline 從始至終都不需要真正“切換”過來。

啟動流程概覽

這里的“零拷貝共享幀緩沖”模型很關鍵。它避免了為了跨越啟動階段而額外進行圖像切換或合成，也解釋了為什么整個切換過程能夠在視覺上保持無縫。

這在 Toradex Verdin iMX8M Plus 上實際帶來了什么變化？

Linux 仍然運行在應用處理器核心上，并配合專用 DRM 驅動；與此同時，GraphLab Boot 與標準啟動流程并行工作，以保證顯示輸出持續不斷。

實際測試

早期啟動：GraphLab Boot 已有可見輸出，而標準 Linux 仍是黑屏。

啟動中期：GraphLab Boot 持續顯示受控的進度信息，而標準 Linux 路徑則在真正應用準備好之前顯示一個 compositor(Weston) 畫面。

應用就緒：兩套系統最終都能進入 UI，但只有 GraphLab Boot 在整個過程中始終保持視覺連續。

在當前配置下，GraphLab Boot 能在 800 毫秒內顯示第一個可見像素。

標準 Linux 啟動在真正 UI 準備好之前會出現多個可見的空白或重置時刻；而 GraphLab Boot 則在整個過程中都保持連續輸出，不會讓用戶看到顯示被重置。

這種方案的一個關鍵優勢，是 Linux 側應用開發方式依然保持不變。GraphLab Boot 改變的是啟動過程中顯示 pipeline 的初始化、保護和顯示方式；它并不要求對 Linux 圖形棧進行根本性重寫。

目前這已經在 Torizon 的 Demo Gallery 鏡像上完成驗證，包括 Qt、Embedded Wizard 和 Crank Storyboard 等示例。這說明現有應用框架可以繼續保留，而 GraphLab Boot 則在底層改善了從啟動到 UI 的體驗。

工業 HMI 可以從中受益，因為它能為操作員提供即時反饋，讓啟動過程看起來是確定的，而不是“抖動、閃屏、像出故障”。醫療設備可以從上電到 UI 可用之間獲得更可控、也更容易追蹤的路徑。

在 Toradex Verdin iMX8M Plus 上進行實際評估時，可以從 GraphLab 的基礎 OS 鏡像開始，再在其上運行 Toradex Demo Gallery 項目。

若想進一步了解 GraphLab Boot，可訪問 https://graphlab.net/。如果想試用演示，首先需要創建 GraphLab Portal 工作區，并按照 https://portal.graphlab.net/ 上的入門與技術文檔操作。如果你需要商業層面的支持，可通過 graphlab.net 上的 Request Sales Information 流程聯系；如果需要面向硬件的評估，則可使用 Request Evaluation Kit 流程進入 Toradex 的評估通道。

結論

GraphLab Boot 證明了：第一個像素可以在上電時就出現；Linux 初始化期間顯示可以始終保持連續活動；真正的應用可以在不經過破壞性顯示切換的情況下直接呈現出來。

目前，這個方案的已驗證落地點是 Toradex Verdin iMX8M Plus。但相同的架構思路并不局限于這一種模塊，它同樣適用于更多基于 i.MX 91、i.MX 93 或 i.MX 95 的 Toradex 平臺，只是具體如何落地，需要結合客戶項目來實現。

FAQ

• ? 是否需要重寫 Linux 側的圖形框架？ 不需要，至少不“重寫應用側圖形框架”。Linux 側仍然使用原本的渲染模型；關鍵變化在于啟動期間顯示 pipeline 如何被初始化、保護、顯示，以及在合適的時刻切換。

• ? Cortex-M 會不會變成每幀渲染瓶頸？ 不會。Cortex-M 核心不會成為逐幀渲染瓶頸。它負責持續擁有顯示管線，而 Linux 則把內容渲染到仍連接在活動輸出路徑上的共享幀緩沖區中。

• ? 切換到 Linux 輸出的時機由什么決定？ 這個時機是可配置的。GraphLab Boot 可以基于連續幀檢測自動切換，也可以在 Linux 側應用認為自己已經準備好時，通過 sysfs 控制進行顯式切換。

• ? Linux 應用后續維護或崩潰時還能切回實時核心嗎？ 可以。當 Linux 應用需要維護、重啟或服務操作時，渲染路徑可以切回實時核心；這有助于在 Linux 已經啟動之后，依然保持穩定的視覺體驗。

• ? 現有 UI 框架還能繼續用嗎？ 可以，這正是它的價值主張之一。現有 Linux 側 UI 框架，例如已驗證的 Toradex Demo Gallery 中的 Qt、Embedded Wizard 和 Crank Storyboard，都可以繼續保留，因為 GraphLab Boot 針對的是啟動期與交接行為，而不是替換上層應用框架。

• ? 啟動畫面的狀態文字能動態變化嗎？ 可以。默認情況下，GraphLab Boot 顯示的狀態文字不是靜態的，而是與真實的啟動和顯示狀態關聯，例如顯示 pipieline 進程或 Linux DRM 就緒里程碑。這些可見消息仍然可以通過一套可配置的狀態到消息映射，按項目需求進行定制。

• ? 它能做的不只是 splash screen 嗎？ 可以，但需要注意幾點。默認情況下，GraphLab Boot 提供的是帶可定制、狀態驅動文本的啟動畫面。再往上擴展，GraphLab 在實時核心側具備內部工程能力和渲染基礎，可將早期顯示體驗擴展成更豐富的 UI，包括動畫、文字、圖片以及實時外設數據。不過這屬于 GraphLab 提供的項目定制工程服務，而不是現成自助開箱功能。

• ? 閃爍是怎么被消除的？ 關鍵在于避免重復初始化顯示，并從早期啟動開始就維持一個持久的顯示 pipieline 所有者。Linux 是作為渲染者加入這條已在運行的pipieline，而不是通過破壞性的模式切換來奪取控制權。

• ? 從哪里開始評估？ 可以從 GraphLab Portal 開始，并按照入門文檔在真實硬件上探索 GraphLab Boot：https://portal.graphlab.net/