모놀리식 커널, 계층별 격리
드라이버를 커널에 포함하며, MMU, EL0 / EL1, 프로세스 격리, 스케줄링, IPC, VFS를 다룹니다. 1차 버전은 디버깅과 재현 가능성을 우선합니다.
BUILT FROM BARE METAL
WAYFINDER OS
WAYFINDER CORE / MAX를 위한 자체 개발 운영체제입니다. 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
1차 버전은 GPU, NPU, 완전한 ISP 카메라 파이프라인을 필수 기능으로 두지 않습니다.
기본 화면과 조작부터 완성합니다. 원시 sensor 데이터 수집, 2D 가속, 고급 영상 기능은 하드웨어 문서와 드라이버 비용을 따로 확인해야 합니다. 칩의 이론상 TOPS는 현재 OS 성능에 대한 약속이 아닙니다.
M0 → M4
첫 출력 한 줄에서, 완전한 조작까지.
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는 공유를 계획할 수 있지만, 하위 드라이버를 그대로 공유할 수 있다고 가정하지 않습니다.
드라이버 구현 전에 규칙을 확립한다
직접 작성 원칙과 서드파티 참고 코드의 한 줄씩 이식은 같은 것이 아닙니다. 라이선스, 파생 관계, 배포 방식을 먼저 검토해야 합니다. 오픈 소스 공개나 다른 배포 방식은 아직 팀에서 결정하지 않았습니다.
ENGINEERING DETAIL
방법을 확인하고 싶다면, 한 단계 더 깊이.
자체 개발은 어디까지인지, 플랫폼 펌웨어와 라이선스의 경계는 어떻게 긋는지, 72시간 에너지 예산은 어떻게 계산하는지, 12–16만 줄 규모 추정은 어디서 나왔는지. 이 내용은 모두 엔지니어링 상세 페이지에 정리했으며, 이 페이지에서는 더 다루지 않습니다.
이 페이지는 팀의 최신 OS 아키텍처 설명을 바탕으로 정리했습니다. 설계 선택, 리소스 예산, 실측 결과를 구분해 표시하며, 현재 모든 기능과 수치는 구현 또는 검증 예정입니다.