QNX RTOS: 9-1. Images & Buildfiles

 

Boot Sequence, Buildfile(Formatted buildfile), mkifs로 이미지 만들기

1) QNX Boot Sequence 큰 흐름

부팅은 “CPU가 실행된 다음 무엇이 이어지느냐”가 보드/플랫폼에 따라 달라지는 구조다.

1.1 초기 부트 단계(보드 의존)

• 가상환경(VMware/VirtualBox/QEMU)
  • BIOS(또는 확장), 가상 BIOS 등
• x86 계열 실제 보드
  • UEFI 등 가능
• 다수 임베디드 보드
  • ROM monitor(U-Boot 등) 또는
  • Flash 내 IPL(Initial Program Loader) 코드

1.2 IPL → Startup → procnto → Boot Script

일반적인 QNX 흐름은 다음과 같다.

1. IPL
   • BSP에 포함되는 경우가 많음
   • RAM 초기화, chip select 설정 등 “최소 HW 세팅”
   • 다음 단계인 startup code로 점프
2. Startup code
   • 추가 HW 설정 및 HW discovery
   • procnto 실행을 위한 환경 구성
3. procnto
   • Process Manager + Neutrino Microkernel 결합체
   • 여기서 boot script 실행 주체(프로세스 매니저)가 준비됨
4. Boot script 실행
   • 드라이버, 서버/클라이언트, 서비스 등을 기동
   • 스크립트 실행이 끝나면 “부팅 완료”

---

2) Secure Boot / Chain of Trust 개념(요지)

Secure Boot은 “소프트웨어 기능”이라기보다 하드웨어 기반 신뢰체인(Chain of Trust) 구축을 의미한다.

• 하드웨어(EEPROM 등)에 해시값을 안전하게 저장
• 부팅 시 각 단계(ROM monitor, IPL, 이미지 등)를 해시 검증
• 검증 통과한 다음 단계만 실행

추가로, 부팅 후 Flash FS에서 실행하는 바이너리까지 신뢰체인을 연장하려면:

• Flash driver 기동 후
• QNX Trusted Disk(QTD) 레이어를 붙여
• Flash 상 바이너리도 “변조 여부 검증” 가능

---

3) QNX Image(IFS)란 무엇인가?

3.1 Image = 파일(부팅 가능한 “OS 이미지 파일”)

• 실행파일(executables)과 데이터 파일을 포함
• 부팅 가능한 이미지라면 앞부분에 bootstrap 정보가 포함됨
• 이후 부분은 “부팅 직후 바로 필요한 파일들”을 담는 파일 시스템 영역

3.2 부팅 후 어디서 보이나? /proc/boot

이미지에 포함된 내용은 기본적으로 부팅 후:

• /proc/boot에 나타남
• 특징:
  • 메모리 상(in-memory)
  • read-only
  • 이미지에 넣은 파일이 그대로 보임

---

4) IFS 이미지는 어떻게 만드나? mkifs

4.1 핵심 도구: mkifs

• mkifs = Make Image File System
• 입력: buildfile(텍스트)
• 출력: OS image file(IFS)

4.2 빌드 흐름

1. 개발자가 buildfile(텍스트) 작성
2. mkifs buildfile 실행
3. buildfile에 적힌 파일들을 찾아서 IFS 생성
4. 생성한 IFS를 타깃 보드에 올림(Flash/SD/네트워크 등은 “보드 의존”)

---

5) buildfile 구성 요소(부팅 가능한 이미지 기준)

 

 

부팅 가능한 IFS를 만들려면 buildfile에 최소한 다음이 포함된다.

• Bootstrap loader section
  • startup code(보드별, BSP 제공)
  • procnto(일반/INSTR/Safety 버전 선택)
• Boot script
  • procnto 준비 후 실행할 “부팅 스크립트”
• 필수 런타임 라이브러리(대표)
  • libc.so (기본 C 라이브러리, open/read/write/printf 등)
  • libgcc_s.so
  • ldqnx-64.so (런타임 로더/링커)
  • libsecpol.so (보안 정책/secure name 등록 등에서 흔히 필요)
• 기타 드라이버/서버/실행파일/데이터(원하는 만큼)

설계 선택지:
“이미지에 다 넣기” vs “최소 부팅만 하고 나머지는 Flash FS에서 로드”
(boot script에서 flash driver를 먼저 올리면 이후 구성 요소를 Flash에서 가져올 수 있음)

---

6) buildfile 문법 요약

buildfile의 한 줄은 기본적으로 다음 형태를 가진다.

