<img src="http://cfs.tistory.com/custom/blog/33/335997/skin/images/banner_spring10s.jpg" border=0 alt="가일의 임베디드 스쿨" />

응용프로그램을 플래시에 저장하기

다음의 명령을 이용하면 응용프로그램을 플래시에 저장하여 필요할때 사용할 수도 있다.

blob> flash kernel [ENTER]

해당 응용프로그램은 리눅스 커널이미지를 저장하는 플래시 영역에 마찬가지로 기록된다.

이후 부터는 보드의 blob 부팅후 자동적으로 응용프로그램이 로드(load) 되어 실행된다.

주의사항!

flash kernel 명령을 사용하게 되면 기존의 플래시 메모리에 들어 있을지도 모르는 리눅스 커널 혹은 zImage 데이타는 사라지게 되므로 이 사실을 꼭 알고 실행하는데 주의를 바란다.

blob과 MMU

현재의 blob v1.07 버젼에는 ARM920T MMU 가 비활성화 되어 있다. 특별한 이유는 없고 현재 기능 구현이 안되어 있다고 보면 된다.

이후의 과정에서 필요한 경우 MMU 기능을 적용할 것이다. 캐시(cache) 또한 마찬가지로 비활성화 되어 있다.

아는 사람은 잘 알고 있는 내용이지만 uboot 라는 부트로더도 또한 MMU와 D캐시가 비활성화 되어 있다.

따라서, uboot 상에서 MMU및 데이타 캐시를 활성화 시키려면 추가의 노력이 필요하다. 한편 명령어 캐시(I-캐시)는

활성화 되어 있다. 따라서 이로 인한 큰 불편함은 없는 것이 또한 사실이다.

한가지 더 이야기 하자면

현재의 blob 에는 어떠한 인터럽트 또한 사용되고 있지 않다. 이 사실을 추가적으로 확인하기 바란다.

금번의 칼럼을 마지막으로 제2부 부트로더 제작 편을 모두 마칠것이다.

그러면 다음 제3부 응용 장치의 활용편에서 다시 뵐 것을 약속드리며 blob에서 사용되는 uu[en|de]code 에 대해서 설명을 끝으로 본 칼럼을 마무리 한다.

uu[en|de]code

현재 blob 에서 파일을 다운로드 하는데 사용되는 uuencode 는 구글에서 찾아보면 다음과 같이 잘 설명되어 있다. http://www.terms.co.kr/Uuencode.htm

기본적으로 Uuencode가 하는 일은 파일이나 전자우편의 첨부물을 자체 바이너리 또는 비트 스트림 표현에서 7 비트 아스키 텍스트로 변환하는 것이다.

텍스트는 오래 전에 제작되어 바이너리 파일을 처리할 수 없는 시스템에서도 잘 처리될 수 있으며, 커다란 파일들을 좀더 쉽게 여러 부분으로 나누어 전송할 수 있다.

blob 에서는 uuencode 라는 유틸리티로 다운로드할 파일을 먼저 변형시킨후 이를 통신터미널을 이용해서 다운로드하고 blob 에서는 이를 다시 uudecode 하는 방법으로 uu[en|de]code가 사용되고 있다.

수고 하셨습니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/80

부트로더 제작 10편. blob과 응용프로그램 실행기능 - 2009/02/10 23:15

download.ex_

blob_ahav9302_107.tar

금번 칼럼에서는 cirrus EP9302에 포팅된 완전한 blob 소스코드를 첨부한다.

따라서, 지난강좌에서 여기!!

이미 소개한 바 있는 내용이지만 다시한번 이전 버젼(v1.00)과의 차이점과 함께 blob 프로그램 이미지를 타겟보드에 내리는 방법에 대해서 알아보도록 하겠다.

앞으로의 강좌에서나 또한 여러분들이 해당 보드를 가지고 직접 프로그램 개발을 하기 위해서 꼭 사용되는 방법인 만큼

본 방법을 잘 숙지토록 하여야 겠다.

첨부파일: download.exe ; BLOB 이미지를 타겟보드에 내려주는 윈도우즈 전용 프로그램

blob-ahav9302-107.tar ; BLOB 소스코드( ver1.07 )

이전 버젼(v1.00)에 비해 추가된 가장 큰 특징은 다음과 같다.

ver1.07의 특징

(1)응용프로그램(kernel) 을 메모리(램)상에 다운로드 하고 실행해 볼 수 있는 기능

(2)위 응용프로그램을 FLASH의 커널위치상에 라이팅(writing)하고 실행 할수 있는 기능

여기서 응용프로그램 이라 함은 리눅스 커널 이미지에 대응되는 것으로서 blob 은 리눅스 커널만을 다운로딩하고 실행 하라는 법은 없다.

일반 펌웨어 이미지도 해당 위치에 같은 요령으로 다운로드하고 실행 가능 한것이다.

그러므로 응용프로그램이라는 용어는 blob 이 실행되는 보드상에 다운로드 되어 지고 자체로 실행가능한 바로 그것을 칭한다.

blob 프로그램 이미지 타겟보드에 내리기

[그림2] BLOB 이미지를 다운로드 하기 위해 사용되는 버튼

BLOB 프로그램을 타겟보드에 올리는 요령(순서)

(1)[그림2]의 예시와 같이 타겟보드와 시리얼 케이블로 연결한다. 그리고 보드에 전원을 인가한다.

(2)[그림3]의 예시와 같이 cirrus 에서 배포한 UART 를 이용한 시리얼 다운로드 프로그램인 'download' 프로그램을 실행시킨다.

(주1. 씨러스에서 배포한 download 프로그램은 각각 linux 용과 win 용으로 제공된다.)

(주2. 각각 보드레이트와 시리얼 포트가 정확한지 확인 필.)

(3)타겟보드의 BOOT 버튼을 지그시 누른 상태에서 POR 버튼을 누르면 곧 바로 다운로드가 시작된다.

[그림3] 다운로드 프로그램의 실행 화면

필자의 경우 USB2SERIAL 케이블을 사용한 관계로 SERIAL PORT3이 사용되었다.

성공적으로 다운로드가 완료된 경우 다음과 같은 메시지가 나타난다.

C:\Temp>download -b 115200 -p 3 blob.bin
Using Serial Port 3
Flash Manufacture ID:0089, Device ID:0018
Successfully programmed 'blob.bin'.

