WinCE 5.0에관한 전반적인 내용

출처 : http://blog.naver.com/nedsys/110001742492

Windows CE의 구조

Kernel

Windows CE의 kernel은 “NK.EXE” (New Kernel)라는 컴포넌트가 된다.

Kernel의 주요 역할은 Memory관리, 스케줄링, Win32 API지원을 수행하며 Micro-kernel 구조를 통해
PSL(Protected Server Library)를 구현 한다. 마이크로소프트는 개발자가 커널의 포팅을 최소화 하기 위해,
주요 커널의 기능을 별도의 라이브러리 파일에 담아 준비 하였으며, 하드웨어 또는 CPU에 관련된 포팅만을
개발자에게 부담하도록 하였다.
주요 커널의 기능을 갖춘 라이브러리는 “NK.lib”가 되며 하드웨어 또는 CPU에 관련된 라이브러리는 “OAL.lib”가 된다.
OAL(OEM Adaptation Layer)는 다양한 하드웨어에 Windows CE Kernel이 운영될 수 있도록 하드웨어와 커널의 중간에 위치한
layer로써, 반드시 OEM(개발자)이 하드웨어에 맞게 포팅해 주어야 하는 layer이다.
인터럽트, 디버깅, Clock & Timer, Power Management의 초기화 및 제어의 역할을 수행하게 된다.
최종적으로 마이크로소프트가 제공한 “NK.lib”와 개발자가 포팅한 “OAL.lib”가 링크되어 “NK.EXE”가 생성된다.

“NK.LIB” + OAL.LIB = NK.EXE

다음은 Windows CE 5.0에 새롭게 달라진 커널의 기능이다.

.Shared Heap Memory
- 개발자가 원하는 heap memory function을 사용할 수 있다. 이를 통해서 OS가 인식하지 않는
또는 개발자가 원하는 별도의 RAM에 memory heap을 구성할 수 있다.

.Watchdog timer
- Application의 holding 상태를 감지하여 해당 Application을 다시 reboot하는 기능이다.

.64 system interrupts

- 기존 32개만 사용할 수 있었던 Interrupt가 64개로 늘어났다.

.Power down thread

- 이전 버전에서는 Poser Handler와 관련한 function에 어떠한 API도 사용할 수 없었는데,
 WinCE 5.0에서는 이 부분에 대한 API를 사용할 수 있게 됨으로써 PM(Power Management)쪽 디버깅 및 일부 API 사용이
 가능하게 되었다.

.Embedded database (EDB)

- SQL Server CE 3.0을 지원한다 (이전 SQL Server CE2.0)
.ATAPI enhancements
- 보다 향상된 기능의 ATAPI Driver를 지원한다.

File System Manager
Windows CE의 File system Manager의 역할은 굉장히 중요하다.
“FILESYS.EXE”라는 component가 된다. Windows CE system의 ROM, RAM File system과 외부 저장장치의
File system관리를 하며, System registry 및 Data Base의 관리도 담당을 한다.

 

.Object Store

- Object Store는 일반 Desktop Windows OS의 HDD와 같은 역할로서 System Registry, Data Base,
 RAM File System으로 구성이 된다. 특정 file을 비 휘발성 외부저장장치에 저장하지 않은 경우
 file은 Object Store에 저장이 되며, Object Store는 RAM에 위치하므로 System의 전원이 꺼지거나,
 cold booting시에 file이 지워지게 된다. Root폴더로 사용되고, Windows CE의 Root폴더는 Desktop Windows OS와는 달리
“\”로 표현 된다. (Desktop Windows OS는 “C:\”, “D:\”로 표현된다.)

.Registry

- 일반 Desktop Windows OS와 같은 형식의 registry를 사용한다.
Registry는 System과 Application의 주요 setting 정보를 담고 있다.