• attribute filename contents

단, 각 요소는 optional이어서 다양한 형태가 가능:

• filename만
• filename=contents
• attribute filename
• attribute만(이후 항목에 계속 적용)
• 단, contents만 단독은 불가(파일명 없이 내용만 둘 수 없음)

기타:

• 빈 줄 허용
• 주석은 #로 시작

---

7) Attribute 종류와 적용 범위

7.1 Boolean attribute

• + 또는 -로 on/off
• 예:
  • +script
  • +optional / -optional

7.2 Value attribute

• key=value 형태
• 예:
  • uid=0

7.3 적용 범위

• 한 줄에 붙이면 해당 파일에만 적용
• attribute만 단독 라인으로 쓰면
  이후 항목에 계속 적용(다시 바꿀 때까지)

---

8) 이미지 내부 경로 지정: /proc/boot 밖에 배치하기

기본적으로는 /proc/boot에 들어가지만, 원하는 경로로 “보이게” 할 수 있다.

예:

• /etc=hosts
  → 부팅 후 /etc/hosts로 보이게 배치

또한 파일을 “inline”으로 넣는 것도 가능:

• buildfile 안에 readme=... 형태로 내용을 직접 작성

---

9) Boot Script 정리 (중요 포인트만)

9.1 +script로 지정된 파일이 boot script

• procnto/프로세스 매니저가 부팅 시 해석/실행
• buildfile에 여러 개 +script가 있으면:
  • mkifs가 등장 순서대로 concatenate하여 하나의 큰 스크립트로 만든 후 실행

9.2 Boot Script 언어는 “매우 단순”

• if/loop/변수/테스트 같은 전통 쉘 기능이 거의 없음
• 복잡한 로직이 필요하면 보통 2가지 방식:
  1. boot script에서 ksh 스크립트 실행
  2. 부팅 시 실행할 launcher 프로그램(C/C++) 작성 후, 그 프로그램이 posix_spawn()으로 필요한 서비스들을 기동

9.3 내장(builtin) 커맨드

부트 스크립트에서 다음 명령들은 “외부 실행파일”이 아니라 프로세스 매니저 내장 기능이다.

• display_msg
• procmgr_symlink
• reopen
• waitfor

mkifs도 이것들을 알고 있어서, 해당 이름의 실행파일을 파일시스템에서 찾지 않는다.

9.4 예제에서 나온 기능 의미

• procmgr_symlink: 심볼릭 링크 생성(예: /usr/lib에서 찾는 파일을 /proc/boot로 연결)
• display_msg: startup이 제공하는 debug device로 문자열 출력(부팅 로그 용도)
• waitfor /dev/ser1: 특정 path가 namespace에 등록될 때까지 대기(드라이버 초기화 완료 동기화)
• reopen /dev/con1: 표준입출력(fd 0,1,2)을 특정 디바이스로 재지정(이후 실행되는 shell/프로그램 출력 위치 고정)
• pri=27,fifo / session: 실행 우선순위/스케줄링 정책/세션 리더 지정

---

10) mkifs가 파일을 찾는 기본 검색 경로

buildfile에서 devc-ser8250처럼 “파일명만” 적으면 mkifs는 다음 순서로 탐색한다.

1. ${QNX_TARGET}/${PROCESSOR}/bin
2. ${QNX_TARGET}/${PROCESSOR}/usr/bin
3. ${QNX_TARGET}/${PROCESSOR}/sbin
   (강의에서는 이런 식의 기본 리스트를 제시)

여기서:

• PROCESSOR는 buildfile의 virtual attribute에서 설정되는 값(예: virtual=x86_64)
• QNX_TARGET는 개발 환경에서 설정되는 환경변수(IDE 또는 qnxsdp 환경 설정 스크립트 통해 설정)

10.1 검색 경로 오버라이드 방법

• 환경변수 MKIFS_PATH 설정
  • Linux/Ubuntu: : 구분자
  • Windows: ; 구분자
• 또는 buildfile에서 search attribute를 사용해 특정 항목만 별도 경로 지정 가능
  • 예: 기본 경로에서 못 찾으면 /project/bin도 추가로 뒤져라

---

결론

QNX는 IPL/Startup/procnto/boot script로 이어지는 부팅 체인을 가지며, 이들 구성 요소와 부팅 직후 필요한 바이너리/데이터를 하나의 IFS 이미지로 묶는다. 이 IFS는 buildfile 로 정의하고, mkifs가 이를 해석하여 생성하며, 결과물은 부팅 후 기본적으로 /proc/boot에 노출된다.