ENGINEERING DETAIL
WAYFINDER OS Engineering Detail
This layer is for readers who want to check the approach: where the in-house work ends, how license boundaries are drawn, how the 72-hour energy budget is calculated, and where the size estimates come from. Every number here is a planning value, not a measured result.
To learn what WAYFINDER OS does and why, see System.
WHAT WE BUILD
Where in-house ends,
stated up front.
The goal is "zero third-party code in the WAYFINDER OS address space." This is a design and acceptance requirement, not a completed audit result.
Code included in the OS image, kernel, and user programs is, as a rule, implemented by the team. Platform firmware, development tools, and standalone chip firmware are tracked separately. Memory layout, link output, and what is actually loaded all need to be checked.
- Development tools
- GCC / Clang, binutils, GDB, OpenOCD, and git may be used for development. Compilers can emit runtime function calls, so libgcc, compiler-rt, startup objects, and the linked image must also be checked. Using bare-metal compiler flags alone is not grounds to claim zero third-party code.
- Platform firmware
- For DDR initialization and BL31, source, availability, and licensing are confirmed per actual platform. BL31 can keep providing runtime services at EL3, so it cannot be treated across the board as code that disappears after boot, nor assumed to be closed source.
- Standalone chip firmware
- Firmware on chips such as the EG915U, the Wi-Fi/BT companion for Genio, and the nRF54L15 is listed as an external module dependency. It is not main OS code, but its versions, interfaces, and update methods still need to be recorded.
Technical boundary references: GCC runtime library documentation ↗︎, Trusted Firmware-A design documentation ↗︎.
ENERGY BUDGET
The 72-hour energy budget.
How do you check the 72-hour energy budget?
Assuming a planned 1S 5000 mAh cell at a nominal 3.7 V, nominal energy is about 18.5 Wh. If usable energy is 16.7 Wh, the average power budget for 72 hours is about 232 mW. Cell, conversion efficiency, and cutoff voltage are still to be confirmed.
If "20% working, 2% full load" are non-overlapping shares of time, with the remaining 78% on standby, working and full-load energy fall at about 11.52–20.16 Wh based on current power ranges. The top of that range already exceeds 16.7 Wh, so 72 hours cannot be guaranteed by lowering standby power alone.
Only by first assuming that working and full load consume 16.1 Wh combined, leaving 0.6 Wh for 56.16 hours of standby, do we arrive at a standby ceiling of about 10.7 mW. This calculation does not yet account for repeated cold boots or other losses not included.
Next, we will measure the energy of each state, the energy per cold boot, wake frequency, and the cost of saving data before power-off, and rebuild the full-device energy model. Here, 20% refers to an assumed share of working time, not development progress or a funding ratio.
An in-house OS is the route this project chose; booting in seconds is not unique to an in-house OS. Bootlin's Linux boot-time optimization material ↗︎ already documents related cases. This cannot be taken to mean that any CORE system can already reach the same speed.
SCALE ESTIMATE
Initial size and memory estimates.
Size and memory: what are the current estimates?
The team's initial estimate of total size is 120,000–160,000 lines, with itemized components adding up to about 140,000 lines. This is a planning order of magnitude, not completed code.
| Module | Estimated lines |
|---|---|
| Kernel: boot, MMU, GIC, scheduling, IPC, VFS | 15,000 |
| SoC drivers | 25,000 |
| libc | 12,000 |
| Graphics and UI | 40,000 |
| File system | 7,000 |
| Peripherals, power, and AT proxy | 20,000 |
| Application layer | 15,000 |
| Always-on core firmware | 6,000 |
An image of 5–10 MB and runtime RAM under 64 MB serve as a provisional resource budget. They must be re-estimated as display resolution, double buffering, fonts, drivers, and the application working set take shape.
The 40–70 person-month figure, and 60–140 person-months for a student team, are likewise uncalibrated initial estimates and cannot be derived directly from line counts. Next, we will calibrate them against a work breakdown, available hours, and actual debugging records.
LICENSING
Licensing, and where "rewriting it ourselves" ends.
The line between GPL and "rewriting it ourselves"
U-Boot as a whole is licensed under GPLv2 or later, but individual files may carry different licenses or exceptions and must be checked file by file. Whether citing or adapting code creates a derivative work cannot be judged merely by renaming it, changing the language, or "typing it out ourselves."
GPL source-code obligations relate to distributing covered programs. Reading or privately modifying code does not by itself require publishing the entire OS to the world. Before adopting any reference code, we first record its source, license, and how it is used, then confirm the specific release conditions.
References: U-Boot project licensing ↗︎, GNU GPL FAQ ↗︎.