.ROM File System
- Windows CE OS binary image인 “NK.bin”에 포함되어있는 Windows CE를 구성하는 component들을 File로 다루기 위한
File System이다. Windows CE상에서 탐색기를 열었을 때 “Windows” 폴더에 들어있는
여러 component file들이 ROM-File system을 통해 사용된다. (Booting 환경에 따라 달라질 수 있다)

.Storage Manger
- 외부저장장치에 대한 File system manager 이다.
Windows CE는 다양한 외부저장장치에 대해서,
여러 개의 partition과 다양한 File system (FAT12, FAT16, FAT32, BinFS)을 사용할 수 있다.
저장장치를 “Block Device”라고 부른다.

DEVICE & GWES

Windows CE의 Device Driver들은 Native Driver와 Stream interface Driver 형태로 나뉘어 사용된다.

.Native Driver

- Built-in Device Driver들이 해당되며, OS를 운영하기 위해선 반드시 필요한 Device Driver들로 구성된다.
 Native driver들은 “GWES.EXE” (Graphic Windowing Event Subsystem)가 load 및 관리를 한다.
종류로는 Display, Key board, Mouse, Touch driver들이 해당된다.

.Stream Interface Device Driver
- Windows CE에서 device를 access하는데 가장 이상적인 Driver Model이다.
 Application을 위한 Device Driver들로 구성되며,
application에서는 해당 driver들을 File API를 통해서 하나의 file처럼 다루어 사용된다.
모든 device에 공통적인 interface를 사용하여 제작되고, “DEVICE.EXE”라는 device driver manager가 load 및 관리한다.
종류로는 Serial, Block Device Driver(외부저장장치), Audio, Custom driver들이 해당된다.

- Windows CE 5.0은 PQD(Production quality drivers)라 불리는 양산수준의 품질을 보장하는
Device Driver를 포함하고 있다. 그 외, USB 2.0 host and function, SDIO host, PC card를 지원한다.

Windows CE Boot Flow

-Windows CE 디바이스에 전원이 공급되어 CPU가 동작을 시작하면 Windows CE Kernel (NK.exe)이 가장 먼저 실행된다.

-         Kernel은 OAL의 여러 함수들을 호출하여, System의 초기화 작업을 수행하게 된다.

-         기본적인 system의 초기화가 완료되면 Kernel은 File system Manager인 Filesys.exe를 호출하여 실행한다.

-         File system Manger는 Object store를 DRAM에 구현하게 되며, 가장 중요한 System Registry를 설치하게 된다.

-         Kernel은 Registry에 등록되어 있는 “LaunchXX” setting값에 의하여 다음에 실행할 component를 호출하여
          load하게 됩니다.

-         이들 호출의 순서는 default로 “Device Manger”(Device.exe) -> “GWES Manager”(GWES.exe) ->
          “UI Shell” (Explorer.exe) 등의 순서를 갖는다.

-         이때 Device Manger는 Registry를 통해 load할 driver들을 확인한 후 정의된 순서에 의해서
          Device Driver들을 load 한다. 물론 GWES Manager 또한 자신이 load해야 할 Device Driver들을 로드한다.

-         Explore.exe가 Windows CE의 기본 UI Shell이 되며 이 UI Shell을 통해서 사용자는
           응용 프로그램을 실행할 수가 있다.

-         OEM(개발자)은 System Registry의 수정으로 위의 boot flow를 변경할 수 있다.

Micro-Kernel Architecture (Protected Server Library)

. Windows CE는 Micro-Kernel Architecture를 가진다.

Kernel을 지원하는 여러 시스템 라이브러리를 사용하여 Kernel의 부하를 최소한을 줄이고 인터넷 및 멀티미디어와 같은
다양한 서비스를 제공한다.

. 앞의 그림은 Micro-Kernel 구조의 system의 특정작업을 수행하는 과정을 보여준다.
Application에서 File을 접근하는 API(CreateFIle)을 호출 했을 때 Kernel을 통하여,
File을 access하는 File system manager와 Block Device를 관리하는 Device Manger까지의 이동경로를 보여 준다.

