크라우니독 기술백서 프로젝트문서 오피스 계획판 셀그래프
← 목록
기타 2026-06-13 12KB 읽기 13분

크라우니OS 커널 VM 배열 패리티 + 젯슨 토르 레퍼런스 OS 선언/HAL 리서치

개요

젯슨 토르(Jetson Thor) = 크라우니 레퍼런스 OS 선언(2026-06-13 사용자 확정). 완전 크라우니기계어(TOAU) 극초경량 OS → 크라우니VM 구동 → 맥 동시실행 VM → 그 위 앱. 첫 앱: 한 모니터 27방향성 화면 선택 = 개인 병렬작업 극한.

이번 작업 = 커널 VM(crownyc_vm_core.c)이 네이티브(crownyc.c)와 배열 시맨틱 100% 동일하게 동작하도록 패리티 달성 + 젯슨 토르 베어메탈 HAL 사실 딥리서치.

무엇을 했는지

1. 커널 VM 배열 패리티 (완료·검증 8/8) ✅

같은 .toau 바이트코드를 네이티브/커널이 동일 출력해야 OS 앱이 커널 위에서 정상 동작한다. 커널 VM의 405~411이 구형 모델(mem_count++ 1칸, LEN=비-0 카운트, INDEX 무경계)이라 발산했음. 네이티브의 1024슬롯 블록 모델(슬롯[1023]=길이)로 이식:
  • case 405 ARRAY: 1024슬롯 블록 할당, 슬롯[1023]=길이0, heap_ptr 경계검사
  • case 406 LEN: 슬롯[1023] 읽기 (구형 비-0 카운트 폐기)
  • case 407 INDEX: 슬롯[1023] 기준 경계검사 (OOB→0, 베어메탈이라 stderr/exit 없음)
  • case 408 APPEND: 슬롯[1023] 길이 갱신 + 주소 push (구형은 push 누락)
  • case 409 SORT / 410 REVERSE: 주소만 pop(구형은 주소+길이 2개 pop → 스택 오정렬), 길이=슬롯[1023], cube_cmp 사용
결정적 발견 — MEM_MAX: 컴파일러(hanseonc_high)가 배열 리터럴 [a,b,c] 요소를 임시영역 array_temp_base=11999700(~12M)에 STORE 후 APPEND한다. 커널 VM MEM_MAX가 2M이라 12M 주소가 경계초과로 silent fail → 리터럴 배열 전부 0. 네이티브는 MEM_DEFAULT=48000000(48M, calloc 지연커밋). 커널 MEM_MAX를 48M로 맞춰 해결. program[]은 바이트코드 전용이라 별도 PROG_MAX=2097152(54MB)로 분리(48M면 불필요하게 +1.3GB).

검증: apps/배열테스트.한선 8케이스(리터럴/인덱싱/음수식/중첩/프레임생존/추가·길이/설정/정렬/루프합산) → 네이티브와 완전일치(40/-35/3/8/2/99/1/30).

2. 젯슨 토르 베어메탈 HAL 딥리서치 (18+ 출처 교차검증)

  • SoC: Tegra264(T264) [확정], Neoverse V3AE 14코어 ~2.6GHz, Blackwell GPU(2560 CUDA, ~2070 TFLOPS FP4), 128GB LPDDR5X 273GB/s.
  • DRAM 베이스: 0x80000000 [추정·높은신뢰] (Tegra 전세대 패턴; BSP DTS 검증 필요).
  • UART: Orin의 SPE 소프트 TCU가 아님 → 하드웨어 UTC(UART Trace Controller) [확정]. 드라이버 nvidia,tegra264-utc. 주소 serial@810c530000(~0x810_C530_000, 40-bit) [미확인·단편1건]. ⚠️ Orin의 0x03100000 재사용 불가.
  • GIC: GICv3+GICv4 [확정]. GICC 없음(시스템레지스터 ICC__EL1). GICD/GICR 주소 미확인.
  • 부트: UEFI 전용(cboot 제거) [확정]. 체인 MB1→MB2→ATF/BL31→OP-TEE→UEFI(BL33)→커널. Hafnium SPM 신규(Orin 대비 SMC/EL3 다름). L4T r38/JetPack 7.0, 커널 6.8. 커스텀 커널=extlinux.conf의 FDT 태그.
  • 자료: Thor SoC TRM 공개(NVIDIA 계정, NDA 불요): developer.nvidia.com/.../thor-soc-trm_dp-11881-002.pdf. BSP DTS tegra264*.dtsi(L4T r38).
  • 결론: 기존 hal_orinnx.h(Tegra234)는 토르에 부적합. 주변장치 버스가 40-bit 고주소로 이전. 확정 주소 입수 선결조건 = TRM 또는 BSP DTS.

