2008년 6월 23일 월요일

PXA320 Dynamic Memory Controller Summary

1. SDRAM Configuration Register(MDCNFG)
The MDCNFG register contains control bits for configuring the SDRAM with parameters such as tRP, tRCD, tRAS, tRC. Both SDRAM chip selects must use the same parameters.

2. SDRAM Refresh Control Register(MDREFR)
The MDREFR register contains control bits for SDRAM refresh.

3. SDRAM Mode Register Set Configuration Register(MDMRS)
The MDMRS register is used to issue MRS and EMRS commands to SDRAM

4. DDR Hardware Calibration Register(DDR_HCAL)
This register allows hardware to calibrate and set the strobe delay lines.

5. DDR Write Strobe Calibration Register(DDR_WCAL)
This register lets hardware calibration set the write-strobe delay lines.

6. Dynamic Memory Controller Interrupt Enable Register(DMCIER)
The DMCIER is the Interrupt Enable register for all of the dynamic-memory controller interrupts.

7. Dynamic Memory Controller Interrupt Status Register(DMCISR)
The DMCISR is the Intrrrupt Status register for all of the dynamic-memory controller interrupts.

8. Delay Line Status Register(DDR_DLS)
The read-only Delay Line Status register monitors the delay-line values on strobes DQSx. DDR_DLS contains calibration information for controlling the external-bus delay lines and DQSx.

9. External Memory Pin Interface Control Register(EMPI)
The EMPI register controls the external-memory pin-interface(EMPI) module.

10. Rcomp Control Register(RCOMP)
The Rcomp Control register is similar in concept to the SDRAM Refresh Control register, MDREFR. Both registers use a counter clocked off of a 13-MHz clock to initiate events, and both registers contain an identical software mechanism for initiating their respective events.

2008년 6월 18일 수요일

VC.net과 VC 2005에서의 C Run-Time Libraries

VC 2005(visual c++ 8.0)의 경우 Run-Time Libray 함수를 사용하기 위해서 해당 함수의 확인이 필요하다. 이는 기존의 Run-Time Libray 함수들이 재정의 되면서 함수의 형태 및 필요 인수와 반환값의 형태가 바뀐 것들이 많기 때문이다.

VC 2005 Run-Time Library 목록

VC .net Run-Time Library 목록

2008년 6월 17일 화요일

마이크로소프트웨어에서 BSP를 검색할수 있는 곳

Find Board Support Packages

http://www.microsoft.com/windows/embedded/msdn/bspsearch.aspx

Visula Studio 2005 단축키

Ctrl + Tab Edit하고 있는 Child Window 간의 이동
Ctrl + F4 현재 Edit하고 있는 Child Window를 닫기
Ctrl + I 문자열 입력 점진적으로 문자열 찾기 (Incremental Search)
Ctrl + F3 현재 커서에 있는 문자열 찾기 fowared (블록 지정 안 해도 됨)
Shift + F3 현재 커서에 있는 문자열 찾기 backward
F3 찾은 문자열에 대한 다음 문자열로 이동 (Next Search)
Ctrl + H 문자열 찾아 바꾸기 (Replace)
Ctrl + Left/Right Arrow 단어 단위로 이동
Ctrl + Delete 또는 Backspace 단어 단위로 삭제
Ctrl + F2 현재 라인에 북마크 지정/해제
F2 지정된 다음 북마크로 이동
Ctrl + Shift + F2 지정된 모든 북마크를 해제
F9 현재 라인에 Breakpoint를 지정/해제
Ctrl + Shift + F9 현재 Edit하고 있는 소스파일에 지정된 모든 Breakpoint 해제
Ctrl + ] 또는 E '{'괄호의 짝을 찾아줌 ('{'에 커서를 놓고 눌러야 함}
Ctrl + J, K #ifdef 와 #endif의 짝을 찾아줌
Ctrl + L 한 라인을 클립보드로 잘라내기 (Cut)
Ctrl + Shift + L 한 라인을 삭제
Alt + Mouse 블록 설정 세로로 블록 설정하기 (마우스d로)
Ctrl + Shift + F8 세로로 블록 설정하기 (키보드로), 취소할 때는 Esc키를 눌러야 함
블록 설정 -> Tab 선택된 블록의 문자열을 일괄적으로 들여쓰기(Tab) 적용
블록 설정 -> Shift + Tab 선택된 블록의 문자열을 일괄적으로 내어쓰기 적용
Alt + F8 -> Tab 또는 Shift + Tab 들여쓰기 자동 조정 (Tab:들여쓰기, Shift + Tab : 내어쓰기)
Ctrl + T 현재 커서에 있는 변수/함수에 대한 Type이 Tooltip 힌트 창에 나타남
Ctrl + Alt + T 멤버 변수/함수 목록에 대한 팝업 창이 나타남
Ctrl + Shift + T 공백/콤마/파이프/괄호 등을 기준으로 좌우 문자열을 Swap시킴
Ctrl + Shift + 8 문단기호 표시/감추기 : Tab은 ^, Space는 .으로 표시
Ctrl + D 툴바의 찾기 Editbox로 이동
Ctrl + Up/Down Arrow 커서는 고정시키고 화면만 스크롤 시키기
Tab 들여쓰기
Shift+Tab 내어쓰기
F4 다음 에러메세지로 이동
Alt+F8 들여쓰기 자동 조정
Ctrl+F 찾기
Ctrl+F3 현재 커서에 있는 단어로 찾기
Ctrl+H 찾아 바꾸기
F3 다음 단어 찾기
Ctrl+Shift+F3 이전 단어 찾기
Alt+E+I 프로젝트 내의 모든 파일에서 찾기
F2 설정된 북마크로 이동
F9 현재 커서위치에 BreakPoint를 설정/해제
Ctrl+B 브레이크 포인트 관리 메뉴
Ctrl+Spacebar 멤버목록 팝업창
Ctrl+T 현재 커서에 있는 단어의 툴팁정보 보기
Ctrl+U 모두 소문자로
Ctrl+Shift+U 모두 대문자로
Ctrl+Shift+8 Tab은 ^ 로 공백은 . 으로 보여줌

디버깅에 관련된 단축키 하나 더.
변수이름을 적어 놓고 브래이크 포인터의 위치 여부와 관계 없이 변수의 내용을 추적하는 기능이 Watch Window에 들어 있다. 디버그 모드에서 추가하고픈 변수나 등등 앞에 커서를 위치 시킨후 Shift + F9를 누르면 그냥 바로 추가된다.

▼ Browse Information file 이 필요한 단축키
(컴파일 되어야 함)

F12 현재 커서의 함수 정의 부분으로 이동
Shift+F12 현재 커서의 함수 참조 부분으로 이동
Ctrl+Num+ 다음 정의/참조 로 이동
Ctrl+Num- 이전 정의/참조 로 이동

▼ Visual Assist 6.0 설치시 가능한 단축키