. Kernel을 지원하여 여러 가지 service를 제공하는 File system manager, Device Manger, GWES Manager등을 PSL이라고
부른다.

Windows CE의 다양한 Booting 환경

XIP 환경

Embedded System은 XIP(eXecute In Place)가 되어야 하는 기본조건이 있다.
 XIP는 CPU가 OS를 Flash(NOR)나 ROM으로부터 직접 읽어와 실행하는 것을 의미한다.
위의 화면은 XIP의 구조를 보여준다. 이 경우 사용해야 하는 Windows CE OS Binary Image는 “NK.nb0” 이다.

이 환경의 장점과 단점은 다음과 같다.
1. 장점
- 압축되지 않는 OS 이미지를 Flash에서 직접 실행할 수 있다.

- 많은 양의 DRAM을 요구하지 않는다.

- Booting시간이 빠른다.

- SDRAM에 비해서 저전력

2. 단점

- OS Performance가 느리다.

- OS update를 할 수 없다.

Load from NAND or NOR into RAM

위의 화면은 Boot Loader를 사용하여 OS Image를 RAM으로 복사하여 사용하는 구조이다.
 Flash나 ROM에는 OS Image를 booting하기 위한 Boot Loader가 필요하며,
 이때 사용하는 Windows CE OS Binary Image는 “NK.bin” 이다.

이 환경의 장점과 단점은 아래와 같다.

1. 장점

- DRAM에서 OS가 운영되므로 Performance가 빠른다

- OS Image의 update를 할 수가 있다.

- OS Binary Image size가 XIP환경보다 적다.

2. 단점

- OS Image를 DRAM에 모두 copy

- XIP 환경에 비하여 많은 DRAM의 공간을 요구한다.

- Booting time이 길어진다.

- XIP환경 (Flash, ROM) 환경에 비하여 고 전력이다.

Multiple XIP

Multiple XIP환경은 OS Image의 update를 효과적으로 하기 위한 환경이다.
Windows CE OS Binary Image인 “NK.bin”을 다수의 Binary Image file로 분리하여 구성한다.
이 환경의 Boot Loader는 여러 개의 OS Binary Image를 모두 DRAM에 copy해야 한다.

이 환경의 장점과 단점은 아래와 같다.
1. 장점

- DRAM에서 OS가 운영되므로 Performance가 빠르다.

- OS Image의 부분적인 update를 할 수가 있다.

2. 단점

- OS Image를 DRAM에 모두 copy

- XIP 환경에 비하여 많은 DRAM의 공간을 요구한다.

- Booting time이 길어진다.

- XIP환경 (Flash, ROM) 환경에 비하여 고 전력이다.

Binary File System (BINFS)

BINFS환경은 Multiple XIP환경의 단점을 보완한 환경이다.
 Multiple XIP환경과 같이 다수개의 OS Binary Image로 구성되지만,
 Boot Loader는 모든 Binary Image를 DRAM에 copy하지 않고, BINFS와 Demand Paging이 가능한 Kernel 영역의
Binary (Bin Region 1)만 DRAM에 copy한다. 이후 Kernel은 필요한 컴포넌트를 BIN File System을 통하여 Flash로부터
읽어와 OS를 부팅한다. Binary File System이란, Platform Builder가 생성한 Windows CE OS Binary Image인 “NK.bin”
안에 구성된 여러 component들을 파일 단위로 access할 수 있는 File system 이다.

이 환경의 장점과 단점은 아래와 같다.

1. 장점
- 요구된 component(Demand Paging)만 RAM에 load하므로 RAM을 효율적으로 사용할 수 있다.

- 일반 NAND Booting 환경에 비하여 Booting time이 빠른다.

2. 단점

- OS Image Update를 위한 padding이 필요하다.

