베어메탈 CrownyOS 오피스 구동 — QEMU virt MVP 계획

개요

순수 한선씨 오피스 서버(현재 호스트 crownyc VM :9090)를 베어메탈 CrownyOS 위에서 구동하기 위한 최소 경로. 울트라 딥리서치(2026-06-21)로 검증된 기술 사실 기반. (딥리서치 검증 투표는 세션한도로 실패했으나 클레임은 QEMU 공식문서·virtio 스펙·smoltcp·FatFs 등 권위출처 기반 = 유효.)

핵심 결론

QEMU virt(aarch64)를 1순위 타겟으로. 실HW(RPi5 GENET ~3,750줄 / Jetson EQOS 멀티클럭)는 virtio 대비 훨씬 복잡 → 나중.

QEMU virt MVP 최소작업 체크리스트

virtio-mmio 디스커버리

- QEMU virt: virtio-mmio 트랜스포트 32개 제공. DTB가 부팅 시 x0 레지스터로 전달(RAM 시작 0x4000_0000). - 각 MMIO 디바이스 영역 0x200 바이트. 매직 레지스터 0x74726976('virt') 확인 → Device ID로 타입(net=1, blk=2) 판별. - FDT(디바이스트리) 파싱으로 base addr/IRQ 획득(하드코딩 대신).

virtqueue 셋업

- 3개 메모리 영역: Descriptor Table(드라이버 작성, 16바이트/엔트리 addr·len·flags·next), Available Ring(드라이버), Used Ring(디바이스). - 모던(v1.0): QUEUE_DESC/AVAIL/USED_LOW/HIGH 64비트 주소 프로그램 → QUEUE_READY. - 핸드셰이크: DEVICE/DRIVER_FEATURES 협상 → status DRIVER_OK → QUEUE_NOTIFY로 kick → INTERRUPT_STATUS/ACK.

virtio-net (TX/RX 큐) — 패킷 송수신. kick = virtqueue_kick.
TCP/IP 최소 스택: smoltcp(no_std, heap 불필요, ARP+IPv4+TCP+UDP+ICMP, listening 소켓 지원) 이식 권장. 직접구현(ARP+IPv4+TCP 상태머신)은 단일연결 HTTP엔 가능하나 smoltcp가 검증됨.
virtio-blk 저장 (3-디스크립터 체인: 헤더 type/sector + 데이터버퍼 + status바이트) + FatFs(disk_status/initialize/read/write/ioctl 5함수 + get_fattime만 이식하면 됨) → 문서 JSON 영속화.
앱 적재: 커널이 raw .toau를 메모리 적재 → VM execute. 시스템콜(소켓/파일 = 한선씨 TCP대기/읽기 등)을 커널 HAL로 디스패치.

난이도/리스크

단계	난이도	리스크
virtio-mmio 디스커버리	낮음	FDT 파싱 정확도
virtqueue	중	메모리배리어/캐시일관성
virtio-net	중	RX 버퍼 재충전
TCP(smoltcp 이식)	중상	no_std 이식, crownyc HAL 바인딩
virtio-blk+FatFs	중	블록 정렬, get_fattime
앱 적재/syscall HAL	중	crownyc TCP/FILE opcode → HAL 라우팅

CrownyOS 현재 상태 (스카우트 기존 확인)

부팅: build-crownyos.sh virt/rpi5/jetson → kernel8.img, QEMU 부팅 OK.
네트워크=NET_BACKEND_LOOPBACK(시뮬), 스토리지=RAMDISK(시뮬), 앱적재=수동 TOAU 프리로드.
기존 자산: apps/크라우니Docs서버.asm(TCP_LISTEN 4100 어셈블리 예제).
메모리 아레나 CROWNY_MEM_MAX=2MB(빌드플래그) → 7MB 오피스 toau엔 확대 필요.

✅ 구현 진행 (실측, 2026-06-21)

virtio-net 드라이버 완성 — QEMU virt에서 TX/RX 실증.