관련 파일

  • /Users/ef/CrownyOS/crownyc/crownyc_vm_core.c — 커널 VM (405~411 + MEM_MAX 48M + PROG_MAX 분리)
  • /Users/ef/CrownyOS/crownyc/crownyc.c — 네이티브(레퍼런스, 미변경): MEM_DEFAULT 48M, array_temp_base 12M
  • /Users/ef/CrownyOS/crownyc/apps/배열테스트.한선 — 8케이스 패리티 회귀
  • /Users/ef/CrownyOS/crownyc/vm_core_host_test.c — 호스트 테스트 래퍼

잔여 이슈 (다음 과제)

  1. 커널 VM 문자열 서브시스템 패리티 (기존 갭, 이번 발견): 출력값→PRINT(324)가 숫자 전용 — 네이티브 324의 문자열 핸들 역참조 분기 없음 → 문자열 리터럴이 핸들번호로 출력("안녕"→20000). 연결("가"+"나")은 핸들 40003 = 풀(20000+256) 밖 할당 → str_valid 불가. 풀도 4096B/256개로 네이티브보다 훨씬 작음. → PRINT 문자열 deref + 연결 할당기 정합 + 풀 사이징 + 345(문자열출력) 핸들러 점검 필요.
  2. 베어메탈 MMU 맵 확장: memory[] 48M×27B≈1.3GB > 현재 항등맵 1GB. 토르(128GB) 부팅 시 맵 확장.
  3. hal_thor.h 신규: TRM/BSP DTS 입수 후 UTC UART·GICv3·DRAM 주소 확정 → Tegra264 HAL 작성(현 hal_orinnx.h 대체).
  4. 근본 개선(장기): 컴파일러 array_temp_base=12M이 MEM_MAX 48M를 강제 — 임시영역 압축 시 양쪽 VM 메모리 축소 가능(단 .toau ABI 변경, 전 서비스 재컴파일 위험).

진행 2 — 문자열·나눗셈 패리티 + 베어메탈 아레나 (완료·검증)

문자열 출력 패리티 (7/7) ✅

커널 VM의 4개 결함 수정(네이티브 동일):
  • PRINT(324): 숫자전용 → va>=STR_HANDLE_BASE && str_valid면 fwrite(str_ptr) 문자열 출력 분기 추가
  • ADD(81): 순수 cube_add → 한쪽이라도 문자열 핸들이면 연결(숫자는 십진 변환). "가"+"나"가 핸들 정수합(40003)으로 깨지던 근인
  • TOSTR(488): 타입만 태깅 → 실제 십진 문자열 str_new 생성("x="+문자열변환(5) 동작)
  • STR_HANDLE_BASE 20000 → 1000000000: 핵심. 20000은 실제 정수(가격·주소)와 충돌해 ADD/PRINT의 str_valid가 오작동. 네이티브가 10억으로 옮긴 이유. 문자열변환(20000)→20000 검증.
  • 풀 사이징: 4096B/256개/1024 → 1MB/16K/4096(경량 유지, 실앱 충분)
검증: apps/문자열테스트.한선 7케이스 완전일치.

나눗셈 자연반올림 패리티 (9/9) ✅

네이티브는 cube_divmod(균형3진 자연반올림 |r|≤|b|/2), 커널은 C va/vb·va%vb였음. nat_div/nat_mod 정수 등가 구현(13%5=-2, 7/2=3 r=1 — 절반은 0방향). tests/나눗셈회귀.한선 9케이스+종합 T 일치.

베어메탈 아레나 제약 해소 ✅

