임베디드 시스템 개발 위한 BSP의 효과적 관리 방법























임베디드 프로세서를 갖춘 플랫폼 FPGA는 융통성과 통합성, 성능을 제공한다. 이제는 하나의 PLD 안에 정교하고 고도로 맞춤화 된 임베디드 시스템을 개발할 수 있게 되었다.
실리콘 능력이 발전함에 따라 해결과제는 설계 방법을 효율적이고 생성 있게 유지하는 데 집중되고 있다. 임베디드 시스템 개발분야의 주요 활동 가운데 하나는 BSP(board support package)의 개발이다. 이는 임베디드 소프트웨어 어플리케이션이 프로세서에 연결된 하드웨어 자원들을 초기화 하고 이들과 통신할 수 있도록 해준다. 전형적인 BSP 콤포넌트들 가운데는 부트 코드, 디바이스 드라이버 코드 및 초기화 코드가 포함되어 있다. BSP의 개발은 장황하고 지루한 프로세스가 될 수 있으며, 마이크로프로세서 콤플렉스(프로세서 더하기 관련 주변기기들)가 변경될 때마다 이루어지지 않으면 안 된다.
FPGA의 경우, 빠른 설계 반복과 플랫폼 고유의 융통성 덕분에 BSP 관리 작업이 한층 더 어려워질 수 있다. 이러한 상황은 BSP 관리를 위한 효율적인 프로세스를 제공해야 할 필요성과 중요성을 보여준다.
여기서는 RTOS BSP의개발 및 관리를 단순화 해주는 솔루션에 대해 살펴 보고자 한다. WindRiver VxWorks 흐름을 통해 이러한 개념을 설명하겠다.
Xilinx 프로세서를 위한 설계에는 하드웨어 플랫폼 어셈블리 흐름과 임베디드 소프트웨어 개발 흐름이 수반된다. 이 두 흐름 모두가 X P S ( X i l i n x Platform Studio) 툴 내에서 관리되는데, 이것은 Xilinx사의 EDK(embedded development kit)의 일부이다.
설계는 대개 프로세서와 여기에 연결되는 콤포넌트들을 XPS에서 어셈블링 하고 구성함으로써 시작된다. 일단 하드웨어 플랫폼을 정의하고 나면, 시스템의 소프트웨어 파라미터들을 구성할 수 있다. Platform Studio의 주요 피처 가운데 하나는 자신이 프로세서, 주변기기 및 임베디드 OS를 선택 및 구성한 내용을 토대로 맞춤화 된 BSP를 만들어낼 수 있는 능력이다.
Platform Studio는 PowerPC 405 프로세서 및 그 주변기기들을 위해 맞춤화 된 Tornado 2.0.x (VxWorks 5.4)나 Tornado 2.2.x
(VxWorks 5.5) BSP를 Xilinx Virtex-II Pro 및 Virtex-4 FPGA로 만들어 낼 수 있다. 생성된 BSP는 시스템에 필요한 모든 지원 소프트웨어를 포함하게 되는데, 여기에는 부트 코드, 디바이스 드라이버 및 VxWorks 초기화가 포함된다.
일단 PowerPC 405 프로세서를 갖춘 하드웨어 시스템을 Platform Studio에서 정의하고 나면, VxWorks를 위한 BSP를 생성하기 위해 다음 세 단계만 따르면 된다:
1. Software Settings 다이얼로그 박스를 사용하여 자신이 시스템에 사용하려는 OS를 선택한다.
2. 일단 OS를 선택하고 나면, Library/OS Parameters 탭으로 가서 Tornado BSP를 맞춤형 하드웨어에 맞도록 만들 수 있다.
3. Tools > Generate Libraries and BSP 메뉴 옵션을 선택하여 Tornado BSP를 생성한다. 이렇게 해서 생성된 BSP는 종래의 Tornado BSP를 닮았으며, Platform Studio 프로젝트 디렉토리에 위치한다.

세부사항의 맞춤화

