윈도 CE를 개발한다는 의미는 ‘윈도우CE 운영체제를 자기가 만든 보드에 정상적으로 동작하도록 하는 작업’ 혹은 ‘윈도우CE를 탑재한 장치에 애플리케이션을 만드는 작업’이라 정의할 수 있다.
사실 이 말들은 아직까지 어렵다. 포팅, BSP(Board Support Package)와 같은 용어에 먼저 익숙해져야 한다. 윈도우CE를 시작하면서 가장 어려웠던 부분 중에 하나가 전체적인 작업 방법이 머리에서 안 그려졌다는 것이다. 매일 매일 기술적인 내용에 대해 조사해 보지 않으면 따라가기가 쉽지 않다.
지금은 개발 과정을 처음에서부터 끝까지 몇 번 해 봤기 때문에 흔히 말하듯 ‘감’이 잡힌다.
하지만 운영체제라는 소프트웨어는 그 내용이 방대하기 때문에 아직도 모르는 부분이 있다.
본 내용은 윈도우CE를 처음 접하는 초보자가 어떻게 BSP를 포팅 하는가에 대한 설명이다. 물론 초보자가 윈도우CE를 개발한 보드에 포팅 한다는 것은 매우 어려운 일이지만, 이 글에서는 ‘감’을 잡으려면 어떻게 해야 하는지 정도만 가이드를 제공한다.
자, 이제 윈도우CE를 운영체제로 사용하기로 결정했다고 가정하자. 그럼 하드웨어 팀은 하드웨어 설계에 들어갈 것이며, 여러분은 윈도우CE 개발 엔지니어로써 어떻게 해야 할까? 필자는 다음과 같은 12단계의 절차를 제시한다. 물론 주관적인 단계이며, 몇 가지는 굳이 포함 안 시켜도 된다.
<윈도우CE 운영체제 포팅 절차>
지금부터는 각 단계에 대해 구체적으로 살펴보도록 한다.
개발보드 구입 및 테스트
윈도우CE를 이용한 개발의 첫 단계는 사용하려고 하는 프로세서를 이용한 개발보드를 구입하는 것이다. 프로세서 업체는 대부분 개발 보드를 제공한다. 물론 개발보드가 없어도 윈도우CE를 포팅하는 것은 가능하다. 다만 프로세서에 대해 제대로 모른 체 개발에 들어간다면 시행착오를 겪을 수 있다.
개발보드에 프로세서 업체에서 제공한 BSP를 빌드하여 제대로 동작되는지 확인하는 것부터 시작한다. 빌드 할 때 어떠한 문제, 특히 기능상의 모자라는 부분이 없는지 확인하기 시작한다.
사실 처음에는 BSP를 설치하고, OS가 정상적으로 동작하는지 확인하는데도 많은 시간이 걸린다. 새로운 프로세서를 사용한다는 것이 쉽게 PC에 OS를 설치하듯이 쉬운 일이 아니라서 그런다.
필자가 위에서처럼 단계를 여러 가지로 나누는 이유도 그 만큼 초기 개발하기 위해서는 많은 준비작업이 필요하기 때문이다. 다음 그림들은 프로세서 별 대표적인 개발보드를 보여주고 있다. 개발보드마다 그 기능상의 차이가 있지만 소프트웨어와 하드웨어 개발하기 위한 기초가 되는 장비 중에 하나라고 생각하면 된다.
<그림 1>
<그림2>
개발보드를 가지고 하는 작업 중 대표적인 것은 윈도우CE가 개발보드 상에서 어떻게 동작하는지 확인하는 것과 앞으로 만들 보드에 문제가 생겼을 때 하드웨어적인 차이점을 확인하여 하드웨어적인 문제를 검증하는 것이다. 너무 어렵게 생각하지 말고 ‘개발보드에 제공된 BSP를 올리고 동작하는 것을 본다!’라는 간단한 정의로 첫 단추를 시작해보자.
개발보드에서 제공되는 BSP OS 빌드 및 동작 테스트
개발보드가 동작하는지 눈으로 확인하는 것은 매우 중요하다. 실제로 동작되는 것을 본다는 것은 그만큼 동기 부여가 된다. 이제 개발보드가 제대로 이미 설치된 운영체제 이미지로 동작하는 것을 확인하고 한번 직접 운영체제 이미지를 만들어서 실행해 보자.
BSP를 플랫폼 빌더 내에 설치하고 OS가 제대로 만들어지는지 확인한다. 여기서 중요한 것은 OS 이미지만 빌드 되고 동작되는 것을 확인하는 것이 다가 아니라, EBOOT가 제대로 빌드 되는지, IPL이 제대로 빌드가 되는지, OS 이미지는 제대로 만들어지는지 알아야 한다는 것이다.
물론 개발보드에 올려서 동작되는 것을 확인하는 것도 잊지 말아야 합니다. 동작이 안된다면 의미가 없다. 개발보드와 함께 제공된 매뉴얼을 바탕으로 생성된 이미지를 확인하고, 동작이 제대로 되는지 점검해야 한다. 여기서 중요한 것은 Release 이미지의 생성뿐만 아니라 Debug이미지를 생성해서 동작이 되는지 확인해야 한다. 이 단계에서 해야 할 것들을 다시 한번 정리한다.
-Platform Builder에 BSP를 설치하고 새로운 플랫폼 생성
-Release 모드로 빌드 하고 개발보드에 올려서 동작이 되는지 확인
-Debug 모드로 빌드 하고 동작이 되는지 확인, Break Point를 설정해 보고 제대로 디버깅이 되는지도 확인 .
개발보드 디버깅 테스트
이제 개발보드에서 플랫폼 빌더로 생성된 윈도우CE OS 이미지가 어떻게 동작하는지는 확인 하였을 것이다. BSP를 설치하고, 하나의 플랫폼을 만들어 보고, OS이미지를 만드는 순서를 익히는 것이 개발의 첫 단계이다.
개발보드라고 할지라도 처음부터 쉽게 되지는 않을 것이다. 개발보드와 함께 제공된 매뉴얼을 정독하면서 사용 방법을 충분히 익히기 바란다. 초보단계에서(물론 지금도 그렇지만..)는 매뉴얼을 정독하고 매뉴얼대로 따라 해보는 것을 간과하는 경향이 있다. 영어 울렁증 때문이기도 할 것이다. 하지만 사소한 것이라도 매뉴얼을 읽고 사용방법을 정확히 아는 것이 무엇보다 중요하다.
개발보드를 사용하는 장점은 디버깅을 위한 환경이 모두 갖추어져 있다는 것이다. JTAG 디버거를 위한 JTAG 포트, 디버그용 시리얼포트, LED 및 기타 출력장치를 통해 디버깅을 할 수 있도록 구성되어 있다.
우선 이 단계에서 중요하게 검증해야 할 것들은 KITL을 이용해 디버깅하는 방법을 숙지하는 것이다. Platform 빌더에서 Breakpoint를 설정하고 동작 중 멈추는지? 다음 진행이 되는지 확인해야 한다. 윈도우CE는 OS라는 것을 명심해야 한다. 지금 당장 동작되더라도 언제 어떤 문제가 생길지 모른다. 따라서 그 문제를 해결할 방법을 미리 가지고 있어야 한다.
이 부문에서 KITL을 이용해 디버깅하는 방법을 알아두는 것이 제일 먼저 해야 할 일이다. BSP에 따라서 Ethernet으로 KITL을 사용하는 방법도 있고, USB를 이용해 KITL을 사용하기도 한다. 어떠한 방법을 사용하는지 그 설정방법을 확실히 숙지해 두기 바란다.
JTAG포트를 이용해 디버깅을 하는 ‘JTAG 디버거’는 중요한 장비중의 하나이다. 다음 그림에 잘 나타나 있다.
<그림 3>
<그림 4>
변경 하드웨어에 따른 EBOOT 수정
이제 어느 정도 개발 환경을 준비했다면 본격적인 포팅 작업에 들어가야 할 시간이다. 이제부터는 개발 보드가 아니라 여러분의 회사에서 만든 보드를 가지고 작업을 해야한다.
우선 Eboot를 여러분이 개발한 보드에 맞게 포팅 해야 한다(Eboot에 대한 구체적인 것은 글 최하단에 박스로 설명했다.)
Eboot가 동작하면 하이퍼터미널에<그림 5>와 같은 화면이 나온다. Eboot가 동작할 준비가 되었다는 뜻이다. NAND 플래시를 많이 사용하게 되면서 Eboot의 역할이 많이 축소되기는 했지만 여전히 Eboot는 윈도 CE 포팅에 있어서 중요한 자리를 차지한다. Eboot가 동작해야 OS관련 포팅 작업을 진행 할 수 있기 때문이다.
<그림5>
Eboot가 정상적으로 동작하기 위해서 중요한 플래시와 램에 관한 설정을 먼저 변경해야 한다. 아직 LCD와 같이 동작을 확인 할 수 있는 부분을 실행하기는 어렵기 때문에 동작 정보를 확인하기 위한 시리얼 포트를 개발한 보드에 맞게 수정해야 한다. 이더넷, LCD 등을 확인하고 수정해야 할 내용들이 많지만 우선은 시리얼로 제대로 동작한다는 메시지가 출력하도록 만드는 것이 중요하다. 아래는 이를 정리한 것이다.
-메모리 관련 수정 사항을 확인 하고 수정 : 여기에는 메모리 종류, 크기, 방식에 따라 수정할 사항이 많다.
-프로세서 설정 : 메모리는 어떤 프로세서 핀을 사용하고, 인터럽트는 어떤 포트를 통해 입력을 받을 것인가에 대한 변경 사항 및 설정을 한다.
-전원 관리 설정 : 초기 부팅 시 전원을 인가해 주어야 하는 소자도 있을 것이다. 이러한 부분에 대해 미리 확인하고 설정해야 한다.
-JTAG 디버거를 개발 초기에서부터 사용하면 보다 빠르게 진행할 수 있다.
Eboot 변경 및 동작 테스트
Eboot가 동작하는 것을 확인했다면 절반 이상은 진행한 것이다. Eboot를 동작하면 보다 일이 쉬워진다. Eboot가 동작했다는 것은 개발한 보드가 정상적으로 만들어져 있으며, 이제 윈도우CE 포팅에만 집중하면 된다는 뜻이다. 이제 Eboot에서 해야 할 세부적인 작업을 설명한다.
-이더넷을 통하여 OS가 다운로드 할 수 있도록 이더넷 드라이버를 포팅한다.
-OS 이미지를 이더넷을 통하여 다운로드한 후 플래시 메모리에 저장될 수 있도록 한 루틴이 제대로 동작하는지 확인한다.
-OS 이미지를 플래시 메모리에서 읽어 들여 실행하는 루틴에 대해 살펴본다.
-Eboot 사이즈, OS 이미지 사이즈 관련된 정보를 개발 보드에 맞게 수정한다.
이렇게 보면 Eboot에서 해야 할 일이 대단히 많아 보인다. 하지만 필요한 부분이 뭔지 확인만 한다면 그렇게 어려운 부분이 아니다. 이제 운영체제를 개발할 기본적인 준비가 되었다.
이 상태로 다른 분들에게 수정한 Eboot를 보드에 탑재한 후 전달하게 된다. 운 좋다면 플랫폼 빌더에서 OS 이미지를 만들고 다운로드 해 실행이 될 수도 있다. 하지만 이는 어디까지나 운에 따라서고 실제 가능성은 매우 적다. OS 이미지가 제대로 랜 케이블을 통하여 다운로드 되고 동작하는 시늉만 하면 된다. 그 다음은 좀 더 노력이 필요하다.
개발 하드웨어 테스트
이 단계는 병행하거나 OS가 동작하는 것을 본 후에 진행해도 무관하다. 필자가 보통 하던 순서일 뿐.
Eboot는 적은 크기의 프로그램이며, 따라서 컴파일 및 링크 시간이 매우 짧다. 보통 256KB 정도한다. 따라서 여기에 개발한 보드의 하드웨어가 제대로 동작하는지 검사하는 루틴을 추가한다. 그래서 나중에 디바이스 드라이버 개발자들이 문제가 없게 미리 준비하는 것이다. 디바이스 드라이버를 만들면서 하드웨어를 검증하기는 어려운 일임을 인지해야 한다.
어쨌든 Eboot의 메뉴에 시리얼을 통하여 키 입역을 받을 수 있게 하고 그것에 따라 각각 하드웨어를 테스트 할 수 있도록 한다.
-메모리 테스트
-GPIO 테스트
-프로세서와 연결되어 있는 장치 테스트 - AC'97 Codec과 같은 주변 장치를
-LCD 모듈 동작 테스트
하지만 Eboot에서 하드웨어를 테스트하는 코드를 작성하는 것은 초보에게는 대단히 어려운 일이다. 아마 윈도우CE 개발 기간만큼의 시간이 필요할지도 모fms다. 따라서 처음에는 메모리 테스트만 확실하게 작성해둘 것을 권한다. 정상적으로 메모리가 읽고, 써지고, 지워지는지 확인하는 것은 중요한 일임을 명심하라. 만약에 이것조차 제대로 안 했다가는 나중에 문제가 생길 수 있다.
Debug 환경 설정
플랫폼 빌더는 강력한 소프트웨어 도구이다. 개발부터 디버깅까지 다 할 수 있다. 예전에 디버거만 따로 판 회사의 제품만큼 강력한 기능이 여기에 담겼다.
하지만 단점도 있다. KITL((Kernel Interface Transport Layer))이라는 환경을 필요로 한다는 것이다. 또 KITL은 이더넷, 시리얼, USB와 같은 인터페이스 장치를 필요로 한다. 만약 이런 것이 없다면 플랫폼 빌더를 사용할 수 없다(KITL은 다음 장에 자세히 설명했다). 보통 양산 제품에는 이런 인터페이스 장치들을 장착할 이유가 없기에 대부분 시리얼 포트 정도만 남겨둔다.
그래서 앞서 설명한 JTAG 디버거가 필요한 것이다. Eboot 개발 초기 단계부터 JTAG을 사용했다면 이 단계는 준비가 끝난 것이며, 개발보드를 디버깅할 강력한 무기를 가졌다고 할 수 있다.
JTAG는 복잡한 하드웨어 연결이 필요 없기 때문에 충분히 보드상에 JTAG 포트를 만들어 둘 수 있다. 이 JTAG 포트로 문제가 생기면 디버깅을 하는 것이다. 또 한 가지 숙지해야 하는 것은 JTAG 디버거를 통하여 플래시에 OS나 Eboot 이미지를 기록하는 방법이다. 그래야 디버깅도 할 수 있고, 나중에 OS 업그레이드 문제가 생길 경우 해결할 수 있기 때문이다.
-JTAG 디버거 개발한 보드에 연결하여 동작하는지 테스트
-JTAG 디버거를 이용하여 보드에 장착한 플래시에 프로그램 이미지 기록 테스트
-JTAG 디버거를 이용하여 중단점을 설정하고 디버깅 테스트
-JTAG 디버거의 메모리 덤푸(Dump)기능을 이용하여 RAM이나 레지스터 확인 테스트
KITL 설정
또 하나 중요한 단계는 KITL 설정이다. 아마 Eboot 단계에서 KITL 설정을 하고 왔을지도 모른다. 필자가 경험한 바로는 이 단계에 와서도 KITL 설정이 제대로 된 적이 없다. 프로세서, 이더넷 칩, 인터페이스, 이더넷 관련 드라이버 수정, Eboot로 포팅등 해야 할 일이 많기 때문에 KITL 설정을 금방 끝낼 수는 없다.
늦었지만 지금부터 시작하여 KITL이 제대로 동작하도록 만들어 놓는다. 물론 JTAG 디버거도 있고 시리얼 포트로 해서 디버깅 메시지를 볼 수는 있다. 하지만 플랫폼 빌더를 이용하면 더 많은 디버깅 정보를 얻을 수 있다.
윈도우CE라는 운영체제는 복잡한 소프트웨어입니다. 시리얼포트로 순차적으로 나오는 정보만 가지고는 운영체제가 어떠한 상태인지 파악할 수 없습니다. <그림 6>은 KITL을 이용하여 플랫폼 빌더에서 디버깅하는 모습이다. 단순히 중단점을 설정해서 한 줄 한 줄 디버깅하는 기능뿐만 아니라, 어떤 함수들이 호출되면서 진행되었고, 커널에서 어떤 문제가 있는지 자세하게 볼 수 있다.
<그림6>
요즘은 USB를 이용한 USB KITL을 이더넷 KITL 보다 많이 사용하는 추세이다. 별다른 하드웨어 추가 없이 ActiveSync를 사용하던 USB 포트로 KITL을 사용할 수 있다. 하지만 대부분 BSP에서 지원하지는 않기 때문에 사전에 알아 봐야 한다.
-KITL 설정
-KITL을 통하여 플랫폼 빌더에서 개발 보드가 인식하는지 테스트
-KITL을 통하여 OS이미지가 다운로드 되는지 테스트
-KITL로 OS이미지를 다운로드 한 후 문제가 없는지 테스트
MINKERENEL 동작 테스트(Release, Debug모드)
MINKERNEL은 플랫폼 빌더에서 만들 수 있는 가장 작은 형태의 윈도우CE 운영체제이다. 사용자를 위한 Explore와 같은 쉘(Shell)이나 그래픽 화면은 안나온다. 오직 커널이 스케줄링을 제대로 하고 있으며, OS가 동작할 준비가 되었다는 것만 확인 할 수 있다. <그림 7>은 플랫폼 빌더를 이용하여 MINKERNEL을 생성하는 모습이다.
<그림7>
아무 생각 없이 윈도우CE 운영체제를 만들면 어려가지 복잡한 문제가 생긴다. 어떤 설정은 LCD 드라이버가 반드시 있어야 하고, 또 어떤 설정은 특정한 드라이버가 있어야 할 수도 있다. 뿐만 아니라 포함시킨 드라이버가 정상적으로 동작해야 OS에 포함시키고 OS가 정상적으로 동작하는지 확인할 수 있다.
하지만 지금은 아직 그럴 단계가 아니다! 그래서 불필요한 요소를 모두 없애고. 오직 필요한 커널만 동작시켜보는 것이다.
그리고 하나하나 추가시키면 윈도우CE 운영체제 포팅이 끝난다. 이런 이유로 MINKERNEL을 먼저 동작시키는 작업을 하는 것이다. 가장 중심이 되는 커널이 동작하는 것을 확인하고, 화면이 나오게, 소리가 나오게, 키 입력을 받을 수 있도록 한다. 그렇게 하면 좀 더 손쉽게 윈도우CE 운영체제를 포팅 할 수 있다.
헌데 일부 BSP는 MINKERNEL을 만들 수 없는 경우가 있다. 윈도우CE 운영체제는 컴포넌트화 되어 있는데 너무 강력하게 BSP를 만들어 다른 컴포넌트가 없으면 문제가 되도록 BSP를 만든 것이다. 이럴 땐 MINKERNEL을 만들 수 없기 때문에 할 수없이 BSP가 제공해준 가이드대로 작업을 해야 한다.
디바이스 드라이버 포팅
이제 동작이 된다고 확인한 MINKERNEL에 드라이버들을 포팅한다. 처음부터 모든 것을 다 할 필요는 없다. LCD를 먼저 추가하고, 터치 패널 드라이버와 오디오 드라이버 순으로 포팅하면 된다. 단 순서가 문제가 되지는 않지만 만약 LCD와 터치가 있다면 다른 무엇보다도 먼저 하는 것이 좋다. 터치를 해서 메뉴를 눌러야 제대로 동작되는 것을 확인 할 수 있으니까 말이다.
여러분의 동료와 자기가 담당한 부분을 책임지고 드라이버를 포팅하면 되는 것이다. 디버깅 환경도, 기본적으로 돌아가는 OS도 있기 때문에 이제 채워 넣기만 하면 된다. 이 단계는 시간과의 싸움이다. 윈도우CE의 드라이버 구조를 잘 파악하고 하드웨어에 맞게 수정하면 된다. BSP에 기본적인 드라이버 소스가 있기 때문에 소스 구조에 잘 맞추어 변경된 하드웨어 부분을 수정한다면 빠른 시간 내에 드라이버 개발을 끝마칠 수 있을 것이다.
Full Kernel 동작 테스트
아직 미진한 부분이 있겠지만 대부분의 드라이버 개발이 끝났을 것이다. 하지만 모든 작업 내용을 통합하여 하나의 OS이미지를 만들어 봐야 한다. 각각은 잘 돌아가는데 통합된 OS 이미지로는 문제가 있는 경우가 있다. 그런 것을 대비하여 미리 개발 초기에서부터 통합하여 테스트를 해 봐야 한다.
운영체제내의 드라이버들은 운영체제가 제시한 규칙에 맞추어 잘 동작하여야 한다. 혹은 드라이버에서 사용한 방법이 다른 드라이버들과 문제를 일으킬 경우가 있다. 윈도우CE 운영체제 포팅은 하나의 심포니와 같이 여러 엔지니어가 작업한 내용이 조화로워야 제대로 성능을 발휘한다.
디버깅, 테스트, 튜닝
이제 마지막 단계이다. 이제부터는 계속 테스트 하고, 문제가 있으면 디버깅하고, 드라이버의 성능을 높이기 위한 최적화 작업을 해야 한다.
또 MP3와 동영상도 돌려보고 ActiveSync도 해 보면서 많이 사용해 봐야 한다. 그래야 어떤 문제가 있는지 확인할 수 있다. 또 한 중요한 것은 이미 출시된 다른 장치와 성능을 비교해 보는 것이다. 이 프로그램을 돌릴 때는 속도가 어느 정도의 차이가 있고, 어떤 프로그램에서 문제가 생기는지 확인해 보는 것이다. 좋은 제품을 만들기 위해서는 많이 사용해서 많은 문제를 찾는 수밖에 없음을 강조하고 싶다.
여기까지 윈도우CE를 어떠한 순서로 포팅하는지에 대해 잠시 살펴보았다. 다음부터는 좀 더 다양한 내용과 주제로 윈도우CE에 대해 알아보도록 한다.
여기서 잠깐!
Eboot란?
Eboot는 Ethernet Boot loader의 줄인 말이다 ‘왜 Ethernet이냐고 묻는다면 필자도 정답을 모른다. 그래도 필자 생각를 정리해 본다면, 윈도우CE가 초기 버전에서는 OS를 다운로드하고 디버깅하는데 시리얼 포트나 패러랠 포트가 이용되다 보니 그러다 보니 속도가 굉장히 늦어졌다. 지금 이 글을 보시는 독자 중에 윈도우CE 3.0이나 그 이하의 버전을 개발해 보는 이는 아마 없을 것이다. 이 버전에서 필자는 시리얼 포트를 사용해서 개발을 했고, 이러나 보니 시간이 많이 걸렸다.
그러나 Ethernet을 이용하여 개발을 하게 되었습니다. 그러다 보니 속도가 엄청 빨라졌다! 아마 이런 연유로 ‘Ethernet을 이용하여 엄청난 속도로 개발하게 되었어’ 하는 감동에 젖어 Eboot라는 이름을 지었지 않나 생각한다.
뭐 어디까지나 필자 개인적인 생각이고, Eboot를 개발보드상에서 동작시키게 하는 것은 가장 기초적인 단계이다.Eboot을 역할을 정리한다면 다음과 같다.
-개발보드의 하드웨어 초기화, SDRAM, Flash, 디버그 시리얼 포트, LED 등
-플래시 내에 있는 OS를 읽어 들여 실행 시키거나 부팅시킴
-Ethernet을 초기화 시켜 Platform Builder를 통해 OS를 다운로드 하거나 디버깅 할 수 있도록 만듦.
결국 보드를 초기화 하고 OS 개발을 도와주는 것이 Eboot의 주 기능이라고 생각하시면 된다.
Debug Vs Release
플랫폼 빌더에는 Debug와 Release라는 두 가지 모드가 있다. 비주얼 스튜디오에서 PC용 응용프로그램을 개발 해 봤다면 Debug와 Release의 차이를 알 것이다. Debug 모드는 디버깅에 관한 정보를 모은 OS 이미지이다. 따라서 OS 이미지도 크고, 동작할 때 많은 정보를 준다. 보통 개발할 때 Debug 모드로 개발을 시작한다. 그래야 문제가 생겨도 쉽게 문제점을 확인할 수 있다.
그리고 나서 어느 정도 안정화가 되면 Release 모드로 OS 이미지를 생성한다. Debug 모드 OS이미지는 용량도 크고 동작 속도도 느리기에 출시 할 때는 반드시 릴리스 모드로 OS 이미지를 만들어야 한다. @
