[펌] 임베디드 프로그래머와 부트로더 - 1

유영창 (frog@falinux.com)
기존에 리눅스를 하던 사람들이 임베디드 리눅스의 세계로 발을 들여 놓으면서 기술적으로 어려워 하는 것이 바로 ‘부트로더’라는 프로그램이다. 부트로더는 PC 프로그래머들은 별로 접할 기회가 없는 프로그램이기도 하다. PC에서 동작하는 BIOS 같은 것으로 PC에서는 당연히 시스템에 내장되어 있어야 할 프로그램이기 때문이다. 하지만 임베디드 시스템에서는 프로그래머가 직접 만들어야 하거나 최소한 공개된 기존 부트로더를 수정해야 할 것이다. 이 때문에 부트로더에 대한 구성을 알고 있으면 큰 도움이 된다. 필자는 실무적인 체험을 바탕으로 직접 작성한 ‘이지부트’라는 부트로더를 설명해 가면서 실제 제작 과정을 펼쳐볼 예정이다.
필자는 이 세상에 PC라는 시스템이 나오기 전에는 임베디드 시스템이라는 구별이 따로 없었던 것으로 기억한다. 또 한 가지 ‘펌웨어’라는 단어도 별로 사용하지 않았다. 그러다가 PC가 나온 후 어느 정도 시간이 지나면서 임베디드 시스템이라는 말이 사용되기 시작했고 또한 펌웨어라는 단어를 접하게 되었다. 임베디드(embedded)를 인터넷의 야후 사전에서 찾아보면 이렇게 나온다. embed[imbd, em-] vt. (-ded; -ding) [1] 깊숙이 박다, 파묻다 [2] (마음 속 등에) 깊이 간직하다((in)) [3]【언어수학】 끼워 넣다 임베디드 시스템을 통상적으로는 내장 시스템이라고 말한다. 하지만 필자는 PC 이외의 시스템을 모두 임베디드 시스템으로 정의하겠다. 물론 경우에 따라서는 PC 자체도 임베디드 시스템으로 사용될 경우도 있다. 아마도 대부분의 독자들은 임베디드 시스템과 밀접하게 연결되어 살고 있을 것이다. 얼마나 많은 것들이 임베디드 시스템인가 필자의 오전 일과를 통해 알아보자. 아침에 일어나면 필자는 냉장고부터 찾는데 시원한 물을 먹기 위함이다. 이 최신(?) 냉장고는 전면에 LCD 창을 달고 있는데 예전의 기계식 제어 방식이 아닌 컨트롤러가 내장된 시스템이다. 식사 중에 잠깐 케이블 TV를 켜서 케이블 방송을 보는데 이 케이블 방송 단말기도 컨트롤러가 내장된 시스템이다. 버스를 타기 위해 버스 카드를 운전자 앞에 있는 버스 카드 리더기에 갖다 대는데 이것도 컨트롤러가 내장된 시스템이다. 버스를 타고 가는 도중 곤혹스럽게 휴대폰이 울려대는데 이 휴대폰도 역시 컨트롤러가 내장된 시스템이다. 회사에 출근해 사원증으로 문을 여는데 사원증 인식 장치 역시 컨트롤러가 내장된 시스템이다. 필자가 회사까지 출근하는 과정에 만나는 상황을 적은 것인데 내장된 시스템이라는 단어가 들어간 것들이 모두 임베디드 시스템이다. 예를 보면서 느꼈겠지만 이 땅에 사는 사람들이라면 거의 임베디드 시스템을 보지 않고는 살 수 없을 것이다. 그만큼 임베디드 시스템은 주변에 널려 있는 것이다. 필자가 PC 이외에 모든 것을 임베디드 시스템이라고 우기는 이유가 바로 여기에 있다. 이런 임베디드 시스템에서 동작되는 프로그램을 일반적으로 펌웨어라고 한다. 이런 내장형 시스템에 들어가는 프로그램을 작성하는 것은 PC 프로그램을 작성하는 과정과는 매우 큰 차이가 있다. 이 차이점은 부트로더를 만들어 가면서 온 몸으로 느낄 것이다. 임베디드 시스템에 사용되던 프로세서들 필자가 느끼는 시간을 기준으로 볼 때 이전에(사실 그리 오래 전도 아니다) 임베디드 시스템에 사용되는 프로세서들은 크게 두 분류로 나눠진다. 무척 싸고 작은 8비트 원칩 계열과 고기능(?)으로 무장한 32비트 프로세서들이다. 물론 중간에 해당하는 16비트 프로세서들도 있었지만 이 프로세서들은 중간 정도의 역할을 했다기보다는 사용처가 애매모호해서 크게 활성화되지 못한 것으로 보인다. 우선 8비트 원칩 계열을 보면 8051 계열, PIC 계열의 칩들이 대표적이다. 32비트 CPU라면 MC68XXX 계열과 V40으로 대표되는 i386 계열이다. 물론 그 외에도 많았겠지만 필자의 발이 그리 넓지 못했기 때문에 주로 접한 프로세서들은 이 정도이다. 일반적으로 8비트 원칩 계열을 적용하는 임베디드 시스템은 싸고 대량 생산이 필요할 경우에 주로 이용됐다. 그 외 제어용으로도 많이 사용됐다. 임베디드 시스템에 사용된 주된 이유는 프로세서의 가격이 싸고 필요로 하는 기능이 대부분 하나의 칩에 구현되어 있기 때문이다. 또한 초기에 이 프로세서를 사용하는 개발자가 많았던 이유도 있다. 이 프로세서의 대표적인 특징은 하나의 칩 제어에 필요한 요소인 램, 롬, 시리얼 포트, I/O 포트, ADC(Analog to Digital Conversion)와 같은 것들이 모두 들어 있다. 즉, 칩 하나면 충분한 구조로 설계되어 있는 것이다. 또한 프로세서 한 종류에 여러 가지 타입이 존재해 필요에 따라 칩을 선택할 수 있는 장점도 있다. 32비트 프로세서 계열은 고기능(?)을 필요로 하는 장비에 많이 사용되었는데 이 프로세서들은 단독으로 사용할 수는 없고 주변에 프로세서가 동작하기 위한 부가 칩들이 필요하다. 특징은 주로 고속이라는 것이다. 물론 고속이라고 해도 현재 PC에 사용하는 프로세서와 비교하면 형편없는 속도다. 빨라도 40MHz 이하의 속도가 대부분이었기 때문이다. 최근에는 8비트도 이 정도 속도는 기본이고 100MHz의 속도를 갖는 제품도 속속 등장하고 있다. 이렇게 두 분류로 나눠지다 보니 내장되는 소프트웨어의 모습도 두 분류로 나눌 수 있다. 우선 32비트 소프트웨어의 모습을 살펴보자. <화면 1> 8비트 프로세스 계열 <화면 2> 32비트 프로세스 계열 32비트 프로세서에 내장되는 소프트웨어 32비트 프로세서를 사용하는 임베디드 장비는 복잡한 작업을 수행하는 경우가 일반적이다. 네트워크 통신 제어라든가, 영상 검출이라든가, 아니면 반도체 장비 제어와 같은 제어 흐름이 복잡해 프로그램 용량이 커야 하고 제어 속도도 매우 중요하고 기능도 많아야 하는 것이 대부분이다. 이러한 기능을 모두 충족시켜야 하고 리얼타임 요소도 갖추다 보니 돈 많은 회사거나 신뢰성을 요구하는 장비에는 리얼타임 OS를 채택하는 경우가 많았다. 대표적인 것이 바로 VxWorks이다. 이 운영체제는 유닉스 스타일의 프로그램을 요구하는데 최고의 특징은 실시간이라는 것이다. 단점으로는 높은 라이선스 비용과 개발 툴 비용, 그리고 개발자 수가 매우 적다는 점이다(개발 툴이 비싸서 돈 없는 중소기업에서는 구경하기 힘들고 중견급 이상의 연구소나 개발실에서나 접할 수 있다). 돈이 없거나 굳이 OS란 개념이 불필요한 엔지니어들은 32비트 프로세서라 해도 그냥 OS 없이 프로그램을 작성하는 경우도 태반이다. i386 계열의 임베디드용 프로세서를 사용하는 경우라면 악명 높은 DOS를 올리고 DOS용 컴파일러를 사용하는 경우가 많았다. OS가 있는 시스템에 프로그램을 하는 펌웨어 프로그래머들은 행복한 편에 속한다. 물론 임베디드 프로그램의 특수성이 있기 때문에 나름대로 어려운 부분은 있겠지만 상당 부분을 OS에서 처리하기 때문에 실제 응용 프로그램에 관련된 부분만 집중적으로 프로그램하면 되기 때문이다. 이에 반해 OS 없이 프로그래밍하는 펌웨어 프로그래머들은 아비규환의 세계에 빠져들 수밖에 없다. 대부분을 직접 구현해야 하기 때문이다. 각 장치의 디바이스 드라이버부터 필요하다면 멀티태스크 기능까지 말이다. 한번 상상해 보라. 프로그램의 엄청난 양의 증가를…. 8비트 원칩 프로세서에 내장되는 소프트웨어 8비트 원칩을 사용하는 임베디드 시스템은 무척 간단하다. 그렇다고 기능이 간단한 것은 아니다. 필자의 프로그램 경험에 의하면 작다고 해서 있을 게 없는 경우는 없다. 눈, 코, 귀 다 달아 주어야 한다. 문제는 8비트 원칩에 넣을 수 있는 프로그램 크기가 제한되어 있고 속도도 느리다는 것이다. 이 때문에 주로 사용되는 언어가 어셈블러이다. 최근에는 C를 사용하기는 하지만 여러 가지 이유에 의해 주로 어셈블러를 사용한다. 어셈블러는 C 같은 언어와 다르게 프로세서마다 문법이 다르다. 때문에 하나의 프로세서를 안다고 해서 다른 프로세서도 동일하게 다룰 수 있는 것은 아니다. 이렇게 작은 용량의 기억장소를 갖는 프로세서에 OS를 갖춘다는 것은 말도 안 되는 것이다. 그래도 프로그래머에 따라서는 나름대로의 멀티태스크 기능을 간단하게 짜서 수행하기도 한다. 오랜 경력의 프로그래머들은 8비트 원칩 프로세서를 위한 어셈블러 매크로 라이브러리나 소스 라이브러리를 갖춘다. 그래서 초짜 프로그래머들이 한달 걸릴 일을 경우에 따라서는 한두 시간 만에 해치우기도 한다. 한마디로 슈퍼 프로그래머들이 있는 것이다. 8비트 프로세서를 다루는 프로그래머들의 구호는 ‘좀더 빠르게 좀더 작게’라는 말로 대변된다. 워낙 프로세서 자체가 느리게 동작하기 때문에 속도가 필요한 경우 온갖 꼼수(좋은 말로 ‘테크니컬’이라는 말들을 사용한다)를 부리기 마련이다. 즉, 명령 하나를 쓸 때마다 시간 계산을 하면서 한다는 것이다. 여기에 요구되는 기능이라도 많아지면 동일한 기능을 하면서 작은 코드를 발생하게 해야 한다. 필자가 본 프로그래머 중에서 이런 부분을 가장 고민하는 임베디드 프로그래머로는 보드 게임 프로그래머가 최고였던 것 같다. 이런 상황이다 보니 코드 가독성에 대한 고려나 유지 보수에 대한 최소한의 배려마저 포기할 때가 많다. 어떤 관리자가 감히 이런 것을 요구할까. 그랬다가는 돌 맞는다. 또 이런 임베디드 프로그램을 작성하는 경우에는 보드 개발부터 프로그램까지 모두 혼자 하는 경우가 비일비재 하다. 국내에서 제어기기를 제작하는 업체 대부분이 소규모 회사이기도 하고 여러 명이 공동으로 작업하는 것이 도리어 능률을 떨어뜨리는 경우가 많기 때문이다. 더구나 필자는 하드웨어 팀과 소프트웨어 팀이 나눠져서 개발하는 경우 두 개발자간의 사이가 좋은 경우를 보지 못했다. 32비트 원칩 프로세서의 등장 8비트 원칩 프로세서는 저가의 대량 생산용 임베디드 시스템에 32비트 프로세서는 고가의 고기능 임베디드 시스템에 사용된다는 규칙은 시대가 변하면서 변하기 시작했다. 왜냐하면 임베디드 시스템 시장의 요구가 달라졌기 때문이다. 사용자들은 PC라는 편리한 시스템에 길들여지기 시작했고 다른 시스템에도 이러한 편리성을 요구하기 시작했다. 한마디로 가격은 싸면서 기능은 PC급을 요구하기 시작한 것이다. 더구나 8비트 원칩 프로세서로는 구현이 힘든 사용자 화면을 요구하기 시작한 것이다. 그밖에 구현해야 하는 기능 역시 매우 복잡해지기 시작한 것이다. 간단하게 냉장고만 예로 들더라도 예전에는 문을 열었을 때 램프를 켜고 온도에 따라 송풍기나 에어컨 구동 모터를 동작시키면 되던 것이 LCD를 달아서 내부 상태를 보여주더니만 급기야 웹까지 구현하기를 요구하게 된 것이다. 공장 자동화 기기들은 어떤가. 요즈음은 네트워크 통신은 거의 기본이 되었다(이런 요구의 틈새 시장을 노린 것이 시리얼과 네트워크 변환 모듈들이다). 이런 고급화된 기능을 기존 32비트 프로세서를 사용해 구현해도 되지만 주변에 추가해야 할 디바이스가 나날이 늘어나서 저가를 형성하는 임베디드 시스템에 적용하기에는 너무도 무리가 따르기 시작했다. 설상가상으로 환경 문제와 에너지 문제가 대두되면서 초절전 시스템을 요구하는 것이다. 개발자들은 이런 시대적 상황 변화에 기민하게 대처해야 하는데 기존 프로세서로는 해결이 거의 불가능한 것이다. 그래서 나온 꼼수가 PC 시스템을 내장하는 것이었다. 문제는 PC 시스템을 제대로 사용하려면 OS를 사용해야 하는데 당시 윈도우 98 계열밖에 없던 터라 개발자는 시스템 다운에 하루하루를 걱정하며 살아야 하는 악몽같은 세월을 거치기도 하였다. 더구나 PC 시스템을 탑재할 수 있는 경우는 덩치 큰 기기들이지 소형 시스템에는 꿈도 못 꾸는 것이다. 이런 상황에 나타난 것이 32비트 원칩 프로세서이다. 기존 32비트 프로세서의 속도에 많은 주변 디바이스를 아예 칩 자체에 내장하고 나타난 것이다. 기존 32비트 프로세서를 사용하기 위해서는 주변에 필요한 프로세서를 보드에 다닥다닥 붙여야 했던 것과는 달리 칩 안에 모두 내장해 버리니 소형 시스템에도 사용할 수 있는 것이다. 더구나 회로 배선과 패키지 기술 발달에 힘입어 8비트 프로세서보다 작아지는 기현상도 발생했다. 이런 32비트 프로세서 역시 대량 생산이 되지 않았다면 가격이 매우 높게 책정될 수밖에 없기 때문에 지금과 같은 32비트 원칩 프로세서가 대중적으로 사용되기는 힘들었을 것이다. 그러나 PDA와 셋톱박스 그리고 네트워크 장비에 사용되면서 대중화되기 시작한 것이다. 또 한 가지 대중화가 가능한 요인으로는 ‘프로세서 코어’라는 개념이 등장하면서 프로세서 생산의 독점 시대가 종말을 고하기 시작한 것을 들 수 있다. 예전에는 ASIC을 생산할 수 있는 공장이 있더라도 프로세서를 만드는 것은 요원했다. 왜냐하면 프로세서를 구현하는 CPU 로직을 만들 소프트웨어 기술이 없었기 때문이다. 삼성전자마저도 D램 시장에서는 선두를 다툴지 몰라도 생산되는 CPU라고 해 봤자 4비트나 8비트 수준이 한계였기 때문이다. 또 기껏 만든다고 해도 기존 시장의 아성을 무너뜨리기에는 한계가 있었다. 누가 특별한 매력이 없는 상황에서 시장에서 검증(?)되지 않은 프로세서를 사겠는가? 그런데 PowerPC라든가 ARM이라든가 하는 프로세서 소프트웨어를 라이선스해 판매하면서 이러한 프로세서 생산 독점 시대도 막을 내리게 된다. 필자가 조금 자신있게 알고 있는 ARM이라는 프로세서는 실제로 제품으로 존재하지 않는다. 단지 소프트웨어 프로세서일 뿐이다. 이 프로세서 코어를 사서 삼성에서 만든 것이 S3C2410과 같은 모델명을 갖는 프로세서이다. 요즘 많이 알려져 있는 인텔의 스트롱암(StrongARM)이나 XScale 역시 원초적인 코어는 ARM에서 제작된 것이다(XScale의 족보는 이것보다 조금 복잡한데 이 이야기는 여기서 굳이 하지 않으려 한다). 즉, ASIC 생산이 가능한 회사라면 누구나 실제 프로세서를 구현하는 프로세서 로직을 라이선스해 프로세서를 생산할 수 있게 된 것이다. 이런 저런 이유로 인해 32비트 원칩 프로세서들은 대중화되기 시작했고 이제는 임베디드 시스템 개발자라면 언젠가는 해야 할 프로세서로 등장하게 된 것이다. 문제는 개발자들이다. 이들의 본격적인 고민이 시작된다. <화면 3> 32비트 원칩 프로세스 계열