hal/hal_network.h에 NET_BACKEND_VIRTIO 백엔드 추가(crownyc_os.c는 PLATFORM_VIRT일 때 loopback 대신 virtio 선택).
핵심 발견: QEMU virtio-mmio는 기본 force-legacy=true → version 1(레거시) 제시. 모던(v2 QueueDesc) 아닌 레거시(GuestPageSize+QueueAlign+QueuePFN) 방식으로 구현해야 함.
구현: 32슬롯 스캔(magic 0x74726976+DeviceID=1) → reset/ACK/DRIVER → 기능협상(VNET_F_MAC) → GuestPageSize=4096 → virtqueue RX/TX(VQ_SIZE=8, desc+avail | page정렬 used, PFN=region/4096) → RX 사전게시 → DRIVER_OK. 송신=net hdr 10B+프레임, 수신=used링 회수+hdr제외 복사+버퍼 재게시. MAC은 config 32비트 워드읽기(MMIO 바이트접근 회피). DMA 영역은 식별맵(virt==phys) 정적 페이지정렬 버퍼.
검증(부팅 로그): virtio-net slot=31 ver=1 MAC=82:84:0:18:52:86 / virtqueue RX/TX 셋업 완료(legacy) / ARP 송신=42 bytes / RX=64 bytes ethertype=8/6 → ARP 응답 수신! — 커널이 ARP 요청 송신→QEMU slirp 게이트웨이(10.0.2.2) ARP 응답 수신. TX+RX 패킷레벨 동작 확정.
자가테스트 vnet_selftest()(crownyc_os.c, PLATFORM_VIRT) 부팅마다 ARP 왕복 검증. 실행: qemu-system-aarch64 -M virt -cpu cortex-a72 -m 256M -nographic -kernel sdcard-virt/kernel8.img -netdev user,id=n0 -device virtio-net-device,netdev=n0.

✅ TCP/IP 스택 완성 — 호스트 curl로 端到端 HTTP 검증 (2026-06-21)

베어메탈 CrownyOS가 실제 HTTP 요청을 받아 응답. hal/net_stack.h 신규(최소 TCP/IP). virtio-net 위 ARP+IPv4+TCP.

구현: ARP(우리 IP 10.0.2.15 요청에 응답) + IPv4(헤더+인터넷 체크섬) + TCP 단일연결 상태머신(LISTEN→SYN수신→SYN-ACK→ACK→ESTAB→데이터수신→응답+FIN). 인터넷 체크섬 _ns_sum/_ns_fin(의사헤더 포함 TCP 체크섬). crownyc_os.c에 net_stack_init/run HTTP 서버 자가테스트(:80 고정응답).
★결정적 버그(tcpdump로 포착)★: SYN-ACK의 출발/도착 포트 뒤바뀜 → slirp가 RST. _ns_tcp_send에서 tcp[0:2]=출발=우리 리슨포트, tcp[2:4]=도착=피어포트로 수정(처음엔 반대로 넣어 RST 받음). 체크섬은 처음부터 correct였음(tcpdump 확인).
검증: qemu ... -netdev user,hostfwd=tcp::5584-:80 -device virtio-net-device. 호스트 curl http://localhost:5584/ → HTTP/1.1 200 OK ... CrownyOS bare-metal TCP/IP works! (virtio-net + ARP/IPv4/TCP) 수신. 커널 로그 [TCP] 요청 77B 수신 → 응답 송신. SYN→SYN-ACK→ACK→PSH(HTTP GET 77B)→200응답→FIN 전 과정 동작.
진단법: QEMU -object filter-dump,id=f0,netdev=n0,file=/tmp/qemu.pcap + tcpdump -r 로 패킷 직접 확인(포트스왑/RST 발견의 결정적 도구).
net_stack.h _ns_dbg(초기 12프레임 [RX] 출력)는 진단용 — 정리 가능.

🏆 한선씨 코드가 베어메탈 CrownyOS VM에서 HTTP 서빙 — 완전한 수직 스택 (2026-06-21)

한선씨 소스 → hanseonc_high → TOAU → CrownyOS VM(베어메탈) → TCP opcode → net_stack → virtio-net → 호스트 curl HTTP 200. 전 계층 순수 크라우니, 端到端 검증.

