File : (TOPDIR)/board/samsung/mango210/u-boot.lds

LD(loader & Linker)의 input으로 주어져서, object 파일을 생성하는데 규칙을 제공한다.

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
/*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
    . = 0x00000000;

    . = ALIGN(4);
    .text      :
    {
      cpu/s5pc11x/start.o   (.text)
      cpu/s5pc11x/s5pc110/cpu_init.o    (.text)
      board/samsung/mango210/lowlevel_init.o    (.text)
          cpu/s5pc11x/nand_cp.o (.text)
          cpu/s5pc11x/movi.o (.text)
          common/secure.o (.text)
      common/ace_sha1.o (.text)
      *(.text)
    }

    . = ALIGN(4);
    .rodata : { *(.rodata) }

    . = ALIGN(4);
    .data : { *(.data) }

    . = ALIGN(4);
    .got : { *(.got) }

    __u_boot_cmd_start = .;
    .u_boot_cmd : { *(.u_boot_cmd) }
    __u_boot_cmd_end = .;

    . = ALIGN(4);
    .mmudata : { *(.mmudata) }

    . = ALIGN(4);
    __bss_start = .;
    .bss : { *(.bss) }
    _end = .;
}



⊙ OUTPUT_FORMAT은 ELF32의 little endian으로 코드를 생성

⊙ OUTPUT_ARCH는 binary를 실행 할 수 있는 CPU architecture를 ARM으로 사용

⊙ ENTRY point은 프로그램의 시작을 가리키며, 시작되는 함수의 이름은 "_start"이다.

⊙ SECTIONS를 보면 text, rodata, data, got, mmudata, bss라는 section들이 정의되어 있다.
        .text  :  실행할 프로그램 코드 영역
        .rodata  :  read-only data 영역 (const 등으로 지정된 데이터)
        .data  :  initialized data 영역
        .got  :  global offset table 영역
        .mmudata  :  MMU data 영역
        .bss  :  uninitialized data 영역

⊙ 특수한 링커 변수 dot `.' 는 항상 현재 출력 address point을 담고 있다.
         address point 는 출력 섹션의 크기만큼 증가한다.

⊙ `*'는 어떤 파일명에도 대응한다. `*(.text)'는 모든 입력파일의 모든 입력 섹션 `.text'을 의미한다.

⊙ 프로그램 코드는 0x00000000에서 시작해서 4byte단위로 정렬된 text section에 놓여질 것이다.

⊙ U-boot의 시작은 Entry point에 선언된 _start부터 시작된다.

⊙ _start는 (TOPDIR)/cpu/s5pc11x/start.S에 정의되어 있다.

⊙ TEXT_BASE에의해 Linker수행 시 symbol들은 상대적 주소를 갖는다.

⊙ Power가 on 한 후 0x00번지(즉,flash)에서 시작하여 memory초기화를 거쳐 flash의 내용을 dram에 relocate
    하면 비로써 dram 에서 동작 하게 된다.

⊙ Symbol들은 모두 TEXT_BASE의 상대적 주소 값을 가지고 있으므로, dram에 relocate전에는 offset branch
    명령만 사용 해야 한다.(B,BL,ADR)

Posted by eoseontaek
Bootloader에서 handling하는 hardware list

core에 의존적인 것들
    Processor mode
    Interrupt
    Cache, MMU

SOC에 의존적인 것들
    Interrupt, Watchdog
    Clock
    Memory interface(dram controller)
    Timer
    UART
    RTC

외부장치
    Flash
    Nand Flash
    Ethernet controller
    RTC
    LCD Contoller
    Keyboard controller

'[C-06] S5PV210' 카테고리의 다른 글

[mango210] start.S의 분석  (0) 2011.03.17
[mango210] u-boot.lds 분석  (0) 2011.03.17
[mango210] u-boot 디렉토리 구조  (0) 2011.03.16
[mango210] ARM Architecture Reference Manual  (0) 2011.03.10
[mango210] S5PV210 Booting Sequence  (0) 2011.01.14
Posted by eoseontaek
u-boot 1.3.4 
                   
                   board           .board에 의존적인 파일

                   common      .architecture에 독립적인 파일

                   cpu             .architecture에 독립적인 파일

                   disk            .code for disk drive partition handling

                   doc            .u-boot 관련 문서

                   driver          .외부 장치의 driver파일

                   examples    .u-boot을 위한 test 실행 파일

                   fs                .uboot에서 지원하는 file system관련 파일

                   include        .header file

                   lib_arm        .arm architecture관련 라이브러리 파일

                   net              .network 관련 파일

                   post            .Power On Self Test

                   tools           .Tools to build S-Record or U-Boot images, etc.       
                  


Posted by eoseontaek
2011. 3. 11. 10:06

텔레비전이나 비디오 같은 영상관련기기 뒤에 연결하는 신호선 단자에 쓰여있는 것을 보셨을 겁니다.

CVBS(Composite Video Banking Sync)는 텔레비전 신호의 종류를 나타내는 말인데, 영상신호(색차, 휘도, 싱크)가 한 개의 신호선에 모두 섞여있고 오디오신호는 포함되지 않는 것을 말합니다. 각각의 영상관련 신호는 TV 내부의 회로에서 분리되므로, RGB 컴포넌트 입력처럼 각 신호가 다 분리되어 있는 경우보다 아무래도 화질이 떨어집니다.

이보다 낮은 레벨의 신호는 텔레비전 안테나선으로 들어오는 RF(또는 HF) 신호로, 이것에는 영상과 음성이 모두 다 섞여있습니다. 그래서 화질이 더 나쁘지요.

CVBS보다 높은 레벨의 신호는 Y/C 신호로 휘도와 싱크가 섞여있고 색차는 분리되어있는 신호입니다. (RGB는 R, G, B, 싱크 다 분리되어있습니다.)

요약하면, CVBS는 영상저장매체와 텔레비전사이에 주고받는 신호중에, 선 하나로 영상이 제대로 나오게 해 주는 신호를 말합니다.

http://blog.daum.net/_blog/BlogTypeView.do?blogid=0O534&articleno=23#ajax_history_home


Posted by eoseontaek

ARM and Thumb-2 Instruction Set Quick Reference Card (Korean) v4.0
http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001mk/QRC0001_UAL.pdf

ARM and Thumb-2 Instruction Set Quick Reference Card
http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf

ARM 아키텍처 참조 문서 ARMv7-A 및 ARMv7-R 버전
http://infocenter.arm.com/help/index.jsp

Posted by eoseontaek

'[E-01] Bootloader' 카테고리의 다른 글

[linux] 리눅스 부팅 프로세스 연구  (0) 2010.12.30
Posted by eoseontaek
Posted by eoseontaek


[root@localhost ~]$ lspci | grep -i vga
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)

Posted by eoseontaek

# vi /etc/gdm/custom.conf

[daemon]
TimedLoginEnable=true
TimedLogin=(사용자이름)
TimedLoginDelay=0

추가.
Posted by eoseontaek

Linux Shell Scripting Tutorial v1.05r3 A Beginner's handbook

http://www.freeos.com/guides/lsst/




Advanced Bash-Scripting Guide

http://www.tldp.org/LDP/abs/html/



'[Z-01] 참고 ' 카테고리의 다른 글

[UTIL] WinHex - Hex 코드 편집기  (0) 2011.04.14
[site] Free Electrons  (0) 2011.03.18
[site] 리눅스 시스템 관리  (0) 2011.01.21
[site] SAMSUNG semiconductor  (0) 2011.01.21
[site] MTD utils download 사이트  (0) 2011.01.18
Posted by eoseontaek

'[Z-01] 참고 ' 카테고리의 다른 글

[site] Free Electrons  (0) 2011.03.18
[site] Linux Shell Scripting Tutorial  (0) 2011.01.26
[site] SAMSUNG semiconductor  (0) 2011.01.21
[site] MTD utils download 사이트  (0) 2011.01.18
[site] Linux Device Driver 2nd edition (O'REILLY)  (0) 2011.01.07
Posted by eoseontaek

SAMSUNG Memory관련 정보를 얻을 수 있는 곳



http://www.samsung.com/global/business/semiconductor/


Posted by eoseontaek

'[Z-01] 참고 ' 카테고리의 다른 글

[site] 리눅스 시스템 관리  (0) 2011.01.21
[site] SAMSUNG semiconductor  (0) 2011.01.21
[site] Linux Device Driver 2nd edition (O'REILLY)  (0) 2011.01.07
[site] LIRC (Linux Infrared Remote Controller)  (0) 2011.01.03
[site] Pro Git  (0) 2011.01.03
Posted by eoseontaek

6.1 OVERVIEW OF BOOTING SEQUENCE

  S5PV210은 내부 메모리로 64KB ROM96KB SRAM을 가지고 있다. 이 두 영역은 booting을 위해 사용된다.
S5PV210은 secure booting을 enable하기 위해 내부 ROM으로부터 boot한다.  이것은 인증되지 않은 user가 이미지를 변경할 수 없게 한다. secure booting과 normal booting을 선택하기 위해,  S5PV210은 e-fuse 정보를 사용해야한다. 이 정보는 program된 후 변경될 수 없다.

Booting device

• General NAND Flash memory
• OneNAND memory
• SD/ MMC memory (such as MoviNAND and iNAND)
• eMMC memory
• eSSD memory
• UART and USB devices

system reset시, program counter는 내부 ROM 영역에서 iROM code로 부터 시작한다. 그러나 system reset은 booting time이나 또는 low power mode에서 wakeup할 때, assert될수 있다. 따라서 iROM code는 reset status로부터 적절한 process를 execute해야만 한다.

bootloader는 크게 iROM, 1st BL, 2nd BL로 구성된다.

• iROM code : small and simple code로 구성됨. platform-independent, 내부 메모리에 저장됨.
• First boot loader :  small and simple code로 구성됨. platform-independent, 외부 메모리 device에 저장, 
                              secure booting과 관련됨.
• Second boot loader: 복잡한 code로 구성됨, platform-specific, 외부 메모리 device에 저장됨.

secure booting 선택시, iROM code와 1st BL은 loaded image를 verify하기 위해 integrity checking function를 제공한다. secure boot key는 160 e-fuse bit로 되어 있으며 iROM의 integrity check전에 loaded pulict key를 인증하는데 사용된다.



• iROM code는 internal 64KB ROM에 위치한다.
   clock, stack, heap와 같은 기본적인 system function을 초기화한다.
• iROM은 명시한 booting device로부터 1st BL image를 internal 96KB SRAM으로 load한다.
   booting device는 OM(Operation Mode) pins에의해 선택된다. 
   secure boot key values에 따라 iROM code는 1st BL image에서 integrity check 작업을 수행할 수도 있다.
• 1st BL은 2nd BL를 load하고 secure boot key values에 따라 2nd BL의 integrity를 check할 수도 있다.
• 2nd BL은 system clock, UART, DRAM controller를 초기화한다.
   DRAM controller를 초기화한 후에, booting device로부터 OS image를 load한다.
   secure boot key values에 따라 2nd BL은 OS image에서 integrity check를 수행할 있다.
• 부팅이 완료된 후에, 2nd BL은 operationg system으로 jump한다.

iROM code는 booting device를 찾기위해 OM pin을 읽는다. OM 레지스터는 booting에 필요한 OM pin과 다른 정보등을 제공한다.

OM pin은 OneNAND, NAND, MoviNAND, eSSD and iNAND와 같은 booting device를 결정한다. bit width, wait cycles, page sizes, and ECC modes 같은 option들도 결정한다.

BL0 : internal 64KB ROM에  위치한 iROM code
BL1 : first boot loader


6.2 SCENARIO DESCRIPTION

6.2.1 RESET STATUS

hardware reset, watchdog reset, software reset, and wake up from power down modes과 같은 다양한 system reset 시나리오가 있다.


hardware reset and watchdog reset 시에, system은 1st, 2nd boot loader, OS image를 가지고 full boot를 해야 한다. 새로운 reset status는 reset group0로서 분류된다.

DRAM 메모리의 내용이 SLEEP mode에서 보존되었다면 DRAM으로 OS image를 loading할 필요가 없다. SoC internal power가 SLEEP mode돋안 내부 logic에 공급되지 않기때문에 내부 SRAM의 내용은 보존되지 않는다.
그러므로 first boot loader and the second boot loader는 다시 load되야 한다. reset status는 reset group1로서 분류된다.

software reset시에 boot loader의 loading은 실행된다. top block’s power가 DEEP_STOP and DEEP_IDLE modes에서 gate되었다었더라도 내부 SRAM은 reserved될 수 있다.  그래서 boot loader의 reloading은 필요없다. DEEP_STOP and DEEP_IDLE modes에서 SRAM의 non-retention의 경우 1st boot loader는 다시 load되야만 한다. DEEP_STOP and DEEP_IDLE statuses에서 wake up하는 software reset은 reset group2로 분류된다.

system이 모두 power down mode로 들어간다면, 현재 system status은 DRAM과 같은 safe memory region에 저장되어야 한다. 그래서 system은 power down mode로부터 wake up 후에 seamlessly하게 processing을 계속해야 한다.

마지막으로 이전 상태 함수를 복구하는 것은 SLEEP, DEEP_STOP, and DEEP_IDLE modes에서 필요하다.


6.2.2 BOOTING SEQUENCE EXAMPLE

Program code는 iROM에서 시작해서 iRAM으로 이동하고, 마지막으로 DRAM에서 program을 실행한다.


booting sequence in internal ROM

1. Disable the watchdog timer.

2. Initialize the instruction cache controller.

3. Initialize the stack and heap region.

4. Check secure key.

5. Set Clock divider, lock time, PLL (MPS value), and source clock.

6. Check OM pin and load the first boot loader (The size of boot loader depends on S/W) from specific 
    device (block number 0) to iRAM.

7. If secure booting is successful, execute integrity check

8. If integrity check passes, then jump to the first boot loader in iRAM (0xD002_0010)


booting sequence in internal SRAM

1. Load the second boot loader from boot device to iRAM.

2. If secure booting is successful, execute integrity check.

3. If integrity check passes, then jump to the second boot loader in iRAM (The jumping address depends
    on user's software)

4. If integrity check fails, then stop the first boot loader.

5. The second boot loader Initializes the DRAM controller.

6. Load the OS image from specific device (block number 1) to DRAM.

7. Jump to OS code in DRAM (0x2000_0000 or 0x4000_0000)


booting sequence in DRAM

1. If S5PV210 is powered on from SLEEP, DEEP_STOP, or DEEP_IDLE modes, then restore the previous
    state.

2. Jump to OS code.


6.2.3 FIXED PLL AND CLOCK SETTING

1st boot loader의 operation speed를 up하기 위해, 1st boot loader는 수정된 PLL 값으로 초기화 한다. 수정된 PLL 설정은 :

• APLL: M=200, P=6, S=1 FOUT = (MDIV X FIN )/ (PDIV X 2(SDIV-1))) = 800MHz
• MPLL: M=667, P=12, S=1 FOUT = (MDIV X FIN) / (PDIV X 2SDIV) = 667MHz
• EPLL: M=80, P=3, S=3, K=0 FOUT = ((MDIV+KDIV) X FIN) / (PDIV X 2SDIV) = 80MHz



6.2.4 OM PIN CONFIGURATION




6.2.5 SECURE BOOTING

security system의 기본적인 표준은 "‘root of trust’는 하드웨어가 되어야만 하고 'validate'하기 위해 소프트웨어 시스템을 요청할 수 없다"는 것이다.

S5PV210에서, root of trust는 내부 ROM에서 iROM code에 의해 동작된다. 그러므로 인증되 않은 user에 의해 modify될수 없다. 하드웨어 디자인은 iROM code integrity를 증명한다. 다시 말해 first boot
loader, the second boot loader and OS images는 외부 메모리 디바이스에 저장된다. 그러므로 iROM code는 1st boot loader의 integrity를 verify해야만 하고, 1st boot loader에서 integrity check가 pass되면, 1st boot loader는 trust region에 포함된다. 다음에 1st boot loader는 2nd boot loader의 integrity를 check하고, 2nd boot loader는  OS image의 integrity를 verify 한다.

secure booting sequence는 다음과 같다.

iROM code는

1. Checks the integrity of RSA public key using E-fuse RSA key hash value.

2. Loads the first boot loader to iRAM.

3. Checks the integrity of first boot loader using trusted RSA public key.


first boot loader는

1. Loads security software to iRAM.

2. Checks the integrity of software using trusted RSA public key.

3. Loads second boot loader to iRAM.

4. Checks the integrity of second boot loader using trusted RSA public key.


second boot loader는

1. Loads security software to iRAM.

2. Checks the integrity of software using trusted RSA public key.

3. Loads OS kernel and applications to DRAM.

4. Checks the integrity of OS kernel and application using trusted RSA public key











Posted by eoseontaek
/

arch
리눅스가 지원하는 Architecture에 의존적인 코드가 위치한 폴더
mango210의 경우 arch/arm/mach-s5pv210 디렉토리 참조

include
커널의 header file이 위치한 폴더.

init
하드웨어 독립적으로 커널이 초기화되고 실질적으로 커널이 시작되는 부분이다. main.c 파일은 커널 초기화하고 시작하는데 사용되고 version.c 파일은 커널의 버전을 기술하는데 사용된다.

kernel
프로세스 관리를 기본으로 하여 운영체제 커널의 기본적인 핵심코어가 위치한다.

mm
가상메모리 관리 루틴이 위치하는 곳으로 Architecture 독립적으로 구현되어 있다.

ipc
세마포어 그리고 내부 프로세스 통신을 위한 공유메모리, 메시지 전달을 지원하는 루틴이 위치한 폴더

fs
파일시스템 관련 파일이 위치한다. /fs 루트에는 VFS 관련 파일이 있고 각 하위 폴더에는 각각의 파일시스템이 구현되어 있다.

net
네트워킹 관련 모듈이 위치하며 지원하는 프로토콜 중 대표적인 것으로는 TCP/IP(IPv4), IPv6, IPX, Netlink 등이 있다.

drivers
하드웨어 디바이스 드라이버가 위치하는 곳으로 Char, Block 등으로 하드웨어를 분류해 종류별로 각 제품별 디바이스가 위치한다.

lib
커널이 사용하는 라이브러리가 위치한 폴더

script
커널 컴파일 및 인스톨 관련 스크립트가 위치한 폴더

Documentation
커널 관련 문서가 위치한 폴더로 소스 코드의 수정사항에 대한 기술문이 주를 이룬다.




Posted by eoseontaek

'[Z-01] 참고 ' 카테고리의 다른 글

[site] SAMSUNG semiconductor  (0) 2011.01.21
[site] MTD utils download 사이트  (0) 2011.01.18
[site] LIRC (Linux Infrared Remote Controller)  (0) 2011.01.03
[site] Pro Git  (0) 2011.01.03
[site] Linux Journal  (0) 2010.12.28
Posted by eoseontaek

'[Z-01] 참고 ' 카테고리의 다른 글

[site] MTD utils download 사이트  (0) 2011.01.18
[site] Linux Device Driver 2nd edition (O'REILLY)  (0) 2011.01.07
[site] Pro Git  (0) 2011.01.03
[site] Linux Journal  (0) 2010.12.28
[site] GCC, the GNU Compiler Collection  (0) 2010.12.28
Posted by eoseontaek
2011. 1. 3. 10:12


http://progit.org/

'[Z-01] 참고 ' 카테고리의 다른 글

[site] Linux Device Driver 2nd edition (O'REILLY)  (0) 2011.01.07
[site] LIRC (Linux Infrared Remote Controller)  (0) 2011.01.03
[site] Linux Journal  (0) 2010.12.28
[site] GCC, the GNU Compiler Collection  (0) 2010.12.28
[site] ARMboot  (0) 2010.12.28
Posted by eoseontaek

초기에 컴퓨터를 부트스트랩(bootstrapping) 한다고 하면 부트 프로그램이 포함된 종이 테이프를 공급하거나 프론트 패널 address/data/control 스위치를 사용하여 부트 프로그램을 직접 로딩하는 것을 의미했다. 오늘날 컴퓨터에는 부팅 과정을 단순화시키는 장치들이 장착되어 있지만 꼭 그렇게 단순한 것 같지는 않다.

리눅스 부팅 과정을 보다 높은 시각에서 조망해야지만 전체적으로 볼 수 있다. 그런 다음 각각의 단계를 자세히 살펴봐야겠다. 곳곳에 첨부한 소스 자료가 커널 트리를 연구하는데 도움이 될 것이다.

개요

그림 1은 리눅스 부트 프로세스 개요도이다.


그림 1. 리눅스 부트 프로세스의 개요도
High-level view of the Linux kernel boot

시스템이 처음 부팅되거나 리셋되면 프로세서는 잘 알려진 위치에 코드를 실행한다. PC의 경우, basic input/output system (BIOS)이다. 이것은 마더보드의 플래시 메모리에 저장된다. 임베디드 시스템에 있는 CPU는 리셋 벡터를 호출하여 플래시/ROM의 알려진 주소에서 프로그램을 시작한다. 두 경우 모두 결과는 같다. PC가 훨씬 유연하고, BIOS는 어떤 장치들이 부팅 후보인지를 결정해야 한다.

부팅 장치를 찾으면 첫 번째 단계 부트 로더는 RAM으로 로딩되어 실행된다. 이 부트 로더는 길이는 512 바이트 미만이고 하는 일은 두 번째 단계의 부트 로더를 로딩하는 것이다.

제 2 단계 부트 로더가 RAM에 있고 실행되면 스플래시 스크린이 디스플레이 되고 리눅스와 초기 RAM 디스크 옵션(임시 루트 파일 시스템)이 메모리에 로딩된다. 이미지가 로딩될 때 2 단계 부트 로더는 제어를 커널 이미지로 전달하고 커널은 압축이 해제되어 초기화 된다. 이 때 2 단계 부트 로더는 시스템 하드웨어를 검사하고 첨부된 하드웨어 장치들을 열거하고, 루트 장치를 마운트 하고 필요한 커널 모듈을 로딩한다. 완료되면 첫 번째 사용자-공간 프로그램(init)이 시작되고 고급 시스템 초기화가 이루어진다.

여기까지가 리눅스 부팅 과정을 간략하게 묘사한 것이다. 이제 리눅스 부팅 과정을 보다 자세하게 살펴보도록 하자.

 

시스템 시작

시스템 시작 단계는 리눅스가 부팅되는 하드웨어에 기반하고 있다. 임베디드 플랫폼에서, 부트스트랩 환경은 시스템이 켜지거나 리셋될 때 사용된다. U-Boot, RedBoot, MicroMonitor 등이 그 예이다. 임베디드 플랫폼에는 일반적으로 부트 모니터가 장착된다. 이 프로그램들은 목표 하드웨어의 플래시 메모리의 특별한 영역에 있고 리눅스 커널 이미지를 플래시 메모리로 다운로드 하는 방식을 제공하고 이를 실행한다. 리눅스 이미지를 저장하고 부팅하는 기능 외에도 이 부트 모니터는 시스템 테스트와 하드웨어 초기화를 수행한다. 임베디드 환경에서 이러한 부트 모니터들은 제 1 부트 로더와 제 2 부트 로더를 관장한다.

PC에서 리눅스 부팅은 BIOS에서 주소 0xFFFF0로 시작된다. BIOS의 첫 번째 단계는 POST (power-on self test)이다. POST가 하는 일은 하드웨어를 검사하는 것이다. BIOS의 두 번째 단계는 로컬 장치 열거(enumeration)와 초기화이다.

BIOS 기능에 따라 사용처도 다르며, BIOS는 두 부분으로 구성된다. POST 코드와 런타임 서비스이다. POST가 완료된 후에 이것은 메모리에서 플러시(flush)되지만 BIOS 런타임 서비스는 그대로 남아있고 해당 운영 체계에서 사용할 수 있다.

운영 체계를 부팅하기 위해서 BIOS 런타임은 complementary metal oxide semiconductor (CMOS)에서 정의된 선호도 순으로 활성화 되고 부팅 가능한 장치를 찾는다. 부트 장치는 플로피 디스크, CD-ROM, 하드 디스크 파티션, 네트워크 상의 장치, USB 플래시 메모리 스틱이 될 수도 있다.

일반적으로 리눅스는 하드 디스크에서 부팅되고, Master Boot Record (MBR)에는 주 부트 로더가 포함되어 있다. MBR은 512-바이트 섹터이고 디스크의 첫 번째 섹터(sector 1 of cylinder 0, head 0)에 위치해 있다. MBR이 RAM이 로딩된 후에 BIOS는 제어권을 여기에 넘겨준다.

 

Stage 1 부트 로더

MBR에 있는 주 부트 로더는 512-바이트 이미지로서 프로그램 코드와 작은 파티션 테이블이 포함되어 있다. (그림 2) 첫 번째 446 바이트는 주 부트 로더이고 여기에는 실행 코드와 에러 메시지 텍스트가 포함된다. 그 다음 64 바이트는 파티션 테이블인데, 네 개의 파티션(각 16 바이트)의 레코드가 포함되어 있다. MBR은 매직 넘버(0xAA55)로 정의된 2 바이트로 끝난다. 매직 넘버는 MBR의 밸리데이션에 사용된다.


그림 2. MBR의 구조
Anatomy of the MBR

주 부트 로더의 작업은 2차 부트 로더(stage 2)를 찾아 로딩하는 것이다. 액티브 파티션을 찾기 위해 파티션 테이블을 검사한다. 액티브 파티션을 찾으면 테이블에 남아있는 파티션들을 검사하여 이들이 모두 비활성 상태인지를 확인한다. 확인이 되면 액티브 파티션의 부트 레코드는 장치에서 RAM으로 읽혀지고 실행된다.

 

Stage 2 부트 로더

2차 또는 제 2 단계 부트 로더는 커널 로더라고 불린다. 이 단계에서의 작업은 리눅스 커널과 선택적인 초기 RAM 디스크를 로딩하는 것이다.

주/부 부트 로더의 결합은 x86 PC 환경에서 Linux Loader (LILO) 또는 GRand Unified Bootloader (GRUB)이라고 한다. LILO는 몇 가지 단점을 갖고 있고 GRUB이 이를 수정했으므로 GRUB을 살펴보도록 하자. (GRUB과 LILO에 대한 자세한 내용은 참고자료를 참조하라.)

GRUB의 좋은 점은 리눅스 파일 시스템을 알고 있다는 점이다. LILO 처럼 디스크 상의 미가공 섹터를 사용하는 대신 GRUB은 ext2 또는 ext3 파일 시스템에서 리눅스 커널을 로딩할 수 있다. 2 단계 부트 로더를 3 단계 부트 로더로 만든다. Stage 1 (MBR)은 리눅스 커널 이미지를 포함하고 있는 특정 파일 시스템을 알고 있는 stage 1.5 부트 로더를 부팅한다. reiserfs_stage1_5 (Reiser 저널링 파일 시스템에서 로딩함) 또는 e2fs_stage1_5 (ext2 또는 ext3 파일 시스템에서 로딩함)가 좋은 예이다. stage 1.5 부트 로더가 로딩 및 실행되면 stage 2 부트 로더가 로딩될 수 있다.

stage 2가 로딩되면서 GRUB은 사용 할 수 있는 커널 리스트를 디스플레이 한다. (/etc/grub.conf에서 정의됨. /etc/grub/menu.lst/etc/grub.conf의 링크 포함). 여러분은 커널을 선택하고 추가 커널 매개변수로 이를 수정할 수도 있다. 부트 프로세스에 보다 직접적인 관여를 하려면 명령행 쉘을 사용할 수도 있다.

Stage 2 부트 로더가 메모리에 있는 상태에서 파일 시스템이 참조되고 디폴트 커널 이미지와 initrd이미지가 메모리로 로딩된다. 이미지가 준비되면 stage 2 부트 로더는 커널 이미지를 호출한다.

 

커널

커널 이미지가 메모리에 있고 stage 2 부트 로더에서 컨트롤도 넘어왔다면 커널 단계가 시작된다. 커널 이미지는 실행 커널은 아니고 다만 압축된 커널 이미지이다. 일반적으로 이것은 zImage (압축 이미지, 512KB이하) 또는 bzImage (큰 압축 이미지, 512KB 이상)이고 이들은 이전에 zlib로 압축된 것이다. 커널 이미지의 앞에 있는 루틴은 최소한의 하드웨어 설정을 수행한 다음 커널 이미지에 포함된 커널의 압축을 풀고 이를 큰 메모리에 둔다. 초기 RAM 디스크 이미지가 있다면 이 루틴은 이것을 메모리로 옮기고 기록해 둔다. 루틴은 커널을 호출하고 커널 부팅이 시작된다.

bzImage (i386 이미지 용)가 호출되면 start 어셈블리 루틴(그림 3의 주 흐름도 참조)의 ./arch/i386/boot/head.S에서 시작한다. 이 루틴은 기본적인 하드웨어 설정을 수행하고 ./arch/i386/boot/compressed/head.S에 있는 startup_32 루틴을 호출한다. 이 루틴은 기본 환경(스택 같은)을 설정하고 Block Started by Symbol (BSS)을 청소한다. 커널은 decompress_kernel (./arch/i386/boot/compressed/misc.c에 있음)이라고 하는 C 함수를 호출하여 압축이 풀린다.

새로운 startup_32 함수(swapper 또는 process 0)에서, 페이지 테이블이 초기화되고 메모리 페이징이 실행된다. CPU 유형이 검사되고 아울러 FPU (floating-point unit)도 검사된다. start_kernel 함수가 호출되면(init/main.c) 일반(non-architecture specific) 리눅스 커널이 된다.


그림 3. Linux kernel i386 boot의 함수 흐름
Major Functions in Linux Kernel i386 Boot Process

start_kernel을 호출하면 초기화 함수의 긴 리스트가 호출되어 인터럽트를 설정하고 보다 구체적인 메모리 설정이 이루어지고 초기 RAM 디스크를 로딩한다. kernel_thread (arch/i386/kernel/process.c)를 호출하면 init 함수가 시작되는데 이는 최초의 사용자 공간 프로세스이다. 마지막으로 유휴 태스크가 시작되고 스케줄러가 주도권을 잡는다. (cpu_idle 호출 후). 인터럽트가 실행되면서 선점 스케줄러는 주기적으로 주도권을 잡아 멀티태스킹을 수행한다.

커널이 부팅되는 동안 stage 2 부트 로더에 의해 메모리로 로딩된 initial-RAM disk (initrd)가 RAM으로 복사 및 마운트 된다. initrd는 RAM에서 임시 루트 파일 시스템의 역할을 하고 커널이 물리적 디스크를 마운트 하지 않고도 완전히 부팅될 수 있도록 한다. 주변 기기와 인터페이싱 할 때 필요한 모듈이 initrd의 일부가 될 수 있기 때문에 커널은 매우 작아질 수 있지만 그래도 여전히 많은 하드웨어 설정들을 지원한다. 커널이 부팅된 후에 루트 파일 시스템이 (pivot_root를 통해) 회전되고 이곳에서 initrd 루트 파일 시스템이 언마운트(unmount)되어 실제 루트 파일 시스템이 마운트 된다.

initrd 함수를 사용하여 로딩 가능한 모듈로 컴파일 된 드라이버를 가진 작은 리눅스 커널을 만들 수 있다. 이 로딩 모듈은 커널에 디스크와 디스크 상의 파일 시스템 뿐만 아니라 다른 하드웨어용 드라이버에도 액세스 할 수 있는 방식을 제공한다. 루트 파일 시스템은 디스크 상에 있는 파일 시스템이기 때문에 initrd 함수는 부트스트래핑 방식을 제공하여 디스크에 액세스 하고 실제 루트 파일 시스템을 마운트 한다. 하드 디스크가 없는 임베디드 환경에서 initrd는 마지막 루트 파일 시스템이 되거나, 마지막 루트 파일 시스템은 Network File System (NFS)을 통해 마운트 될 수 있다.
 

커널이 부팅 및 초기화 된 후에 커널은 최초의 사용자 공간(user-space) 애플리케이션을 시작한다. 이것은 표준 C 라이브러리로 컴파일 된 첫 번째 프로그램이다. 이전에는 어떤 표준의 C 애플리케이션도 실행되지 않았다.

데스크탑 리눅스 시스템에서 시작된 첫 번째 애플리케이션은 일반적으로 /sbin/init이다. 하지만 꼭 이럴 필요는 없다. 임베디드 시스템은 init (/etc/inittab을 통해 설정됨)에서 제공하는 초기화를 거의 필요로 하지 않는다. 많은 경우에, 필요한 임베디드 애플리케이션을 시작하는 간단한 쉘 스크립트를 호출하곤 한다.

 

리눅스가 그러하듯, 리눅스 부트 프로세스도 매우 유연하고 많은 프로세서와 하드웨어 플랫폼을 지원한다. 초기에는 loadlin 부트 로더가 있었다. LILO 부트 로더는 부팅 기능을 확장했지만 파일 시스템 인식 부분에서 부족했다. GRUB과 같은 최신 부트 로더가 생기면서 많은 파일 시스템(Minix 부터 Reiser 까지)에서 리눅스를 부팅할 수 있게 되었다.

Note

- IBM DeveloperWorks -
http://www.ibm.com/developerworks/kr/library/l-linuxboot/



'[E-01] Bootloader' 카테고리의 다른 글

[u-boot] u-boot의 i2c command 사용에 대한 문서  (0) 2011.03.10
Posted by eoseontaek

'[Z-01] 참고 ' 카테고리의 다른 글

[site] LIRC (Linux Infrared Remote Controller)  (0) 2011.01.03
[site] Pro Git  (0) 2011.01.03
[site] GCC, the GNU Compiler Collection  (0) 2010.12.28
[site] ARMboot  (0) 2010.12.28
[site] MSDN E-boot bootloader library site  (0) 2010.12.28
Posted by eoseontaek
이전버튼 1 2 3 4 5 6 7 ··· 14 이전버튼