blob을 실행 시켜 보기

이제 타겟 보드에서 BLOB 이 정상적으로 동작하는지 확인 해 보는 일만 남았다. 이를 위하여는 PC 호스트 상에서 터미널 프로그램을 사용하여야 하는데 바이너리 파일을 전송할수 있는 기능을 가진 터미널 프로그램이면 어떤 것이든 무방하겠다.

리눅스용으로 Minicom 이나 윈도우즈에서는 하이퍼터미널 정도가 그 예가 될 수 있다.

필자의 경우는 [그림4] 처럼 윈도우 환경에서 테라텀을 사용하였다.

[그림4] blob이 실행된 타겟보드와 연결한 터미널 화면

타겟보드에 BLOB 프로그램을 내리고 케이블 연결후 터미널을 보면 대개 [그림4]와 같은 메시지를 확인할 수 있어야 한다.
만약에 그림과 같이 메시지가 보이질 않는다면 본 칼럼의 절차를 다시 확인후 그래도 안될 시에는 게시판이나 덧글로 문의 바란다.

터미널 창에 다음과 같이 입력하여 보자.

blob> help [ENTER]

이후 메시지들이 디스플레이 될것이다. 이후 강좌에서 BLOB 소스를 분석할 시에 이야기 하도록 하겠지만 여러분들이 보시고 계신 터미널(테라텀)상의 모든 메시지들은 타겟 보드에서 뿌려 주고 있는 것들이다. 더불어 여러분들이 키보드에서 입력한 모든 명령들은 마찬가지로 타겟보드에서 해석되고 실행되며 마지막으로 실행 결과를 터미널에 보여 주는데 이 모든 행위를 BLOB에서 관장한다.

주의사항!

부팅후 10초안에 키보드중 아무키나 누르기 바란다. 나중에 다시 설명하겠지만 현재 플래시 메모리에는 커널이미지나 응용프로그램이 없고 blob 이미지 만이 only 들어 있기 때문에 부팅 10초후에는 자동적으로 커널을 실행하게 된다. 따라서 플래시에는 아직 커널이 존재 하지 않는 관계로 그냥 놔두면 시스템은 폭주 하게 된다. 이후 커널이미지나 응용프로그램이 플래시에 내장되게 되면 이같은 주의 사항은 고려 하지 않아도 되겠다.

uuencode 설치하기

사용하는 리눅스 개발 환경에서 uuencode 명령을 다음과 같이 실행 해 본다.

이는 이후의 작업을 위해서 필수적이다.

#uuencode[ENTER]

uuencode: Command not found.

만약 위의 예시처럼 해당 명령이 존재 하지 않는 것으로 표시 된다면 이후 소개하는

방법대로 해당 기능을 설치를 해야 한다.

리눅스 패키지중 sharutils 내에 uuencode 툴이 들어 있다.

셸프롬프트에서 다음과 같이 입력한다.

# yum install sharutils

이후 부터는 설치 안내에 따라 진행하면 된다.

응용프로그램 이미지 만들기

본 배포본(blob-ahav9302-107.tar)에는 데모용 응용프로그램을 만들수 있도록 함께 코딩이 되어져 있다.

데모 프로그램 이미지를 만들기 위해서는 다음의 방법을 따른다.

첫째, include/config.h 파일 수정

아래처럼 적색부를 활성화 시킨다.

/* Version number of package */
#define VERSION "1.0.8-pre2-ahav107"

/* FIRMWARE 컴파일 사용시 설정 */
#define __BUILD_USER_APP

#endif

둘째, Makefile 파일 수정

blob 이미지 만들때는 (가)를 활성화 시키며,

응용프로그램 만들때는 (나)를 활성화 시킨다.

.EXPORT_ALL_VARIABLES:

#TEXT_BASE = 0xC3C00000 ...........(가)

#
# __BUILD_USER_APP 컴파일시 설정
#
TEXT_BASE = 0xC0008000 ...........(나)

CROSS_COMPILE = arm-linux-

이처럼 수정후 프롬프트 상에서 다음과 같이 실행하면

# make clobber [ENTER]

# make [ENTER]

최종적으로 'blob.uu' 파일이 만들어 졌을것이다.

해당 폴더내에 blob.bin 은 있으나 위와 같은 파일('blob.uu' )이 안만들어 졌을경우

이미 앞서 설명한 'uuencode 설치하기'가 정확히 안되었을 가능성이 높다.

응용프로그램 다운로드및 실행해 보기

터미날 상에서 다음과 같이 입력한후 테라텀의 파일-파일보내기[S] 메뉴를 선택하면

'[그림5] 응용프로그램의 다운로드' 처럼 화면이 나타난다. 이후 'blob.uu' 을 선택한다.

blob> download kernel [ENTER]

[그림5] 응용프로그램의 다운로드

잠시 후 다운로드가 완료되며 다음과 같은 방법으로 해당 프로그램을 실행 해 볼수 있다.

blob> boot kernel [ENTER] 혹은 boot [ENTER]

특별한 문제가 없다면 '[그림6] 응용프로그램의 실행화면' 처럼 Hello World라는 문장이 보일것이다.

[그림6] 응용프로그램의 실행화면

NEXT. . . 다음 시간에는 blob과 MMU에 대해 알아 봅니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/79

부트로더 제작 9편. startup (III) 클럭시스템과 sdram 초기화 - 2009/02/10 23:14

그림1. lowlevel_init.S 소스코드

이번 시간에는 부트 스타트업 기동시 행해지는 주요한 시스템 specific 한 동작들. 예컨대 클럭설정및 SDRAM 초기화 등의 주제를 다루어 본다.

섹션 BB, HH 에서는 링크레지스터(lr)의 값을 임시 보관하고 있는 scratch 레지스터의 사용이 눈에 띤다. EP9302 프로세서에는 위와같이 소용량의 메모리 혹은 레지스터가 별도로 존재하여 필요시 유용하게 사용 될 수 있다.

*[CC] : flash_cfg. strata FLASH 메모리를 사용키 위해서 static memory controller 의 초기화를 수행한다. 버스 인터페이스는 16비트, wait 클럭의 수는 single과 burst access 가 구별되어 각각 3HCLK, 6HCLK 로 설정된다. 이는 비교적 느린 속도의 FLASH 메모리의 버스 인터페이스 타이밍을 맞추어 주기 위함이다.

