강좌 & 팁
오랫만에 포럼에 글을 올립니다.
최근에 UEFI 에 관련 일들을 진행하고 있는데 UEFI 오픈 소스로는 tianocore 의 EDKII 가 대표적이죠
이곳에서 FAQ 중 PI와 관련된 것이 있어서 번역 해서 올립니다.
번역은 원문 그대로 보다는 조금 의역한 부분들이 있습니다.
발로 번역한 거라 내용중 틀릴 수도 있는데 그런 부분은 꼭! 지적해 주세요.
번역된 내용을 나중에 한글 FAQ 를 해당 사이트에 올려 오픈 소스 하시는 분들에게 도움이 되고 싶습니다.
번역 원문은 http://tianocore.sourceforge.net/wiki/UEFI/PI_FAQ 입니다.
끝으로 이 번역을 도와 주신 미지님께 감사 드립니다.
### 들어 가기
UEFI는 이전 BIOS 와 차별화된 놀라운 변화를 이루었다.
이전 BIOS가 어셈블러로 작성된 것과 달리 "C" 언어로 쓰여진 것이
혁신적으로 보이는 이유중 하나일 것이다.
또한 UEFI는 UEFI 구조만 이해한다면 기존 BIOS 를 이해하는 것보다
동일한 일을 어떻게 수행하는지 더 알기 쉽다.
UEFI 가 구현되는 과정 대부분은 단순히 프로그램 코드 구현이 아니라
소프트웨어적인 디자인 구조의 구현과정으로 이루어진다.
먼저 유념해야 할 두 가지가 있다.
* UEFI/PI 는 CSM( Compatibility Support Module)을 통하여
이전 바이오스를 지원한다.
* 원래 UEFI는 UEFI 옵션 롬과 UEFI 드라이버 인터페이스를 지원하는 구조로
이전 bios의 상단층에 구축되었다.
### 멀티 프로세서를 지원하는가?
지금은 인텔사의 아이테니엄 프로세서 계열과
인텔 X86 계열인 IA32 와 X64 에 대해서만 지원한다.
인텔 이외에 ARM 계열의 프로세서도 일부 지원한다.
### BIOS 시장에서 UEFI 플랫폼의 채용율은 얼마나 되는가?
현재는 50% 이상이고, 2010년 즈음에는 대략 70% 이상일 것으로 예상하고 있다.
### SCT는 (Self Certification Tests) 확장 시킬 수 있는가?
확장 시킬 수 있다.
SCT를 확장하기 위해서 SCT에 테스트 케이스를 추가하는 방법은 UEFI SCT 유저 가이드 섹션(5.3)에 설명되어 있다.
공식적인 SCT 릴리스 버전은 http://uefi.org에서 다운로드 할 수 있다.
### 호출규약(프로토콜)은 누가 정의하는가?
개발자들에게 도움이 될만한 다양한 호출규약(프로토콜)은 UEFI와 PI 설명서에 정의되어 있다.
여러분이 드라이버를 제작할 때, 작성된 드라이버가 정의하고 있는 또 다른 호출규약(프로토콜)이 있을 것이다.
이렇게 만들어진 호출규약(프로토콜)은 UEFI나 PI 규격으로 정의되고 필요한 시점에 이렇게 정의된 것 중
적당한 인터페이스 함수를 호출한다.
### 부트와 런타임 서비스간에 어떤 관련이 있는가?
부트 서비스는 ExitBootServices() 함수가 호출되기 전까지만 실행할 수 있다.
그에 반해서 런타임 서비스는 부팅 중에도, ExitBootServiecs() 함수 호출 후에도 실행이 가능하다.
런타임 서비스는 프리 부팅 상태가 끝난 후에도 OS에 추가적인 처리가 가능하도록 하기 위한 것이다.
이미 구축이 끝난 SMM 스페이스에서 SMM 코드를 제거하는 것은 불가능하므로 인텔 프로세서인 경우
SMM 코드는 런타임 코드에 대한 고려를 해야 한다.
이런 이유로 SMM 코드는 ExitBootServices()함수 호출 후에도 남아 있어야 한다.
### SMM 모드에서 부트와 런타임 서비스는?
SMM 런타임 서비스는 DXE와 기본적인 모양은 비슷하지만
SMM 라이브러리에 SMM 코드만 포함하는 점이 다르다.
구축된 SMM 공간에서 SMM 코드를 제거하는 것은 불가능하기 때문에
인텔 프로세서 일 경우에는 SMM 코드에 대한 런타임 코드를 고려해야 한다.
이것이 ExitBootServices()함수 호출 후에도 SMM 코드가 남아 있어야 하는 이유다.
### Add-in 카드의 경우 EBC(EFI Byte Code)에 예전 이미지를 지원해야 하는데 이럴 때 필요한 변환 도구는 무엇인가?
UEFI의 변경 대상이 되는 드라이버에 기존 옵션 ROM 소스나 바이너리 변환을 처리하기 위해서 지원하는 도구는 없다.
변경 대상인 UEFI 드라이버을 설계하고 구현한 이후에 EBC를 위한 크로스 컴파일을 처리 할 수 있다.
UEFI 드라이버 제작자는 "C" 를 사용하여 UEFI 드라이버를 구현하기 위해서는 반드시 EBC 컴파일러뿐 아니라 네이티브
컴파일러의 호환성도 고려해야 한다.
http://developer.intel.com/technology/efi/dg.htm 에 쓰여져 있는 19장의 EFI 드라이버 제작 가이드는
EBC 컴파일러를 사용할 때의 포팅 규칙을 기술한다.
### Power-on 단계에서 OS 부팅 단계까지 진행되는 흐름을 알려줄 수 있는가?
PI에 규정된 UEFI/PI 펌웨어 각각은 다음 단계를 통과한다.
* Sec - 보안 단계 - 임시 메모리 셋업
* PEI – Pre-EFI – 메모리 초기화
* DXE – Driver Execution(드라이버 실행) - UEFI/DXE 드라이버 디스패치 리스트
* BDS – Boot Device Selection(부트 디바이스 선택) – 셋업 실행
* TSL- Transient System Load(임시 시스템 로드) - EFI Shell 수행
* OS 런타임 부트 - OS 로더 실행
### PI는 무엇인가? 이전 BIOS 와 같은 것인가?
아니다, PI 는 플랫폼 초기화를 의미한다.
UEFI 규격 중 Intel® Platform Innovation Firmware 파트가 PI(Platform Initialization) 규정으로 확장 되었다.
PI는 프로토콜과 서비스 관련 UEFI 규정을 포함하는 부트 실행 단계를 말한다.
PI는 서비스를 정의하는 UEFI가 있고, PI 서비스가 있다.
### 이 서비스 중에 중복되는 서비스는 어떤것이 있는가?
UEFI 서비스는 PI 서비스 파트 전체로, PI 서비스는 서비스의 수퍼 셋이다.
또한 메모리 부족으로 PEI가 실행될수 없는 이후의 PEI 단계에서 수행되는 PEI 서비스들이 있다.
### 이벤트란?
UFEI 이벤트는 UEFI 모듈간에 커뮤니케이션을 제공하기 위해 사용하는 매커니즘이다.
타이머 이벤트는 비동기적이고 그외 다른 모든 이벤트 타입은 동기적이다.
UEFI 서비스는 UEFI 이벤트를 관리한다.
UEFI 이벤트는 생성되거나 소멸될 수 있다.
이벤트 상태는 대기 상태나 시그널 상태 중 하나가 될 수 있다.
최종적으로 생성되어 수행되는 UEFI 이미지는 아래와 같은 것을 할 수 있다 :
* 이벤트 생성
* 이벤트 소멸
* 시그널 상태에서 이벤트가 있는가를 체크한다.
* 시그널 상태에서 이벤트를 기다린다.
* 이벤트가 시그널 상태에서 시그널 상태로 옮겨지도록 요청한다.
### 이벤트 사이에서 우선순위는?
모든 이벤트는 태스크 우선 순위 레벨(TPL- Task Priority Level)이 있다.
TPL 레벨은 :
* TPL_APPLICATION
* TPL_CALLBACK
* TPL_NOTIFY
* TPL_HIGH_LEVEL
### 인터럽트가 아닌 (INTS) HW 시그널은 어떻게 다루는가?
인터럽트 대신 UEFI는 폴링 방식을 사용하여 드라이버를 지원한다.
UEFI 드라이버가 주기적으로 디바이스를 폴링하기 위해 이벤트를 사용하는 주된 방법은 타이머 이벤트이다.
따라서 대부분의 디바이스 I/O처리는 폴링 방식으로 이루어진다.
### UEFI는 인터럽트 경로 탐색과 APIC(Advanced Programmable Interrupt Controller) 관련 프로그램을 하는가?
기존 OS로 부팅하기 위해서 UEFI 플랫폼에 해당하는 것들이 주로 프로그램 된다.
이와 관련된 것들은 PEI와 DXE에서 볼 수 있다.
인터럽트 경로 탐색과 APIC 관련 처리는 나중에 수행되는 OS에서 CSM을 사용하여 핸드쉐이킹 한다.
플랫폼 레벨에서 처리되는 많은 것들이 ACPI 데이터 구조를 이용한다.
### UFEI는 사용자 관여없이 어떻게 부트 디바이스인 것을 인식하고, 열거하는가?
부팅 장치는 UEFI 부트 매니저가 결정한다.
UEFI 부트 메니저는 글로벌 NVRAM 변수에 기반하여 구성될 수 있는 펌웨어 부팅 정책 엔진이다.
보통 OEM에 의해서 설정된 첫 번째 부트 장치는 UEFI NVRAM 부트순서를 저장하는 변수에 저장되어 있다.
### C ++는 사용할 수 있는가?
사용할 수 없다,
왜냐하면 C++의 컴파일 결과가 너무 커지고 C++의 생성자와 소멸자를 UEFI 환경에서는 지원할 수 없다.
보통 C 언어를 이용해서 C++ 와 유사한 방식의 프로그램 구조를 만들어 사용한다.
위와 같은 이유로 C++를 지원하지 않지만, C++ 의 new 키워드를 사용하지 않아 전역 객체가 사용되지 않는다면
C++를 사용할 수 있다.
### 이빅션 (NEM)모드는 왜 작동하지 않는가?
Intel X86 프로세서 경우에는 SEC 초기 단계에서 캐쉬가 아닌 4G 이하의 메모리에 스택을 설정하기 위해서
MTRR을 셋업 한다.
그 이후에 프로세서는 "이빅션 모드가 아닌 상태로 설정되고 그 다음에 스택 포인터 (SP)를 이 메모리에 위치시킨다.
이것은 데이타 액세스를 위해 캐쉬를 사용할 수 있도록 하고, 해당 주소가 마치 RAM에 있는 것처럼 한다.
이때의 캐쉬는 "플러쉬된" (no eviction) 상태는 아니다.
RAM이 사용 가능해 진후 , 캐쉬에 있는 내용은 캐쉬에 연결된 물리적인 RAM 공간으로 보내질 수 있다.
최종적으로 CAR의 컨텍스트는 RAM 모드로 자연스럽게 전환된다.
### 인텔 아이테니엄® 프로세서 제품군 (IPF) 서버에서 PAL & SAL 컴포넌트로 설계된 로케이션 포인팅에 대한
테이블(펌웨어 인터페이스 테이블 FIT)은 유사한가?
인텔 아이테니엄® 프로세서 제품군 (IPF) 서버에서 FIT는 아키텍처적이다.
인텔 아이테니엄® 프로세서 제품군 (IPF) 서버에서 FIT 는 IPF의 public SDM(Secure Download Manager)에서
설명하고 있다.
PAL/SAL의 로케이션을 설명하고 있는데 NEM과는 관계가 없다.
### 멀티 펌웨어 볼륨일 경우(Firmware Volumes), 어떤 추가 코드를 작성해야 하는가?
기본적으로 제공되는 PI/PEI 코어는 멀티 FV를 다루기 위한 매카니즘을 이미 가지고 있다.
멀티 FV는 일반적인 플랫폼은 아니지만, FDF 파일을 이용하여 작성될 수 있다.
플랫폼에 있는 REIM은 추가된 FV 의 위치를 PEI 코어가 알수 있도록 선언하여야 한다.
일단 해당 정보를 PEI 코어에 알려주면 PEI 코어는 그것을 이용하여 PEIM를 디스패치할 수 있다.
부트 펌웨어 볼륨 BFV(Boot Firmware Volume)가 시작되었을때는 PEI 코어가 알고 있는 것은 FV 뿐이다.
BFV는 SEC, PEI 코어, 하나 이상의 PEIM를 포함한다.
### 리던던시를 구현하기 위하여 멀티 FV를 가진 서버가 있는가?
그렇다. 플랫폼에 따라 다른데 , 이런 서버는 리던던시에 대한 FV 사용 메커니즘 플랫폼 정책을 갖는 경우이다.
이러한 매커니즘은 PI 규정에서는 다루지 않는다.
### 메모리 크기에 어떤 제한이 있는가?
단지 64 비트 주소 공간에 대한 제한만 있다.
### TSEG는 어떻게 처리되고 있는가?
TSEG는 플랫폼 특징이고 관련 정보는 특정 HOB, EFI_SMRAM_HOB_DESCRIPTOR_BLOCK에서 처리된다.
### 타이머는 APIC 와 관련이 없거나 CPU 아키텍쳐에 따른 구현에 의존하는가?
타이머 메쏘드는 구현 방식에 의존적이지만 인텔 아키텍쳐인 경우에는 8254 타이머 API 를 모델로 하고 있다.
### 모든 이벤트들은 글로벌 타임인가?
그렇다.
### PI Vol. 2 Section 10.11 DXE Dispatcher State Machine 에서, SOR 은 무엇이고 무슨 일을 하는가?
SOR 은 Schedule On Request 의 약자이다.
DXE 드라이버 표현식에 SOR 수행코드가 있으면, DXE 드라이버는 "요청받지 않는" 상태가 된다.
DXE 드라이버 표현식에 SOR 수행코드가 없으면, DXE 드라이버는 "의존적인" 상태가 된다.
SOR이 있으면, 다른 드라이버가 드라이버의 실행을 확실히 요구할 때까지 모듈은 실행되지 않을 것이다.
모듈은 DXE 서비스가 Schedule()함수를 호출할때 수행된다.
자세한 내용은 PI 1.2 DXE CIC 섹션 7.3 을 볼 것.
### NMI는 NMI의 원래 처리 방식과 동일하게 처리되는가?
플랫폼에 맵핑된 상태에 따라 다르다.
PC 환경에서는, NMI는 프로세서의 표준 인터럽트 중 하나이다.
PC 하드웨어에서는 칩셋를 제어하여 NMI 소스를 디저블 시킬 수 있다.
("마스크 불가능 인터럽트"는 너무 많다.)
이건 기존 SMI 시스템 에서 사용되던 non-Maskable 인터럽트를 다루는 방식을 펌웨어에서 사용하기 위한 것이다.
### DXE는 추가적인 SMI 핸들러를 나중에 등록할 수 있는가?
DXE 단계 처리중에 SMM 코어는 SMM 드라이버를 디스패치 한다.
그러므로 추가적인 SMI 핸들러는 DXE 단계에서 등록될 수 있다.
DXE 단계 후반에서, SMM 드라이버가 더 이상 디스패치될 수 없으면, SMRAM은 락 다운 될 것이다 (권고 사항).
일단 SMRAM이 락 다운되면, 부가적인 SMM 드리이버는 디스패치되기 어려워지므로,
추가적인 핸들러를 등록할수 없게 된다.
예를 들면, SMI 핸들러를 등록한 SMM 드라이버는 EFI 쉘로에서 로드 될 수 없거나 UEFI 부트 매니저의 드라이버
옵션처리로 추가될 수 없다.
### 부트 옵션은 PI 스펙에 있는가?
PI 스펙에 있지 않고 UEFI 스펙에 있다.
### 실제 플렛폼에서 플래시가 구성된 예를 알려 줄수 있나?
물론, 다음은 예이다.
1. FV 복구
2. Ftw 예비 공간
3. Ftw 작업 공간
4. 이벤트 로그
5. 마이크로코드
6. 가변 영역
7. FV 메인
### 플래시 디바이스 FD 의 계층구조는 어떻게 되어 있고 펌웨어 볼륨 FV, 펌웨어 파일 시스템 FFD, EFI 파일은 무엇인가?
플래시 디바이스 FD 의 계층 구조는 다음과 같다.
플래시 디바이스 FD -> FV -> FFS -> EFI 파일들.
멀티 EFI 섹션은 0 개 이상의 EFI 섹션으로 구성된 펌웨어 파일(FFS)에 포함된다.
각 FFS 는 FFS 헤더와 데이터로 구성된다.
펌웨어 볼륨 FV 는 한개 이상의 FFS 파일로 구성된다.
플래쉬 디바이스는 한 개 이상의 FV 리스트로 구성된다.
### 플래시 구조에 대한 정의는 어디에 기술 하는가?
플랫폼에 대한 플래시 레이아웃은 FDF 파일에서 정의한다.
### BDS는 PI에서 규정하는가?
BDS 단계는 PI 스펙의 한 부분이고, 플랫폼 부트 정책을 구현하는 부분이다.
하지만, PI 설명서를 준수하는 BDS 단계 시스템 펌웨어는
UEFI 2.x 설명서의 부트 매니저 쳅터(쳅터 3)에 기술된 부트 정책을 기준으로 구현해야 한다.
### 죽음의 마이크로소프트 윈도우즈 블루 스크린은 어떤가?
현재 윈 7은 여전히 블루 스크린과 윈 7 설치를 위해 CSM을 요청한다.
이 부분은 마이크로소프트 윈7 sp2 에서 수정될 것으로 보인다.
### FV 혹은 펌웨어 볼륨은 어디에 포함되는가?
FV는 하나 이상의 플레시 디바이스 내부에 포함된다.
### EFI_DISK_IO_PROTOCOL 과 EFI_BLOCK_IO_PROETOCOL 간의 차이점은 무엇인가?
UEFI 부트 서비스 환경에서 디바이스를 관리하는 컨트롤러 타입이나 디바이스 타입에 대한
정확한 정보가 없어도 디바이스를 엑세스하는 코드가 수행 가능하도록
EFI_BLOCK_IO_PROTOCOL 은 대용량 스토로지 디바이스를 추상화 한다.
EFI 부트 서비스 환경에서 디바이스를 관리하고
대량 스토로지 디바이스로에서 블록 레벨로 읽고 쓰는 기능들을 정의한다.
반대로, 전통적인 오프셋-길이 프로토콜인 블록 I/O 프로토콜을 이용하는 블록 엑세스를 추상화 하기 위하여
EFI_DISK_IO_PROTOCOL 을 사용한다.
디스크 I/O 프로토콜이 없는 시스템에서 블록 I/O 인터페이스에 대한 EFI_DISK_IO_PROTOCOL을 추가하는 기능은
펌웨어에 있다.
파일 시스템과 다른 디스크 엑세스 코드는 디스크 I/O 프로토콜을 이용한다.
디스크 I/O 는 디스크에 바이트 레벨 엑세스를 제공한다.
### 왜 드라이버가 핸들 데이터베이스에 설치된 순서대로 처리되지 않는가?
부트 실행 단계에서 UEFI 펌웨어는 로드된 각 이미지에 대한 핸들을 정할 것이다.
설정이 바뀌면 동일한 드라이버에 다른 핸들 번호가 할당 될수 있다.
하지만, 매 부팅 시 변한게 없다면, 결과적으로 각 부팅은 동일한 부팅이다.
### UEFI 와 OS 는 각각 다른 수행 모드가 가능한가?
UEFI 와 OS 는 같은 모드이어야 한다. - 32 비트 또는 64 비트
### 다른 공식적인 포럼이 있는가?
있다. Sourceforge에 참가하고 EDK에 개발자로서 등록하라.
https://sourceforge.net/projects/edk2/develop 메일링 리스트(https://sourceforge.net/projects/edk2/develop)에
가입하세요.
UEFI 포럼(http://www.uefi.org) 에 참여하세요.
### FV / ROM 이미지의 구조를 볼수 있거나 팩키지하는 툴이 있는가?
EDK II는 새로운 툴을 제공한다.
PI 와 FFS에 대한 Firmware Volumes 스펙과 Firmware Volumes .9 스펙은 다르다.
EDK II는 PI 스펙에 있는 FV 와 FFS를 처리 할 수 있는 툴을 제공하고 있다.
이전 툴은 프레임워크 .9 규격서가 적용된 EDK I 에서만 사용할 수 있다.
Vollnfo 는 파일에 있는 펌웨어 볼륨에 관련된 정보를 보기 위해서 관련 정보를 출력하는 유틸리티이다.
Vollnfo 명령은 Basetools/Bin/Win32 에 있다.
### 컴포넌트에 서명하는 메카니즘이나,서명된 컴포넌트를 정의하는 툴이 있는가?
EDK II는 PI 규격서 encapsulation 섹션에 기반한 메카니즘을 가지고 있다.
FV 에 대한 encapsulation 섹션은 압축, 서명, 암호화에 대한 것들을 설명하고 있다.
EDK II에 대한 빌드 도구가 지원하는 것은 PI 1.2 스펙이다.
서명이 필요하다면 EDK II 빌드 툴은 서명된 섹션을 포함한 하나의 FFS를 처리할 것이다.
EDK II 예제 – Tiano 압축 방식과 LZA 압축 방식 – FDF 파일에 GUID가 있다.
새로운 encapsulation 타입에 대한 새 GUID를 정의할 수 있다.
Encode/Decode 오퍼레이션 플랫폼이 디코드할 필요가 있을 때 디코드를 실행하는 라이브러리가 있다.
### 어떻게 EFI에서 인터럽트 후킹 매카니즘을 처리하는가?
EFI에서 하드웨어 인터럽트는 없다. 타이머만 있다.
타이머 이벤트를 만들기 위해서 CreateEvent() 함수 부트 서비스를 이용하고,
그런 뒤에 이벤트 주기와 타입을 프로그램하기 위해 SetTime() 함수 부트 서비스를 호출한다.
CreateEvent() 함수를 사용할 때,원하는 통지 기능을 처리 하기 위한 컨텍스트 포인터와 수행하고자 하는 통지 기능을
지정할 수 있다.
