Superstar's New World

플랫폼 빌더 내의 PUBLIC나 PLATFORM쪽의 소스들을 보게 되면 'DEGUBMSG()'라는 녀석을 자주 볼 수 있다. 이녀석은 디버깅 모드로 빌딩을 했을 때 디버깅 메시지를 볼 수 있도록 해주는 녀석이다. 하지만.. 디버깅 모드로 빌드를 하게되면.. 용량도 엄청(?)커지게 되고.. 느리지고.. 뭐 그래서 잘 하지 않을 것이다.

그렇다면.. 릴리즈 모드로 빌드를 해서 디버깅 메시지를 어떻게 확인을 할 수 있을까? -_-
그래서 'RETAILMSG()'라는 녀석이 존재한다.
'RETAILMSG()'라는 녀석은 릴리즈 모드로 빌드를 했을 때 디버깅 모드의 'DEBUGMSG()'와 마찬가지로 디버깅 메시지를 볼 수 있도록 해주는 녀석이다.

RETAILMSG()의 문법은 다음과 같다.

Expression는 0 혹은 0이 아닌 다른 것으로써, 0이 아니면 Message의 내용을 출력하게 된다..
Message는 일반적인 printf와 같은 포맷으로 동작을하고, Message의 내용이 디버깅 메시지로 출력이 된다.

주의할 사항은 RETAILMSG는 2개의 인자(Expression, Message)만을 받기 때문에 두번째 인자를 주의해서 사용해야 한다.
예를 들면 다음과 같다.

위의 예에서 보는 것처럼 Message에 들어갈 내용을 괄호로 묶어 하나의 인수처럼 사용을 해야한다. 괄호로 묶지 않고 일반 C에서 사용하는 printf처럼("xxx %d", value) 사용하면 에러가 발생한다. -_-

X86의 경우 Windows CE 부팅을 하기 위해서 Bios Loader라는 것을 사용을 한다.

BIOS LOADER를 이용해서 부팅을 해보면.. NK.bin의 로딩 중에 아래와 같이 검은 바탕화면에 Windows CE라는 로고가 나오는 것을 확인할 수가 있다.


위  화면에서 WindowsCE라는 로고는 splash.bmx라는 파일 형식으로 되어 있고, BIOS LOADER동작시 .bmx파일을 읽어와서 화면에 뿌려주는 것이다.

C:\WINCE600\PLATFORM\CEPC\SRC\BOOTLOADER\BIOSLOADER\DISKIMAGES\BOOTDISK가 바로 splash.bmx라는 파일이 있는 위치이다.
다른 로고를 위해서는 splash.bmx 파일을 삭제하고, 변경하려는 로고를 splash.bmx라는 이름으로 첨부하면 된다. .bmp파일을 이용하여도 되지만... 용량의 압박이... ㅡㅡ;

.bmx라는 파일은 Platform Builder에서 제송하는 bincompress.exe라는 프로그램을 사용하면 된다.
bincompress.exe의 위치는 C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386이고, 사용법은 다음과 같다.

bincompress [옵션(/C, /D)] 원본파일 적용할 파일
/C : 원본파일(.bmp)를 적용할 파일(.bmx)로 압축한다.
/D : 원본파일(.bmx)를 적용할 파일(.bmp)로 압축을 해제한다.
ex)
C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386>bincompress /D
C:\WINCE600\PLATFORM\CEPC\SRC\BOOTLOADER\BIOSLOADER\DISKIMAGES\
BOOTDISK\splash.bmx todayis.bmp
Decompressing:100%
Input file size :4582 bytes
Output file size : 10678 bytes

C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386>

위의 예를 따라하게 되면 다음처럼 .bmx를 .bmp로 변경한 파일을 확인할 수 있다.

반대로 BIOS LOADER의 부팅시 화면을 바꾸려면, "/C"옵션을 사용해 원하는 .bmp이미지를 .bmx로 바꾸어주면 된다.

Windows CE에서 화면을 회전(Screen Rotation)하는 방법에 대한 문서이다.

갑자기 해야할 일이 생겨서 여기 저기 문서를 뒤지다가.. MSDN에 있는 문서를 참고해서 대충 돌아가는 것만 확인했다.

하나의 응용프로그램을 만들어 실행(더블클릭) 시 90도씩 시계 반대방향으로 화면이 회전하는 것이다. 일반적으로 PDA같은 곳에 있는 기능이라고 하여 시도를 해본 것이다.
참고로 현재는 멀티 스크린은 적용되지 않고, 또 screen rotation 프로그램을 실행시키게 되면 커서나 마우스의 동작이 자동으로 바뀐 스크린에 맞게 동작을 하게 된다.
그리고, screen rotation은 display driver가 screen rotation을 지원할 경우에만 가능하다. 더 자세한 사항은 'Screen Rotation'를 참조하면 될 듯 하다.

