モノリシックカーネル、階層で分離
ドライバーはカーネルに組み込み、MMU、EL0 / EL1、プロセス分離、スケジューリング、IPC、VFS をカバーします。第1版はデバッグ可能で再現可能であることを優先します。
BUILT FROM BARE METAL
WAYFINDER OS
WAYFINDER CORE / MAX のための自作 OS。AArch64 ベアメタルから出発し、カーネル、libc、ドライバー、ファイルシステム、グラフィカルインターフェースを自ら開発。電力の配分と現場での操作を、一体で設計します。
自作範囲は決定済み · 機能は実装・検証待ち待機は低消費電力に、
待機は低消費電力に、
演算能力は必要な瞬間に。
チームは 2026年9月10日に自作の範囲を確定しました。Linux カーネルは採用せず、musl、LVGL、lwIP、littlefs も取り入れません。C を主に、AArch64 アセンブリを補助として、制御可能なシステムを段階的に築きます。
当面は CORE の Genio 720 プラットフォームで検証を進めます。MAX の演算プラットフォームはまだ選定中です。現時点で、ダウンロード可能な正式版システムや、検証済みの本体性能データはありません。
AARCH64 / BUILT IN-HOUSE
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。完了後はすぐ低負荷に戻り、イベントがなければ電源オフ待機に入ります。
タスク完了 → 動作状態へ戻る
SYSTEM ARCHITECTURE
まず、検証できるシステムの骨格を。
描画も、インターフェースも自作
まずソフトウェア描画で画面を構築します。2D エンジンは資料とドライバーの実現性が確認されてからです。CJK のサブセットはビルド時にビットマップフォントとして生成し、フォントの出所とライセンスは別途管理します。
電源オフで待機、コールドブートで復帰
自作のジャーナリング型ファイルシステムと、読み取り専用の FAT 対応を計画しています。flush、書き込み中断、再マウント、データ復旧の検証が必要で、「ジャーナリング」という名前だけで電源断に対する安全性をうたうことはできません。
ネットワーク機能は、モジュールに任せる
EG915U の AT コマンドと socket プロキシを通じ、モジュール側の TCP/IP、TLS 機能を使う計画です。実際の対応状況は型番とファームウェアのバージョンで確認します。第1版では TLS や暗号処理を自前で実装しません。
モジュールのインターフェース参考資料：Quectel TCP/IP アプリケーションノート ↗︎。証明書の検証、信頼できる時刻、鍵の保管、ファームウェア更新は、引き続き統合作業の範囲です。
FIRST-RELEASE SCOPE
初版では、GPU、NPU、完全な ISP カメラパイプラインを必須機能にしません。
まず基本的な画面と操作を完成させます。生のセンサーデータの取得、2D アクセラレーション、高度な画像機能は、いずれもハードウェア資料とドライバーのコストを別途確認する必要があります。チップの理論上の TOPS は、現時点での OS 性能のお約束ではありません。
M0 → M4
最初の 1 行の出力から、完全な操作へ。
当面の検証の重点は M0 と M1 です。ストレージ、表示、タッチ、UI を備えた M2 で、ようやく基本的に操作できる試作機の段階に入ります。M0 は 2026年9月27日に達成済みで、それ以外のマイルストーンはまだ完了していません。
- M0完了 · 2026.09.27
エミュレーション環境でのシステム基盤
QEMU virt：起動、MMU、スケジューリング、SMP、page fault、ユーザープロセス。まず開発ボードに依存しない再現可能な検証を構築します。
- M1当面の目標
CORE 開発ボードでの基本制御
UART、GIC、timer、GPIO、I2C。Genio 720 の資料、ブートファームウェア、ボードの入手が前提です。
- M2別途計画
基本的に操作できる試作機
eMMC / UFS（実際の構成に合わせて選択）、ファイルシステム、表示、タッチ、UI フレームワークを統合します。今後の主要なエンジニアリング段階です。
- M3M2 の結果を見て評価
周辺機能の統合
LR2021、GNSS、電源 IC は各モジュールの実際のバスに合わせて接続し、すべてを SPI とする前提は置きません。
- M4モジュール検証を見て評価
モバイル回線と socket プロキシ
EG915U の AT チャネル、接続状態、エラー復旧、ネットワークプロキシの統合検証。
OPEN ENGINEERING QUESTIONS
重要な不確実性を、先に示す。
スケジュールは、検収できる成果に合わせる
コードの行数は、そのまま完成日に換算できません。12月は M0 / M1 と電源の概念実証に注力し、完全な M2 試作機は人員、資料、ハードウェアの進捗に応じて組み直します。
プラットフォームが変われば、下層を洗い直す
CORE を Genio 720 に変更したことで、DDR、BL31、クロック、表示、ストレージのドライバーを改めて洗い出す必要があります。MAX の演算プラットフォームはまだ選定中です。カーネルの汎用部分と UI は共通化を計画できますが、下層のドライバーがそのまま共用できるとは想定できません。
ドライバー実装の前にルールを確立
自作の原則と、サードパーティの参考コードを 1 行ずつ移植することは、同列には扱えません。ライセンス、派生関係、配布方法を先に審査すべきです。オープンソース化やその他の公開方法は、チームでまだ決めていません。
ENGINEERING DETAIL
手法を確かめたいなら、もう一段深く。
どこまでを自作するのか、プラットフォームのファームウェアとライセンスの境界をどう引くのか、72 時間の電力収支をどう計算するのか、12–16 万行という規模の見積もりの根拠は何か。これらはエンジニアリング詳細ページにまとめており、このページでは扱いません。
このページはチームの最新の OS アーキテクチャ説明をもとに整理しています。設計上の選択、リソース予算、実測結果は分けて示しています。現時点で、すべての機能とデータは実装または検証待ちです。