Alt+O 현재 파일의 헤더(.h)/구현(.cpp) 파일로 이동
Alt+G 현재 커서의 함수 정의 부분으로 이동
Alt+M 현재 파일의 모든 함수 목록
Ctrl+Shift+V 선택해서 붙여넣기
Alt+← 이전 커서 위치로 이동
Alt+→ 다음 커서 위치로 이동
■ 디버그 단축키

변수이름을 적어 놓고 브래이크 포인터의 위치 여부와 관계 없이 변수의 내용을
추적하는 기능이 Watch Window에 들어 있죠...
그 때 디버그 모드에서 추가하고픈 변수나 등등 앞에 커서를 위치 시킨후
Shift + F9를 누르면 그냥 바로 추가됩니다

■ General Development Settings Default Shortcut Keys
http://msdn.microsoft.com/en-us/library/xte2hh6a(VS.80).aspx

2008년 6월 16일 월요일

[Tip] RETAILMSG로 디버그메시지 출력하기 [펌]

디버깅 하고자하는 파일(*.cpp, *.c)에 다음 두줄을 선언하시고 빌더하시면 됩니다.
(대략 위치는 헤드 파일 선언 이후면 되겠네요.)

#undef DEBUGMSG
#define DEBUGMSG( a, b) RETAILMSG( 1, b)

그러면 해당 파일에 있는 DEBUGMSG의 메시지들이 릴리즈 모드에서도 출력됩니다.
※ 헤드파일(*.h)에는 선언하지 마시기 바랍니다. 여러 파일에 적용되어 메시지 홍수 납니다.
함수 내에 선언하셔서 함수만 적용되도록 하셔도 됩니다.

이런게 가능한 이유는 DEBUGMSG 가 함수가 아니라 define으로 되어 있기 때문입니다.

고수님들은 다 알고 계신 내용을 팁이겠지만 도움되시는 분들이 있으실까봐 올립니다.
역시나 적고 보니 조금 허접하네요. 단 두줄이라니.. ^^;;

--------------------------------------------------------------------------------------------------------------------------------------

참고로.. RETAILMSG의 사용법은 소스를 보시면 많이 있는데 보통 아래와 같습니다.
RETAILMSG( 1, (TEXT("Message \r\n") ));
RETAILMSG( 1, (TEXT("Message : %d \r\n"), count ));
메시지들은 KITL로 연결되면 PB에 출력되며, KITL 연결이 아니면 디버거 시리얼 포트로 출력됩니다.참 RETAILMSG의 첫 인자가 1일때 출력됩니다. ( 1이나 TRUE 일때 )
---------------------------------------------------------------------------------------------------------------------------------------

WinCE에서의 스트링 사용

WinCE에서 스트링을 처리할 때는 기존의 표준 ANSI C 함수(strcpy, strcmp 등)를 사용할 수 없다. WinCE가 유니코드를 사용하기 때문이다. 유니코드라고 해서 특별히 복잡한 것은 없는데 다만 1바이트로 처리하던 문자(ANSI의 경우 표준 아스키코드 128종류문자, 확장 특수문자까지 포함하면 256가지)를 2바이트로 대폭 확장했다는 차이만이 있을 뿐이다. 그렇지만 이 차이로 인해 PC상에서 주로 썼던 친숙한 스티링 함수 등은 전부 쓸 수 없게 되었다. 대신 한글처리나 기타 여러 언어의 문자를 처리함에 있어서 언어버전마다 다른 복잡한 PC윈도 프로그램 보단 통일성 있게 프로그래밍이 가능해졌다.

스트링의 선언
- ANSI의 경우(컴파일러 환경에 _MBCS라는 매크로가 정의된 경우)
char string[10];

- Unicode 의 경우(컴파일러 환경에 UNICODE나 _UNICODE라는 매크로가 정의된 경우)
wchar_t string[10];

두 가지를 통합하는 변수타입도 있는데 다음과 같이 선언해주면 ANSI든 Unicode든 상관없이 컴파일러 옵션에서 알아서 처리한다.
TCHAR string[10];

앞으로는 WinCE 의 스트링을 처리할 때는 꼭 'TCHAR'를 기억하자. 참고로 TCHAR는 다음과 같이 선언되어 있다.
#ifdef _UNICODE
#define TCHAR wchar_t
#endif
#ifdef _MBCS // ANSI의 Ascii 코드 방식일 때
#define TCHAR char
#endif

스트링을 선언과 함께 초기화할 때
- ANSI의 경우
char szString[20] = "I am a girl";

- Unicode의 경우
wchar_t szString[20] = L"I am a girl";

유니코드의 경우 쌍따옴표 앞에서 붙은 'L'이라는 매크로를 붙임으로 해서 쌍따옴표 부분이 유니코드로 변환된다. 하지만 실제로 가장 많이 쓰는 변수형은 다음과 같다.

TCHAR szString[20] = _T("I am a girl");
TCHAR szString[20] = TEXT("I am a girl");

_T()와 TEXT()는 사실 같은 역할을 하는 매크로로 컴파일러 환경이 ANSI로 정의되어 있으며 괄호안에 스트링을 그대로 두어 ANSI코드로 만들고 UNICODE로 되어 있으면 'L'이라는 매크로를 앞에 붙여서 괄호안의 스트링을 유니코드로 만드는 것과 같은 역할을 한다.
즉, 다음과 같은 역할을 하는 것이다.

- ANSI의 경우
TCHAR szString[20] = _T("I am a girl");
-> char szString[20] = "I am a gril";

-Unicode의 경우
TCHAR szString[20] = _T("I am a girl");
-> wchar_t szString[20] = L"I am a girl";

결론적으로 가장 중요하게 강조하고 싶은 저은 TCHAR와 _T("")/TEXT("") 매크로로 프로그램이나 모듈을 짜놓으면 개발환경이 ANSI인지 유니코드인지 상관없이 컴파일이 가능한 코드를 작성할 수 있다. 가급적으로 WinCE에서는 이 매크로들만 사용하기를 강하게 추천하는 바이다.
또 주의해야 할 점은 TCHAR와 _T(""), TEXT("") 같은 통합 매크로를 사용했으면 지속적으로 사용해야지 중간에 char, tchar나 'L' 매크로 등을 소스 중간 중간에 써넣으면 나중에 간혹 환경이 다른 상황에서 컴파일 할 때의 자잘한 수 백 개의 컴파일 에러들이 짜증날 가능성이 높다.

스트링 처리 함수
C 프로그램을 짜다가 보면 아마 가장 많이 사용하는 함수 중의 하나가 strcpy, strlen 등의 스트링 처리 함수일 것이다. 하지만 이런 함수들은 기본적으로 1바이트 차계의 스트링들을 처리하기 위한 함수들이므로 WinCE의 유니코드 환경에서 제대로 작동하지 않는다.
- ANSI에서 스트링 처리 함수
strcpy, strncpy, strlen, strcmp, strncmp 등
- Unicode에서 스트링 처리 함수
wcscpy, wcsncpy, wcsnlen, wcscmp 등