참고한 'MSDN( How to Implement Screen Rotation)' 링크이다.

다음은 Screen Rotation APP를 만드는 절차이다.

Step	Topic
1. Create an OS design. Make the following choices in the Windows Embedded CE 6.0 OS Design Wizard: Name the OS design ScreenRotation. From the Available BSPs list, choose CEPC: x86. From the Available design templates list in the New Platform Wizard, choose the PDA Device design template. In the Variants step, choose Mobile Handheld.	Creating an OS Design
2. Make the registry changes.	Screen Rotation Registry Settings
3. Create a project for the screen rotation application.	Creating a Project for the Screen Rotation Application
4. Specify whether you are building a release or debug configuration of the OS design. Choose the release build.	Levels of Debugging Support
5. Build the run-time image. The following list shows the choices to make: From the Build menu, select Global Build Settings. Ensure that the following are selected: Copy Files to Release Directory After Build Make Run-Time Image After Build From the Build menu, choose Build Solution.	Building a Run-Time Image
6. Download the run-time image.	Downloading a Run-Time Image to a CEPC
7. Run the application and verify the screen rotation. To execute the sample application on the CEPC, right-click the Start button and choose Run. Type ScreenRotationProj and choose OK. Verify that the screen has rotated by 90 degrees. Each time you run the ScreenRotationProj program, the screen will rotate by 90 degrees.	Not applicable.

부트로더는 데스크톱의 BIOS와 비슷한 역할을 한다. 처음 전원을 이가하거나 하드웨어적으로 리셋을 시키면 부트로더는 시스템을 시작하기 위해 필요한 최소한의 하드웨어를 초기화 한다. 그리고난 후 메모리에 담겨져 있는 커널 이미지와 루트파일 시스템을 찾아서 RAM으로 복사를 하고 커널이미지를 위치로 옮겨 부팅을 하게 한다.

Windows CE에서의 부트로더도 다르지 않다.
부트로더(Bootloader)는 호스트에서 타겟(혹은 타겟 내의 저장공간)에서 메모리로 OS Image를 읽어들이는 역할을 한다.
간단히 말하자면, 호스트(개발 PC)에서 타겟장치(개발하는 보드)로 부팅시키고자 하는 이미지를 올리는 작업을 하는 녀석이다. 추가로 부트로더는 타겟 플랫폼의 디바이스를 초기화한다.

일반적으로 부트로더의 역할은 다음 세가지로 요약할 수 있다.
1. 타겟 플랫폼 디바이스를 초기화한다.

CPU를 사용가능한 환경으로 초기화 한다. CPU내의 MMU(Memory Management Unit)와 캐시 등을 활성화 하고, 리얼타임 클럭, 다운로드 경로로 사용될 하드웨어를 초기화 한다.

2. 부팅 과정을 통제(부팅과정 중 옵션을 사용)한다.

다운로드 경로(USB, 패러럴, 이더넷 등)을 선택
호스트에서 RAM으로 직접 다운로드
다운로드 하기 전에 사용될 메모리 진단
다운로드될 장소를 결정

3. Windows CE 이미지를 다운로드 하고 실행시킨다.

패러럴 포트, USB, 이더넷과 같은 비교적 전송속도가 빠른 경로를 사용해서 호스트에서 타겟 플랫폼으로 OS Image를 다운로드 시킨다.

'Windows CE'는 처음부터 Portable기기에 적합하도록 설계되었고, 'Object Store'의 수용공간으로  RAM을 이용하게 되었다.
Object Store란 OS가 사용하는 기본 저장장소로 File, DataBase, Registry가 담기는 저장소이며, Windows CE의 모든 File System의 Root Directory("/")로 사용된다. 쉽게 말해 일반 PC의 HDD정도로 생각하면 된다.

RAM을 기반으로 Object Store가 구현된 Windows CE기기들은 RAM의 특정상 전원공급이 중단되면, 저장되었던 모든 File과 Data 및 Registry가 사라지게 된다(휘발성).

이를 보안하고자 나온 대안이 'Hive Registry'이다

Hive 기반의 Registry는 System Registry를 File로 저장하여 사용하도록 설계된 것이다.
Ram 기반의 Registry와는 다르게 OAL에 구현해 주어야 하는 code가 요구되지 않고, Windows CE에서 인식한 어떠한 File System 저장장치에 Registry를 영구적으로 저장할 수 있는 기능을 제공한다.