VxWorks를 위해 XPS 생성된 BSP는 Xilinx 디바이스 드라이버 코드의 배
치를 제외하고는 대부분의 다른 Tornado BSP들과 닮았다.
Tornad와 함께 배포되는 기성품 디바이스 드라이버 코드는 대개 Tornado 배포 디렉토리의 target/src/drv 디렉토리에 담겨 있다.
Platform Studio에 의해 자동 생성되는 BSP용의 디바이스 드라이버 코드는 BSP 디렉토리 자체에 담겨 있다.
이러한 사소한 차이점은 FPGA 기반 임베디드 시스템들의 역동적인 성격 때문이다. FPGA 기반의 임베디드 시스템은 새롭거나 변경된 IP로 재프로그램할 수 있기 때문에, 디바이스 드라이버 구성이 바뀔 수 있다. 따라서 디바이스 드라이버 소스 파일들의 보다 역동적인 배치를 요구할 수 있다.
Xilinx 디바이스 드라이버들은 C로 구현되며 여러 소스 파일들 간에 배포된다. 또한 디바이스 드라이버들을 위한 OS 독립적인 구현물과 선택 사양인 OS 종속적인 구현물이 있다.
OS 독립적인 드라이버 부분은 모든 OS나 프로세서와 사용할 수 있도록 설계된다. 이것은 기저 하드웨어의 기능을 추상화 하는 API(application program interface)를 제공한다. OS 종속적인 드라이버 부분은 드라이버를 VxWorks와 같은 OS와 사용할 수 있도록 적응시켜 준다.
자동생성 되는 BSP는 Tornado IDE(Project Facility)에 통합된다. BSP는 Tornado 제작 툴을 이용한 명령어 라인이나 혹은 Tornado 프로젝트로부터 컴파일 될 수 있다. 일단 BSP를 생성하고 나면 명령어 라인으로부터 make vxWorks를 입력하여 부팅 가능한 RAM 이미지를 컴파일할 수 있다.
Tornado 2.2.x에서는 gnu 컴파일러 외에도 diab 컴파일러가 지원된다. Platform Studio로 생성한 Tornado BSP는 makefile을 갖고 있어서, gnu 컴파일러 대신 diab 컴파일러를 사용하고 싶을 경우 명령어 라인에서 이를 수정할 수 있다. TOOLS라는 명칭의 make 변수를 찾아내 그 값을 “gnu” 대신에 “diab”로 설정한다. 만일 Tornado Project 설비를 사용하고 있다면 프로젝트가 처음 생성될 때 원하는 컴파일러를 선택할 수 있다.
Tornado Project Facility의 Files 탭은 Xilinx 디바이스 드라이버들을 Tornado 빌드 프로세스에 통합시키는 데 사용되는 파일들의 수도 보여준다. 이러한 파일들은 Platform Studio에 의해 자동 생성된다.
흔히 사용되는 디바이스들 가운데 일부는 OS와 긴밀하게 통합되어 있는 반면, 다른 디바이스들은 디바이스 드라이버들을 직접 사용함으로써 어플리케이션으로부터 액세스할 수 있다.
다른 모든 디바이스 및 관련 디바이스 드라이버들은 VxWorks 인터페이스에 긴밀하게 통합되어 있는 것이 아니라 느슨하게 통합되어 있다.
이러한 디바이스들에 대한 액세스는 사용자 어플리케이션으로부터 관련 디바이스 드라이버들을 직접 액세스함으로써 가능하다.
한편, 역동적인 맞춤형 BSP를 생성할 수 있도록 해주는 기술은 Xilinx의 독점적 포맷인 MLD(Microprocessor Library Definition)를 토대로 하고 있다. 이 포맷은 써드파티 벤더들에게 Xilinx Platform Studio에 대한 플러그인 인터페이스를 제공함으로써 맞춤형 라이브러리 및 특정 OS용 BSP를 생성할 수 있도록 해준다. MLD 인터페이스는 대개 써드파티 업체들에 의해 이들의 특정 흐름에 맞도록 작성된다. 이는 다음과 같은 애드온 기능들을 가능케 해준다:
• 맞춤형 디자인 룰 체킹
• 목표 OS 환경에 맞도록 디바이스 드라이버들을 맞춤화
• BSP를 OS 툴 체인에 맞는 포맷과 폴더 구조로 맞춤생성
• OS/커널을 고려되고 있는 하드웨어 시스템을 토대로 맞춤화