즉 str로 시작되는 접두사 부분을 wcs로 바꾸어 프로그램을 짜면 된다. 또 TCHAR형식처럼 ANSI와 유니코드를 동시에 지원하려면 다음 함수들을 사용하면 되며, 모두 'tchar.h'에 정의되어 있다.
_tcscpy, _tcsncpy, _tcsnlen, _tcscmp 등

스트링 입출력 함수
- ANSI : printf, sprintf, scanf
- Unicode : wprintf, swprintf, wscanf
- TCHAR : _tprintf, _stprintf, _tscanf

실제 사용 예제는 다음과 같다.
{
TCHAR szTemp1[100] = _T("You are my brother.");
TCHAR szTemp2[100] = _T(" And we are the world.");
TCHAR szTemp3[100] ;

_tcscat(szTemp1, szTemp2);
_stprintf(szTemp3, _T("%s -> Merge string"), szTemp1);
MessageBox(NULL, szTemp3, _T("Test"), MB_OK);
}

Win32에서는 sprintf를 쓸 수 없고 wsprintf를 써야만 되는 경우가 있어서 위 소스가 컴파일 에러를 낼 수 도 있다. 이 경우 다음의 사용자 정의 스트링 처리 함수 부분을 참조하자.

사용자 정의 스트링 처리 함수
아무리 TCHAR 형식 스트링이 ANSI/유니코드를 동시 지원한다고는 하지만 실제 프로그래밍을 들어가 보면 사용자 정의 형식의 함수가 필요할 때가 아주 많다. 예를 들어 위 스트링 처리 함수들을 응용하고 재조합하는 함수를 만들다가 보면 중간에 별도의 다른 내용의 함수가 필요할 때가 종종 있다.
예를 들어 다음과 같이 Sample이라는 스트링의 실제 문자 수를 알고 싶다면
TCHAR Sample[10] = _T("Test");

ANSI에서는 strlen()함수, 유니코드에서는 wcslen()함수 등을 쓰면 된다. 혹은 _tcslen함수를 써도 마찬가지다. 근데 만약 알고 싶은 것이 실제 문자수가 아니라 스트링이 몇 바이트인지 알고싶을 때는 _tcslen 함수를 사용해도 알 수 없다.
왜냐하면 _tcslen함수는 무조건 4라는 리턴값을 취할 것이기 때문이다. 유니코드 상태에서 Sample이라는 변수의 "Test"란 스트링이 차지하는 바이트 수는 8이다(4개의 문자 * 유니코드 기본바이트 2). 이 경우는 비교적 간단한 경우라서

_tcslen(Sample) * sizeof(TCHAR)

이런 식으로 리턴값을 얻어내면 되겠지만 모든 소스코드 라인에 이런 귀찮은 표현을 타이핑 하기에도 아주 번거로울 것이다. 이런 경우에 대비하여 아예 my_strbyte()란 함수를 만들어두고 필요할 때마다 사용하면 편할 것이다. 다음과 같이 사용자 정의 함수를 만들면 된다.
inline int my_strbyte( TCHAR *szString )
{
#ifdef _MBCS // ANSI
return strlen(szString);
#endif
#ifdef _UNICODE // Unicode
return wcslen(szString) *2
#endif
}

그리고 어쩌다가 윈도 표준 스트링 함수와 스트링 처리 함수가 충돌하는 경우가 있는데 이런 경우(대표적 예가 _strintf 이다) 다음과 같이 define 형식으로 처리하면서 각각 상황에 맞는 함수를 정의 내릴 수 있다.
// my_stprintf의 등록
#ifdef _MBCS
#define my_stprintf wsprintf
#endif
#ifdef _UNICODE
#define my_stprintf swprintf
#endif

윗 부분을 정의한 다음에 윗 장에서 썼던 예제 소스를 다시 수정하여 넣어보면 적어도 윈도우를 사용하는 어떠한 플랫폼에서도 제대로 컴파일 되고 아무런 문제가 없이 실행됨을 알 수 있다.

다음은 예제 소스이다.
{
TCHAR szTemp1[100] = _T("You are my brother.");
TCHAR szTemp2[100] = _T(" And we are the world.");
TCHAR szTemp3[100] ;

_tcscat(szTemp1, szTemp2);
my_stprintf(szTemp3, _T("%s -> Merge string"), szTemp1);
MessageBox(NULL, szTemp3, _T("Test"), MB_OK);
}

그 외 여러 가지 사용자 정의 함수의 예들을 넣었다. 필자가 초기에 _tcs 계열의 함수들이 미덥지 못해서 만든 함수들인데 비록 모든 함수들이 _tcs(XXX)형식으로 다 있는 것이기는 하지만 예제를 보고 충분히 재활용할 수 있게 소스를 실었다.

// my_strcpy함수: UNICODE와 ANSI 코드 동시 지원
TCHAR inline *my_strcpy(TCHAR* dest, TCHAR* src)
{
#ifdef _MBCS
return strcpy(dest, src);
#endif
#ifdef _UNICODE
return wcscpy(dest, src);
#endif
}

// my_strncpy함수: UNICODE와 ANSI 코드 동시 지원
TCHAR inline *my_strncpy(TCHAR* dest, TCHAR* src, int n)
{
#ifdef _MBCS
return strncpy(dest, src, n);
#endif
#ifdef _UNICODE
return wcsncpy(dest, src, n);
#endif
}

// my_strtok함수: UNICODE와 ANSI 코드 동시 지원
TCHAR inline *my_strtok(TCHAR* buff, TCHAR* token)
{
#ifdef _MBCS
return strtok(buff, token);
#endif
#ifdef _UNICODE
return wcstok(buff, token);
#endif
}

// my_atoi함수: UNICODE와 ANSI 코드 동시 지원
int inline my_atoi(TCHAR* str)
{
#ifdef _MBCS
return atoi(str);
#endif
#ifdef _UNICODE
return _wtoi(str);
#endif
}

// my_strlen함수: UNICODE와 ANSI 코드 동시 지원
int inline my_strlen(TCHAR* str)
{
#ifdef _MBCS
return strlen(str);
#endif
#ifdef _UNICODE
return wcslen(str);
#endif
}
parent.ContentViewer.parseScript('b_388771');

Wince에서 cached와 uncached를 사용하는 이유

CPU Core 내부에 Cache Controller 가 있으면 캐쉬를 인에이블시켜 쓰던데 ...
CPU내부 core에서 CPU의 내부에 있는 Register나 SDRAM 또는 NAND 또는 Address로 접근 가능한 장치를 address mapping 할때 cache와 uncache로 구분해서 사용합니다.
Oemaddress Table에는 physical address와 cached address만 기록하면 cached address에서 0x2000_0000만큼 높은 번지는 Uncached address가 됩니다.

가령 physical 0x000__0000을 cached로 0x8000_0000이면 uncached는 0xa000_0000 이됩니다.
WINCE에서 Cached address는 0x8000_0000 ~0x9FFF_FFFF까지 이고 Uncached는 0xA000_0000 ~ 0xB000_0000까지 입니다.
cached로 사용하면 Core에서 Address를 access하는 순간 바로 해당 주소를 access하는 반면 uncached로 addressing 하면 그 즉시 access하지 않고 지연되어 read/write가 됩다.