NK.bin vs NK.nb0

앞에서 Windows CE의 다양한 Booting 환경을 확인해 보았다.
 Boot Loader를 필요로 하는 환경과 그렇지 않은 환경을 비교 했을 때,
사용하는 Windows CE OS Binary Image가 다르다. 위의 그림은 두 가지 형태의 Windows CE OS Binary Image인
“NK.bin”과 “NK.nb0”의 차이점을 보여준다.

“NK.bin”은 OS Image의 여러 정보를 포함하고, OS를 구성하는 component들을 Record별로 나누어 구성된 Binary Image 이다.
그러므로 CPU가 실행 할 수 있는 유효 code들을 분리해 주는 Boot Loader가 필요하다.
반면 “NK.nb0”의 경우 CPU가 실행할 수 있는 유효 code들 만으로 구성된 Binary Image이기 때문에
대부분 Boot Loader가 필요하지 않은 XIP 환경에서 사용된다.

Platform Builder

OS Build System

1.       SYSGEN: OS design으로 선택된 모듈과 컴포넌트들을 여과해주는(filtering) 단계임

2.       Build: OS Design과 BSP의 소스코드들을 컴파일 하는 단계임

3.       Build Release (BUILDREL):

Release Directory(%_FLATRELEASEDIR%) 안으로 파일들을 복사해오는 단계이다

4.       Make Image: 최종적인 OS Run-Time Image(NK.BIN)을 생성해 내는 단계이다.

Configuration Files

- BIB files, REG files, DAT files, DB files

1) BIB files (Binary Image Builder Files)

. OS Image안에 포함되는 module & components를 가리키는 파일이다

. BIB files은 총 4가지 section으로 구성된다.

Files Section: 정적인 데이터 파일 (폰트파일, txt파일, bmp파일, wave파일)이 메모리 영역 안에 저장되도록 예약되는 section 이다.

Ex) Tahoma.ttf $(_FLATRELEASEDIR)\Tahoma.ttf NK SHU

위 내용은 $(_FLATRELEASEDIR) 안에 있는 Tahoma.ttf 라는 파일을 OS Image안에 포함시키되,
 S, H, U라는 속성을 갖고 Tahoma.ttf 라는 이름으로 등록된다는 예제이다.

S: system속성

H: Hidden 속성

U: Uncompress 속성

MODULES Section: EXE, DLL 같이 메모리에 로드 되는 object module들을 정의하는 section 이다.

Ø       MEMORY Section: Platform 메모리 정보를 정의하는 section 이다. (CONFIG.BIB 파일 안에 있는 section 이다)

<TYPE>

- RAM: 실행중인 프로세스를 위한 그리고 RAM 베이스 파일시스템을 위한 메모리 영역이다.
이 영역들은 연속적이어야 하며 이 영역의 중간에 메모리를 예약하지 말아야 한다.

- RAMIMAGE: ROM과 같이 다루어질 메모리 영역으로, 한번만 선언되어야 한다.

- RESERVED: RAM 영역을 예약하며, 이 영역이 다른 영역과 겹쳐서는 안 된다. (비디오 프레임 버퍼 등을 예약한다)

 CONFIG Section: 이 섹션은 강제적이지 않으며, 압축 혹은 ROM Size와 같은 속성들을 설정하기 위해 사용되는 Section 이다
(CONFIG.BIB 파일 안에 있는 Section 이다)

2) REG files (레지스트리 파일)
- Windows CE MODULES와 관련된 Registry가 정의되어 있다
- Device driver entries와 같은 Platform 의존적인 Registry가 정의되어 있다.

3) DAT files (파일시스템 파일)
- WinCE의 폴더구조를 정의 할 수 있다.
- EX) Directory (“\DEMO”):-Directory

위와 같이 DAT files을 정의해 놓으면, 내 컴퓨터(윈도우 탐색기)안에 DEMO라는 폴더가 생성된다. (OS가 부팅된 후 확인 가능)

