Embedded Linux를 개발하는 과정은 꽤나 길고 까다로운 난이도로 인해 힘들어하는 과정이다. 이로 인해 대부분의 CPU 개발 회사에서 이 부분을 Dev KIT과 BSP로 레퍼런스를 제시하고 참고해서 사용할 수 있게 많은 자료를 제시하고 있다. 사용자는 이 부분을 기준으로 내부 구조는 고치지 않고 그대로 사용 할 수 있는 것이다.
하지만 부득이 수정 할 부분이 생기면 아래 과정을 거쳐야 한다.

CPU (MPU) 선정

제일 먼저 가장 중요한 성능을 좌우하는 CPU를 선정해야 하는데 몇 가지 고려해야 할 사항들이 있다.

Dev KIT 을 구입이 쉬운가 ? 다른 Third Party KIT 이 다양한가?

=> 제조사에서 만드는 기본적인 Dev KIT 및 많은 Third Party 회사에서도 Dev KIT을 만든다. 제조사의 제품의 경우 넓은 개발 범위를 제공하기 위해 복잡한 KIT를 제시하기도 하거니와 가격도 부담스러운 경우도 있다. 반대로 Third Party 회사의 경우 꼭 필요한 부분만 제공하고 구입 가격도 저렴한 경우가 많아 참고할 사항들이 많아야 설계 초기 적절한 선택을 할 수 있다.

BSP 자료가 잘되어 있는가 ? 개발자 Community 에 개발자 활동이 활발한가 ?

=> CPU 성능을 고려하지만 사실 제조사 별로 성능이 크게 차이가 없기 때문에 SW 개발자의 입장에서는 BSP (Board Support Package) 지원이 얼마나 잘 되는지 ? BSP 접근이 Web을 통해 잘 정리된 자료를 얻을 수 있는지 ? 또한, 개발자들간 질문과 응답이 얼마나 활발한지 등도 고려 할 사항이다.

Dev KIT 구입 및 BSP 다운로드

적절한 Dev KIT 구입 후 제조사에서 제공하는 기본 BSP를 직접 빌드 후 다운로드하는 과정을 확인한다. 이 과정은 프로젝트 완성 때까지 빈번하게 하는 작업이기에 익숙해져야 한다.

다운로드 Tool 및 방법

Linux Binary Image를 다운로드 할 경우 제조사가 별도로 지원하는 Tool 을 확인한다. JTAG과 같은 전용 장비를 사용하는 경우도 있지만 제조사에서 지원하는 Tool도 다운로드 목적으로 부족하지 않게 제공 하므로 다운로드 Tool도 CPU 선정 시 조금이나마 고려할 사항이 된다.

Dev KIT 동작 확인

리눅스는 대부분은 시리얼 터미널 로그를 기준으로 Dev KIT의 UART를 통해 동작을 확인한다. 부팅 로그가 잘 동작하고 로그인까지 동작하면 이 시점부터가 개발 시작이다.

BSP 빌드 후 Dev KIT 에서 확인 (기준점)

빌드하는 과정은 Buildroot와 Yocto 두 종류가 있다. Buildroot는 Yocto가 나오기 전의 빌드 과정으로 make 문법을 사용한다. 요즘은 많은 제조사가 Yocto 기반의 과정을 지원하고 있다.
빌드 후 만들어진 Binary Image를 다운로드 후 Dev KIT과 동일한 동작을 확인한다. 이 과정이 확인되면 개발에서 이제 한 걸음 나갔다고 할 수 있다.

Dev KIT 과 Target B’d 차이점 확인

직접 수정 개발한 HW가 Dev KIT과 어떤 부분에서 차이가 나는지 면밀히 확인해야 한다. 외부 제어에 필요한 UART, I2C, SPI, USB 등의 경우 CPU의 외부 회로 및 FW 문제로 문제가 발생해도 대처 및 수정이 어렵지 않다.
하지만 메모리 (Flash, DDR DRAM 등)를 변경해야 하는 경우는 부팅 단계부터 소스코드 수정도 어렵고 디버깅 방법도 많지 않다. JTAG과 같은 전용 장비를 사용할 필요성이 생긴다.
Ethernet PHY Chip의 경우도 Dev KIT과 다르지 않으면 문제가 전혀 되지 않지만 특별한 Ethernet을 사용할 경우 이 부분도 포팅이 필요하다. Ethernet이 지원이 되지 않으면 개발 과정에서 빈번한 수정과 이것을 확인하기 위한 다운로드를 무수히 반복해야 하므로 이로 인한 개발 소요 시간이 무의미하게 증가한다.