Uncached를 주로 사용하는 경우는 다음과 같습니다.
- CPU내부 register - DMA descriptor
- CPU외부의 chip selector 에 연결되어 있는 IO device - SDRAM의 특정 영역(global 영역등 sharing 을 위한 목적)

Cached를 주로 사용하는 경우는 다음과 같습니다.
- OS가 access하는 SDRAM
- 대용량 memory share(display area / audio dma area 등등)

Cache와 Uncached 의 가장 큰 차이점은 속도 입니다. Uncached로 선언된 영역을 access하면 core의 command가 나갈때 마다 실제로 memory를 access하여야하는데 이과정에서 속도가 떨어지게됩니다. 왜냐면 만약 core는 400Mhz로 작동하는데 외부 버스는 100Mhz나 50Mhz로 작동되는 상황을 생각해 보시기 바랍니다

Windows CE 실전가이드 중요내용 요약

플랫폼 빌더 : 마이크로소프트 사에서 제공하는 wince용 이미지를 제공하는 툴

이미지 생성 절차를 이해하기 위해서는 BSP와 Common요소를 반드시 이해

BSP : 몇가지 표준 타겟 시스템을 정해놓고, 해당하는 타겟 시스템에 종속적인 코드들을
담아놓은 환경

common : 타겟 시스템에 종속적인 코드를 제외한 나머지 코드들중 어떤 BSP를 사용하더라도
호환성을 가질수 있는 코드

프로젝트 : 개발자가 직접 생성하는 타겟을 위한 프로그램

Windows CE용 이미지 생성 = BSP + Common + 프로젝트

명령프롬프트 상에서 이미지를 생성하는 절차
1. system 생성과정(Header 생성과정)
2. Bulid Platform 과정
3. Bulild Release 과정
4. Make Image 과정

REG,DAT,DB,BIB
이미지 생성을 하는데 사용되어지는 중요한 구성파일
실제로 이미지 생성 시 사용되는 시기는 Make Image과정때

REG
시스템 레지스트리 파일을 만드는데 사용되어지는 파일
MakeImage과정을 하게 되면
모든 REG 확장자를 가지는 파일들을 통합하여 REGINIT.ini파일 생성
REGINIT.ini 파일은 DEFAULT.fdf파일로 변환
해당 파일을 NK.bin 이미지 파일에 포함되어,
부팅과정에서 형성될 초기 시스템 레지스트리 환경을 구축

PLATFORM.reg : 디바이스 드라이버의 관련정보가 들어 있음

DAT
단축아이콘 등을 원하는 위치에 생성하도록 지시하는 파일
DAT파일 통합 INITOBJ.dat파일생성 이를 NK.bin 이미지 파일에 포함

DB
데이터 베이스 테이블을 생성하도록 지시하는 파일이다.
확장자 통합하여 INITDB.ini를 만듬

BIB
NK.bin으로 압축할 파일들에 대한 정보와 압축이미지의 속성을 결정하는 파일
확장자를 통합하여 CE.bib 파일을 만듬


파일 속성
S : System 속성
H : Hidden 속성
X : 이미지 속에 압축될 때 서명된 정보를 보관하도록 지시
L : 가상메모리 상에서 해당하는 파일이 분리되어 보관되지 않도록 지시

sample BSP생성시 반드시 빌요한 폴더 및 파일
SRC폴더 및 3개의 파일이 존재해야 함
dirs : 플랫폼 빌더의 의해서 BSP가 빌드되는 과정때, 사용될 빌드 대상 폴더정보를 담고 있다.
samplebsp.bat : 특별히 정하고자 하는 BSP_XXX환경변수를 정의
Sources.cmm : SRC폴더 내의 각 Component들이 Build명령어에 의해서 빌드될때 참고

부트로더에서 중요하게 생각하는 부분
CPU 내에서 존재하는 MMU와 캐시의 활성화
리얼타임 클럭등 초기화, 다운로드 경로로 사용될 하드웨어 초기화

EBOOT작성을 도와주기 위해서 제공되어지는 라이브러리 소스의 위치

$(_PUBLICROOT)\COMMON\OCK\DRIVERS\ETHDBG\BLCOMMON

BLCOMMON 제공하는 함수 크게 두가지 = BootloaderMain() + DownloadImage()
전원=> OEM의 StartUp() => BLCOMMON의 BootloaderMain() =>
OEMDeBugInit() : 디버그 모니터용 포트를 초기화 =>
OEMPlatformInit() : 부트로더로서 역활을 수행하기 위해서 필요한 타겟 플랫폼을 초기화 =>
OEMPreDownLoad() : 연결될 호스트를 착기 위해서 BOOTME 패킷을 Broadcast형식으로 내보내려 한다.
=> BLCOMMON의 DownloadImage()
=> OEMReadData()
=> OEMMapMemAddr()
=> OEM의 OEMLaunch()
=> OEM의 StartUp()
이미지 로딩이 끝나면 호스트 이미지의 시작주소로 제어이행

OAL(OEM Adaptation Layer)은 커널과 함께 링크되어 하나의 NK.exe 프로세스 파일을 이루는 요소
WinCE 스레드 단위의 작업 스케줄링을 처러
동일한 시간에 32개의 최대 프로세스가 메모리에 상주하는 것을 허용(WinCE5.0)

액티브슬롯 : 실행중인 모든 프로세스 중에서 현재 실행되고 있는 스레드를 위한 프로세스가 사용
WinCE 커널은 퀀텀타임(기본 CPU선점시간)에 기반을 둔 라운드로빈 방식의 스케줄링을 지원

가상메모리 4GB중 2GB의 공간이 응용프로그램을 위해 사용
커널레벨에서 동작하는 커널 코드와 OAL코드들은 상위 2GB의 공간을 사용

부팅과정에서 OAL은 커널에게 가상메모리 가 실제 어떤 물리메모리 공간으로 매핑돼야 하는지
알리는 OEMAddressTable을 소개하게되는데, 커널은 이 테이블을 사용해서 가상메모리를 물리
메모리공간으로 매핑하도록 MMU를 초기화

디바이스 드라이버 개발자들이 흔히 저리르는 실수가 하나 있다. WinXP와 같은 운영체제를 사용하는
습관에서 비롯된 부분인데, 동일한 프로세스 내의 모든 스레들은 같은 공간을 참조할 수 있다는 것이다.
그러나 이것은 WinCE에서는 불가능하다. 그렇기 때문에 스레드를 생성한 뒤 반드시 해당하는
스레드에게 적절한 퍼미션을 줘야 한다.

커널과 OAL(OEM Adaptation Layer)중에서, 개발자가 코딩해야 하는 부분은 OAL
커널과 OAL은 서로 같이 링크되어 NK.exe라는 프로세스 파일을 형성하게 된다.

