Monolithic kernel, layered isolation
Drivers live in the kernel, which covers the MMU, EL0 / EL1, process isolation, scheduling, IPC, and VFS. The first version prioritizes debuggability and reproducibility.
BUILT FROM BARE METAL
WAYFINDER OS
The in-house operating system for WAYFINDER CORE / MAX. Starting from AArch64 bare metal, we write our own kernel, libc, drivers, file system, and graphical interface, so energy management and field operation are designed together.
In-house scope decided · Features still to be implemented and verifiedLeave standby to low power.
Leave standby to low power.
Save compute for when it matters.
On September 10, 2026, the team set the in-house scope: no Linux kernel, and no musl, LVGL, lwIP, or littlefs. Written mainly in C with AArch64 assembly where needed, the system is built up step by step under our own control.
Near-term verification targets CORE's Genio 720 platform. The compute platform for MAX is still under selection. There is currently no downloadable release and no verified full-device performance data.
AARCH64 / BUILT IN-HOUSE
POWER BY DESIGN
Wake
Wake to work. Step back when done.
The system does not keep everything switched on. Normally only the smallest part stays awake, waiting for events. When one arrives, main compute wakes, does what it needs to, and returns to standby.
CORE prioritizes powered-off standby for the main SoC. An always-on control core receives wake events, then cold-boots the system back to the operations it needs. The time and energy of every boot count against overall battery life.
CORE exploratory battery life target72 h
Depends on battery, duty cycle, and number of wake-ups
Powered-off standby power target5–10 mW
Includes the always-on core, receiving, and power losses
Cold boot to usable screen target<1 s
Includes power-up, DDR, loading, and display initialization
- 01 / Powered-off standby
Only the wake path stays on
The always-on core, duty-cycled LoRa receive, and the RTC. The 10% receive duty cycle is an initial assumption; missed-call rate and call latency are to be verified.
LoRa call, button, or alarm → - 02 / Cold boot
From zero to usable
Per platform: DDR initialization, BL31, loader, kernel, and UI. Saving state in always-on RAM and a storage journal is a plan still to be verified.
Screen and basic input ready → - 03 / Working
Compute matched to the task
Low-frequency little cores and panel self-refresh are candidate strategies, pending confirmation of actual hardware support. Working power is initially estimated at 0.5–1 W.
30 seconds with no events: save, then power off - 04 / Full load
Speed up, then step back
High-compute work or LTE transfers are initially estimated at 3–4 W. When done, the system drops back to low load right away, and enters powered-off standby when no events remain.
Task complete → back to working state
SYSTEM ARCHITECTURE
First, a system skeleton we can verify.
Our own rendering, our own interface
Screens are drawn in software first. A 2D engine depends on confirming documentation and driver feasibility. A CJK subset bitmap font is generated at build time; font sources and licenses are tracked separately.
Power off on standby, cold boot back to work
A self-written journaling file system and read-only FAT support are planned. Flush, interrupted writes, remounting, and data recovery must be verified; a journal alone does not make it power-loss safe.
Networking, handled by the module
The plan is to use the module's own TCP/IP and TLS through EG915U AT commands and a socket proxy; actual support will be checked against the model and firmware version. The first version will not implement TLS or cryptography itself.
Module interface reference: Quectel TCP/IP Application Note ↗︎. Certificate validation, trusted time, key storage, and firmware updates remain integration work.
FIRST-RELEASE SCOPE
The first release does not treat the GPU, NPU, or a full ISP camera pipeline as required features.
Basic screens and operation come first. Raw sensor capture, 2D acceleration, and advanced imaging each require separate confirmation of hardware documentation and driver cost. The chip's theoretical TOPS is not a current OS performance commitment.
M0 → M4
From the first line of output to full operation.
M0 and M1 are the near-term verification focus. Only M2, with storage, display, touch, and UI, reaches the basic operable prototype stage. M0 was completed on September 27, 2026; the remaining milestones are not yet complete.
- M0Completed · 2026.09.27
System foundations in emulation
QEMU virt: boot, MMU, scheduling, SMP, page faults, and user processes. Reproducible verification first, without depending on a development board.
- M1Near-term goal
Basic control on the CORE dev board
UART, GIC, timer, GPIO, I2C. Requires access to Genio 720 documentation, boot firmware, and boards.
- M2Scheduled separately
Basic operable prototype
Integration of eMMC / UFS (whichever is actually fitted), file system, display, touch, and UI framework. This is the main engineering phase ahead.
- M3Evaluated after M2 results
Peripheral integration
LR2021, GNSS, and the power IC connect over each module's actual bus. SPI is not assumed for all of them.
- M4Evaluated after module verification
Cellular and socket proxy
Integration and verification of the EG915U AT channel, connection state, error recovery, and network proxy.
OPEN ENGINEERING QUESTIONS
Key uncertainties, up front.
Schedule aligned to acceptable results
Lines of code do not translate directly into a completion date. December focuses on M0 / M1 and a power proof of concept; the full M2 prototype will be rescheduled based on staffing, documentation, and hardware progress.
New platform, new low-level review
With CORE moving to Genio 720, DDR, BL31, clocks, display, and storage drivers all need a fresh review. MAX's compute platform is still under selection. Shared kernel code and UI can be planned for reuse, but low-level drivers cannot be assumed to carry over.
Set the rules before writing drivers
Writing our own code is not the same as porting third-party reference code line by line. Licensing, derivative relationships, and distribution should be reviewed first. Whether to open-source or release another way is still a team decision.
ENGINEERING DETAIL
Want to check the approach? Go one level deeper.
Where the in-house work ends, how platform firmware and license boundaries are drawn, how the 72-hour energy budget is calculated, and where the 120,000–160,000-line size estimate comes from are all covered on the engineering detail page, not here.
Compiled from the team's latest OS architecture notes. Design choices, resource budgets, and test results are presented separately. All features and figures are still to be implemented or verified.