이제 우리가 'ARM 공부'를 위해서는 'ARM 시스템을 개발하기위한 개발환경'을 갖추어야한다.
그 개발환경 속에서 여러 ARM 어셈블리 코드를 배우고, 그 코드가 의미하는 하드웨어적 의미들을 배워나갈것이다.
ARM 개발 환경은 무엇이 있을까? ARM Development Environment
우선 전반적인 개발 환경 구축에 앞서, 우리는 제일 첫번째로 가상화를 지원하는 '가상 머신'이란것이 필요하다.
왜 ARM 개발 환경을 구축하기 위해 우리는 '가상화'를 이용해야하는가?
우리가 ARM을 배우기 위해서 ARM의 개발과정을 알아야하고, 그 과정속에서 코드를 익히는것이 목적인데, 기본적으로 앞서 말했듯이 ARM 아키텍쳐는 우리가 사용하는 PC regime과 전혀 다르다. ( CISC 가 아닌 RISC 라고 설명하였었다. ) 우리는 ARM 아키텍쳐의 개발을 위해서 PC를 이용해야하지만, ARM은 PC와 다르기 때문에 PC에서 ARM 과 유사한 환경을 '가상적'으로 구축해야지 작업을 할수있게 되는것이다.
이것이 앞으로 우리가 하려는 '가상화'의 가장 큰 목적이다.
[ 1. Virtual Machine : 가상 머신 ] : QEMU (ARM virtual machine)
'가상머신'이란 무엇인가? VM(Virtual Machine)의 정확한 정의는 '컴퓨터 과학 분야에서 특정한 프로그램들을 실행하는 컴퓨터를 진짜 컴퓨터같이 만들어 주는 소프트웨어'이다. 아주 쉽게 설명을 하자면, A 기술로 만들어진 기기'내부'에서 가상적으로 B 기술로 만들어진 기기의 작동원리를 구성해주는 것을 뜻한다. 예전에 PC안에서 에뮬레이터를 다운받아 'GAMEBOY ADVANCE'의 기기처럼 작동시키거나, 실제로 없는 DVD롬을 'DAEMON TOOL'을 이용하여 가상의 DVD롬 기기가 있는것처럼 작동시켜주었던 기억이 있을것이다. 사실 VM(Virtual Machine : 가상머신)은 이렇게 단순하게 정의되는것이 아니다. 세세한 내용은 아래 분홍 박스를 참조하여라.
가상 머신(VM)은 "일반 '호스트 운영 체제'속에서 완벽하게 고립된 '게스트 운영 체제'(guest operating system)"를 뜻한다. 현대의 가상 머신은 '소프트웨어 에뮬레이션' 혹은 '하드웨어 가상화' 둘 중 하나로 작동이 되기도 하지만, 거의 대부분의 가상머신은 이 두 가지를 한번에 이용한다.
가상 머신은 '물리적 머신'과 같은 프로그램들을 실행시켜주는 머신(예를 들어 컴퓨터와 같은)의 소프트웨어 실행기이다. 가상 머신은 두 가지의 주 카테고리로 나뉘어진다.
* 완전한 시스템 플랫폼을 제공하며, 다시 말해 완전한 운영 체제 (OS)의 실행을 지원하는 '시스템 가상 머신' (A system virtual machine).
* 반대로, 단일 프로그램을 실행하기 위해 고안되어진, 즉 싱글 프로세스를 지원해주는 것을 뜻하는 '프로세스 가상 머신' (a process virtual machine).
가상 머신의 '근본적 성질'(essential)은 제한된 리소스들과 가상 머신에 의해 제공되는 추상화들에 국한되어 소프트웨어를 구동한다는 점이다. (가상 world에서 벗어날 수 없다.)
> 일반적 분류
가상 머신은 실제 컴퓨터와 어느 정도의 통신과 사용을 기반으로 두 가지로 나뉜다.
: 완전한 시스템 플랫폼을 제공하며, 다시 말해 완전한 운영 체제 (OS)의 실행을 지원한다.
시스템 가상 머신은 가끔 하드웨어 가상 머신이라고 하며 각 운영 체제를 실행하는 가상 머신 사이의 기초가 되는 물리 컴퓨터를 다중화(multiplex)한다. 가상화를 제공하는 소프트웨어 계층은 가상 머신 모니터 또는 하이퍼바이저라고 한다. 하이퍼바이저는 순 그대로의 하드웨어 또는 호스트 운영 체제 위에서 실행할 수 있다.
시스템 가상 머신의 주요 이점:
* 여러 운영 체제를 쓰는 환경은 운영 체제가 완벽히 고립된 채로 같은 컴퓨터에서 존재할 수 있다.
* 가상 머신은 실제의 컴퓨터가 제공하는 것과 다른 형태의 명령어 집합 구조 (ISA, Instruction Set Architechure)를 제공한다.
* application provisioning, maintenance, high availability 그리고 disaster recovery 들을 제공한다.
시스템 가상 머신의 주요 단점:
* 가상 머신이 하드웨어에 간접적으로 접근할때 가상 머신은 실제 머신보다 적은 효율을 지닌다.
* 복수의 VM들이 동시적으로 같은 물리적 호스트에서 작동할 경우, 각각의 VM 들은 다양하고, 불안정한 퍼포먼스들(실행 속도, 혹은 결과 자체가 없는 경우)을 보여줄 수 도 있다.
각자 게스트 운영 체제라 불리는 저만의 운영체제를 실행하는 복수의 VM들(Multiple VMs)은 '서버 통합(server consolidation)'에 사용된다. 서버 통합(server consolidation)은 '서로 방해되는 것을 막기위해 각자의 머신에서 가동되는 다른 서비스들'을 같은 물리적 머신 내에서 분산된 VM들을 이용함으로써 가동시키는 것을 뜻한다. 이러한 사용을 '제품 품질의 고립 (QoS 고립)'이라고 한다.
여러 개의 운영 체제를 사용하려는 열망은 가상 머신의 원래 취지였으며, 여러 개의 단일 작업 운영 체제들 사이에서 시분할 단일 컴퓨터를 허용함으로서 이를 실현하였다.
In some respects, a system virtual machine can be considered a generalization of the concept of virtual memory that historically preceded it. IBM's CP/CMS, the first systems to allow full virtualization, implemented time sharing by providing each user with a single-user operating system, the CMS. Unlike virtual memory, a system virtual machine allowed the user to use privileged instructions in their code. This approach had certain advantages, for instance it allowed users to add input/output devices not allowed by the standard system.
'게스트 운영 체제'들은 같은 컴퓨터 내에서 절대적으로 '각 다른 운영 체제들을 가동시키는 것을 가능하기위해 만들어진 하드웨어'에 순응할 필요는 없다. 다시 말해, 같은 컴퓨터에서 다른 운영체제를 돌릴 수 있게 해 준다. (예: 마이크로소프트 윈도와 리눅스, 또는 최신 버전에서 지원하지 않는 소프트웨어를 지원하기 위해 옛날 버전의 운영체제를 설치) 다른 '게스트 운영체제'들을 지원하기 위해 가상 머신을 사용하는 것은 임베디드 시스템에서 인기를 끌고 있다 : 일반적으로 리눅스와 윈도와 같은 높은 수준의 운영 체제와 동시에 실시간 운영 체제를 지원하는 용도로 많이 사용한다.
다른 사용으로는 신뢰할 수 없는 운영체제를 sandbox하는 것이다. 왜냐하면 그 시스템이 개발 하의 시스템일 수도 있기 때문이다. 가상 머신들은 더 나은 오류 수정의 접근과 더 빠른 다시 시동과 더불어 운영 체제 개발에 다른 이점들을 가져다 준다.
'QoS 고립'을 위한 가상 머신의 인기는 대부분의 동시대 운영 체제가 제공하는 완전하지 못한 자원 고립을 이끈다. 솔라리스 존은 강력한 자원 고립을 제공하는 대체물이다. 존은 가상 머신이 아니지만 "운영 체제 가상화"의 예이다. 여기에는 Virtuozzo, FreeBSD Jail, Linux-VServer, chroot jail, 그리고 OpenVZ와 같은 가상 환경(가상 서버)을 포함한다. 이러한 환경은 운영 체제 안의 프로세스를 어떠한 형태로 둘러싼다.
: 하나의 단일 프로그램을 실행하기 위해 만들어져 있는데, 다시 말해 단일 프로세스를 지원하는 것을 뜻한다.
종종 일반적인 '애플리케이션 가상 머신'이라고 불리우는 '프로세스 가상 머신'은 호스트 운영 체제 안에 있는 일반적인 애플리케이션을 실행하고, 단일 프로세스를 지원해준다.
이 프로세스 가상 머신은 프로세스가 시작될때 생성되고, 프로세스를 나갈때 파괴된다(destroyed).
프로세스 가상 머신의 목적은 하드웨어나 운영 체제의 밑부분에 있는 매우 상세한 사항들을 추상화시켜주고, 어느 플랫폼에서든 같은 방식으로 하나의 프로그램을 실행시키는 것을 가능하게 해주는 platform-independent programming environment (플랫폼과 독립적인 프로그래밍 환경)를 제공하는 것에 있다.
'프로세스 가상 머신'은 고급 프로그래밍 언어에서와 같은 높은 수준의 추상화를 제공한다. ('시스템 가상 머신'에서의 낮은 수준의 ISA 추상화에 비하면) — '프로세스 가상 머신'들은 interpreter를 사용하여 실행된다.(implement); interpreter 는 just-in-time compilation (JIT)를 이용함에 따라 compile 프로그래밍 언어와 견줄만한 퍼포먼스를 갖게 되었다.
이러한 종류의 가상 머신은 '자바 가상 머신(JVM : Java Virtual Machine)'을 사용하여 수행(implement)되는 '자바 프로그래밍 언어'와 더불어 유명해졌다. 또 다른 예로는, 몇몇의 interpreted 언어를 위해 추상화 계층을 제공하는 Parrot virtual machine 이 있고, '닷넷 프레임워크'가 있는데 '닷넷 프레임워크'는 공통 언어 런타임(Common Language Runtime)이라고 불리는 가상 머신을 실행한다.
http://en.wikipedia.org/wiki/Just-in-time_compilation Just-In-Time Compilation
'프로세스 가상 머신'의 특수한 케이스는 잠재적으로 여러 다른 요소들로 구성된(potentially heterogeneous) 컴퓨터 클러스터의 통신 구조를 추상화하여 감추는(abstract over) 시스템들이다. 이러한 종류의 VM은 단일 프로세스로 구성되있지 않지만, 클러스터 내부에서 '물리적 머신 당 하나의 프로세스'(one process per physical machine)로 구성된다. 이것들은 프로그래머들에게 내부 연결(interconnect)과 OS 에 의한 통신 구조들은 복잡하게 생각하지 않게하고(이것이 'abstract over'의 의미), 단지 알고리즘에만 집중할 수 있도록 함으로써 병렬 응용 프로그램(parallel applications)들을 프로그래밍하는 작업을 쉽게 하기 위해 고안되었다.
다른 '프로세스 가상 머신'들과는 다르게, 이러한 시스템들은 특정한 프로그래밍 언어를 제공하지 않지만 기존의 언어에 통합(embedded)되어 있다. ; 보통 이러한 시스템들은 몇몇의 언어들을 합친 꾸러미(bindings)들을 제공한다(예를 들어, C와 FORTRAN). 병렬 가상 머신 (PVM : Parallel Virtual Machine)와 메시지 전달 인터페이스 (MPI : Message Passing Interface)가 그 예이다. 위에서 실행되는 응용 프로그램(애플리케이션)들이 여전히 모든 운영 체제 서비스에 대한 접근을 가지고 있기 때문에 가상 머신이라고 딱 잘라 말하진 않으므로 "가상 머신"이 제공하는 시스템 모델로도 정의하지 않는다.
> 기술
1. underlying raw hardware 에서의 에뮬레이션 (native execution)
이러한 접근은 하드웨어의 완전한 가상화를 말하며, 유형 1 또는 2의 하이퍼바이저(hypervisor)를 사용하여 수행(implement)된다.
* 유형 1 하이퍼바이저 : 직접적으로 '하드웨어' 위에서 실행한다.
* 유형 2 하이퍼바이저 : 리눅스와 같은 '다른 운영 체제' 위에서 실행한다.
각각의 가상 머신은 underlying hardware에 의해 지원을 받는 아무 운영 체제나 실행할 수 있다. 유저들은 당연히 별도의 '개인'(private) 가상 컴퓨터내에서 2개 혹은 그 이상의 다른 '게스트 운영 체제'들을 동시에 가동할 수도 있다.
The pioneer system using this concept was IBM's CP-40, the first (1967) version of IBM's CP/CMS (1967–1972) and the precursor to IBM's VM family (1972–present). With the VM architecture, most users run a relatively simple interactive computing single-user operating system, CMS, as a "guest" on top of the VM control program (VM-CP). This approach kept the CMS design simple, as if it were running alone; the control program quietly provides multitasking and resource management services "behind the scenes". In addition to CMS, VM users can run any of the other IBM operating systems, such as MVS or z/OS. z/VM is the current version of VM, and is used to support hundreds or thousands of virtual machines on a given mainframe. Some installations use Linux for zSeries to run Web servers, where Linux runs as the operating system within many virtual machines.
Full virtualization is particularly helpful in operating system development, when experimental new code can be run at the same time as older, more stable, versions, each in a separate virtual machine. The process can even be recursive: IBM debugged new versions of its virtual machine operating system, VM, in a virtual machine running under an older version of VM, and even used this technique to simulate new hardware.[6]
The standard x86 processor architecture as used in the modern PCs does not actually meet the Popek and Goldberg virtualization requirements. Notably, there is no execution mode where all sensitive machine instructions always trap, which would allow per-instruction virtualization.
Despite these limitations, several software packages have managed to provide virtualization on the x86 architecture, even though dynamic recompilation of privileged code, as first implemented by VMware, incurs some performance overhead as compared to a VM running on a natively virtualizable architecture such as the IBM System/370 or Motorola MC68020. By now, several other software packages such as Virtual PC, VirtualBox, Parallels Workstation and Virtual Iron manage to implement virtualization on x86 hardware.
Intel and AMD have introduced features to their x86 processors to enable virtualization in hardware.
As well as virtualization of the resources of a single machine, multiple independent nodes in a cluster can be combined and accessed as a single virtual NUMA machine.
2. non-native 시스템의 에뮬레이션
가상 머신은 또한 다른 컴퓨터 프로세서 아키텍쳐를 위해 쓰여진 소프트웨어 애플리케이션과 운영 체제가 동작할 수 있게 도와 줌으로써 에뮬레이터의 역할을 수행할 수도 있다.
몇몇의 가상 머신들은 자세한 규격으로 존재하는 하드웨어를 가상으로 구현(emulate)한다. 예를 들면:
* 가장 첫번째가 프로그래머들에게 '규격을 알맞게 수행하는 가상 머신 소프트웨어를 작동시키는 어느 컴퓨터에서든지 작동하는' Pascal 프로그램들을 작성할 수 있게끔 만들어주는 p-code machine specification이다.
* Java Virtual Machine의 규격(specification)
* 마이크로소프트 닷넷 계획(initiative)의 핵심(the heart)인 Common Language Infrastructure 가상 머신
* Open Firmware는 '플러그인 하드웨어'가 어떠한 종류의 CPU든 그 위에서 작동하는 부트시간 진단, 환경설정 코드, 디바이스 드라이버들을 포함하게끔 가능하게한다.
이 기술은 다양한 컴퓨터가 해당 규격에 맞춰 쓰인 아무 소프트웨어나 실행할 수 있게 해 준다.; 오직 가상 머신 소프트웨어 자체만이, 그 소프트웨어가 실행되는 각 컴퓨터 타입에 맞춰 독립적으로 쓰여질 수 있다.
3. 운영 체제 수준의 가상화
운영 체제 수준의 가상화는 서버들을 운영 체제 (커널) 계층 위에서 가상화하는 '서버의 가상화 기술'이다. 이 기술은 파티셔닝(partitioning)으로 간주될 수 도 있다 : 단일 물리 서버는 다수개의 작은 파티션들 (가상 환경 (VE), 가상 개인 서버 (VPS), guests, zones 등이라고도 한다.)로 쪼개진다. ; 이러한 각 파티션은 그것의 유저가 보는 관점에서 진짜 서버처럼 작동한다(looks and feels like).
orts multiple guest OSes running under the same OS (such as Solaris 10). All guest OSes have to use the same kernel level and cannot run as different OS versions. Solaris native Zones also requires that the host OS be a version of Solaris; other OSes from other manufacturers are not supported.[citation needed],however you need to use Solaris Branded zones to use another OSes as zones.
Another example is System Workload Partitions (WPARs), introduced in the IBM AIX 6.1 operating system. System WPARs are software partitions running under one instance of the global AIX OS environment.
The operating system level architecture has low overhead that helps to maximize efficient use of server resources. The virtualization introduces only a negligible overhead and allows running hundreds of virtual private servers on a single physical server. In contrast, approaches such as full virtualization (like VMware) and paravirtualization (like Xen or UML) cannot achieve such level of density, due to overhead of running multiple kernels. From the other side, operating system-level virtualization does not allow running different operating systems (i.e. different kernels), although different libraries, distributions etc. are possible.
그래서 우리는 VM인 QEMU라고 불리는 x86 이외(쉽게말해 PC 이외)의 기기(ARM)를 위해 소프트웨어 스택 전체를 가상머신 위에서 실행가능하게 만들어주는 가상화 소프트웨어(에뮬레이터)를 이용할것이다. 그런데 이 QEMU 에뮬은 우분투, 데비안 등의 버젼은 있지만 (리눅스 계열에서) 마이크로소프트 윈도우 버젼은 없다. 그 이유는 QEMU가 ARM 에뮬레이터이고, 우분투와 데비안은 ARM 개발환경을 위한 OS 이기 때문, 자연히 Windows는 ARM 개발환경 OS가 아니라는 뜻이다. 이러한 이유때문에 우리는 우분투 OS를 설치해야하는 귀찮은 상황에 놓이게된다.
우분투를 사용해야하는 이러한 이유 말고도, 추가로 우분투를 이용하는 이유는, 우분투에 패키지 매니지먼트 기능이라고하는 Windows와 차별화된 매우 유용한 기능이 있기때문이다.
1. 리눅스 환경 세팅의 핵심.
2. 대부분의 우분투 프로그램들과 라이브러리들은 '데비안 패키지 시스템'에 의해 관리된다.
( 우분투 OS는 데비안 OS (리눅스 커널을 탑재한 공개 OS)기반으로 제작된 OS이다. 이런 이유로 데비안의 패키지 시스템이 우분투에 그대로 내려와서 '우분투 패키지 매니지먼트'로 불리우는 것이다. )
3. 만약 인스톨 하려는 패키지 A가 전제조건적( A설치 이전에 필요한 ) 패키지 B, C, D...에 대한 의존성을 지니고 있다면, 매니저가 자동적으로 그 모든것들을 합쳐서 한번에 설치, 처리해준다.
4. 거의 대부분 사용되는 패키지관련 commands
+ apt-get update : 모든 패키지를 최신으로 업데이트,
+ apt-get install <pkg-name> : 해당 패키지를 설치한다.
5. '4번' 에서의 명령어를 이용하여 터미널(Windows의 cmd와 같음)에서 컴퓨터에게 명령하면 sources.list 라고 하는 파일에 저장되어있는 '주소'리스트들에서 해당 패키지를 찾는다.
예를 들어 현재 나의 sources.list 에는 [ J-POP 파일들이 모아져있는 A 주소 ], [ K-POP 파일들이 모아져있는 B 주소 ] 이 두 개의 '주소'만 있다고 가정하자. 내가 US 노래를 설치하고싶어 터미널에 명령어 apt-get install US SONG 를 입력하면, US SONG 에 해당하는 파일을 A 주소와 B 주소에서 찾아 볼것이고, US SONG은 K-POP 과 J-POP 의 범주에 속하지 않은 파일이므로 어느 주소에서도 찾지 못하고, 설치 명령을 수행하지 못할 것이다.
※ '주소'는 PPA (Personal Package Achive) 라는 software repository (소프트웨어 저장소) 서버 '주소'이다.
6. 우분투 패키지들에 관련된 한국 프록시 DB(데이타베이스, 위에서 말한 '주소'개념)는 가끔 싱크가 맞지않아.
sources.list 에 있는 모든 주소들의 끝부분에 달린 ko(한국)를 en(미국)으로 바꾸는것을 추천한다.
그래서 우선 ARM 개발환경 구축을 하는데에 있어 가장 먼저 해야할것이
1. 우툰투 가동을 위한 VMplayer (첫번째 가상머신) 설치
2. VMplayer가 돌릴 수 있는(run) '우분투 OS' VMplayer용 이미지를 구한다.
3. 우분투를 설치한 VMplayer로 돌리기.
4. 우툰부 OS 안에서 Terminal (Windows의 cmd 하고 유사)를 켠 후에 거기서 우분투 버젼의 QEMU 를 설치.
1. 리나로 프로젝트의 PPA(Personal Package Archive)를 추가한다.
PPA는 위에서 말한 '우분투 패키지 매니지먼트'에서 특정 패키지를 다운로드 하기 위한 하나의 '패키지들의 저장소(Repository)'로써, 웹 하드처럼 각각의 용도별로 서버에 파일들을 깔끔하게 '필요에 맞추어' 저장, 정렬해 놓은것을 말한다. 복잡하게 A 사이트에서 '바퀴 부품'을 받고, B 사이트에서 '차체 부품'을 받고, C 사이트에서 '유리 부품'을 받아 자동차 조립을 시작하지 않고, S 사이트에서 '바퀴 부품', '차체 부품', '유리 부품'을 한꺼번에 구해서 조립을 시작할 수 있게끔. 필요한 파일들끼리 모아둔 '주소'인 것이다.
위 US SONG 예시에서 [ J-POP 파일들이 모아져있는 A 주소 ], [ K-POP 파일들이 모아져있는 B 주소 ] 밖에 없는 source.list 에 sudo add-apt-repository ppa:'US-POP 파일들이 모아져있는 C 주소' 명령어를 입력하면, 최종적으로 sourst.list 에는 C 주소가 추가된 'A, B, C' 총 3개의 주소가 존재하게 된다.
이렇게 add-apt-repository 명령어와 함께 자신이 추가하고 싶은 PPA를 커맨드해주면, 그 '주소'가 'sources.list'에 주소리스트에 추가가 된다.
리나로 프로젝트는 단순하게 말하자면, ARM의 개발 향상을 위해 ARM 개발 소프트웨어와 ARM 오픈 소스들을 제공하는 그룹으로, 데비안(우분투) 패키지 서버에 'linaro' 카테고리를 마련하여 이런 ARM 개발 소프트웨어들을 담아두고 있다. 우리는 linaro 의 개발 환경을 그대로 따라서 ARM을 공부할것이기 때문에, QEMU도 linaro에 맞추어 설치하여한다. 즉, linaro에 최적화된 QEMU를 이용하기 위해서는 리나로 프로젝트의 PPA에서 QEMU 관련 툴을 다운받아야한다.
그래서 우선 linaro-maintainers/tools 퍼스널 패키지 아카이브를 추가하는 것이다.
( linaro-maintainers/tools 디렉토리 서버에 QEMU 관련 패키지들이 포함되있다.)
2. 리나로 프로젝트 PPA가 source.list 추가되었으니, 혹시나 있을 구버전을 신버전으로 교체해주기 위하여
패키지 데이터베이스를 업데이트한다음 QEMU 관련 패키지들을 설치한다.
추가한 서버 '리나로/tools'
우선 이들을 받기 이전에 linaro-maintainers/tools 에 포함되있는 파일들 중에 각종 구버젼들을 모두 새로운 버젼으로 바꾸어주는 매우 간편한 명령어 sudo apt-get update 를 이용해 업데이트 먼저 해주자.
sudo apt-get install qemu-user-static qemu-system
이렇게 ARM을 위한 가상화 소프트웨어 QEMU를 모두 마련하였다.
우리가 ARM을 개발하기 위해 최종적으로 사용할 리나로(Linaro : Open source software for ARM SoCs / SoC 개발을 위한 '소프트웨어 모음'으로 우리가 사용할 OS도 있고, Versatile Express 라는 '가상 환경'도 있다.)를 그 QEMU 위에서 작용시킬것이다.
QEMU 위에서 작동시킬 '가상 이미지'를 만든 다음, SoC 개발을 위해 필요한것들만 모아놓은 'Linaro-Developer (custom-built Dedian-Linux)' OS 를 그 위에 설치하고, 'Versatile Express ARM Development Board'라는 'ARM 가상 환경'을 구축하여 ARM을 공부할것이다. 아래는 이에 대한 과정들이다.
5. 가상화 소프트웨어 QEMU 가 읽을 수 있는 vexpress.img 이미지 파일(크기는 2G)을 제작한다.
(흔히 DVD 이미지를 읽기위한 가상화 소프트웨어 DAEMON TOOLs를 생각하면 쉽다.)
우리가 vexpress.img 를 생성한 이유는 간단하다. 위에서 살짝 언급했던 DAEMON TOOL 로 큰 용량의 게임을 돌릴때, 여러 파일들을 들고 다닐 필요가 없고, 단지 '하나'의 '이미지 파일'만을 들고다니면 되니까 굉장히 간편하다. vexpress.img 와 이 DVD 이미지 파일간의 차이점이라면 단지 DVD 이미지 파일은 읽기만 가능하지만, vexpress.img는 그 안의 내용 파일들을 언제든지 수정 가능하다는 점이다.
쉽게 'ARM 개발 환경'을 큰 컴퓨터들을 들고 힘들게 관리할 필요없이, 이동성이 있는 USB나 SD카드에 저장해서, 컴퓨터 한 대를 간편히 들고다니는 것이다.
6. 리나로 홈페이지 http://www.linaro.org/ 에서 '다운로드 - Developer'란에서 hwpack_linaro-lt-vexpress-a9_20120221-1_armel_supported.tar.gz (Vexpress-a9 가상 하드웨어 환경을 위한 '하드웨어 팩') 와 linaro-o-developer-tar-20120221-0.tar.gz (Developer를 위한 linaro 소프트웨어 모음) 를 다운받는다.
이렇게 우리는 Linaro가 제공하는 ARM을 위한 모든 환경들을 QEMU를 통해 가상디스크 vexpress.img에다 세팅할 준비가 다 되었다.
7. 리나로 홈페이지 http://www.linaro.org/ 에서 '다운로드 - Developer - Instruction' 을 읽으면서 세팅을 마친다.
사실 이 과정이 제일 힘든 과정이다. 홈페이지는 모두 영문자로 되어있고, 각 자신의 상황에 맞추어 세팅을 진행해야 하기 때문이다. 그러나 내가 1번 부터 설명한대로 따라왔다면, 수많은 케이스들 중에 단 하나의 케이스의 상황에 우리는 놓아져있는것이다. 그럼 다음 설명만 잘 따라오면 된다. 그런데, 만약 1번 부터 6번 까지의 과정을 거치지 않은 사람들은, 밑에 설명이 맞지 않을것이다. 이런 분들은 리나로 홈페이지의 Instruction을 읽어보면서 자신의 상황에 맞게 설치하길 권장한다.
Linaro Developer Platform Team에서 출시된 우분투용 이미지들을 설치하기 위해서는 당신은 아래 설명된 2개의 아티펙츠(인공체)를 다운받아야합니다. 그리고 그것을 바이너리 이미지 ( vexpress.img 의 파일 정보를 보면 01010.. 바이너리 파일 포맷인 것을 볼 수 있다. )로 합쳐야하며 그 이미지(vexpress.img)를 SD카드나, USB 저장소에 저장하셔야합니다.
A disk image is a single file or storage device containing the complete contents and structure representing a data storage medium or device. A disk image is usually created by creating a complete sector-by-sector copy of the source medium(매체, 도구/복수형:media) and thereby perfectly replicating the structure and contents of a storage device.
Some disk imaging utilities omit unused file space from source media, or compress the disk they represent to reduce storage requirements, though these are typically referred to as ‘archive files’, as they are not literally disk images.
1. UX (User eXperience) root filesystem tarball : 이것은 보드와 독립적입니다.
- 여기서 UX의 의미는 쉽게 말하자면 '유저가 사용하고 싶어하는 것에 최적화한' 을 뜻합니다. Linaro는 ARM 개발 환경에 알맞게 모든 프로그램들과 root filesystem들을 사용하기 편하게 정리를 깔끔하게 해놓았으므로, ARM 개발 환경을 원하는 유저들은 이 tarball (파일들의 집합) 만을 다운받아 설치하면, 기타 다른 환경 세팅이 필요없이 완벽하게 설치됩니다. 이것이 유저가 편하다는 UX 의 뜻과 부합합니다.
2. Board package (hardware pack)
- hardware pack 이라고 부르는 것은 커널, bootloader와 같은 보드 특유의 bits와 보드 특유의 미들웨어 등을 제공합니다. 우리는 Board package 로 Versatile Express with A9x4 CoreTile을 이용할것입니다. 당신에게 필요한 (하드웨어팩)이 무엇인지 판단하기 위해서 이 링크를 따라주세요.
Root filesystems 와 hardware packs 에 대한 링크들은, ‘매달 출시 안내’를 언급하는 ‘출시 페이지’로 링크되어있습니다. 또한 우리는 구버젼의 daily snapshots뿐만 아니라 milestone builds의 아카이브(achive)들을 가지고 있습니다. (링크에 들어가시면 받으실 수 있습니다.)
이 두 아티펙츠를 모두 다운로드 한 후에, 당신은 linaro-media-create 툴을 사용하여, SD 카드에 당신의 이미지를 플래시할 수 있게 됩니다.
Installing linaro-media-create
다음 명령들은 Linaro tools ppa를 당신의 시스템에 추가하고, linaro-media-create를 인스톨할것이다.
$ sudo apt-get update
$ sudo apt-get install linaro-image-tools
linaro-image-tools 에 있는 linaro-media-create 를 이용하여, vexpress.img 에다가 root filesystems와 hwpack을 바로 다음 과정에서 플래시할것이다.
Generating an image for QEMU : QEMU를 위한 이미지 만들기
아래 명령어에서 환경 변수들을 세팅하여라, 당신은 바로 아래에 있는 명령에 의해 이 명령이 제공되는 여러 변수 값들이 무엇인지 알 수 있고, 각각의 알맞은 변수값들을 결정할 수 있다.
--help 를 이용하여 linaro-media-create 라는 명령어가 어떤 변수들을 지니고 있고, 각 변수에 어떠한 값들이 들어가야하는지 알려달라.
위 명령어로 변수들을 결정하였다면 당신이 이미지(vexpress.img)와 hardware pack을 다운로드 했던 디렉토리에서 linaro-media-create를 실행하여라.
--image-file : QEMU-이미지에 의해 만들어진 이미지 파일을 적어라.
- vexpress.img
--binary : 다운로드받은 linaro OS 파일을 적어라.
- linaro-o-developer-tar-_ _ _ .tar.gz
--hwpack : 다운로드받은 하드웨어 환경을 적어라.
- hwpack_linaro-lt-vexpress-a9_ _ _ .tar.gz
--dev : hwpack 인자에서 보드(하드웨어 환경) 식별자를 읽어서 적어라.
※ 추가로, linaro-media-create 명령어 실행중에 VERIFICATION 에 대한 이야기가 나온다면, NO 라고 대답하여라. Installations MUST be performed WITHOUT VERIFICATION when perform linaro-media-create
이제, 당신의 file.img 이미지 파일로 아까 다운받았던 linaro root filesystems와 hwpack을 플래시 완료하였다. (바이너리 이미지로 합쳤다.)
이 페이지는 QEMU의 Versatile Express의 상태(정보)를 간단하게 요약해놓았고, 어떻게 그 위에 Linaro snapshot을 작동시킬지 설명한다.
http://ko.wikipedia.org/wiki/%EC%8A%A4%EB%83%85%EC%83%B7_(%EA%B8%B0%EC%96%B5_%EC%9E%A5%EC%B9%98)
Status of Versatile Express support
Implemented components:
- Quad-core A9MP
- Up to 1GB RAM
- SD/MMC card
- CLCD graphics, keyboard and mouse
- Serial ports
- Timers and RTC
- LAN9118 ethernet
Missing components:
- No USB (no model of the ISP1761 USB chip)
- No modelling of the Flash memory
- Components like the PL341 dynamic memory controller, PL354 static memory controller, PL310 L2 cache controller are not implemented (not even as dummy registers). This causes no problems for Linux booting but will probably be needed if we want to run u-boot or the VE boot ROM or other low level setup code
- No Trustzone support (either in QEMU's A9 core model or in the Trustzone address space controller etc on the board)
- We provide a PL110 CLCD controller, not a PL111
- No Compact Flash
- No audio (no PL041 model)
- We don't implement remapping low memory; it is always RAM
- No support for running the VE boot ROM -- you must provide the kernel and initrd directly to qemu
이중에서 몇 개의 구성요소들이 없더라도, Versatile Express 모델은 일반적으로 작동한다. Support (Support는 작동중인 키보드와 마우스 supprt를 포함한다.) 는 Linaro 이미지들이 root prompt와 display graphics를 부팅하기 위해 완벽하다. 이 support들은 ‘versatilepb’ 또는 ‘realview-pbx’ 모델들을 위해 존재하는 QEMU support와 거의 같은 레벨이거나, 더 높은 레벨의 수준이다.
Creating Linaro Versatile Express images for qemu-linaro
이 과정을 수행하는 방법들 중에, 제일 간단한건 releases.linaro.org 에서 vexpress SD 카드 이미지 파일을 받는것이다. (예를 들어 images/12.01/oneiric/nano/ -- 다른 릴리즈 혹은 이미지 취향에 맞게 조정해서 다운받아라.) 아니면 만약에 당신이 snapshot 이미지들을 다 마련한 이후의 단계에 있다면, 당신은 linaro-media-create 를 이용하여 당신만의 이미지(QEMU-img)를 만들 수 있다. 만약에 snapshot 이미지가 gzipped 되있다면 이미지를 Umcompress하라.
이제 당신은 snapshot 이미지 파일로 부터 kernel 과 initrd 를 추출해야한다.
a scheme for loading a temporary file system into memory in the boot process of the Linux kernel. initrd and initramfs refer to slightly different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted.
아래에 (IMG=vexpress.img...로 시작하는 커맨드는 마운트가 될 '파일(file)'과 이미지 파일에서 두번째 파티션의 offset(어떤 주소로부터 간격을 두고 떨어진 주소와의 거리)를 찾아 내기위한 'awk'를 이용한다. 그리고 나서 /mnt/mnt에 루프백 마운트를 이용하여 마운트 시킨다.
a data extraction and reporting tool that uses a data-driven scripting language consisting of a set of actions to be taken against textual data (either in files or data streams) for the purpose of producing formatted reports. : 자료 처리 및 리포트 생성에 사용하는 프로그래밍 언어
우선 리나로 가상 디스크를 마운트하기 위한 디렉토리(파일)를 준비한다
그리고 가상 디스크를 /mnt/mnt에 마운트한다. (virtual disk 마운트)
위의 마운트 과정에 의하여 모든 파일 세팅이 /mnt/mnt 안에서 이루어진다. /mnt/mnt/boot 에는 마운트 과정에서 boot에 관련된 모든 파일들이 저장되는데, 이 boot 관련 파일들을 '현재 머물러있는 경로'라는 의미의 '로컬'의 boot 파일로( = local/boot )로 모든 kernel 과 initrd 을 복사한다. (kernel 과 initrd 를 추출하는 과정이다.)
$ sudo chown -R kauce:kauce boot
$ sudo umount /mnt/mnt
USB와 SD카드에 우리가 추출한 'boot 파일 전부'(kernel 과 initrd 를 포함하고 있다.)와 'vexpress.img 파일'만을 들고다니면 어느 우분투 컴퓨터에서든 아주 빠른 시간내에 ARM 개발환경을 구축할 수 있다.
* kernel, initrd 를 포함한 'boot 파일'
* 'vexpress.img'
8. 이렇게 해서 추출된 kernel(커널)과 initial ramdisk(initrd), 그리고 virtual disk를 가지고 QEMU 가상 머신을 실행시키면, 우리의 최종 목적인 'ARM 개발 환경 구축'이 끝난다.
$ qemu-system-arm –kernel boot/vmlinuz-3.2.0-1800-linaro-lt-vexpress-a9 -M vexpress-a9 -cpu cortex-a9 -serial stdio –m 256 –initrd boot/initrd.img-3.2.0-1800-linaro-lt-vexpress-a9 -append 'root=/dev/mmcblk0p2 rw mem=256M raid/noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' –sd vexpress.img
- 메모리는 256M 으로 하향조정하였다.
- kernel : OS Kernel image
- initrd : Initial ramdisk image
위 qemu-system-arm 명령어는 우리가 'ARM 개발 환경 구축'을 하고싶을때 마다 작성해야할 명령어이다. 보다시피 명령어 길이가 길기때문에 매 시간마다 이 명령어를 치기에는 약간 귀찮을 수 있다. 그래서 이 statement를 shell(.sh) 쉘 파일로 저장해놓아 명령어를 치는 대신에 쉘 파일만 실행시키면 간단하게 환경 구축을 끝낼 수 있다.
arm.sh 라는 이름의 쉘 파일을 작성한다. 'chmod 755 arm.sh'로 설정하고, 이 파일을 실행하고 싶을때는 이 arm.sh 이 있는 디렉토리로 가서 './arm.sh'만 명령어에 작성해주면 된다. QEMU VM을 끄고싶다면 'shutdown -h now' 명령어를 작성해주면 된다.
* kernel, initrd 를 포함한 'boot 파일' - QEMU VM에서 OS를 boot하는데에 필요한 파일
* 'vexpress.img' - QEMU VM에서 수정, 작성된 내용들이 저장될 가상 하드디스크
* 'arm.sh' - QEMU VM을 실행하기 위한 명령어 모임
명령어를 실행하였을때 (arm.sh) 펭귄이 나온다면, 모든 환경 구축이 끝난것이다.
WELCOME!
'시스템 프로그래밍 > - 강의 정리' 카테고리의 다른 글
| 시스템 프로그래밍 - 4 (2) : Data Processing Instructions - Arithmetic operations (0) | 2012.04.05 |
|---|---|
| 시스템 프로그래밍 - 4 (1) : Data Processing Instructions - Logical operations (0) | 2012.04.05 |
| 시스템 프로그래밍 - 3 : Load / Store Instructions (0) | 2012.04.05 |
| 시스템 프로그래밍 - 2 : System Data Structure (시스템 데이터 구조) (0) | 2012.04.04 |
| 시스템 프로그래밍 - 1 (1) : 시스템 공부의 의의 (0) | 2011.03.05 |
