單體式核心，分層隔離
驅動納入核心；規劃 MMU、EL0 / EL1、行程隔離、排程、IPC 與 VFS。第一版以可除錯、可重現為優先。
BUILT FROM BARE METAL
WAYFINDER OS
WAYFINDER 尋途 CORE / MAX 的自製作業系統。從 AArch64 裸機起步，規劃自行開發核心、libc、驅動、檔案系統與圖形介面，讓能源安排與現場操作一起設計。
自製方向定案 · 功能尚待實作與驗證把待命留給低功耗，
把待命留給低功耗，
把算力留給需要的時刻。
團隊於 2026 年 9 月 10 日確立自製方向：不採用 Linux 核心，不納入 musl、LVGL、lwIP、littlefs。以 C 為主、AArch64 組語為輔，逐步建立可控制的系統。
近期先驗證 CORE 的 A733 平台；MAX 的 RK3588S2 硬體適配另行評估。目前沒有可下載的正式系統或已驗證的整機效能數據。
WAYFINDEROS
AARCH64 / BUILT IN-HOUSE
WHAT WE BUILD
自製的邊界，
先說清楚。
目標是「WAYFINDER OS 位址空間內零第三方程式碼」。這是設計與驗收要求，尚非已完成的稽核結果。
OS 映像、核心與使用者程式所納入的程式碼，以團隊自行實作為原則；平台韌體、開發工具與獨立晶片韌體分開列管。記憶體配置、連結結果與實際載入內容都需要核對。
- 開發工具
- GCC / Clang、binutils、GDB、OpenOCD、git 可作開發用途。編譯器可能產生執行期函式呼叫，因此還要檢查 libgcc、compiler-rt、啟動物件與連結映像，不能僅憑使用裸機編譯選項就宣稱零第三方碼。
- 平台韌體
- DDR 初始化與 BL31 依實際平台確認來源、可取得性與授權。BL31 可在 EL3 持續提供執行期服務，不能一概視為開機後消失的程式，也不能一概視為閉源。
- 獨立晶片韌體
- EG915U、ESP32-C6、nRF54L15 等晶片上的韌體列為外部模組依賴。它們不等於主 OS 程式碼，但版本、介面與更新方式仍需記錄。
POWER BY DESIGN
醒來處理，完成就退場。
CORE 以主 SoC 斷電待命為優先探索方向，由常駐控制核心接收喚醒事件，再冷開機回到必要操作。每一次啟動的時間與耗能，都要算進整體續航。
CORE 續航探索目標72 h
受電池、工作週期與喚醒次數影響
斷電待命功耗目標5–10 mW
包含常駐核心、接收與電源損耗
冷開機至可操作畫面目標<1 s
包含供電、DDR、載入與顯示初始化
- 01 / 斷電待命
保留最小喚醒能力
常駐核心、LoRa 佔空比接收與 RTC。10% 接收佔空比是初始假設，需驗證漏接率與呼叫延遲。
LoRa 呼叫、按鍵或鬧鐘 → - 02 / 冷開機
恢復必要操作
依平台完成 DDR 初始化、BL31、載入器、核心與 UI；狀態保存於常駐 RAM 與儲存日誌的方案待驗證。
畫面與基本輸入可用 → - 03 / 工作
按任務配置算力
小核低頻與面板自刷新為候選策略；須核對實際硬體支援。工作功耗初估 0.5–1 W。
無事件 30 秒，先保存再斷電 - 04 / 滿載
需要時短暫提速
高算力工作或 LTE 傳輸初估 3–4 W。完成後立即回到低負載；無事件時再進入斷電待命。
任務完成 → 降回工作狀態
72 小時的能源帳，怎麼核對？
以規劃假設 1S 5000 mAh、標稱 3.7 V 計算，名目能量約 18.5 Wh；若可用能量為 16.7 Wh，72 小時平均功率預算約為 232 mW。電芯、轉換效率與截止電壓尚待確認。
若「20% 工作、2% 滿載」是互不重疊的時間比例，其餘 78% 待命：工作與滿載能量依目前功耗區間，約落在 11.52–20.16 Wh。區間上緣已超過 16.7 Wh；因此 72 小時不能只靠壓低待命功耗保證。
只有先假設工作與滿載合計耗能 16.1 Wh，剩餘 0.6 Wh 分配給 56.16 小時待命，才得到約 10.7 mW 的待命上限。此算法尚未另計重複冷開機與其他未納入損耗。
接下來要量測各狀態能量、每次冷開機耗能、喚醒頻率及斷電前資料保存成本，重新建立整機能源模型。20% 在這裡指工作時間假設，不是開發進度或募資比例。
自製 OS 是本專案選擇的路線；秒級啟動並非自製 OS 獨有。Bootlin 的 Linux 啟動優化資料 ↗已有相關案例，不能據此推論 CORE 的任何系統已可達到同樣速度。
SYSTEM ARCHITECTURE
先建立能驗證的系統骨架。
自寫繪圖與 UI
先以軟體繪圖建立畫面；2D 引擎須待文件與驅動可行性確認。CJK 子集在建置時產生點陣字型，字型來源與授權另行列管。
把斷電當成正常流程
規劃自寫日誌式檔案系統及唯讀 FAT 支援。需驗證 flush、寫入中斷、重新掛載與資料復原，不能僅靠日誌名稱宣稱斷電安全。
由模組處理網路能力
規劃透過 EG915U 的 AT 指令與 socket 代理使用模組端 TCP/IP、TLS 能力；實際支援依型號與韌體版本核對。第一版不自行實作 TLS 或密碼學。
模組介面參考：Quectel TCP/IP 應用說明 ↗。憑證驗證、可信時間、金鑰保存與韌體更新仍屬整合工作。
FIRST-RELEASE SCOPE
首版不把 GPU、NPU 與完整 ISP 相機管線列為必要功能。
先完成基本畫面與操作；原始 sensor 資料擷取、2D 加速與進階影像功能，都須另行確認硬體文件與驅動成本。晶片的理論 TOPS 不作為目前 OS 效能承諾。
M0 → M4
從第一行輸出，走到完整操作。
M0、M1 為近期驗證重點；具備儲存、顯示、觸控與 UI 的 M2，才進入基本可操作原型階段。下列節點均未宣告完成。
- M0近期目標
模擬環境中的系統基礎
QEMU virt：開機、MMU、排程、SMP、page fault 與使用者行程。先建立不依賴開發板的可重現驗證。
- M1近期目標
在 CORE 開發板建立基本控制
UART、GIC、timer、GPIO、I2C。以取得 A733 文件、啟動韌體與板卡為前提。
- M2另行排程
基本可操作原型
eMMC / UFS 擇實際配置、檔案系統、顯示、觸控與 UI 框架完成整合。這是後續主要工程階段。
- M3依 M2 結果評估
整合周邊能力
LR2021、GNSS、電源 IC 與 NFC 依各模組實際匯流排接入，不預設全部使用 SPI。
- M4依模組驗證評估
行動網路與 socket 代理
EG915U 的 AT 通道、連線狀態、錯誤復原與網路代理整合驗證。
OPEN ENGINEERING QUESTIONS
把關鍵的不確定性，放在前面。
時程先對齊可驗收成果
程式碼行數無法直接換算完成日期。十二月以 M0 / M1 及電源概念驗證為重點，完整 M2 原型依人力、文件與硬體進展重排。
A733 與 RK3588S2 分開適配
CORE 變更至 A733 後，DDR、BL31、時鐘、顯示與儲存驅動要重新盤點。核心通用部分與 UI 可規劃共用，不能假設底層驅動直接共用。
在驅動實作前確立規則
自寫原則與逐行移植第三方參考碼不能混為一談。授權、衍生關係及散布安排應先審查；開源或其他發布方式仍待團隊決策。
規模與記憶體：目前有哪些估算？
團隊初估總規模為 12–16 萬行，分項合計約 14 萬行。這是規劃量級，不是已完成程式碼。
| 模組 | 估算行數 |
|---|---|
| 核心：啟動、MMU、GIC、排程、IPC、VFS | 15,000 |
| SoC 驅動 | 25,000 |
| libc | 12,000 |
| 繪圖與 UI | 40,000 |
| 檔案系統 | 7,000 |
| 周邊、電源與 AT 代理 | 20,000 |
| 應用層 | 15,000 |
| 常駐核韌體 | 6,000 |
映像 5–10 MB、執行 RAM 小於 64 MB，暫作資源預算；需隨顯示解析度、雙緩衝、字型、驅動與應用工作集重新估算。
40–70 人月、學生團隊 60–140 人月亦屬未校準的初估，不能直接由行數推出。下一步以工作分解、可投入時數與實際除錯紀錄校準。
GPL 與「自己重寫」的界線
U-Boot 整體採 GPLv2 或後續版本，但個別檔案可能有不同授權或例外，須逐檔確認。引用或改寫程式碼是否形成衍生作品，不能僅以改名、改語言或「自己打一次」判斷。
GPL 的來源碼提供義務與受涵蓋程式的散布有關，不是只要閱讀或私下修改就必須向全世界公開整套 OS。採用任何參考碼前，先保留來源、授權與使用方式紀錄，再確認具體發布條件。
本頁依團隊最新 OS 架構說明整理。設計選擇、資源預算與實測結果分開呈現；目前所有功能與數據均待實作或驗證。