VM opcode 결선: crownyc/crownyc_vm_core.c의 TCP opcode 491~495(TCP대기/수락/읽기/쓰기/닫기)에 #if defined(PLATFORM_VIRT) 분기 추가 → hal_net(L2 raw) 대신 net_stack 소켓 API(ns_listen/ns_vm_accept/ns_vm_read/ns_write/ns_close) 호출. (그 외 플랫폼은 기존 hal_net 유지.)
net_stack 소켓 API: _ns_tcp 데이터 수신 시 자동응답 대신 요청 버퍼링(_ns_req/_ns_req_ready/_ns_rpos). ns_listen/ns_vm_accept(요청 도착까지 폴)/ns_vm_read(읽기 커서)/ns_write(PSH+ACK, 1400B 분할)/ns_close(FIN).
한선씨 서버: apps/한선HTTP서버.한선(import 없는 최소 — TCP대기(80)+동안(참){TCP수락/TCP읽기/TCP쓰기/TCP닫기}). hanseonc_high→16,268B TOAU(581 cubes).
boot toau 주입법: hanseonc_high 서버.한선 > /tmp/boot.toau 후 부팅시스템.한선을 잠시 비키면 build_boot_toau가 /tmp/boot.toau를 boot_toau.h로 변환(부팅시 execute()가 실행). C HTTP 자가테스트는 비활성(포트80 양보).
검증: qemu ... -netdev user,hostfwd=tcp::5586-:80 -device virtio-net-device + 호스트 curl localhost:5586 → HTTP/1.1 200 OK ... 한선씨 코드가 베어메탈 CrownyOS VM 위에서 응답합니다!. 커널 로드: 581 cubes + [RX] n=131(HTTP GET).
결론: docs.crowny.org 오피스 서버를 베어메탈 OS에서 구동할 통합 경로 완전 입증. 남은 건 스케일(9MB toau 적재+MEM_MAX 2M→48M, 다중연결 테이블) — 새 능력 아닌 엔지니어링 확장.

🎯 크라우니 Docs 라이브 — 베어메탈 CrownyOS에서 브라우저 접속 (2026-06-21)

docs.crowny.org 7앱 워크스페이스 홈이 베어메탈 CrownyOS VM 위에서 실행, 호스트 브라우저로 접속 확인.

apps/크라우니Docs서버.한선(import없는 인메모리 — 실제 7앱 카드 홈HTML + /health). hanseonc_high→184KB TOAU(6,575 cubes), 2MB MEM_MAX 안에 적재.
라우팅: 포함(요청,"/health") → JSON, 그외 → 홈HTML(7앱 카드+골드테마+"베어메탈 CrownyOS VM 위에서 실행 중" 배지).
검증: curl http://localhost:8090/ → 2,311B 홈HTML(앱카드 7개: 아웃라인/워드/프리젠/시트/마인드맵/플랜/포커스). /health → {"engine":"crowny-docs","host":"bare-metal CrownyOS","apps":7}. 캡처: CrownyDoc/베어메탈-크라우니Docs-실행화면.html.
라이브 실행: CrownyOS/베어메탈Docs실행.sh [포트] — 컴파일+주입빌드+QEMU(hostfwd)+브라우저오픈. http://localhost:8090/ 접속.
남은 스케일링(풀 9MB 오피스서버.한선 = 동적 앱데이터): MEM_MAX 2M→48M + 파일 I/O opcode를 RAMDISK/스토리지 HAL에 결선(현재 인메모리 홈은 파일불요) + 다중연결. 워크스페이스 프론트엔드는 이미 베어메탈 라이브.

다음 세션 작업 순서 (권고)

crownyc_os.c에 virtio-mmio 디스커버리 + FDT 파서 추가(QEMU virt).
virtio-net 단일 RX/TX → ping(ARP+ICMP) 먼저 확인.
smoltcp 또는 최소 TCP → HTTP 핸드셰이크 → /health 응답.
virtio-blk+FatFs → 문서 저장/로드.
오피스 toau 적재 + MEM_MAX 확대(48M) → QEMU virt에서 office.crowny.org MVP.