4) DB files

- Define default image database

DIRS & SOURCES FILES

1. DIRS FILES
- 빌드 되어야 하는 소스코드를 포함한 서브 디렉토리의 리스트를 포함한 텍스트 파일이다.

2. SOURCES Files

. Source 파일의 정의를 통해 DLL, LIB, EXE 등의 모듈로 소스코드가 컴파일 된다.

. 루트 안에 반드시 makefile이 있어야 한다.

Ex)

 

. loport.cpp & vagport.cpp 코드를 사용하고 Coredll.lib 파일과 링크가 되서 Kdbmouse.dll 파일로 컴파일(생성)된다는 의미이다.

- Sources 파일에서 사용되는 Macro들

. TARGETNAME: 타겟 이름(생성될 모듈의 이름: 확장자는 없음)을 정의한다.

. TARGETTYPE: 확장자와 파일의 type을 정의한다.

             PROGRAM ? (.EXE) Application

             DYNLINE ? (.DLL) Dynamic Link Library

             LIBRARY ? (.LIB) Static Library

. TAGETLIBS: 링크되어야 하는 libraries들을 정의한다.

. INCLUDES: 포함되어야 하는 .H 파일에 대한 경로를 추가한다.

. SOURCES: 컴파일에 필요한 소스코드를 정의한다.

Catalog, CEC Files and CEC Editor

1. Catalog

. Windows CE Catalog는 런타임 이미지 안에 포함되어야 하는 모듈과 컴포넌트들의 리스트를 제공하는 database 이다.

. Catalog View를 통해 계층화된 트리 형태의 Catalog 항목들을 볼 수 있다.

. End User나 Third party에 의해 이 구조는 확장될 수 있다. (Catalog를 추가 및 삭제가 가능)

2. CEC File

. CE component file을 말하며, Catalog database안으로 Import하여 사용하는 간단한 텍스트 기반의 파일이다.

. CEC File의 구조

. CECInto Block: CEC 파일에 대한 일반적인 정보를 포함한다.

ComponentType Block: Catalog 항목의 그룹 혹은 생성된 Catalog 항목을 포함한다.

 

MaxResolvedimpsAllowed: (Optional) OS Design에 존재해야 하는 같은 형태의 구현에 대한 최대 수를 설정하는 Element이다.
일반적으로 1을 사용한다. RequiredCEModues: (Optional)OS Design에 더불어 추가되어야 하는 모듈을 설정하는 element 이다.
5.0에서는 이 설정을 무시해도 된다.

Implementation Block: Component의 구현을 정의한다.

Variable: (Optional) Catalog Item과 함께 사용되어야 하는 특별한 환경변수이다.

Ex. Variable ( , )

 .BuildMethod Block : Component 빌드에 필요한 정보를 제공하는 블록이다.

 

* Step: Build Step을 말한다.

- BSP: Feature Build Step

- BUILDREL: Release Copy Step

- MAGEIMG: Make Image Step

- CESYSGEN: Cesysten Step

* Action: 빌드 단계에서 Platform Builder에 의해 특별한 활동을 수행한다.

(즉, SOURCES 혹은 DIRS 파일에서 정의한 형태로 동작을 수행한다)

- #SRCCODE: 소스코드의 위치를 IDE상에서 보여주는 element 이다.

(IDE상에서 해당 소스코드를 편집 할 수도 있음)

3. CEC Editor

. CECEditor.exe 파일을 통해 CEC 파일의 작성 및 수정이 가능하다

. Platform Builder의 메뉴 / Tools / CEC Editor를 수행하면 된다.
 

4. CEC File의 추가 및 제거
. Platform Builder Tool의 File Menu에 보면 Manage Catalog Items를 통해 CEC 파일을 새롭게 등록한다거나  기존의 CEC 파일을 제거 할 수 있다.