48M memory[](1.3GB)가 256M 베어메탈 RAM 영역 초과로 virt 빌드 회귀 발생(직전 턴 부작용). MEM_MAX를 #ifndef CROWNY_MEM_MAX 오버라이드화: 호스트/Thor=48M(배열 리터럴 12M 임시영역 수용), 베어메탈은 build-crownyos.sh가 -DCROWNY_MEM_MAX=2097152(2M)로 축소 → virt 빌드 GREEN(kernel8.img 106KB). 문자열·나눗셈은 아레나 무관하게 동작, 배열 리터럴만 대용량 RAM 전용.

진행 3 — 맵(해시) 문자열 키 패리티 (완료·검증) ✅

커널 HASH(412/413/414)가 slot=키핸들&0xFF 스텁이라 문자열 키가 깨졌음(str_new 인터닝 없음 → 같은 리터럴이 매번 다른 핸들 → 슬롯 불일치 → 맵꺼내 0). 네이티브 모델로 이식:
  • trit_hash_cube/trit_hash_str 헬퍼 추가(24트릿/바이트열 → 6트릿 → 0~728)
  • HASH_NEW=1458슬롯(729엔트리×2) heap_ptr 하향, HASH_SET/GET=3진해시+729 선형프로빙+키 내용비교(memcmp). 문자열은 내용 해싱(인터닝 불요), 정수는 cube 해싱
검증: apps/맵테스트.한선 — 문자열키(서울/한국)·문자열키+숫자값(183)·정수키(4200) 전부 일치. virt 베어메탈 GREEN 유지.

진행 4 — 600번대 ISA 정렬 + UTF-8 + 파일 I/O (완료·검증) ✅

광범위 스윕(예외/문자열함수/재귀/수학)이 3개 발산을 드러냄 → 추적 결과 커널 600번대 opcode가 컴파일러 ISA와 어긋남:
  • 601/602 오배치: 커널이 FILE_WRITE/FILE_EXISTS로 처리(컴파일러는 601=반올림, 602=내림) → 반올림·내림 깨짐. 진짜 파일은 620/621.
  • 603~609 통째 스텁: 올림·루트·절댓값·사인·코사인·탄젠트·로그 전부 no-op → 절댓값(-7)이 -7 반환.
  • 620/621/622 (쓰기/파일존재/덧쓰기)도 스텁 → 파일 쓰기 자체가 깨져 있었음.
  • 읽기(249): 파일 핸들만 처리, 경로 문자열(읽기(경로)) 미지원.
  • UTF-8: 글자수(339)=바이트수, 부분(344)=바이트 슬라이싱+(시작,길이) 오해 → 한글 깨짐.
수정(네이티브 정렬): 601 ROUND/602 FLOOR/603 CEIL/604 SQRT(정수반올림,libm불요)/605 ABS 정수구현 + 606~609(SIN/COS/TAN/LOG) 호스트전용(베어메탈 libm부재→0스텁, math.h는 host wrapper). 620/621/622 파일 복원, 249 경로문자열 분기. utf8_charcount/char_offset/char_len 추가 → 글자수/글자/부분 문자인덱스화. 검증: apps/수학UTF8파일테스트.한선 7케이스 + 스윕 일치, virt 베어메탈 GREEN(110KB).

진행 5 — 3값논리·트릿연산·형변환·삼진·버퍼 (완료·검증) ✅

2차 스윕이 6개 발산 발견 → 수정:
  • Kleene 3값 AND(167)/OR(172): (va>0&&vb>0)?T:A 비-Kleene → trit_clamp MIN/MAX(모름 전파). 모름 그리고 참=모름(0).
  • 균형3진 트릿 연산: 비트곱90/비트합91/비트배타92가 이진 &|^였음 → trit-wise MIN/MAX/곱. 왼94/오른95시프트 <<>> → ×3ⁿ/÷3ⁿ. (trit_clamp/trit_and/or/xor/shift_up/down 헬퍼 이식)
  • 숫자변환(TOINT 486): 타입태깅만 → strtol 실파싱(이전엔 숫자변환("123")+7이 문자열연결 "1237"이 됐음).
  • 삼진인코딩712/디코딩713: stub → [값,배열]/[배열] 실구현(네이티브 동일).
  • 버퍼390/391/392: 387~404 통째 스텁이었음(컴파일러는 390~392=버퍼) → 정적 풀 이식(BUF_SLOTS64×65536, 핸들 30000+슬롯, 베어메탈 freestanding malloc 부재 대응). 버퍼생성/쓰기[버퍼,문자열,오프셋]/읽기[버퍼,오프셋,길이] 동작.