커널이 관심을 두고 있는 플랫폼 하드웨어는 그 용도가 정해져 있다.

시간등을 기록하고 읽어오기 위한용도
인터럽트 컨트롤러로 하여금 인터럽트를 금지하거나 허용시키는 용도
지정된 시간마다 타이머 인터럽트가 발생되도록 시도하는 용도
디버그 용도로 사용될 UART,NETCARD등을 다루는 용도

커널이 접근하려는 하드웨어 플랫폼에 대해 이를 접근할수 있도록 지원하는 목적이 OAL의 역할
디바이스 드라이버도 플랫폼에 관심을 두고 있는 모듈이지만 그 용도가 사용자 서비스와
관련된 용도라는 점에서 OAL과 다른 특징을 가짐

OAL필수함수들이 반드시 구현되어야지만 NK.exe가 만들어진다.

StartUp()
이함수가 호출될때는 CPU내의 MMU는 사용되지 않는 상태이어야함
이 함수를 호출할때 파라미터로 사용되는 것인 OEMAddressTable
이테이블은 가상메모리 주소와 실제 메모리 주소와의 매핑 관계를
서술하고 있는 테이블로서 이테이블을 넘겨받아야 커널이 MMU를 초기화하게 된다.

OEMInitDebugSerial() 이 함수를 통해 UART로의 디버그지원함수를 준비할 책임이 있음

OEMInit() 함수를 호출해 플랫폼 하드웨어를 초기화
1플랫폼 하드웨어 초기화
2인터럽트 핸들러 초기화
ARM CPU를 사용하는 경우에는 OAL의 OEMInterruptHandler() 핰수가 보편적인
인터럽트 서비스 루팀으로서의 역할을 수행
3전역변수 초기화


커널은 BIB파일을 통해서 개발자가 알린RAM외에 또다른 RAM의 존재를 확인
이때 호출되는 함수가 OEMGetExtensionDRAM()

커널은 하드웨어 플랫폼으로부터 인터럽트를 가장 먼저 받는 모듈.
그러나 커널은 인터럽트의 구제적인 의미를 파악하지 못하기 때문에 OAL이 제공하는
인터럽트 서비스 루틴의 지원을 받게됨

OAL이 제공하는 ISR의 프로토타입

int OEMISR(unsigend int reserved);


커널과 디바이스 드라이버들이 이해하는 인터럽트를 Interrupt Logical ID라고 부른다.

결국 OAL이 지원하는 ISR은 타겟 시스템에 이미 내장된 하드웨어가 발생하는 인터럽트를
인식하는 역활을 수행하지만, 디바이스 드라이버가 추가적으로 지원하는 Installabe ISR은
복수개의 동일한 인터럽트 벡터를 사용하는 하드웨어를 지원하기 위함이라는 사실을 알아야 함

OEMInterruptEnable()
디바이스 드라이버는 자신이 받고자 하는 하드웨어 인터럽에 대한 Logical ID를 커널에게
전달해 이 인터럽트가 유효한지를 확인하고 해당하는 인터럽트가 발생될수 있는 조건을
만들도록 용처해야하는데 이때 이 함수를 씀

InterruptInitialize()
디바이스 드라이버가 사용하는 인터럽트 Logical ID에 대한 허용요청 함수
커널이 드라이버에게 제공하는 함수

디바이스 드라이버 => 커널 InterrputInitialize()=> OAL의 OEMInterruptEnable()

OEMInterruptDisable()
해당하는 인터럽트를 금지시키는 함수
다바이스 드라이버는 커널함수 InterruptDisable()을 호출하여 자신이 사용하는 인터럽트ID를
중지하려 할때, 커널이 이 사실을 OAL에게 알려주는 용도로 사용된다.

디바이스 드라이버 => 커널 InterruptDisable() => OAL의 OEMInterruptDisable()

OEMInterruptDone()
해당하는 인터럽트의 재개를 허용해달라는 의미
디바이스 드라이버는 자신이 인터럽트를 모두 처리한 뒤 인터럽트의 재개를 부탁해야 하는데,
이때 사용하는 커널함수가 InterruptDone()이다. 커널은 이 함수가 호출되었을때, OAL의
OEMInterruptDone()를 호출하여 해당하는 인터럽트의 재개를 부탁하게 된다.

디바이스 드라이버 => 커널 InterruptDone() => OAL의 OEMInterruptDone()

OEMIoControl()
응용프로그램이나 디바이스 드라이버는 커널함수 KernelIoControl()사용해서 IO컨트롤 코드를 커널에게
보내게 되는데, 이때 커널은 커널 자신이 처리해야 하는 IO컨트롤 코드를 제외한 나머지 IO컨트롤 코드를
OAL의 OEMIoControl()함수로 보내어 처리를 의뢰하게 된다.

IO컨트롤 코드를 정의할때, 주의할 점은 매크로의 2번째 파라미터인 Function값이 반드시
0x800에서 0xFFF사이어야 한다는 것이다.

디바이스 드라이버 => 커널 KernelIoControl()=>OAL의 OEMIoControl()

커널 디버깅을 하기 위해서는 KITL(Kernel Independent Transport Layer)환경을 구축해야 한다.
KITL은 플랫폼 디버그 포트를 다양한 목적으로 서비스될 수 있도록 지원하기 위해서 커널이 구축한
특별한 환경이다.

디바이스 드라이버란 하드웨어를 구동하는 소프트웨어로서 최종 사용자에게 서비스를 제공하는
목적을 가진 모듈을 의미
디바이스 드라이버는 응용프로그램과 달리 항상 누군가에게 호출되어 동작하는 특성을 가지고 있다.

스트림 인터페이스 드라이버를 취하고 있는 드라이버의 종류는 다음과 같다.
시리얼 드라이버, 디스크 드라이버, 오디오 드라업, 패러럴 드라이버,USB호스트 컨트롤러,NDIS.dll(네트워크 관리 드라이버)등. 그 밖에 대부분 개발자가 개발 방법으로 선택하는 대부분의 디바이스 드라이버들이 여기에 속한다. 스트림 인터페이스 드라이버 모델을 취하는 드라이버는 DEVICE.exe 프로세스의 DLL형식으로 동작하게 되며, 그렇기 때문에
항상 이들 드라이버는 DEVICE.exe 프로세스의 문맥 아래에서만 동작


버스 인터페이스 드라이버는 WinCE가 지원하는 특정 버스에 대한 서비스 드라이버들을 들수 있다. 클라이언트 드라이버들에게 서비스를 제공하는 역할을 한다. DEVICE.exe 문맥 아래에서
동작한다. 스트림과는 단지 같은 프로세스 문맥 아래에서 동작하는 공통점을 가질뿐
REGENUM.dll(Legacy BUS), PCI.dll(PCI BUS), USBD.dll(USB BUS), PCMCIA.dll(PCMCIA BUS)등이 있다.