"Boot.hv", "Default.hv", "User.hv" 등 세가지의 registry file을 사용한다.

Boot.hv
저장장치에 file로 저장 되어있는 "Default.hv"와 "User.hv"를 읽어오기 위해 필요한 Device Driver와 File System을 로드하기 위한 정보가 담겨있다. 또한 "Default.hv"와 "User.hv"의 위치정보도 포함되어 있다.
이 file은 절대 변경되지 않고, 항상 OS image(NK.bin)에 있는 것을 사용한다.

Default.hv
OS에 관련된 대부분의 System registry 정보를 담고 있다.
OS image에 포함되어 있는 registry에서 변경된 부분만 저장장치에 저장한다.
크게 아래 세 가지 root registry key안에 모든 registry 정보를 포함한다.

• HKEY_LOCAL_MACHINE
• HKEY_CLASS_ROOT
• HKEY_USER
  

User.hv
사용자별 registry 정보를 포함한다.
HKEY_CURRENT_USER root key안의 각각의 사용자별 경로를 저장한다.

Hive 기반의 registry 환경에서의 System 초기화 과정은 아래와 같다.

• NK.exe(Kernel)이 Filesys.exe를 실행.
• Filesys.exe가 Boot.hv를 OS Image로부터 로드.
• Filesys.exe가 Device.exe(Device Driver Manager)를 실행.
• Device.exe는 Boot.hv의 registry설정에 따라 Driver들을 로드.
• Block Device driver와 관련 File system로드.
• Filesys.exe는 System.hv를 로드.
• Filesys.exe는 대기상태이고, System.hv의 registry설정에 따라 Kernel 재 초기화.
• Kernel이 Filesys.exe에 신호발생하여 Filesys.exe가 Device.exe를 실행.
• Device.exe에 "BootPhase2" event를 보내 driver들을 로드, re-enunerate.
  

'Hive based registry'관련 자료를 찾으려 웹 여기저기를 돌아다니다 발견한 사이트에서 일단 퍼왔다.
Microsoft에서 주관하는 Windows CE관련 'e-seminar'이라고 하는데 꽤 오래전(2년이 넘었으니...)자료인 듯 하나.. 어차피 개념을 알고자 하는 것이므로.. 일단 스크랩!!

e-seminar 주소는 '여기'를 클릭하시라!! ㅋ

이 세미나에서 담고 있는 내용은 다음과 같다.

• Windows CE의 Object Store
• 비 휘발성 저장 Solution의 장점
• File System
• Hive란?
• 비 휘발성 Object Store 구현

여튼 무슨 일이든.. 날고 뛰는 사람들이 너무 많은 것 같다..
아... 언제쯤.. ㅜ

Windows CE 이미지 생성을 위한 절차이다.
이를 위해선 BSP와 Common요소를 먼저 이해해야 한다. BSP와 Common에 대한 설명은 '여기'를 참고하면 될 듯 하다.

Window CE 이미지를 생성을 하기 위해선 다음의 4단계를 거치게 된다.
  1. System 생성 과정
  2. Build Platform 과정
  3. Build Release 과정
  4. Make Image 과정

1. System 생성 과정에서는 Platform Builder가 Windows CE를 위해 제공하는 기본적인 구성요소들, $(_PUBLICROOT)에있는 자료를 개발자가 생성한 $(_PROJECTOAKROOT)\Files 와 $(_COMMONOAKROOT), $(_COMMONDDKROOT), $(_COMMONSDKROOT)로 복사하는 작업을 한다.

참고로 $(_COMMON~)\Target 폴더는 소스의 컴파일과정을 거쳐서 빌드된 모듈 중 DLL, EXE, OCX와 같이 실행가능한 모듈들이 복사되는 위치를 말하고, 이를 통해 System 생성과정 중에서도 컴파일 과정이 발생할 수 있다. $(_PROJECTOAKROOT)\Files 폴더는 컴파일 과정없이, 미리 준비된 모듈들이 복사되는 위치를 의미한다.

2. Build Platform 과정에서는 개발자가 생성하려는 플랫폼의 참조코드인 BSP와 개발자가 새롭추가한 Features를 실제로 빌드하는 과정이다.
이때 사용되는 BSP 코드는 빌드환경에서 설정한 SYSGEN_XXX와 같은 환경변수에 의해 선택적으로 빌드된다.

3. Build Release 과정에서는 위의 과정에서 생성된 파일들이 플랫폼의 릴리즈 폴더로 복사된다.
릴리즈폴더는 $(FLATRELEASEDIR)을 말한다. 이 단계를 거치게 되면, Windows CE용 이미지를 위한 모든 파일들이 릴리즈폴더에 존재하게 된다.