검증: apps/{논리트릿,버퍼}테스트.한선 + 2차 스윕 완전일치, virt 베어메탈 GREEN.

진행 6 — 3차 스윕: 문자열검색·셀·트릿부정·한글변환 (완료·검증) ✅

3차 스윕(셀/비트부정/포함/정렬/피보/반복문/최대최소) → 4개 수정:
  • ★str_new 널종료 누락(근본버그): 풀 문자열이 널종료 안 돼 strstr이 인접 문자열로 오버런 → 포함 미발견 시 -1 아닌 strlen 반환("AB","Z")→2. str_pool[ptr+len]='\0'; ptr+=len+1(네이티브 동일). 모든 C-문자열 처리에 영향.
  • STR_FIND(342): 바이트 오프셋 → UTF-8 글자 인덱스(포함("안녕하세요","하")=2).
  • 비트부정(93): 이진 ~ → 트릿 부정(trit_not, T↔A). 비트부정(5)=-5.
  • 글자변환(724): 스텁 → HANGUL_UTF8(코드포인트→UTF-8). 글자변환(45397)="녕".
검증: apps/문자열셀비트테스트.한선 + 3차 스윕 일치, virt GREEN(114KB).

커널 VM 패리티 — 검증 테스트 (7종, 전부 네이티브 일치)

배열8 · 문자열7 · 나눗셈9 · 맵4 · 수학UTF8파일7 · 논리트릿10 · 버퍼3 · 문자열셀비트6 (apps/.한선 + tests/나눗셈회귀.한선) — 데이터타입/산술/3값논리/트릿연산/UTF-8문자열/파일·버퍼 I/O/맵 전부 커버.

진행 7 — hal_thor.h 골격 (작성·컴파일검증) ✅

젯슨 토르 HAL 골격 hal/hal_thor.h — 딥리서치 확정사실을 코드로 고정, 미확인 주소는 [미확인]+Orin폴백+TODO:
  • 확정: Tegra264/Neoverse V3AE 14코어/UTC UART(nvidia,tegra264-utc)/GICv3(GICC 없음)/DRAM 0x80000000/UEFI+Hafnium/L4T r38.
  • 미확인: UART ~0x810C530000(40bit), GICD/GICR(Orin 0x0F400000/0F440000 폴백). UTC는 16550 아닌 트레이스컨트롤러 → putc/getc 잠정 16550 폴백(⚠실기 부팅은 TRM 확정 후).
  • 배선: crownyc_os.c PLATFORM_THOR 분기 + build-crownyos.sh thor 타깃(linker/boot=jetson 재사용, load 0x80080000). ./build-crownyos.sh thor → kernel8.img 102KB 빌드.
  • ★실기 미부팅(골격) — UTC/GIC 실주소는 TRM(thor-soc-trm_dp-11881-002.pdf)/BSP DTS(tegra264.dtsi) 입수 후 확정.

잔여 이슈 (갱신)

  • hal_thor.h 실주소 확정: TRM/DTS 입수 → UTC 송수신 레지스터(16550 폴백 교체)·GICD/GICR·DRAM·UEFI 로드주소. start_thor.S/linker-thor.ld 전용화.
  • 베어메탈 배열 리터럴 + 대형 배열: 컴파일러 array_temp_base 축소(근본) 또는 Thor 대용량 아레나 + MMU 맵 확장
  • 커널 VM 잔여(미검증): 버퍼확장(393~399), 소켓/TCP/UDP(네트워크 — 단위테스트 어려움)
← 이전크라우니OS 동시모드 UX 패리티 — 세션 종합 (2026-06-13)2026-06-13-크라우니OS-동시모드-UX패리티-종합다음 →2026-06-13 크라우니앱+브라우저 — 라이브 복구 + 헤드리스 검증2026-06-13-크라우니앱-브라우저-라이브복구-검증

관련 문서

Phase 2 연동 스펙 — Tradovate · NinjaTrader · TradingView 챌린지 룰 설계 (온체인 고정) 포네 결제 모듈 스펙 교육 커리큘럼 초안 crowny-sweep — Crowny 데이터 관리 도구2026-04-14
1 / 1