네이티브 인터페이스 드라이버란 드라이버들이 저마다 자신에게 가장 적합한 드라이버 인터페이스를 갖고 있는 드라이버를 의미한다. 네이티브 인터페이스 드라이버는 GWES.exe 프로세스 아래에서 동작하는 드라이버이다. 이들은 DLL 형식으로 작성되어 동작하는 드라이버들과, LIB 형식으로 작성되어 있어서 프로세스(GWES.exe)가 생성될 당시에 같이 링크되는 정적링크 형식을 취하는 드라이버들이다.


PDD(Platform Dependent Driver)
디바이스 드라이버를 개발할 때 응용프로그램과 대화하는 부분에서 다른 소스의 도움을 받고
자신은 이 소스로부터 호출되는 간단한 작업들만 수행하는 드라이버를 의미

DDI(Device Driver Interface)
디바이스 드라이버가 응용프로그램과 대화하는 방법

미니포트 드라이버
부수적으로 프랫폼을 직접 다루는 부분을 지원하는 PDD

MDD(Model Device Driver)
PDD를 사용하는 외부소스나 라이브러리

DDSI(Device Driver Service Provider Interface)
PDD와 MDD와 링크되는 부분

Layered Driver(계층드라이버)
MDD와 PDD형식으로 드라이버를 개발하는 경우

미니포트 드라이버
계층드라이버(MDD, PDD)형식과 의미는 같으나, MDD가 소스나 라이브러리 형태가 아닌 정형화된 드라이버 파일형태(DLL)로 되어 있으며, 이들 MDD DLL은 디바이스 드라이버로서의 DDI를 지원하고, 개발자는 이들 MDD DLL이 직접 로딩하여 다루게 되는 PDD DLL을 만들게 된다.

스트림 드라이버의 조건
1. 디바이스 드라이버로서 가져야 할 접두어 세글자를 정해야 한다.
2. DLL형식으로 작성되야 하며, DDI 함수들(XXX_open,XXX_Read)을 구현해야 한다.
3. 구현된 DLL함수들 중 DDI로 사용되는함수들은 모두 익스포트돼야 한다(DEF 파일사용)
4. 디바이스 드라이버로서 등록되기 위한 적절한 시스템 레지스트리를 가져야 한다.
5. 다바이스 드라이버가 “DEVICE.exe” 프로세스 아래에서 동작하는 것을 유념해야 한다.


사용자 혼란을 줄이기 위해 접두어 세글자를 제공하는 것과 동시에 자신이 어떤 드라이버인지를 소개하는 인터페이스 GUID를 시스템 레지스트리에 같이 등록하는 것이 좋다.

불가피하게 C++ 형식의 DLL로 만드는 경우라면, 이 함수명들은 모두 extern “C”형식으로 정의해서 C++ 맹글링 현상을 피해야 한다.

XXX_Init
DEVICE.exe(장치관리자) 프로세스 공간으로 스트림 인터페이스 드라이버가 등록될 때 호출하는 함수

스트림 인터페이스 드라이버를 등록시킬 때 사용하는 3가지 방법
1. RegisterDevice() 함수 사용
특별히 시스템 레지스트리를 준비하지 않는 상태에서 손쉽게 드라이버를 스트림 인터페이스 드라이버로 등록할 때 사용하는 함수. Dll 드라이버내에 스트림 인터페이스를 위한 함수들이 존재해야 함
2. ActivateDevice() 함수 사용
시스템 레지스트리를 준비한 상태에서만 사용이 가능한 스트림 인터페이스 드라이버 등록함수
3. ActivateDeviceEX() 함수 사용
다양한 변수들을 Active 키 아래에 추가적으로 등록하는 방법을 제공하기 위해 지원되는 함수

XXX_Deinit
등록해제시 호출되어지는 드라이버함수

RegisterDevice() 함수를 사용해 등록한 드라이버는 DeregisterDevice()함수를 사용해 등록해제하게 되며, ActivateDevice(), ActivateDeviceEX() 함수를 사용해 등록한 드라이버는
DeactivateDevice() 함수에 의해 등록해제 된다.

XXX_PowerUp
시스템의 공급되는 파워가 낮은 레벨에서 높은 레벨로 변화를 시도하게 되면, 커널은 디바이스 드라이버들이 이 사실을 인지하도록 지원하기 위한 함수

XXX_PowerDown
시스템의 공급되는 파워가 높은 레벨에서 낮은 레벨로 변화를 시도하게 되면, 커널은 디바이스 드라이버들이 이사실을 인지하도록 지원한다.

XXX_IOControl
응용프로그램과 통신하는 목적으로 사용

IOCTL_POWER_CAPABILITIES
드라이버가 등록되는 과정에서 호출되며, 드라이버가 원하는 전원관리 정보를 받는데 사용

응용프로그램과 통신하는 함수
XXX_Open
응용프로그램은 Win32API인 CreatFile() 함수를 사용해 드라이버에 접근할수 있는 권한을 얻게 되는데, CreateFile() 함수는 적절한 디바이스 드라이버의 XXX_Open()을 호출해 드라이버의 동의를 구하게 된다.

XXX_Read
응용프로그램은 Win32 API인 ReadFile() 함수를 사용해 드라이버로부터 일정량의 데이터를 읽어 올 수 있다. 이때 사용하는 파일 핸들은 반드시 이전에 CreatFile()을 통해 얻은 파일핸들을 사용해야 한다.

XXX_Wirte
응용프로그램은 Win32 API인 WriteFile() 함수를 사용해 드라이버로 일정양의 데이터를 기록하는 요청을 보낼수 있다.

XXX_IOControl
응용프로그램은 Win32 API인 DeviceIoControl() 함수를 사용해 응용프로그램이 2개의 버퍼를 제공함으로써, 하나는 응용프로그램 측에서 드라이버로, 또다른 하나는 드라이버 측에서 응용프로그램으로 데이터를 전달하도록, 즉 양방향으로 사용되는 버퍼를 하나의 DeviceIoControl() 함수를 이용해 사용할수 있다.

XXX_Seek
응용프로그램은 Win32 API인 SetFilePointer() 함수를 사용해, 읽기 혹은 쓰기 작업을 하는 시작 위치를 정의 할수 있다.

XXX_Close
응용프로그램인 Win32 API인 CloseHandle() 함수를 이용해, 사용하던 권한을 반납한다.


스트림 인터페이스 드라이버는 장치관리자(DEVICE.exe) 프로세스 아래에서 동작하는 DLL형식을 갖는 모듈이다. 이들은 장치관리자 프로세스 아래에서 DLL로 동작하는 성질을 가짐과 동시에 자기 자신을 디바이스 드라이버로 동작하도록 등록되어야한다.
필수요건 3가지
1. 스트림 인터페이스를 지원하기 위한 함수들을 가져야한다.(XXX_Init, XXX_Open등)
2. 적당한 시스템 레지스트리에 등록되어 있어서 ActivateDevice()되거나 아니면 누군가에 의해서 RegisterDevice() 되어야 한다.
3. 사용되는 XXX_Init, XXX_Open 등의 함수를 DLL 외부에서 쉽게 찾을수 있도록 각 함수들을
DLL 익스포트 시켜야 하며, 보통은 DEF파일이 사용된다.