4. Make Image 과정은 3단계의 릴리즈폴더에 무수히 많은 파일들을 타겟시스템으로 다운하기 위한 바이너리 파일로 압축을 하는 작업을 한다.

BSP는 CE에서 제공하는 몇가지의 타겟시스템(CEPC, GEODE, ARM, XSCALE)의 종속적인 코드들을 담아놓은 환경을 말한다.
쉽게 말해 $(_PLATFORMROOT) 하위의 폴더에 있는 폴더들(CEPC, GEODE, EMULATOR, SMDK2410)등을 말한다. 이는 모두 해당하는 타겟시스템을 위한 종속적인 코드들이다.

그러나, 단지 이 BSP만을 가지고는 Windows CE이미지를 만들 수 없다. BSP라는 것은 타겟시스템에 종속적인 코드만 들어있을 뿐, 그 이외의 운영체제를 위한 프로그램들(익스플로러, 노트패드 등)은 들어있지 않기 때문이다.

이렇듯 타겟시스템에 종속적인 코드를 제외한 나머지 코드들을 Platform Builder에서는 Common요소로 간주하여 $(_PUBLICROOT)에서 관리하게 된다. Common요소는 어떤 BSP를 사용하더라도 호환성을 가질 수 있는 코드들이다.

이처럼 하나의 타겟시스템에서 동작하는 Windows CE 이미지를 제작하기 위해서는 적당한 타겟 BSP와 Common요소가 필요하다.

Windows Embedded CE의 update사이트를 소개하려 한다.

기본적으로 Platform Build를 설치하고 나서 꼭 해주어야 하는 작업이기에...
CE로 이미지를 제작하다 보면 여러 에러를 볼 수 가 있는데.. 여기 저기 서칭하다보면 자주 듣게되는 말이 QFE를 설치하라는 말이 있다.
이 QFE를 통해서 Windows CE관련 업데이트를 하게 되는 것이다.

Windows Embedded CE Update Site


오늘 날짜로 들어가 보니 Windows Embedded CE 6.0의 경우는 2007년 9월까지 릴리즈된 update 현황을 볼 수 있었다.
왜 더는 없는 거지?? 이녀석들도 상당히 게으른 건가?? ㅡㅡ;

참고 : 자신의 Platform Builder에서 현재 QFE 업데이트 상황이 어떻게 되는지 확인을 하고 싶다면..
         '여기'를 통해 알 수 있다.

platform builder에서 'Platform\XXX\Files'에 있는 파일들.. 즉 *.reg, *.bib.. 등의 파일을 수정한 후 다시 전체 빌드를 해야할지를 가지고 고민을 하는 경우가 있다.

일반적으로 '디바이스 드라이버'라든지 개발자가 직접만든 '프로젝트 프로그램'의 경우는 수정을 가한 해당 파일만 '빌드'해주고, Copy Files to Release Directory, Make run-time Image를 해주면, NK바이너리에 추가가 된다.

하지만, 이것들은 'Platform\XXX\Src'에 있는 녀석들의 경우이다.

'Platform\XXX\Files'의 경우는 두가지 경우로 나눌 수 있다.

첫 번째, release디렉토리의 *.reg, *.bib등의 파일을 수정하는 경우이다.
*.reg나 *.bib를 수정해야 할 경우이고, 어차피 NK를 만들기 위함이면, release디렉토리의 이 녀석들만 수정하면 된다. 그리고 make image를 하면 수정한 녀석들이 적용된 NK 바이너리를 사용할 수 있다.

두 번째, Files디렉토리의 *.reg, *.bib등의 파일을 수정하는 경우이다.
이경우는 수정한 파일을 release디렉토리로 복사해 make image해주어도 되고(첫 번째와 동일한 작업이 될 수 있음), Sysgen 후에 make image를 해주어도 된다.

문제는 얼마나 많은 시간이 걸리느냐 이지만, 첫번째의 경우 1분정도(?), 두 번째(sysgen)의 경우 10분 이상이 걸린다는 것이다.

release 디렉토리의 것들을 수정할 경우, sysgen을 해주게 되면, 수정했던 것들이 Files의 것들로 바뀌게 된다.
Sysgen 시에, Files의 파일들을 Release 디렉토리로 복사하는 과정이 있기 때문이다.
이점만 주의하면, 자주 *.bib, *.reg등의 파일을 수정하는 작업의 경우, 유용하게 사용할 수 있을 것이다.