부팅순서

Bootloader (Boot mode, eMMC or SDCard)

CPU(MPU)의 경우 다양한 부팅모드를 지원한다. eMMC, SDCard 등 외부 Flash 메모리의 형태에 따라 적절한 설정을 확인한다. 전원인가 후 설정이 올바르지 않은 경우 부팅을 할 수 없다.

통상 전원이 인가되면 CPU 내부의 ROM 영역의 코드는 외부의 Flash 메모리로부터 부팅에 필요한 코드를 읽어 CPU 외부의 RAM 영역에 복사한다. 이 단계의 코드는 아직 CPU 내부의 ROM 영역이다.

U-Boot (Memory Map, Partition, Device Tree)

CPU 외부의 RAM(예, DDR DRAM)에 복사 된 후 이 시점부터 CPU가 수행하는 코드를 통상 U-boot 이라 한다. U-Boot에서 지원하는 여러가지 기능이 있지만 주 용도는 Linux Binary Image를 업데이트 하거나 Kernel 코드를 수행하기 위한 과정을 준비한다.

Kernel

Kernel 코드가 수행되는 과정은 ROM 영역의 코드를 압축해제 해서 RAM의 다른 영역(파티션)을 옮기고 옮겨진 코드가 수행하는 과정이다. 부팅 시 대부분의 시간은 이 시간이다. 부팅 시간을 줄이기 위해 필요하지 않은 요소를 줄이기도 한다.

Memory Porting

Dev KIT에서 제공하는 메모리를 그대로 사용하는 것을 추천한다. 포팅 과정도 어렵고 포팅 후에도 안정적으로 동작하는 과정도 오래 걸린다. 특히 CPU와 RAM(DDR RAM)간의 클럭 스피드는 보통 1GHz로 동작한다. 만일 이런 경우 보드 동작이 불안한 경우 CPU와 RAM간의 PCB 신호선이 문제인지 CPU의 DDR DRAM Controller 설정 부분이 문제인지 검증이 쉽지 않기 때문이다.
Memory를 포팅하기 위해서는 CPU의 Memory Controller에게 어떤 Type의 메모리가 연결되어 있는지 메모리 정보(Manufacturer ID, Device COde, Chip SIze, Block당 Page 수 등)를 Data Sheet 에서 확인 후 소스코드, 헤더파일 등 수정할 곳이 늘어난다.
이 부분이 완료되면 대략 40% 완성도라고 할 수 있다. 코드가 동작하기 시작하면 이 이후의 단계는 디버깅이 가능한 단계이기 때문이다.

Device Driver

CPU의 경우 외부 제어를 위해 많은 I/O 핀을 제공 하는데 Reference Dev KIT과 다른 I/O를 변경할 경우 (다른 GPIO를 사용하거나 Dev KIT과 다른Peripheral을 사용) BSP 수정 시 Kernel Configuration, Device Tree 부분을 수정해야 한다.
이 단계가 완성되면 Embedded Linux 과정의 70% 단계라 볼 수 있다.

Network Test

TFTP, NFS

Device Driver 포팅이 완료되면 Embedded Linux Target B’d에서 동작하는 User Space의 Application을 개발해야 하는데 이 부분 설정이 없으면 확인 과정을 거치기 위해 매번 다운로드를 해야 한다. 이 부분 설정을 통해 다운로드 없이 PC에서 Ethernet을 통해 Target B’d 상태를 직접 확인 할 수 있다.

Auto Login

Linux는 부팅이 완료되면 사용자 계정을 묻는 로그인 단계를 수행 하므로 설정을 통해 자동으로 로그인되게 한다. Linux 버전마다 조금씩 다르기는 하지만 해당 코드를 시작 프로그램에 등록한다.

#include <unistd.h>

int main(void)
{
    execlp("/bin/login", "login", "-f", "root", 0);
    return 0;
}

Auto Start Application

Auto Login 이후 Target B’d에서 목적하는 Application이 자동으로 수행해야 한다.

이제 개발이 완료 되었다.