실제로 디바이스 드라이버가 바로 호출될 당시에는 커널에 의해 디바이스 드라이버를 호출한 응용프로그램을 접근할 수 있는 권한이 디바이스 드라이버 코드에게 할당된다. 그렇기 때문에 드라이버는 호출한 슬롯상의 응용프로그램 버퍼 주수에 대한 매핑(MapPtrToProcess)후 사용

MapPtrToProcess()
접근하는 주소를 구하는 함수

네이티브 인터페이스 드라이버
네이티브 인터페이스라는 이름에서 이름에서 알수 있듯이, 네이티브 인터페이스를 지향하는 드라이버 작성방법이 모두 동일하지는 않다. 이들은 모두 GWES.exe 프로세스 문맥아래에서 동작하며, 부팅과정을 통해서 메모리에 상주한다.

GWES 문맥 아래에서 동작하는 드라이버에서 하드웨어 접근을 위한 코드를 갖는 방식은 크게
2가지로 나뉜다.
1. 직접 버스에 접근하는 방식
2. DEVICE.exe문맥 아래에서 동작하는 스트림 인터페이스 DDI를 사용하는 클라이언트 드라이버를 호출하는 방식

하드웨어로부터 발생하는 인터럽트는 OAL(OEM Adaptation Layer)에 의해서 적절한 Logical Interrupt ID로 변환되어 커널에게 보고 되는데, 이렇게 보고되는 Logical Interrupt ID에 의해 디바이스 드라이버 상에서 동작하고 있는 인터럽트 서비스 스레드에게 알려진다.

GWES : Graphic Windowing Event Subsystem

디바이스 드라이버는 크게 두가지 방향의 인터페이스를 구현한다. 하나는 응용프로그램으로부터 연결되는 Upper Edge이며, 또 다른 하나는 하드웨어나 버스 인터페이스를 사용하는 Lower Edge이다. 이 중 Upper Edge에 해당하는 부분이 사실상 스트림 혹은 네이티브라는 의미를 갖게 된다. 개발자가 만들 드라이버 소스를 실제로 열어 봤을 때, 본인이 Upper Edge와 Lower Edge모두를 구현하는 경우를 모노리딕(Monolithic Driver)라고 부르며, 그렇지 않고 Upper Edge나 Lower Edge중 하나만을 구현한 경우를 계층 드라이버(Layered Driver)라고 부른다.


마이크로소프트 플랫폼 빌더는 개발자들이 드라이버를 개발하는 데 도움을 주고자 Upper Edge에 해당하는 부분을 제공하는데, 이것을 MDD(Model Device Driver)라고 부른다. 반면 이런 MDD를 사용하는 경우에 개발자가 당당하는 Lower Edge를 PDD(Platform Dependent Driver)라고 부른다. “Platform Dependent”이라는 말 그래도 하드웨어 종속적인 코드만을 구현한다는 의미를 가진다. 이렇게 MDD와 PDD형식을 갖는 계층 드라이버 작성이 있어서 스트림이나 네이티브라는 용어 대신에 MDD와 PDD간의 호출규약이 필요하게 되는데, 이것을 DDSI(Device Driver Service Provider Interface)라고 한다.

미니포트 드라이버는 서로 다른 바이너리 파일 형태를 가진 복수 개의 드라이버들이 어우러져 있는 상태이다.

하드웨어 인터럽트 서비스 스레드 구현방법
모든 종류의 하드웨어 인터럽트는 커널이 가장 먼저 이를 수신하여 OAL의 도움을 받아서 실제로 디바이스 드라이버에게 전달하기 때문이다.

디바이스 드라이버의 IST(Interrupt Service Thread)는 다른 스레드와는 달리 비교적 높은우선순위에서 체류하기 때문에, 대부분 자신에게 할당된 퀀텀 시간을 sleep상태 (WaitForSingleObject)로 설정해둬야 한다. 그러다가 하드웨어 인터럽트를 다를 때만 잠깐 깨어나며, 인터럽트를 모두 다른 뒤에는 다시 Sleep상태로 전화해야 한다.


하드웨어 인터럽트 처리과정

1. IST는 자신이 사용할 하드웨어 인터럽트를 명시하는 Interrupt Logical IDfmf 정한다. 또한 자신이 사용할 Event를 준비한다. 이렇게 ID와 Event를 준비한 다음, 두가지 정보를 커널함수
InterruptInitialize()을 통해서 커널에게 전달

2.커널은 해당하는 인터럽트 ID가 유효한 ID인지를 확인하기 위해서, OAL의 OEMInterruptEnable()함수를 호출한다.

3. 이렇게 호출된 OAL의 OEMInterruptEnable()은 자신이 받은 Logical ID의 유효성을 확인한뒤, 해당하는 하드웨어 인터럽트가 발생 가능하도록 조치한 다음돌아간다. 이제 IST는 대부분의 시간을 WaitForSingleObject(Event) 함수를 사용하여 Event를 기다리게 된다.하드웨어로부터 인터럽트 신호가 발생하면, 이처리는 가장 먼저 커널이 담당하게 된다.

4.커널은 발생한 하드웨어 인터럽트의 Logical ID를 확인ㅇ하기 위해서 OEM의 ISR(Interrupt Service Routine)을 호출한다.ㄴ

5.이때 호출되는 OEMInterruptHandler()함수는 ARM계열의 CPU를 사용하는 플랫폼에서 사용되는 OSL의 ISR함수이름이다. 호출된 OEMInterruptHandler()는 해당하는 하드웨어 인터럽트를 금지시킨뒤 적절한 ID커널에게 리턴한다. 그러면 커널은 리턴된 ID를 사용하여, 관련된 Event를 시그널시킨다.

6. 디바이스 드라이버는 오랜 시간 Sleep 상태에서 머물다가 깨어난 뒤 하드웨어를 접근하여 원하는 데이터를 수신하거나 송신하게 된다. 이렇게 디바이스드라이버가 실제로 인터럽트에 대한 조치를 한다는 것을 유념해야 한다. OAL이나 커널은 인터럽트 허용 및 금지와 관련된 조치만 취한다. 디바이스 드라이버는 적당한 시기에 해당하는 인터럽트 처리 종료 사실을 커널함수 InterruptDone()을 사용해서 알린다.

7.커널은 OAL의 OEMInterruptDone()를 호출하여 해당하는 인터럽트 처리 종료 사실을 OAL에게 알린다. 해당함수는 인터럽트의 금지상태를 해제하게 된다.


저마다의 IST가 자신이 깨어날 조건을 커널에게 알리기 위해서 등록하는 서비스루틴을 Installable ISR이라고 부른다. Installable ISR이 하는 일은 같은 종류의 하드웨어 인터럽트가 공유되는 경우에 실제 인터럽트를 요청한 장치를 찾아서 이것과 관련된 서로 구분된 Interrupt Logical ID를 커널에게 리턴하는 것이 그목적이다.