*[DD] : pll_cfg. 66MHz의 HCLK, 33MHz의 PCLK 주파수 선택을 위한 PLL1과 USB 클럭 주파수를 위한 PLL2의 초기화가 진행된다.

*[FF] : sdram_cfg.

SDRAM 초기화 는 ('그림2. sdram_cfg.S 소스코드' 참고) 60~62라인의 Dev config 중 특히 latency 값의 세팅에 주의 하여야 하며 마찬가지로 80~86라인의 refresh timer 값의 적절한 선택과 92~101라인의 MODE 레지스터 값의 적정성이 주요한 것이된다.

1 /*
2 * SDRAM setup for Olimex CS-E9301 board
3 *
4 * Copyright (C) 2006 Dominic Rath <Dominic.Rath@gmx.de>
5 *
6 * See file CREDITS for list of people who contributed to this
7 * project.
8 *
9 * This program is free software; you can redistribute it and/or
10 * modify it under the terms of the GNU General Public License as
11 * published by the Free Software Foundation; either version 2 of
12 * the License, or (at your option) any later version.
13 *
14 * This program is distributed in the hope that it will be useful,
15 * but WITHOUT ANY WARRANTY; without even the implied warranty of
16 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
17 * GNU General Public License for more details.
18 *
19 * You should have received a copy of the GNU General Public License
20 * along with this program; if not, write to the Free Software
21 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
22 * MA 02111-1307 USA
23 */
24 #include <ep93xx.h>
25
26 /* delay for 200us
27 * loop takes 4 cycles at 6.02ns per cycle = 24.1ns
28 * 0x3000 (12288) gives us 296us to be safe
29 */
30 .macro delay200
31 ldr r0, =0x3000
32 200:
33 subs r0, r0, #1
34 bne 200b
35 .endm
36
37 .globl sdram_cfg
38 sdram_cfg:
39 /* 1x Samsung K4S561632C-TC/L75 4M x 16bit x 4 banks SDRAM
40 *
41 * CLK cycle time min:
42 * @ CAS latency = 3: 7.5ns
43 * @ CAS latency = 2: 10ns
44 * We're running at 66MHz (15ns cycle time) external bus speed (HCLK),
45 * so it's safe to use CAS latency = 2
46 *
47 * RAS-to-CAS delay min:
48 * 20ns
49 * At 15ns cycle time, we use RAS-to-CAS delay = 2
50 *
51 * SROMLL = 1: Swap BA[1:0] with A[13:12], making the SDRAM appear
52 * as four blocks of 8MB size, instead of eight blocks of 4MB size:
53 * 0x00000000 - 0x007fffff
54 * 0x01000000 - 0x017fffff
55 * 0x04000000 - 0x047fffff
56 * 0x05000000 - 0x057fffff
57 *
58 * BANKCOUNT = 1: This is a device with four banks

59 */
60 ldr r0, =0x0021002c
61 ldr r1, =SDRAM_BASE
62 str r0, [r1, #0x10] /* SDRAMCFG0 */
63
64 /* Issue continous NOP commands */
65 ldr r0, =(GLOBALCFG_INIT | GLOBALCFG_MRS | GLOBALCFG_CKE)
66 str r0, [r1, #0x04] /* SDRAMGLOBALCFG */
67
68 delay200
69
70 ldr r0, =(GLOBALCFG_INIT | GLOBALCFG_CKE)
71 str r0, [r1, #0x04] /* SDRAMGLOBALCFG */
72
73 /* Load refresh timer with 10 to issue refresh every 10 cycles */
74 ldr r0, =0x10
75 str r0, [r1, #0x08] /* SDRAMREFRESHTIMER */
76
77 /* Wait at least 80 clock cycles to provide 8 refresh cycles to all SDRAMs
*/
78 delay200 /* we wait 200us, which is a lot more than necessary */
79
80 /* Program refresh timer with normal value
81 * We need 8192 refresh cycles every 64ms at 15ns per cycle:
82 * 64ms / 8192 = 7.8125us
83 * 7.8125us / 15ns = 520 (0x208)
84 */
85 ldr r0, =0x01e0
86 str r0, [r1, #0x08] /* SDRAMREFRESHTIMER */
87
88 /* Select mode register update mode */
89 ldr r0, =(GLOBALCFG_CKE | GLOBALCFG_MRS)
90 str r0, [r1, #0x04] /* SDRAMGLOBALCFG */
91
92 /* Program mode register
93 * A[22:09] is output as SYA[13:0] on a 16 bit ext. bus
94 * CAS latency: 2
95 * Burst type: sequential
96 * Burst length: 8 (required for 16 bit ext. bus)
97 * SYA[13:0] = 0x0023
98 */
99 /*ldr r0, =0x00004600*/
100 ldr r0, =0xc0004600
101 ldr r0, [r0]
102
103 /* Select normal operation mode */
104 ldr r0, =(GLOBALCFG_CKE)
105 str r0, [r1, #0x04] /* SDRAMGLOBALCFG */
106
107 mov pc, lr
108

그림2. sdram_cfg.S 소스코드

pll 설정이나 sdram의 설정은 모두 시스템에 지대한 영향을 끼치는 요소들인 만큼 주의가 필요하며 한편, 이에 대한 부주의로 혹은 잘못된 이해로 설정값이 잘못되었을 경우 시스템이 정지(halt) 할 수도 있게 된다.

이에 마찬가지로 이와 관련된 코드의 디버깅에도 세심한 방법이 요구되어 '그림1. lowlevel_init.S 소스코드' 과 같이 'AA', 'EE', 'GG' 섹션처럼 led가 적극적으로 사용되어 만일에 코드가 실행중 정지되더라도 마지막 실행된 위치를 즉각적으로 파악 할 수가 있게 된다.

예를들어 위와 같은 코드의 실행시 그 결과 GREEN LED는 꺼져 있고 RED LED는 켜져 있게 된다면 sdram_cfg 코드의 실행중 프로그램은 'halt' 되었다는 것을 쉽게 알수 있게 된다.

NEXT. . . 다음 시간에는 blob의 mmu 설정과 main() 을 살펴 봅니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/78

부트로더 제작 8편. startup (II) LED의 활용례 - 2009/02/10 23:13

지난시간에 부트로더의 relocation(재배치) 기능을 소개하였다.

이번 시간에는 프로그래머라면 한번쯤은 궁금하게 생각하였던 부분을 건들여 보는 것으로 금번의 강좌를 시작해 보겠다.

바로 프로그래밍 모델이라고 부르는 것이다.

설명을 위해 간단한 'c' 코딩을 즉석에서 해보자.
1 int glvar1 = 0; // '0'으로 초기화
2 int glvar2; // 초기화 하지 않음
3
4 int main(void)
5 {
6    int i;    // 지역변수(자동변수)
7    char* pIMG;
8
9    glvar2 = 70;
10    pIMG = malloc(1024); // using heap memory
11    중략...
12

전역변수와 지역변수

코드라인 1과 2의 변수를 우리는 뭐라고 부르는가? 전역변수 맞다. 영어로는 'global variables' 라고도 부른다.
이에 반해 코드라인 6의 변수를 우리는 지역변수 혹은 자동변수라고 불러서 이는 통상 CPU의 레지스터 혹은 스택에 그 영역이 확보되고 사용된다. 지역변수는 또한 필요할 경우 생성되었다가 소멸되는 특징을 가지고 있다.

초기화 된 변수와 초기화 되지 않은 변수

둘다 전역변수인 코드라인 1과 2의 차이점이 보이는가? 코드라인1의 glvar1 은 프로그래머가 의도적으로 0으로 초기화 한 반면 glvar2 는 현재 초기화 되어 있지 않다.

그렇다면 glvar2 에는 어떤 값이 들어가 있을까? 쓰레기값이 들어가 있을까? 마이크로프로세서 내장 임베디드 시스템의 거의 모든것들은 이에 대한 처리로서 이렇게 프로그래머가 의도적이든 의도적이 아니든 초기화 하지 않은 모든 변수들을 일괄적으로 'zero out(clear)' 시키는 기능이 들어가 있다. 보통 부트스타트업 코드에 이러한 기능을 하는 코드를 넣어둔다.
( 만약에 여러분이 사용하는 임베디드 시스템 'start.s' 코드내에 이러한 기능을 하는 코드가 없다면 아마도 이의 처리를 컴파일러가 직접하는 경우다. 이 설명까지 하게 되면 강좌가 너무 복잡하게 전개되기 때문에 본 강좌에서는 생략한다. )
결론적으로 코드라인 1과 2 모두 0으로 초기화 된다고 할 수 있다.
임베디드 시스템에서는 glvar1 처럼 초기화된 변수 영역을 지칭하여 .data 혹은 RW 영역이라고 칭한다.
한편, glvar2 처럼 초기화 하지 않은 변수 영역을 BSS 영역이라고 부른다.

전시간 강좌 부트로더 제작 6편의 '그림2. start.S 소스코드' 을 참고 하기 바란다. 'AE' 섹터를 보면 바로 이 영역(BSS)의 처리를 하고 있음을 확인 할수 있다.

다음과 같이 정리해 보도록 한다. 부트스타업 코드의 역할중 하나는 바로 '프로그래머 메모리 초기화' 인것이다.

임베디드 시스템에서의 malloc

우리는 보통 동적 메모리 할당(Dynamic Memory Allocation)을 할때 new() 나 malloc() 함수를 이용하곤 한다.

그리고 이렇게 사용자가 요청한 메모리는 소위 힙메모리(HEAP)라는 곳에서 할당 받게된다.

이의 처리는 실제로는 메모리관리자라고 부르는 코드(소프트웨어)가 담당한다. 이 코드는 우리가 사용하는 컴파일러내의 라이브러리에 들어 있다.

그렇다면 임베디드 시스템에서 HEAP 메모리는 어떻게 초기화 시켜야 하는가? 아니 어떻게 사용할 수 있는가.
그림2. start.S 소스코드 내 'AD'섹터 와 그림3. blob 의 프로그램 메모리(SDRAM상) 구조도를 함께 보면 좋겠다.

첫째, 다른 프로그램들에 의해서 방해받지 않는 별도의 메모리 영역을 확보한다. 둘째, 컴파일러에게 HEAP 메모리의 존재 유무와 그 위치를 알려주어야 한다. 통상 링커환경파일(blob의 예로는 'ld-script')에 그 내용을 기재해 주도록 되어 있는 경우가 많다. 현재 우리가 사용하는 'blob' 에는 아쉽게도 그 한가지 처리가 들어가 있지 않다. 따라서 HEAP 을 사용하는 malloc 류의 함수는 사용 할 수 없다고 말 할 수 있겠다.

이상과 같이 '프로그래머 메모리 모델'을 간단히 살펴 보았다. 비록 추가적으로 언급하지는 않았지만 메모리 모델에는 몇가지 테마가 사실상 더 있다. 임베디드시스템에서의 const 변수의 의미라든가 volatile, static 변수의 의미, 초기화된 배열및 스트링데이타 등이 있겠다.

이후에 시간이 허락하면 '프로그래머 메모리 모델'을 한번 정리해 보겠다.

임베디드시스템의 디버깅 방법론 하나! LED

이번 시간에는 누구나 알고 있슴직한 LED(light emitted diode) 라고 부르는 발광다이오드에 대한 이야기를 해보도록 한다.
전자공학을 전공하지 않은 이라도 누구나 잘 알고있는 즉, 전기가 통하면 불이 들어오고 반대로 하면 불이 꺼지는 바로 그 부품이다.
버스타고 도심을 가로지르면 상점들 간판이나 윈도우에 장식한 전광판들이 요즘 눈에 많이 들어온다.

우리가 지금부터 살펴 볼것은 이의 다른 특별한 사용례 정도가 될 것이다.

UART 장치는 통상 콘솔(CONSOLE) 이라고도 불리워서 임베디드 소프트웨어 디버깅시에 즐겨쓰는 도구이다. 프로그래머가 원하는 문자열을 화면에 디스플레이 하게끔 해서 내가 실행한 코드가 정확히 수행되었는지. 실행시 중단되지는 않았는지를 확인하기 위하여 사용되는 필시 좋은 도구임이 틀림없다.

하지만, 이러한 도구를 이용하기 위하여는 적절한 초기화가 필요하다. 이후의 강좌에서 다룰것인데. main() 루틴에 와서야 UART 장치의 초기화가 이루어 짐으로 인해 불행히도 우리가 'start.s' 라는 코드를 디버깅 할때는 사용할 수가 없다. 이쯤와서 눈치 빠른 분들은 필자가 무슨 이야기를 하려는지 짐작 하실 것이다.

바로 main() 루틴이 실행되기전의 절대적인 디버깅 도구로서의 LED 역할을 지금부터 설명하려는 것이다.

'start.s' 소스중 'AF' 섹터의 184라인을 보면 두개(각각 녹색/적색)의 LED를 모두 끄는 함수(clr_lightled)가 실행되고 있다. 또한, 'main.c' 소스중 7라인을 보면 두개의 LED 켜는 함수(set_lightled)가 실행되고 있다.

위의 프로그램을 실행 시켜 보아 만약 LED가 하나만 켜져 있거나 모두 꺼져 있다면 시스템은 어떤 상태임을 의미하는가? 알지 못하는 어떤 문제가 발생하여 main() 함수를 진입하지 못하였음을 알 수 있고 LED 켜고 끄는 함수를 적절히 위치를 바꾸어 가며 실행해 본다면 어떤 함수를 실행중에 시스템 critical failure 가 발생하였는지를 확인 할 수 있다.

LED는 필경 단순한 장치임에 틀림없으나 이렇게 사용하기에 따라서 우리에게 간단한 설정만으로 꼭 필요한 기능을 잘 수행해 주도록 임무를 부여 할 수도 있다.

이후의 프로그램 그리고 강좌에서는 이 LED가 적극적으로 활용된다.

NEXT. . . 다음 시간에

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/77

부트로더 제작 7편. startup - 2009/02/10 23:12

blob_ahav9302_106.tar

보통 부트 스타트업 코드는 어셈블리로 작성되어 있는 경우가 많다. 우리가 지금 보고 있는 부트로더도 마찬가지여서 스타트업 코드가 존재하고 이제부터 우리는 이의 분석을 진행 하려 한다.

부트 스타트업 코드를 필자는 다음과 같이 5가지의 테마로 세분화 하였으며 금번 시간에는 이중 첫번째로 (1)을 분석한다. (2),(3),(4),(5)는 다음회차 강좌에서 진행 할 계획임을 더불어 알린다.

분석목표

(1)relocation

: 코드가 저장되어 있는 공간인 플래시메모리에서 부트후 self 코드를 SDRAM 영역으로 복사하여 2차로 실행되는 과정

(2)programmers memory initialization

: 초기화된 데이터 영역(.data), 초기화 되지 않은 데이터 영역(.bss), 스택, 동적메모리(.heap)의 초기화 시퀀스

(3)MMU

: MMU의 처리

(4)PLL config

: CPU core / BUS clock의 컨피규어

(5)SDRAM config

: SDRAM controller 초기화

첨부 소스의 설명

첨부된 소스는 금번시간과 다음 시간에 걸쳐 startup 동작에 대한 설명에 촛점을 맞추기 위하여 부트로더의 소스코드중 startup 엔트리에서 main() 함수로의 진입까지의 소스만을 발췌하였다.

주요 파일 리스트

Makefile
ld-script
blob.bin

src/flash_cfg.S
src/lowlevel_init.S
src/pll_cfg.S
src/sdram_cfg.S
src/start.S
src/main.c

include/ahav9302.h
include/config.h
include/ep93xx.h

타겟보드에 코드를 컴파일하여 다운로드 하는 방법에 대한 설명

#tar xvf blob-ahav9302-106.tar ; 배포 이미지 압축을 푼다

#cd blob ; blob 폴더로 이동

#make clobber ; 컴파일하기 전에 오브젝트및 바이너리들을 깨끗하게 지우기

#make ; 컴파일

.. 이상이 없다면 해당 blob 폴더내에 'blob.bin' 이라는 실행파일이 만들어 졌을 것이다.

이 파일을 download 툴을 이용하여 타겟 보드에 다운로딩 한다.

타겟 보드에 다운로딩하는 요령에 대하여는 이전의 강좌를 참고 할것.

#download -b 115200 -p 3 blob.bin ; 115000baud, COM3 사용의 예

프로그램 다운로딩이 끝났다면 보드의 리셋버튼을 눌러보자. 혹은 보드의 전원을 켜보자.

'그림1. LED가 동작하는 ahav9302 보드 참조' ahav9302보드의 LED 부분을 보면 LED가 두개 있을 것이다. 이 LED가 각각 적색, 녹색등으로 켜진다면 정상적으로 실행된 것이다. 반면, LED가 안 켜지거나 녹색등만 켜진다면 오동작을 한 것으로 보면 된다

그림1. LED가 동작하는 ahav9302 보드

다음부터의 설명에는 start.S 을 주목하여야 한다.

그림2. start.S 소스코드

"그림. start.s 소스코드" 각 섹션의 설명

*[AA] : ARM의 동작 모드를 수퍼바이져 모드로 변경한다.

*[AB] : MMU제어, PLL config, CPU core / BUS clock의 세팅, SDRAM config 등의 작업을 수행한다.

*[AC] : relocation 작업. 코드가 저장되어 있는 공간인 플래시메모리에서 부트후 self 코드를 SDRAM 영역으로 복사하여 2차로 실행되는 과정이 일어나며 이 작업의 목적은 아래의 relocation 절에서 설명될 것이다.

*[AD] : 스택의 초기화.

*[AE] : bss 영역의 초기화.

*[AF] : LED 'TURN OFF'
*[AG] : c_main() 의 호출

relocation

ahav9302 보드의 SDRAM은 그 크기가 64M바이트 이며 0xC000.0000가 그 시작 주소이다. 한편, FLASH 는 그 크기가 16M바이트 이며 0x6000.0000가 그 시작 주소이다.

relocation 은 두가지 정도의 목적을 가지고 있다. (첫째), 코드가 실행되는 플래시 메모리는 SDRAM 에 비해 읽고 쓰는 속도가 느리다. 따라서, 고속의 페이지 동작이 가능한 SDRAM 상으로 코드를 이동시켜서 실행되도록 한다. (둘째), blob 부트로더에는 플래시 라이팅 기능도 지원되는데 이의 처리를 위해서는 필히 현재 실행되는 코드가 플래시에서

동작되서는 곤란하다. 왜냐구? 플래시를 라이팅하는 프로그램이 동작하는 곳도 플래시고 타겟 장치도 자신이므로 이는 플래시 메모리의 특징상 불가능 하다. (AVR이라는 마이크로 컨트롤러에서는 이것이 가능하다. 인상적이다.)

이상과 같은 이유로서 relocation 작업이 필요하며 'start.s' 상에서 그 기능이 구현되어 있다.

그러면 몇번째 코드라인 부터 SDRAM 상에서 실행될까? 188라인 이후부터인 c_main() 이라고 말할수 있다. 즉, 188라인까지는 blob 프로그램 코드는 플래시 상에서 실행된다.

188라인의 문장을 보자. " ldr pc, _start_armboot "으로 작성 되어져 있다. 실행후 프로그램 카운터에는 어떤 값이 들어갈까?. 0xc3c01004 라는 주소값이 들어간다.

어떻게 알았는가?. 첨부문서() 에서 blob.map 이라는 파일은 LINKING 후의 맵(MAP) 정보를 담고 있다. 131라인을 보면 다음과 같이 나와 있다.

*(.text)
.text    0xc3c01004 0x14 src/main.o
0xc3c01004    c_main
.text    0xc3c01018 0x9c src/lowlevel_init.o

결국 " ldr pc, _start_armboot " 의 실행결과 프로그램 카운터는 이후 부터 SDRAM 상의 주소에 해당하는 c_main() 함수를 실행하고 이후 부터 실행되는 모든 코드는 SDRAM 상에서 실행될 것이다.

참고를 위하여 '그림3. blob 의 프로그램 메모리 구조도' 와 '그림4. blob 의 relocation 동작 개념도' 을 아래와 같이 첨부한다.

그림3. blob 의 프로그램 메모리(SDRAM상) 구조도

blob 의 프로그램 메모리(SDRAM) 영역상의 각각은 다음의 의미를 갖는다.

(1).stack 영역

수퍼바이져 스택, 인터럽트(irq, fiq 각각) 스택 영역에 해당한다.

(2).bdinfo

보드 specific 한 정보를 담기 위한 것으로 실제로는 사용되지 않는다.

(3) .heap 영역

malloc(C), new(C++) 와 같은 동적 메모리 할당 명령 실행시 할당되는 메모리 영역이다.

(4).text 영역

프로그램(기계어)이 저장되는 메모리 영역이다.

(5).rodata 영역

const 나 스트링 참조 배열 초기값을 가지고 있는 영역이다.

(6) .data 영역

cf) int gvariable= 1; 처럼 초기화 한 전역변수들이 모여있는 영역이다.

(7) .got 영역

모르겠다(죄송~~)

(8) .bss 영역

cf) int gvariable; 처럼 초기화 하지 않은 전역변수들이 모여있는 영역이다.

그림4. blob 의 relocation 동작 개념도

NEXT. . . 다음 시간에는 blob의 부트스타트업(start.s) 을 계속해서 진행합니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/76

부트로더 제작 6편. EP9302 보드 와 LED 장치 - 2009/02/10 23:11

EP9302 매버릭 프로세서를 내장한 보드인 AHAV9302 보드의 블럭 다이어 그램( 그림 6-1. AHAV9302 보드 블럭도 )을 볼 수 있다.

그림 6-1. AHAV9302 보드 블럭도

CPU 는 씨러스 로직사의 ARM9 매버릭 시리즈중의 하나인 EP9302 프로세서를 채용하고 있으며, 백업 배터리 구동 RTC, 64MB SDRAM, 16MB FLASH, RS232C 통신, 이더넷 네트웍 통신, JTAG I/F, 확장용 커넥터들을 갖추고 있다.

더하여, SD 카드 슬롯도 갖추고 있어서 관련 드라이버만 설치된다면 해당 카드를 사용할 수가 있겠다. 블럭도에는 나와 있지 않은 LED 디스플레이도 있어서 이는 앞으로의 BLOB 포팅시 요긴하게 사용될 것이다.( 그림 6-2. AHAV9302 보드 의 LED 장치 )

그림 6-2. AHAV9302 보드 의 LED 장치

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/75

부트로더 제작 5편. blob 'STARTUP.S' 의 분석 - 2009/02/10 23:10

우리가 지금부터 하려는 작업인 ARM9 기반의 AHAV9302 보드상으로의 소위 포팅 작업은 blob의 구성 프로그램중 초기 기동 코드인 'STARTUP.S' 을 출발점으로 해야 마땅 할 것이다.

한편, blob 의 본시 배경 플랫폼은 인텔의 스트롱암 기반이다. ARM9 으로의 포팅 작업은 많은 량의 코드 수정을 요하지는 않지만 그중 가장 많은 코드의 수정을 요하는 것이 아마도 금번의 분석 대상인 'STARTUP.S' 이 아닐까 한다.

따라서, 금번회차와 다음회차 정도가 가장 어려운 내용이 아닐까 싶다.

당연 우리가 진행하고 있는 본 강좌. 부트로더 제작 강좌는 시간이 갈 수록 그 내용이 쉬워지지 않을까 생각된다.

설명을 위해 도입한 다음의 소스코드를 한번 살펴 보자.

생선중 '갈치'라는 것이 있다. 주방에서 갈치를 구워 내면 그 냄새가 매우 독특하고 진한 향이 난다. 그 모양 또한 길쭉하게 생긴것이 특징이다.

시장에 가서 이 갈치를 사면 생선가게 아줌마가 생선을 적당한 크기로 토막내어 소금을 뿌려준다.

갈치를 토막 내듯 우리가 지금부터 분석할 소스 코드를 적당한 크기로 흑(BLACK), 백(WHITE)로 토막낸다. 당연 각 파트는 설명을 위해 기능별로 잘라내었다. 그리고 각 부위별로 번호를 매긴다( AA, AB, AC, . . . .AV ) 이런식으로 말이다.

금번 회차에서는 blob의 원본 소스 코드('STARTUP.S')를 분석해 보고 다음회차에서는 AHAV9302 버젼의 'STARTUP.S' 을 선보인다.

*[AA] : 주석이다.

*[AB] : 인터럽트 벡터 테이블(IVT)이 보인다. 소스의 최하단에 위치한 [AV] 와 함께 보면 좋을듯.

BLOB 부트로더에서는 인터럽트를 전혀 사용하지 않는 것이 이채롭다. 왜냐구? [AV] 을 보라. 인터럽트 서비스 루
틴이 보이질 않는다.

*[AC] : 모든 인터럽트를 비 허가 한다(DISABLE)

*[AD] : 주석을 보면 CPU의 클럭을 설정하고 있음을 알 수 있다.

*[AE] : SDRAM 의 초기화를 수행한다.

*[AF] : 시리얼(UART) 장치의 초기화를 수행한다.

*[AG] : LED 장치의 초기화를 수행한다. 이후에 이 LED 장치가 대단한 활약(?)을 하게 된다.

*[AH] : 초기화 가 완료된 시리얼 장치를 이용하여 문자열('welcome')을 디스플레이한다.

*[AI] : 현재의 코드가 외부 플래시 장치에서 실행되고 있음이 확인되면 해당 코드 이미지를 내부 플래시로 복사를 수행한다('cpy_ext2int')

*[AJ] : 램(RAM) 의 메모리를 zero out(클리어) 한다.

*[AK] : 플래시 메모리에서 특정 키워드를 검색한다. 읽어낸 이 코드값을 이후에 main() 에게 파라메터로 전달한다.

코드의 후반부에서 이후 사용될 스택(STACK) 포인터를 세트한다.(코드 sub sp, r11, #$04)

*[AL] : c_main 메인 엔트리를 호출한다.

*[AM] : AM ~ AV 까지는 C 언어로 비유하자면 함수(서브루틴) 정도가 된다.

LED 을 켜고 끄는 코드가 작성되어 있다.

*[AN] : 시리얼로 디스플레이 할때 사용될 문자열들이 저장되어 있다.

*[AO] : 문자열 디스플레이 함수이다.

*[AP] : 숫자 디스플레이 함수이다.

*[AQ] : 시리얼 문자 전송 함수이다.

*[AR] : cpy_ext2int 함수로서 EXTERNAL 플래시로 부터 INTERNAL 플래시로 복사해 주는 함수이다.

*[AS] : 플래시 쓰기에 사용되는 함수이다.

*[AT] : 플래시 읽기에 사용되는 함수이다.

*[AU] : 시간 지연(대기) 함수이다.

*[AV] : 인터럽트 서비스 루틴이다. 다만, 그 내용물이 없다. 따라서 본 BLOB 부트로더에서는 인터럽트를 사용하지 않음을 알 수 있다.

ps. 필자가 쓴 칼럼중 다음의 내용과 함께 보면 좋을듯 싶다. 어떤 내용이 추가되어 있고 어떤 내용이 생략되어 있는지 말이다. 부트 스타트업 코드(crt0.s)의 실체. 다음회차의 칼럼을 보는데 도움이 될 것이다.

NEXT. . . 다음 시간에는 AHAV9302 보드용 blob의 부트스타트업(start.s) 을 만들어 봅니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/74

부트로더 제작 4편. blob 의 동작원리 - 2009/02/10 23:09

기능적으로 분류한다면 BLOB는 크게 3가지의 역할을 수행한다고 보면 될것같다.

첫째, 부트와 사용자 인터페이스이다. 부트로더는 커널이 올라가 있지 않은 프로그램인 관계로 일종의 펌웨어라 볼 수 있으며, 따라서 자체적으로 부트하며 이에 필요한 기초적인 하드웨어 장치(타이머, UART)에 대한 초기화를 하며 관련 드라이버를 가지고 있다.

또한 사용자 키 입력을 받아 인터프리트(해석)후 특정 기능을 수행해 주며 필요한 경우 해당 결과를 화면(CONSOLE)으로 알려 줄 수 있다.

둘째, 응용 프로그램(소프트웨어) 예를들면 리눅스 커널 같은 프로그램을 UART 혹은 TFTP 등의 인터페이스를 통해 보드 내의 SDRAM 혹은 FLASH 메모리에 다운로드 할 수 있다.

셋째, 다운로드된 프로그램으로 제어권을 옮기는 즉, 실행 할 수 있는 기능을 가지고 있다.

BLOB의 메인코드인 'main.c' 의 일부를 다음과 같이 발췌한다.

이 메인코드의 분석은 BLOB의 기능들을 모두 조망하여 보기에 좋은 방법이 된다.

startup.s 이후의 첫번째 실행 코드인 main() 은 다음과 같은 프로시져로 구성되어 있다.

라인번호[99 - 100] 에 의해 타이머와 UART 장치의 초기화를 수행한다.

라인번호[111 - 112] 플래시메모리에서 커널과 램디스크 이미지를 각각 SDRAM 으로 읽어 적재한다(LOADING...).

라인번호[142 - 150] 10초 동안 사용자 키입력을 대기한다. 키입력이 없을 경우 디폴트로 라인번호[153-156]에 의해 커널이 실행된다.

라인번호[162-194] 루프를 회전하며 사용자 명령을 대기한다.[ BLOB> 프롬프트 대기 ]

현재 BLOB 에서 지원하는 주요 기능[명령]은 main.c 에서 보이는 것이 전부 이다. 따라서 지원 하는 명령들은 boot / clock / download / flash / help / reload / reset /speed /status 이다.

이중 자주 사용되기도 하고 또한 중요한 명령은 reset / boot / download / flash 정도 일 것이다.

NEXT. . . 다음 시간에는 blob의 부트스타트업(start.s)에 대하여 알아 봅니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/73

부트로더 제작 3편. blob 동작 시키기 - 2009/02/10 23:09

blob.bin

download.ex_

이번 시간에는 blob 프로그램 이미지를 타겟보드에 내리는 방법에 대해서 알아보도록 하겠다.

앞으로의 강좌에서나 또한 여러분들이 해당 보드를 가지고 직접 프로그램 개발을 하기 위해서 꼭 사용되는 방법인 만큼

본 방법을 잘 숙지토록 하여야 겠다.

첨부파일: download.exe ; BLOB 이미지를 타겟보드에 내려주는 윈도우즈 전용 프로그램

blob.bin ; BLOB 이미지( ver1.00 )

blob 프로그램 이미지 타겟보드에 내리기

[그림2] BLOB 이미지를 다운로드 하기 위해 사용되는 버튼

BLOB 프로그램을 타겟보드에 올리는 요령(순서)

(1)[그림2]의 예시와 같이 타겟보드와 시리얼 케이블로 연결한다. 그리고 보드에 전원을 인가한다.

(2)[그림3]의 예시와 같이 cirrus 에서 배포한 UART 를 이용한 시리얼 다운로드 프로그램인 'download' 프로그램을 실행시킨다.

(주1. 씨러스에서 배포한 download 프로그램은 각각 linux 용과 win 용으로 제공된다.)

(주2. 각각 보드레이트와 시리얼 포트가 정확한지 확인 필.)

(3)타겟보드의 BOOT 버튼을 지그시 누른 상태에서 POR 버튼을 누르면 곧 바로 다운로드가 시작된다.

[그림3] 다운로드 프로그램의 실행 화면

필자의 경우 USB2SERIAL 케이블을 사용한 관계로 SERIAL PORT3이 사용되었다.

성공적으로 다운로드가 완료된 경우 다음과 같은 메시지가 나타난다.

C:\Temp>download -b 115200 -p 3 blob.bin
Using Serial Port 3
Flash Manufacture ID:0089, Device ID:0018
Successfully programmed 'blob.bin'.

blob을 실행 시켜 보기

리눅스용으로 Minicom 이나 윈도우즈에서는 하이퍼터미널 정도가 그 예가 될 수 있다.

필자의 경우는 [그림4] 처럼 윈도우 환경에서 테라텀을 사용하였다.

[그림4] blob이 실행된 타겟보드와 연결한 터미널 화면

현재의 프로그램(blob)은 아직 모든 프로그램 기능이 완성되지 않은 상태이다. 완성을 위하여는 포팅 단계중 중요한 두가지 기능이 완료되어야 한다.

FLASH writing 기능과 운영체제 로딩후 실행 기능이다. 따라서 금번의 릴리스 버젼(v1.00 )을 가지고 독자들이 실행해 볼 수 있는 명령은 다음의 명령으로 매우 제한적이다. help 명령과 status 정도이다. 이외의 다른 명령은 동작하지 않거나 대개 시스템이 먹통이 되게 만드는 강한 효력(?)을 지녔다.

미완이지만 독자들의 편의를 위하여 제목처럼 미리 선을 보인다. 빠른 시일내에 모든 프로그램 기능이 포팅 완료 될 것을 믿는다.

터미널 창에 다음과 같이 입력하여 보자.

blob> help [ENTER]

uuencode 설치하기

마지막으로 이후의 강좌에서의 사용을 위하여 다음의 내용을 잘 읽고 설치 바란다.

사용하는 리눅스 개발 환경에서 uuencode 명령을 다음과 같이 실행 해 본다.

#uuencode[ENTER]

uuencode: Command not found.

만약 위의 예시처럼 해당 명령이 존재 하지 않는 것으로 표시 된다면 이후 소개하는

방법대로 해당 기능을 설치를 해야 한다.

리눅스 패키지중 sharutils 내에 uuencode 툴이 들어 있다.

셸프롬프트에서 다음과 같이 입력한다.

# yum install sharutils

이후 부터는 설치 안내에 따라 진행하면 된다.

본 기능(uuencode)의 사용 용도는 이후의 강좌에서 진행될 예정이다.

NEXT. . . 다음 시간에는 blob의 동작 원리에 대해 알아 봅니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://hongikcom.com/trackback/72

부트로더 제작 2편. blob의 특징과 EP9302 보드 - 2009/02/10 23:08

부트로더라 함은 '일반적으로 운영체제나 혹은 2차 프로그램을 램(RAM) 이나 플래시(ROM)와 같은 메모리 디바이스에 상주시킨후 이를 실행해 줄 수 있는 소프트웨어라고' 필자는 이를 정의하겠다.

현재 임베디드 리눅스에서 사용되는 대표적인 부트로더는 u-boot 임에 아마 이의를 제기하는 이는 거의 없을것으로 본다.

본 강좌에서 다루는 blob 은 이 u-boot의 전신('아버지') 정도로 생각하면 되겠다.

blob 과 u-boot

다시 이야기 하거니와 본 강좌에서 blob 이 채택된 이유는 우리가 분석해야 할 코드의 크기도 상대적으로 매우 작고(TINY), 기능도 심플하다. 아주 기본적인 부트로더의 기능만을 담고 있기 때문에 썩 훌륭하진 않지만 부트로더의 동작원리를 이해하기 위해 소스분석을 할때 들이는 시간이나 그 노력면으로 볼때 보다 쓸모 있게 된다.

또한 부트로더라는 것도 어찌 보면 펌웨어 코딩 방식에 의해 작성되는 바. EP9302 프로세서상에서 펌웨어를 작성하는 기법도 더불어 익힐 수 있으니 이 또한 기쁜 소식 아닌가?. 참고 사진 [그림1], [그림2], [그림3]

[그림1] BLOB 과 u-boot의 소스파일의 크기 비교

[그림2] blob의 디렉토리 구조

[그림3] uboot 의 디렉토리 구조

BLOB은?

LART 라는 곳에서는 다음의 제원을 갖는 메인보드상에 부트로더를 얻는 작업을 진행 하였는바.

곧 이것이 BLOB(Boot Loader OBject) 이다.

Here are the LART mainboard specs in short:

220 MHz Digital SA-1100 StrongARM CPU
32 Mbyte EDO RAM
4 MB Intel Fast boot block Flash memory
Power usage < 1 W
Performance > 200 MIPS

또한 BLOB의 주요 특징을 다음과 같이 소개 하고 있다. 자세한 내용은 해당 사이트(http://www.lartmaker.nl)를 참조하길 바란다.

initialise the hardware (CPU speed, memory, interrupts, RS232)
boot a linux kernel and provide it with a ramdisk
download a kernel or a ramdisk to the LART
write a freshly downloaded kernel or ramdisk to flash memory
determine the memory layout (and tell the kernel about the results)
give a command line to the kernel

요약하면, 임베디드 리눅스에서 사용되는 BLOB 은 커널이미지(zImage), 램디스크(ramdisk) 등을 호스트(PC)로부터 UART/Ethernet 인터페이스를 통해 다운로드 받게 해주고 이를 내부메모리(SDRAM, FLASH) 상에서 실행해 주는 것을 그 주요 기능으로 한다.

NEXT. . . 다음 시간에는 blob을 타겟보드에 직접 내려보고 실행을 해보는 시간을 갖습니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->