플랫폼 빌더 : 마이크로소프트 사에서 제공하는 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() 함수가 사용된다.
댓글 없음:
댓글 쓰기