C 함수는 스택(stack)과 힙(Heap)이 없으면 사용이 불가능하기 때문에 어셈블리 언어로 이 작업들을 완료한 이후에 C언어로 넘어가 작업을 한다.

메모리 사용을 위한 정보를 바꾸기 위해서는 g_oalAddressTable만을 수정해 사용
해당테이블은 oemaddrtab_cfg.inc 파일에 명기되어 있음

EBOOT
부트로더의 목적은 실행이미지를 메모리에 위치시키고, 운영체제를 구동할수 있도록 점프하는 기능을 가지고 있다.
OEM 코드부분에는 시스템의 초기화 부분과 각각의 하드웨어에 대한 콘트롤 함수들이 위치하게 된다.

코드를 분석하는데 있어서 중요한 점은 시작점을 찾아내는 것이다.
실제 시작점은 Sources파일의 상단에 있는 EXEENTRY=StartUP 부분

리셋핸들러의 내용
1. I/D TLB 클리어/캐시 사용중지
2. 위치독 타이머 사용중지
인터럽트 사용중지
클럭 설정
메모리 컨트롤러 초기화
부트로더를 메모리로 복사
3. MMU설정(물리지소를 가상주소로 설정)
4. 스택 포인터 초기화
5. C의 main()함수로 점프

EBOOT의 수행내용은 BootloaderMain()함수에 모두 존재

BootloaderMain() 함수안에 있는 EdbgOutputDebugString 명령에 의해서 디버그 포트로
출력되는 메시지

OEMDebugInit() 함수에서 디버그 포트를 초기화

OEMPlatformInit() 함수에서는 사용하는 플랫폼에 대한초기화 작업을 수행

EBOOT 디렉토리의 boot.bib의 파일에 의해서 EBOOT이미지가 생성

ROM 이미지를 빌드하기 위해서는 ROM 이미지를 만들어내는 툴인 Romimage.exe파일을 사용
이것은 또한 Makeimg.exe라고도 부르는데 .bib 파일에 의해서 메모리에 적재되는 위치가 결정

OAL이란 OEM Adaptation Layer의 약자로 Windows CE의 커널과 하드웨어 사이에서 상호 간에 정보를 교환해 주는 창구역하를 하는것이다. 그렇기 때문에 BSP는 이와 같은 OAL 함수로 대부분이 구성된다.

OAL을 손쉽게 작성하려면 다음의 기본절차를 따르게 된다.
1. OAL을 작성하기 위해서는 BSP안에 특별한 디렉토리를 만든다.
PLATFROM\[BSP이름]\KERNEL\OAL
Dirs 파일에 새로 생성한 디렉토리 이름을 추가한다.
2. 기본적인 OAL함수를 작성한다.
Startup 관련함수
디버그 포트초기화(Debug Port Initialize) 관련함수
시스템 타이머(System Timer) 관련함수
인터럽트 처리함수
3. 추가적인 OAL 함수를 작성한다.
RTC(Real Time Clock)
타이머
확장 메모리

ARM CPU에 대한 초기화 작업은 다음과 같은 일을 한다.
SVC(Supervisor) 모드로 변경
FIQ와 IRQ를 사용하지 못하도록 설정
MMU와 I/D 캐시를 사용하지 못하도록 설정
TLB(Translation Look-aside Buffer)를 지우고 WB(Write Buffer)를 지움
각종 디바이스들의 초기화
메모리 컨트롤러 초기화
인터럽트 컨트로러 초기화
클럭 설정
OEMAddressTable의 물리주소에 대한 기준 주소를 R0 레지스터에 저장
KernelStart로 분기

ARM CPU에 대한 초기화 작업은 시스템이 동작하게끔 하기 위한 일련의 코드들이 들어간다.

커널에 대한 초기화
첫번째 페이지 테이블 초기화
MMU와 캐시를 사용하도록 설정
동작모드 별 스택 초기화
커널이 사용하는 글로벌 데이터 초기화
디버깅 관련 함수를 사용하도록 설정
OEMInit() 함수를 호출
메모리 초기화
기타 초기화

디버그 포트에 관련된 함수
OEMInitDebugSerial()
동작속도, 패리티 비트, 정지비트에 대한 설정
OEMReadDebugByte()
디버그용 포트로부터 한 바이트씩 입력
OEMWriteDebugByte()
디버그 포트로 한 바이트씩 출력
OEMWriteDebugString()
디버그 포트로 문자열을 출력

OEMInit() 함수에서는 펌웨어로 초기화하는 과정이다.
타겟 시스템의 모든 하드웨어에 대한 초기화, KITL 초기화, 커널이 사용하는
전역변수(Global Variable)의 초기화 작업이 수행

인터럽트 처리에 쓰여지는 함수
OEMInterruptEnable()
하드웨어적으로 인터럽트를 사용하도록 설정함
OEMInterruptDisable()
하드웨어적으로 인터럽트를 사용하지 못하도록 설정함
OEMInterruptDone()
인터럽트 처리가 완료된 이후에 다시 인터럽트를 사용하도록 설정함

OALTimerInit 함수
이 함수는 시스템 타이머를 설정하기 위한 함수. 시스템 타이머는
인터럽트 서비스 루틴(ISR, Interrupt Service Routine)을 이용해 인터럽트 등록을
시켜서 사용한다.

WinCE에서는 두가지 과정을 통해서 인터럽트가 처리된다.
그 두가지는 ISR로 불리는 인터럽트 서비스 루틴(Interrupt Service Routine)과 IST로
불리는 인터럽트 서비스 스레드(Interrupt Service Thread)이다. ISR은 복수개의 인터럽트 요청에 대응한다. 인터럽트가 사용 가능한 상태에서 인터럽트를 사용하기 위해서는 ISR에 인터럽트를 등록해야만 사용이 가능하다. 외부에서 인터럽트가 요청이 들어오면 ISR은 해당 인터럽트를 식별하여 어떤 인터럽트인지를 알려준다. 이것이 바로 SYSINTR로 시작되는 인터럽트 ID이다.
커널은 인터럽트 ID를 가지고 해당하는 IST를 수행하게 되는것이다.


인터럽트를 처리를 위해서 해당하는 디바이스 드라이버가 로딩된 이후에 초기화 단계에서 인터럽트를 초기화하는 작업을 수행해야 한다. 이경우에 CreatThread()함수를 이욯하게된다. 이함수는 실행시킬 스레드 함수의 주소를 설정한다. 즉, 해당 스레드의 ID가 발생하는 경우에 실행될 스레드 처리 함수의 주소를 설정한다는 것이다.

인터럽트 초기화단계

1. CreateThread()
2. CreateEvent()
3. KernelloControl()
4. InterruptInitialize()

위와 같은 인터럽트가 초기화 되면, 스레드가 수행되며 인터럽트가 발생되기를 기다리게 되는데, 인터럽트 처리를 위해서 WaitForSingleObject()와 InterruptDone() 함수가 사용된다.