[Linux] 리눅스/x86 부트 프로토콜 (Linux/x86 boot protocol)

원문: https://www.kernel.org/doc/Documentation/x86/boot.txt

이 글은 GPL 라이센스를 따릅니다.

리눅스/x86 부트 프로토콜


번역: 양정석 (dasomoli@gmailREMOVETHIS.com)

x86 플랫폼 상에서 리눅스는 좀 복잡한 부트 컨벤션을 사용합니다. 이는 역사적인 관점에서 조금씩 진화한 것 뿐 아니라 커널 그 자체를 부팅가능한 이미지로 가졌던 초기 요구, 복잡한 PC 메모리 모델과 메인스트림 운영체제로서 리얼 모드 DOS의 실질적인 종말에 의한 PC 산업 내의 변화한 기대들로 인한 것입니다.

현재 리눅스/x86 부트 프로토콜의 다음 버전들이 존재합니다.

Old kernels:    zImage/Image만 지원. 극초기 몇몇 커널들은 커맨드 라인조차
                지원하지 않을 수 있음.

Protocol 2.00:  (커널 1.3.73) bzImage와 initrd 지원 추가 뿐만 아니라
                부트로더와 커널 간 통신을 위한 방법이 형식화됨.
                기존 셋업 공간이 writable한 것으로 가정되어도
                setup.S가 relocatable

Protocol 2.01:  (커널 1.3.76) 힙 오버런 경고를 추가.

Protocol 2.02:  (커널 2.4.0-test3-pre3) 새로운 커맨드 라인 프로토콜.
                더 낮은 관례적 memory ceiling. 기존 셋업 공간의 덮어쓰기 없앰,
                그래서 SMM이나 32비트 BIOS 엔트리 포인트로부터 EBDA를
                사용하는 시스템을 안전하게 부팅하도록 만듦.
                zImage를 지원은 하지만, 곧 사라지도록 함.

Protocol 2.03:  (커널 2.4.18-pre1) 명시적으로 부트로더에 가능한 가장 높은
                initrd 주소를 사용가능하도록 만듦.

Protocol 2.04:  (커널 2.6.14) syssize 필드를 4바이트로 확장.

Protocol 2.05:  (커널 2.6.20) 프로텍티드 모드 커널을 relocatable하게 만듦.
                relocatable_kernel과 kernel_alignment 필드를 도입.

Protocol 2.06:  (커널 2.6.22) 부트 커맨드 라인의 크기를 포함하는 필드를 추가.

Protocol 2.07:  (커널 2.6.24) paravirtualised 부트 프로토콜 추가.
                hardware_subarch와 hardware_subarch_data, 그리고
                load_flags 안의 KEEP_SEGMENTS 플래그를 도입.

Protocol 2.08:  (커널 2.6.26) crc32 체크섬과 ELF 형식 페이로드를 추가.
                payload_offset과 payload_length 필드를 페이로드를
                위치시키는데 조정할 수 있도록 도입.

Protocol 2.09:  (커널 2.6.26) setup_data 구조체의 링크드 리스트 하나로의
                64비트 물리 포인터 필드를 추가.

Protocol 2.10:  (커널 2.6.31) 추가된 kernel_alignment를 넘는 relaxed alignment를
                위한 프로토콜 추가, 새로운 new init_size와 pref_address 필드.
                확장된 부트로더 ID들 추가.

Protocol 2.11:  (커널 3.6) EFI 핸드오버 프로토콜 엔트리 포인트의 오프셋을 위한
                필드 추가.

Protocol 2.12:  (커널 3.8) 64비트에서 4G위로 bzImage와 ramdisk를 로딩하기 위한
                boot_params을 구조화하기 위한 xloadflags와 확장 필드들 추가.

**** 메모리 레이아웃
Image나 zImage 커널에 사용되었던 커널 로더를 위한 전통적인 메모리 맵은 보통 다음과 같습니다:

        |                        |
0A0000  +------------------------+
        |  BIOS를 위해 예약됨    |     사용하지 마세요.  BIOS EBDA를 위해 예약됨.
09A000  +------------------------+
        |  커맨드 라인           |
        |  스택/힙               |     리얼 모드 코드가 사용.
098000  +------------------------+  
        |  커널 셋업             |     커널 리얼 모드 코드.
090200  +------------------------+
        |  커널 부트 섹터        |     커널 레가시 부트 섹터.
090000  +------------------------+
        |  프로텍티드 모드 커널  |     대부분의 커널 이미지.
010000  +------------------------+
        |  부트로더              |  <- 부트 섹터 엔트리 포인트 0000:7C00
001000  +------------------------+
        |  MBR/BIOS에 의해 예약됨|
000800  +------------------------+
        |  일반적으로 MBR이 사용 |
000600  +------------------------+ 
        |  BIOS만 사용           |
000000  +------------------------+

bzImage를 사용하면 프로텍티드 모드 커널이 0x100000 (“하이 메모리”)에 재배치되어 있고, 커널 리얼 모드 블럭(부트 섹터, 셋업, 그리고 스택/힙)은 0x10000과 로우 메모리의 끝 사이의 어느 주소에 relocatable로 만들어져 있습니다. 불행히도, 프로토콜 2.00과 2.01에서는 0x9000+ 메모리 범위를 여전히 내부적으로 커널이 사용합니다; 2.02 프로토콜이 이 문제를 해결합니다.

새로운 BIOS들이 확장 BIOS Data 영역(EBDA)으로 부르는 메모리를 로우 메모리의 가장 위 가까이에 좀 많이 할당하기 시작했기 때문에 “memory ceiling” — 부트로더에 닿는 로우 메모리의 가장 높은 지점 –을 최대한 낮게 지키는 것이 바람직합니다. 부트로더는 로우 메모리가 얼마나 사용가능한지를 검증하기 위해서 “INT 12h” BIOS 콜을 사용해야 합니다.

불행히도, INT 12h가 메모리의 양이 너무 적다고 보고하면, 보통은 부트로더가 할 수 있는 게 없고, 사용자에게 에러만 보고할 수 있습니다. 부트로더는 그래서 로우 메모리 안에 필요한 만큼만 적은 공간을 취하도록 설계되어야 합니다. 0x90000 세그먼트 내로 쓰여지는 데이터가 필요한 zImage나 오래된 bzImage 커널을 위해 부트로더는 0x9A000 위의 메모리를 사용하지 않는지 확인해야 합니다; 너무나 많은 BIOS들이 이 지점 위를 깹니다.

근래의 부트 프로토콜 버전 >= 2.02인 bzImage 커널을 위해 다음과 같은 메모리 레이아웃이 제안되었습니다:

        ~                        ~
        |  프로텍티드 모드 커널  |
100000  +------------------------+
        |  I/O 메모리 홀         |
0A0000  +------------------------+
        |  BIOS를 위해 예약됨    |     가능한 사용하지 않은채로 두세요
        ~                        ~
        |  커맨드 라인           |     (X+10000 표시 아래도 사용 가능)
X+10000 +------------------------+
        |  스택/힙               |     커널 리얼 모드 코드가 사용하도록
X+08000 +------------------------+  
        |  커널 셋업             |     커널 리얼 모드 코드.
        |  커널 부트 섹터        |     커널 레가시 부트 섹터.
X       +------------------------+
        |  부트 로더             |  <- 부트 섹터 엔트리 포인트 0000:7C00
001000  +------------------------+
        |  MBR/BIOS를 위해 예약됨|
000800  +------------------------+
        |  일반적으로 MBR이 사용 |
000600  +------------------------+ 
        |  BIOS만 사용           |
000000  +------------------------+

여기서 주소 X는 부트로더의 디자인이 허용하는 한 낮습니다.

 

**** 리얼 모드 커널 헤더

다음 본문에서 커널 부트 시퀀스의 어디에서든, “섹터”는 512 바이트로 참조됩니다. 이는 밑바탕의 미디어의 실제 섹터 크기에 무관합니다.

리눅스 커널을 로딩하는 첫 단계는 리얼 모드 코드(부트 섹터와 셋업 코드)를 로드하고 난 후 오프셋 0x01f1에 뒤따르는 헤더를 검사하는 것이어야 합니다. 리얼 모드 코드는 부트로더가 처음 두 섹터 (1K)만 로드하고나서 부트업 섹터 크기를 검사하도록 골라질 수 있다 하더라도, 전부 32K까지 될 수 있습니다.

헤더는 다음과 같습니다:

오프셋  Proto   이름                  의미
/크기

01F1/1  ALL(1   setup_sects           섹터로 된 셋업의 크기
01F2/2  ALL     root_flags            셋팅되면 그 루트는 readonly로 마운트됨
01F4/4  2.04+(2 syssize               16-byte paras로 된 32비트 코드의 크기
01F8/2  ALL     ram_size              사용 금지 - bootsect.S만 사용
01FA/2  ALL     vid_mode              비디오 모드 제어
01FC/2  ALL     root_dev              디폴트 루트 디바이스 번호
01FE/2  ALL     boot_flag             0xAA55 매직 넘버
0200/2  2.00+   jump                  점프 명령
0202/4  2.00+   header                매직 시그니처 "HdrS"
0206/2  2.00+   version               지원되는 부트 프로토콜 버전
0208/4  2.00+   realmode_swtch        부트로더 훅 (아래 참조)
020C/2  2.00+   start_sys_seg         load-low 세그먼트 (0x1000) (구식)
020E/2  2.00+   kernel_version        커널 버전 스트링의 포인터
0210/1  2.00+   type_of_loader        부트로더 식별자
0211/1  2.00+   loadflags             부트 프로토콜 옵션 플래그
0212/2  2.00+   setup_move_size       하이 메모리로 옮기는 크기 (훅과 사용)
0214/4  2.00+   code32_start          부트로더 훅 (아래 참조)
0218/4  2.00+   ramdisk_image         initrd 로드 주소 (부트로더가 셋팅)
021C/4  2.00+   ramdisk_size          initrd 크기 (부트로더가 셋팅)
0220/4  2.00+   bootsect_kludge       사용 금지 - bootsect.S만 사용
0224/2  2.01+   heap_end_ptr          셋업 끝 이후 남는 메모리
0226/1  2.02+(3 ext_loader_ver        확장된 부트로더 버전
0227/1  2.02+(3 ext_loader_type       확장된 부트로더 ID
0228/4  2.02+   cmd_line_ptr          커널 커맨드 라인으로의 32비트 포인터
022C/4  2.03+   initrd_addr_max       가장 높이 허용되는 initrd 주소
0230/4  2.05+   kernel_alignment      커널을 위해 요구되는 물리 메모리 얼라인먼트
0234/1  2.05+   relocatable_kernel    커널이 재배치 가능한지 아닌지
0235/1  2.10+   min_alignment         2의 거듭제곱인 얼라인먼트의 최소값
0236/2  2.12+   xloadflags            부트 프로토콜 옵션 플래그
0238/4  2.06+   cmdline_size          커널 커맨드 라인의 최대 크기
023C/4  2.07+   hardware_subarch      하드웨어의 서브 아키텍처
0240/8  2.07+   hardware_subarch_data 서브 아키텍처 전용 Data
0248/4  2.08+   payload_offset        커널 페이로드의 오프셋
024C/4  2.08+   payload_length        커널 페이로드의 길이
0250/8  2.09+   setup_data            setup_data 구조체의 링크드 리스트로의 64비트 물리 포인터
0258/8  2.10+   pref_address          선호하는 로딩 주소
0260/4  2.10+   init_size             초기화하는 동안 필요한 리니어(Linear) 메모리
0264/4  2.11+   handover_offset       핸드오버 엔트리 포인트의 오프셋

(1) 하위 호환을 위해, setup_sects필드가 0을 가지면, 실제 값은 4.

(2) 2.04 이전의 부트 프로토콜을 위해, syssize 필드의 상위 2바이트는 사용 불가다.
    이는 bzImage 커널의 크기는 결정될 수 없음을 의미한다.

(3) 무시되지만 부트 프로토콜 2.02-2.09를 위해 셋팅하는 것이 안전하다.

“HdrS” (0x53726448) 매직 넘버가 오프셋 0x202에 없다면 부트 프로토콜 버전은 “오래된” 것입니다. 오래된 커널을 로딩하면 다음 파라미터들이 가정되어야 합니다:

이미지 타입 = zImage
initrd는 지원하지 않음
리얼 모드 커널은 0x90000에 위치해야 함.

아니면, “version” 필드가 프토토콜 버전을, 예를 들면 프로토콜 버전 2.01은 0x0201을 이 필드 안에 가지는 것처럼 가집니다. 헤더 안의 필드를 셋팅할 때 사용하는 프로토콜 버전이 지원하는 필드만 셋팅하는지 확인해야 합니다.

 

**** 헤더 필드의 상세 사항

각 필드에 대해 어떤 것들은 커널로부터 부트로더로의 정보이고(“read”), 어떤 것들은 부트로더에 의해 채워질 것으로 기대되고(“write”), 그리고 어떤 것들은 부트로더에 의해 읽히고 수정될 것으로 기대됩니다(“modify”).

모든 일반 목적의 부트로더들은 (obligatory) 표시된 필드들을 써야합니다. 커널을 비표준 주소에 로드하길 원하는 부트로더들은 (reloc) 표시된 필드들을 채워야 합니다; 다른 부트로더들은 이들 필드를 무시할 수 있습니다.

모든 필드의 바이트 오더는 리틀엔디안입니다 (이건 전부 x86입니다).

필드 이름:    setup_sects
타입:         read
오프셋/크기:  0x1f1/1
프로토콜:     ALL

셋업 코드의 크기는 512 바이트 섹터 수로 되어 있습니다. 이 필드가 0이면 실제 값은 4입니다. 리얼 모드 코드는 부트 섹터 (항상 512 바이트 하나) + 셋업 코드로 구성됩니다.

필드 이름:    root_flags
타입:         modify (옵션)
오프셋/크기:  0x1f2/2
프로토콜:     ALL

이 필드가 0이 아니면, 루트는 디폴트로 readonly. 이 필드는 앞으로 사라집니다; 대신 커맨드 라인 상에 “ro” 또는 “rw” 옵션을 사용하세요.

필드 이름:    syssize
타입:         read
오프셋/크기:  0x1f4/4 (프로토콜 2.04+) 0x1f4/2 (모든 프로토콜)
프로토콜:     2.04+

16 바이트 단위로 된 프로텍티드 모드 코드의 크기. 2.04 이전의 프로토콜 버전에서 이 필드는 2바이트 길이로만 사용되었기 때문에 LOAD_HIGH 플래그가 셋팅되어 있다면 커널의 크기를 믿을 수 없습니다.

필드 이름:    ram_size
타입:         kernel internal
오프셋/크기:  0x1f8/2
프로토콜:     ALL

이 필드는 구식입니다.

필드 이름:    vid_mode
타입:         modify (obligatory)
오프셋/크기:  0x1fa/2

특별한 커맨드 라인 옵션 절을 보세요.

필드 이름:    root_dev
타입:         modify (optional)
오프셋/크기:  0x1fc/2
프로토콜:     ALL

디폴트 루트 디바이스의 디바이스 넘버. 이 필드는 곧 사라집니다. 대신 커맨드 라인 상에서 “root=” 옵션을 사용하세요.

필드 이름:    boot_flag
타입:         read
오프셋/크기:  0x1fe/2
프로토콜:     ALL

0xAA55를 가짐. 이는 오래된 리눅스 커널들이 가지는 매직 넘버와 가장 비슷합니다.

필드 이름:    jump
타입:         read
오프셋/크기:  0x200/2
프로토콜:     2.00+

0xEB 다음 부호있는 0x202 바이트에서의 상대적인 오프셋이 뒤에 오는 x86 점프 명령을 가짐. 이는 헤더의 크기를 결정하는데 사용될 수 있습니다.

필드 이름:    header
타입:         read
오프셋/크기:  0x202/4
프로토콜:     2.00+

매직 넘버 “HdrS” (0x53726448)를 가짐.

필드 이름:    version
타입:         read
오프셋/크기:  0x206/2
프로토콜:     2.00+

(메이저 << 8) + 마이너 형식, 예를 들면, 버전 2.04는 0x0204, 가상의 버전 10.17은 0x0a11로 된 부트 프로토콜 버전을 가짐.

필드 이름:    realmode_swtch
타입:         modify (optional)
오프셋/크기:  0x208/4
프로토콜:     2.00+

부트로더 훅 (아래의 고급 부트로더 훅을 보세요)

필드 이름:    start_sys_seg
타입:         read
오프셋/크기:  0x20c/2
프로토콜:     2.00+

Load low 세그먼트 (0x1000). 구식.

필드 이름:    kernel_version
타입:         read
오프셋/크기:  0x20e/2
프로토콜:     2.00+

0이 아닌 값으로 셋팅되어 있다면 NUL로 끝나는 사람이 읽을 수 있는 커널 버전 넘버 스트링으로의 포인터보다 0x200보다 작은 포인터를 담습니다. 이는 유저에게 커널 버전을 보여주는데 사용될 수 있습니다. 이 값은 (0x200*setup_sects) 보다 작아야 합니다.

예를 들어, 이 값이 0x1c00으로 셋팅되어 있으면, 커널 버전 넘버 스트링은 커널 파일 내의 오프셋 0x1e00에서 찾을 수 있습니다. 이 값은 다음처럼 “setup_sects” 필드가 15 이상의 값을 담고 있을 때만 유효합니다:

0x1c00 < 15*0x200 (= 0x1e00) 그러나
0x1c00 >= 14*0x200 (= 0x1c00)

0x1c00 >> 9 = 14, 그래서 setup_sects의 최소값은 15.

필드 이름:    type_of_loader
타입:         write (obligatory)
오프셋/크기:  0x210/1
프로토콜:     2.00+

부트로더가 할당된 id를 가지면, 0xTV가 여기에 들어가는데, T는 부트로더의 identifier이고, V는 버전 넘버입니다. 아니면 0xFF가 여기에 들어갑니다.

T = 0xD 위의 부트로더 ID들을 위해서는, T = 0xE를 이 필드에 쓰고 확장된 ID – 0x10을 ext_loader_type 필드에 씁니다. 비슷하게 ext_loader_ver 필드는 부트로더 버전의 4비트 이상을 제공하는데 사용될 수 있습니다.

예를 들면, T = 0x15, V = 0x234는 다음처럼 씁니다:

  type_of_loader  <- 0xE4
  ext_loader_type <- 0x05
  ext_loader_ver  <- 0x23

할당된 부트로더 ID들 (16진수):

   0  LILO         (0x00이 pre-2.00 bootloader에 예약됨)
    1  Loadlin
    2  bootsect-loader  (0x20, 다른 모든 값은 예약됨)
    3  Syslinux
    4  Etherboot/gPXE/iPXE
    5  ELILO
    7  GRUB
    8  U-Boot
    9  Xen
    A  Gujin
    B  Qemu
    C  Arcturus Networks uCbootloader
    D  kexec-tools
    E  Extended     (ext_loader_type를 보세요)
    F  Special      (0xFF = undefined)
       10  Reserved
       11  Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de>
       12  OVMF UEFI virtualization stack

부트로더 ID 값의 할당이 필요하면, <hpa@zytor.com>에 연락하세요.

필드 이름:    loadflags
타입:         modify (obligatory)
오프셋/크기:  0x211/1
프로토콜:     2.00+

이 필드는 비트마스크이다.

  Bit 0 (read):    LOADED_HIGH
    - 0이면, 프로텍티드 모드 코드가 0x10000에 로드됨.
    - 1이면, 프로텍티드 모드 코드가 0x100000에 로드됨.

  Bit 1 (커널 내부용): KASLR_FLAG
    - 압축된 커널이 적절히 커널로 KASLR 상태를 통신하는데 내부적으로 사용됨
      1이면, KASLR 켜짐.
      0이면, KASLR 꺼짐.

  Bit 5 (write): QUIET_FLAG
    - 0이면, 얼리(early) 메시지를 출력.
    - 1이면, 얼리(early) 메시지를 찍지 않음.
        이는 커널 (decompressor와 얼리 커널)에게 디스플레이 하드웨어에
        직접 접근이 필요한 얼리 메시지를 쓰지 않도록 요청함.

  Bit 6 (write): KEEP_SEGMENTS
    프로토콜: 2.07+
    - 0이면, 32비트 엔트리 포인트 내에 세그먼트 레지스터들을 다시 로드.
    - 1이면, 32비트 엔트리 포인트 내에 세그먼트 레지스터들을 다시 로드하지 않음.
        %cs %ds %ss %es 가 모두 베이스 0에 (또는 그들의 환경에 동등하게)
        플랫(flat) 세그먼트로 셋팅되었음을 가정.

  Bit 7 (write): CAN_USE_HEAP
    heap_end_ptr 내에 들어있는 값이 유효함을 나타내기 위해서 이 비트를 1로 셋팅.
    이 필드가 셋팅되어 있지 않으면, 어떤 셋업 코드 기능은 꺼짐.
필드 이름:    setup_move_size
타입:         modify (obligatory)
오프셋/크기:  0x212/2
프로토콜:     2.00-2.01

프로토콜 2.00 또는 2.01을 사용할 때, 리얼 모드 커널이 0x90000에 로드되지 않으면, 로딩 시퀀스 안에서 나중에 옮겨집니다. 리얼 모드 커널 자체 뿐만 아니라 추가로 옮길 (커널 커맨드 라인 같은) 추가 데이터를 원한다면 이 필드를 채우세요.

단위는 부트 섹터의 시작에서 시작하는 바이트 수입니다.

이 필드는 프로토콜 2.02 이상 또는 리얼 모드 코드가 0x90000에 로드된다면 무시될 수 있습니다.

필드 이름:    code32_start
타입:         modify (optional, reloc)
오프셋/크기:  0x214/4
프로토콜:     2.00+

프로텍티드 모드 내에서 점프할 주소. 이는 커널의 로드 주소가 디폴트이고 부트로로가 적절한 로드 주소를 결정하는데 사용될 수 있습니다.

이 필드는 두가지 목적으로 바뀔 수 있습니다:

1. 부트로더 훅으로써 (아래의 고급 부트로더 훅을 보세요)

2. 혹이 설치되지 않은 부트로더가 재배치 가능한 커널을 비표준 주소에 로드하면 로드 주소를 가리키는 이 필드를 바꿔야 합니다.

필드 이름:    ramdisk_image
타입:         write (obligatory)
오프셋/크기:  0x218/4
프로토콜:     2.00+

32비트 초기 램디스크나 ramfs의 리니어(linear) 주소. 초기 램디스크/ramfs가 없으면 0으로 두세요.

필드 이름:    ramdisk_size
타입:         write (obligatory)
오프셋/크기:  0x21c/4
프로토콜:     2.00+

초기 램디스크나 ramfs의 크기. 초기 램디스크/ramfs가 없으면 0으로 두세요.

필드 이름:    bootsect_kludge
타입:         kernel internal
오프셋/크기:  0x220/4
프로토콜:     2.00+

이 필드는 구식입니다.

필드 이름:    heap_end_ptr
타입:         write (obligatory)
오프셋/크기:  0x224/2
프로토콜:     2.01+

셋업 스택/힙의 끝의 (리얼 모드 코드의 시작으로부터의) 오프셋 – 0x0200로 이 필드를 셋팅하세요.

필드 이름:    ext_loader_ver
타입:         write (optional)
오프셋/크기:  0x226/1
프로토콜:     2.02+

이 필드는 type_of_loader 필드 내의 버전 넘버의 확장으로 사용됩니다. 합친 버전 넘버는 (type_of_loader & 0x0f) + (ext_loader_ver << 4)로 처리됩니다.

이 필드의 사용은 부트로더에 따라 다릅니다. 안쓰이면 0입니다.

2.6.31 이전의 커널은 이 필드를 인식하지 않습니다만 프로토콜 버전 2.02 이상을 위해 쓰이는 것이 안전합니다.

필드 이름:    ext_loader_type
타입:         write (obligatory if (type_of_loader & 0xf0) == 0xe0)
오프셋/크기:  0x227/1
프로토콜:     2.02+

이 필드는 type_of_loader 필드 내의 타입 넘버의 확장으로 사용됩니다. type_of_loader의 타입이 0xE이면, 실제 타입은 (ext_loader_type + 0x10)입니다.

이 필드는 type_of_loader가 0xE가 아니면 무시됩니다.

2.6.31 이전의 커널은 이 필드를 인식하지 않습니다만, 프로토콜 버전 2.02 이상을 위해 쓰이는 것이 안전합니다.

필드 이름:    cmd_line_ptr
타입:         write (obligatory)
오프셋/크기:  0x228/4
프로토콜:     2.02+

커널 커맨드 라인의 리니어 주소로 이 필드를 셋팅하세요. 커널 커맨드 라인은 셋업 힙의 끝에서 0xA0000 사이의 어디에나 위치될 수 있습니다; 리얼 모드 코드 그 자체와 같은 64K 세그먼트내에 있을 필요 없습니다.

부트로더가 커맨드 라인을 지원하지 않는다해도 이 필드를 빈 스트링으로 (또는 더 나은 “auto” 스트링으로) 가리킬 수 있게 채우세요. 이 필드가 0으로 남아있다면 커널은 부트로더가 2.02+ 프로토콜을 지원하지 않는다고 가정할 겁니다.

필드 이름:    initrd_addr_max
타입:         read
오프셋/크기:  0x22c/4
프로토콜:     2.03+

초기 램디스크/ramfs 내용으로 채워질 수 있는 최대 주소. 부트 프로토콜 2.02 이전에는 이 필드가 없고, 최대 주소가 0x37FFFFFF입니다. (이 주소는 가장 안전한 바이트 주소로 정의되므로, 램디스크가 정확히 131072 바이트 길이이고 이 필드는 0x37FFFFFF라면 램디스크는 0x37FE0000에서 시작할 수 있습니다)

필드 이름:    kernel_alignment
타입:         read/modify (reloc)
오프셋/크기:  0x230/4
프로토콜:     2.05+ (read), 2.10+ (modify)

(relocatable_kernel 이 true라면) 커널에 필요한 얼라인먼트(alignment) 단위. 이 필드 내에 값으로 얼라인먼트에 맞지 않는 곳에 로드된 재배치가능 커널은 커널 초기화시에 다시 얼라인될 겁니다.

프로토콜 버전 2.10부터, 이는 최적의 성능을 위해 선호되는 커널 얼라인먼트를 반영합니다; 로더가 더 적은 얼라인먼트를 허용하기 위해 이 필드를 바꾸는 것이 가능합니다. 아래의 min_alignment와 pref_address 필드를 보세요.

필드 이름:    relocatable_kernel
타입:         read (reloc)
오프셋/크기:  0x234/1
프로토콜:     2.05+

이 필드가 0이 아니면, 커널의 프로텍티드 모드 부분이 kernel_alignment 필드를 만족하는 어느 주소에도 로드될 수 있습니다. 로딩 후에 부트로더는 로드된 코드 또는 부트로더 훅을 가리키도록 code32_start 필드를 셋팅해야 합니다.

필드 이름:    min_alignment
타입:         read (reloc)
오프셋/크기:  0x235/1
프로토콜:     2.10+

이 필드가 0이 아니면, 선호되는 것과 반대로, 커널이 부팅하기 위해 필요한 최소 얼라인먼트의 2의 거듭제곱 값을 나타냅니다. 부트로더가 이 필드를 사용한다면, 원하는 얼라인먼트 단위로 kernel_alignment 필드를 업데이트해야 합니다; 일반적으로:

kernel_alignment = 1 << min_alignment

지나치게 정렬되지 않은 커널에는 상당한 성능 비용이 있을 수 있습니다. 그래서 로더는 일반적으로 kernel_alignment로부터 2의 거듭제곱씩 이 얼라인먼트로 내려가면서 시도하는 것이 좋습니다.

필드 이름:    xloadflags
타입:         read
오프셋/크기:  0x236/2
프로토콜:     2.12+

이 필드는 비트 마스크입니다.

  Bit 0 (read):    XLF_KERNEL_64
    - 1이면, 이 커널은 0x200에 레가시 64비트 엔트리 포인트를 갖습니다.

  Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
        - 1이면, kernel/boot_params/cmdline/ramdisk은 4G 위에 있을 수 있습니다.

  Bit 2 (read): XLF_EFI_HANDOVER_32
    - 1이면, 커널이 handover_offset에서 주어지는 32비트 EFI 핸드오프 엔트리 포인트를 지원합니다.

  Bit 3 (read): XLF_EFI_HANDOVER_64
    - 1이면, 커널이 handover_offset + 0x200에서 주어지는 64비트 EFI 핸드오프 엔트리
          포인트를 지원합니다.

  Bit 4 (read): XLF_EFI_KEXEC
    - 1이면, 커널이 EFI 런타임 지원으로 kexec EFI 부트를 지원합니다.
필드 이름:    cmdline_size
타입:         read
오프셋/크기:  0x238/4
프로토콜:     2.06+

0으로 끝나는 것을 뺀 커맨드 라인의 최대 크기. 이는 커맨드 라인이 최대 cmdline_size 문자를 담을 수 있음을 의미합니다. 프로토콜 버전 2.05 이전에는 그 최대 크기가 255였습니다.

필드 이름:    hardware_subarch
타입:         write (optional, defaults to x86/PC)
오프셋/크기:  0x23c/4
프로토콜:     2.07+

paravirtualized 환경에서 인터럽트 처리, 페이지 테이블 처리, 그리고 레지스터를 제어하는 접근 처리와 같은 하드웨어 로우 레벨 아키텍처적인 부분은 다르게 수행될 필요가 있습니다.

이 필드는 부트로더가 커널에게 우리가 아래와 같은 환경 내에 있음을 알릴 수 있도록 합니다.

  0x00000000   기본 x86/PC 환경
  0x00000001    lguest
  0x00000002    Xen
  0x00000003    Moorestown MID
  0x00000004    CE4100 TV 플랫폼
필드 이름:    hardware_subarch_data
타입:         write (subarch-dependent)
오프셋/크기:  0x240/8
프로토콜:     2.07+

하드웨어 서브아키(subarch) 전용 데이터로의 포인터. 이 필드는 현재 기본 x86/PC 환경에선 사용되지 않으므로, 수정하지 마세요.

필드 이름:    payload_offset
타입:         read
오프셋/크기:  0x248/4
프로토콜:     2.08+

0이 아니면, 이 필드는 프로텍티드 모드 코드의 시작에서 페이로드까지의 오프셋을 담습니다.

페이로드는 압축될 수 있습니다. 압축된, 그리고 압축되지 않은 데이터 둘 모두의 형식은 표준 매직 넘버를 사용해서 결정되어야 합니다. 현재 지원하는 압축 형식은 gzip(매직 넘버는 1F 8B 또는 1F 9E), bzip2 (매직 넘버 42 5A), LZMA (매직 넘버 5D 00), XZ (매직 넘버 FD 37), 그리고 LZ4 (매직 넘버 02 21) 입니다. 압축되지 않은 페이로드는 현재 항상 ELF (매직 넘버 7F 45 4C 46) 입니다.

필드 이름:    payload_length
타입:         read
오프셋/크기:  0x24c/4
프로토콜:     2.08+

페이로드의 길이

필드 이름:    setup_data
타입:         write (special)
오프셋/크기:  0x250/8
프로토콜:     2.09+

NULL로 끝나는 struct setup_data의 싱글 링크드 리스트로의 64비트 물리 포인터. 메카니즘을 넘기는 더 확장된 부트 파라미터를 정의하는데 사용됩니다. struct setup_data의 정의는 다음과 같습니다:

  struct setup_data {
      u64 next;
      u32 type;
      u32 len;
      u8  data[0];
  };

여기서 next는 링크드 리스트의 다음 노드로의 64비트 물리 포인터이고, 마지막 노드의 next 필드는 0입니다; type은 데이터의 내용을 식별하는데 사용됩니다; len은 data 필드의 길이입니다; data는 진짜 페이로드를 담습니다.

이 리스트는 부팅 과정 중에 여러 곳에서 수정될 수 있습니다. 그래서 이 리스트를 수정할 때 항상 이 링크드 리스트가 이미 엔트리를 담고 있는 경우를 고려해 확인해야 합니다.

필드 이름:    pref_address
타입:         read (reloc)
오프셋/크기:  0x258/8
프로토콜:     2.10+

0이 아니면, 이 필드는 커널을 위한 선호하는 로드 주소를 나타냅니다. 재배치 중인 부트로더는 가능하면 이 주소에 로드를 시도해야 합니다.

재배치 가능이 아닌 커널은 무조건 이 주소로 그 자신을 옮기고 실행할 겁니다.

필드 이름:    init_size
타입:         read
오프셋/크기:  0x260/4

이 필드는 커널이 그 메모리 맵을 시험할 수 있기도 전에 커널이 필요로 하는 커널 런타임 시작 주소에서 시작하는 리니어하게 연속된 메모리의 양을 나타냅니다. 이는 커널이 부팅하기 위해 필요한 전체 메모리의 양과는 다릅니다만, 재배치 중인 부트로더가 커널을 안전하게 로드할 주소를 고르는데 도움을 주는데 사용될 수 있습니다.

커널 런타임 시작 주소는 다음 알고리듬으로 결정됩니다:

  if (relocatable_kernel)
    runtime_start = align_up(load_address, kernel_alignment)
  else
    runtime_start = pref_address
필드 이름:    handover_offset
크기:         read
오프셋/크기:  0x264/4

이 필드는 커널 이미지에서 EFI 핸드오버 프로토콜 엔트리 포인트까지의 오프셋입니다. 커널을 부팅하는데 EFI 핸드오버 프로토콜을 사용하는 부트로더는 이 오프셋으로 점프해야 합니다.

더 자세한 사항은 EFI 핸드오버 프로토콜을 보세요.

 

**** 이미지 체크섬

부트 프로토콜 버전 2.08 부터 CRC-32가 특유의 폴리노미얼 0x04C11DB7과 초기 나머지 0xffffffff를 사용해서 전체 파일에 걸쳐 계산됩니다. 체크섬은 파일에 덧붙여집니다; 그래서 헤더의 syssize 필드 내에 지정된 한계까지의 그 파일의 CRC는 항상 0입니다.

 

**** 커널 커맨드 라인

커널 커맨드 라인은 부트로더와 커널이 통신하는 중요한 수단이 되었습니다. 그 옵션 중 일부는 또한 부트로더 그 자신과 관련됩니다. 아래의 “특별한 커맨드 라인 옵션”을 보세요.

커널 커맨드 라인은 null로 끝나는 스트링입니다. 최대 길이는 필드 cmdline_size로부터 얻을 수 있습니다. 프로토콜 버전 2.06 전에는 최대 255 문자였습니다. 너무 긴 스트링은 커널에 의해 자동으로 잘릴 겁니다.

부트 프로토콜 버전이 2.02 이후라면, 커널 커맨드 라인의 주소는 헤더 필드 cmd_line_ptr에 의해 주어집니다 (위를 보세요). 이 주소는 setup heap의 끝과 0xA0000 사이의 어느 곳에든 될 수 있습니다.

프로토콜 버전이 2.02가 아니거나 더 높다면, 커널 커맨드 라인은 다음 프로토콜을 사용해서 들어갑니다:

   오프셋 0x0020 (word)에, "cmd_line_magic", 매직 넘버 0xA33F가 들어갑니다.

    오프셋 0x0022 (word)에, "cmd_line_offset", (리얼 모드 커널의 시작과 관련된)
    커널 커맨드 라인의 오프셋이 들어갑니다.
    
    커널 커맨드 라인은 *반드시* setup_move_size로 커버되는 메모리 영역 내에 있어야 하므로,
    이 필드는 조정될 필요가 있을 수 있습니다.

 

**** 리얼 모드 코드의 메모리 레이아웃

리얼 모드 코드는 셋업되기 위해 스택/힙뿐 만 아니라 커널 커맨드 라인을 위해 할당된 메모리를 필요로 합니다. 이는 아래쪽 메가바이트 내에 리얼 모드 접근 가능한 메모리 내에서 수행될 필요가 있습니다.

근래의 머신들은 종종 상당히 큰 확장된 BIOS 데이터 영역(EBDA = Extended BIOS Data Area)을 갖는다는 것을 주의해야 합니다. 그래서 가능한한 적게 낮은 메가바이트를 사용하는 것이 권고됩니다.

불행히도 다음 상황 아래에서 0x90000 메모리 세그먼트가 사용되어야 합니다:

   - zImage kernel ((loadflags & 0x01) == 0)을 로딩할 때.
    - 2.01 또는 그 이전의 부트 프로토콜 커널을 로딩할 때.

      -> 2.00과 2.01 부트 프로토콜에서는 리얼 모드 코드가 다른 주소에
         로드될 수 있지만 내부적으로 0x90000에 재배치됩니다.
         "오래된" 프로토콜에서는 리얼 모드 코드는 0x90000에 로드됩니다.

0x90000에 로딩될 때, 0x9a000 위의 메모리 사용을 피하세요.

부트 프로토콜 2.02 또는 그 이상에서는, 커맨드 라인이 리얼 모드 셋업 코드와 같은 64K 세그먼트 내에 있을 필요는 없습니다; 그래서 스택/힙에 64K 세그먼트 전체를 주고, 그 위쪽에 커맨드 라인을 두는 것이 허용됩니다.

커널 커맨드 라인은 리얼모드 코드 아래 쪽 또는 하이 메모리 내에 두지 않아야 합니다.

 

**** 샘플 부트 설정

샘플 설정으로 리얼 모드 세그먼트의 아래 레이아웃을 가정합니다:

    0x90000 아래에 로딩할 때, 전체 세그먼트를 사용합니다:

    0x0000-0x7fff   리얼 모드 커널
    0x8000-0xdfff   스택과 힙
    0xe000-0xffff   커널 커맨드 라인

    0x90000에 로딩할 때 또는 프로토콜 버전이 2.01 또는 그 이전일 때:

    0x0000-0x7fff   리얼 모드 커널
    0x8000-0x97ff   스택과 힙
    0x9800-0x9fff   커널 커맨드 라인

부트로더는 그 헤더 내에 다음 필드를 넣어야 합니다:

   unsigned long base_ptr; /* 리얼 모드 세그먼트의 베이스 주소 */

    if ( setup_sects == 0 ) {
        setup_sects = 4;
    }

    if ( protocol >= 0x0200 ) {
        type_of_loader = <type code>;
        if ( loading_initrd ) {
            ramdisk_image = <initrd_address>;
            ramdisk_size = <initrd_size>;
        }

        if ( protocol >= 0x0202 && loadflags & 0x01 )
            heap_end = 0xe000;
        else
            heap_end = 0x9800;

        if ( protocol >= 0x0201 ) {
            heap_end_ptr = heap_end - 0x200;
            loadflags |= 0x80; /* CAN_USE_HEAP */
        }

        if ( protocol >= 0x0202 ) {
            cmd_line_ptr = base_ptr + heap_end;
            strcpy(cmd_line_ptr, cmdline);
        } else {
            cmd_line_magic  = 0xA33F;
            cmd_line_offset = heap_end;
            setup_move_size = heap_end + strlen(cmdline)+1;
            strcpy(base_ptr+cmd_line_offset, cmdline);
        }
    } else {
        /* 매우 오래된 커널 */

        heap_end = 0x9800;

        cmd_line_magic  = 0xA33F;
        cmd_line_offset = heap_end;

        /* 매우 오래된 커널은 그 리얼 모드 코드를 0x90000에
           로드해야만 한다 */

        if ( base_ptr != 0x90000 ) {
            /* 리얼 모드 커널 복사 */
            memcpy(0x90000, base_ptr, (setup_sects+1)*512);
            base_ptr = 0x90000;      /* 재배치 */
        }

        strcpy(0x90000+cmd_line_offset, cmdline);

        /* 32K 표시까지 메모리를 깨끗이 하는 것이 권장된다 */
        memset(0x90000 + (setup_sects+1)*512, 0,
               (64-(setup_sects+1))*512);
    }

 

**** 커널의 나머지 로딩

32비트 (리얼 모드가 아닌) 커널은 커널 파일 내의 오프셋 (setup_sects+1)*512에서 시작합니다(다시 한번, setup_sects == 0이면, 실제 값은 4). Image/zImage 커널에서는 주소 0x10000에, bzImage 커널에서는 주소 0x100000에 로드되어야 합니다.

프로토콜 >= 2.00 이고, loadflags 필드 내의 0x01 비트 (LOAD_HIGH)가 셋팅되어 있으면, 커널은 bzImage 커널입니다:

   is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
    load_address = is_bzImage ? 0x100000 : 0x10000;

Image/zImage 커널은 그 크기로 512K까지 될 수 있음을, 그래서 메모리의 0x10000-0x90000 범위 전체를 사용함을 주의하세요. 이는 이들 커널이 리얼 모드 부분을 0x90000에 로드하는 중요한 요구사항임을 의미합니다. bzImage 커널은 더 유연하게 허용합니다.

 

**** 특별한 커맨드 라인 옵션

부트로더가 제공한 커맨드 라인이 사용자에 의해 입력되었다면, 사용자는 다음 커맨드 라인 옵션이 동작할 거라고 기대할 수 있습니다. 그들은 보통 커널 커맨드 라인으로부터 그들 전체가 실제로 커널에 의미가 없다 하더라도 지우지 말아야 합니다. 부트로더 그 자신을 위한 추가 커맨드 라인 옵션이 필요한 부트로더 작성자들은 지금 또는 그 이후에 실제 커널 옵션과 충돌하지 않음을 확인하기 위해서 Documentation/admin-guide/kernel-parameters.rst 내에 등록된 것들을 보아야 합니다.

  vga=<mode>
    <mode> 여기는 정수(C 표기로, 10진수, 8진수, 또는 16진수)거나
    "normal" (0xFFFF를 의미), "ext" (0xFFFE를 의미) 또는 "ask"(0xFFFD를 의미)
    중 하나의 스트링입니다. 이 값은 커맨드 라인이 파싱되기 전에 커널이 사용하는
    vid_mode 필드 내에 입력되어야 합니다.

  mem=<size>
    <size> 는 (대소문자 구별 없는) K, M, G, T, P 또는 E (<< 10, << 20,
    << 30, << 40, << 50 or << 60을 의미)가 옵션으로 붙는 C 표기의 정수입니다.
    이는 메모리의 끝을 커널에 지정합니다. 이는 initrd를 메모리의 끝 근처에
    두어야 하기 때문에 initrd의 가능한 배치에 영향을 미칩니다.
    이는 커널과 부트로더 *둘 모두*에 옵션임을명심하세요!

  initrd=<file>
    initrd가 로드되어야 합니다. <file>의 의미는 부트로더에 따라 명확히 다르고,
    어떤 부트로더들(e.g. LILO)은 이런 커맨드를 갖지 않습니다.

추가로 어떤 부트로더들은 다음 옵션을 사용자 지정 커맨드 라인으로 추가합니다:

  BOOT_IMAGE=<file>
    로드되었던 부트 이미지. 다시 한번, <file>의 의미는 부트로더에 따라 
    명확히 다릅니다.

  auto
    명확한 사용자 간섭없이 커널이 부팅되었습니다.

이들 옵션을 부트로더가 추가하면, 그들을 사용자 지정 혹은 설정을 지정하는 커맨드 라인보다 먼저 두는 것을 강력히 권합니다. 아니면 “auto” 옵션에 의해 “init=/bin/sh”가 혼란스럽게 됩니다.

 

**** 커널 실행

커널은 리얼 모드 커널의 시작으로부터 세그먼트 오프셋 0x20 에 위치한 커널 엔트리 포인트로 점프하면서 시작됩니다. 이는 여러분의 리얼 모드 커널 코드를 0x90000에 로드하였다면, 커널 엔트리 포인트는 9020:0000 이라는 뜻입니다.

엔트리에서, ds = es = ss 는 리얼 모드 커널 코드의 시작 (0x90000에 코드가 로드되었다면 0x9000)을 가리키고, sp는 적절히, 보통 힙의 가장 높은 곳을 가리키도록 셋업되어야 하고, 인터럽트들이 꺼져있어야 합니다. 추가로 커널 내의 버그를 막기 위해서 부트로더가 fs = gs = ds = fs = ss로 셋팅하는 것이 권장됩니다.

위의 우리의 예제에서 우리는 이렇게 할 겁니다:

   /* 주의: "오래된" 커널 프로토콜의 경우, 이 시점에 base_ptr 은 == 0x90000여야
       합니다; 이전의 샘플 코드를 보세요. */

    seg = base_ptr >> 4;

    cli();  /* 인터럽트가 꺼진 상태로 들어감! */

    /* 리얼 모드 커널 스택을 셋업 */
    _SS = seg;
    _SP = heap_end;

    _DS = _ES = _FS = _GS = seg;
    jmp_far(seg+0x20, 0);   /* 커널 실행 */

여러분의 부트 섹터가 플로피 드라이브를 접근한다면, 커널 부트는 인터럽트를 끈 상태로 놔두고, 그래서 그 모터를 끄지 않을 것이기 때문에 특별히 로드된 커널이 플로피 드라이버를 demand-loaded 모듈로 가진다면, 커널이 실행되기 전에 플로피 모터를 끄는 것을 권합니다!

 

**** 고급 부트로더 훅

부트로더가 (DOS 하에서 실행되는 LOADLIN 같은) 특정 우호적이지 않은 환경에서 실행된다면, 표준 메모리 위치 요구사항을 따르는 것이 불가능할 수 있습니다. 그런 부트로더는 셋팅되었다면, 적절한 시점에 커널이 실행하는 다음 훅을 사용할 수 있습니다. 이들 훅의 사용은 아마 최후의 수단으로 고려되어야 합니다!

중요사항: 모든 훅은 호출하고 나서 %esp, %ebp, %esi, 그리고 %edi를 보존하는 것이 요구됩니다.

  realmode_swtch:
    프로텍티드 모드로 들어가기 전에 바로 실행되는 16비트 모드 far 서브루틴.
    디폴트 루틴은 NMI를 끕니다. 그래서 아마 여러분의 루틴 역시 그렇게 동작하여야 할 겁니다.

  code32_start:
    프로텍티드 모드로 전이된 후, 그러나 커널 압축이 해제되기 전에 바로 *점프되는*
    32비트 flat 모드 루틴. CS를 제외한 세그먼트가 셋업됨(현재 커널은 합니다만,
    합니다만, 오래된 것들은 하지 않습니다)이 보장되지 않습니다; 여러분 스스로
    BOOT_DS (0x18)로 그들을 셋업해야 합니다.

    여러분의 훅이 완료된 후, 여러분의 부트로더가 덮어씌우기 전의 이 필드 안에 있던
    (적당하다면 재배치된) 주소로 점프해야 합니다.

 

**** 32비트 부트 프로토콜

레가시 BIOS보다 새로운 BIOS의 머신들에는 EFI, LinuxBIOS, 기타, 그리고 kexec, 레가시 BIOS에 기초한 커널 내의 16비트 리얼 모드 셋업 코드가 사용될 수 없어서, 32비트 부트 프로토콜이 정의될 필요가 있습니다.

32비트 부트 프로토콜내에서, 리눅스 커널을 로딩하는데 있어 첫번째 단계는 (전통적으로 “zero page”로 알려진 struct boot_params) 부트 파라미터들을 셋업하는 것이어야 합니다. struct boot_params를 위한 메모리는 모두 0으로 초기화되어 할당되어야 합니다. 그러고나면 커널 이미지의 오프셋 0x01f1으로부터의 셋업 헤더가 struct boot_params내로 로드되어 시험되어야 합니다. 셋업 헤더의 끝은 다음과 같이 계산될 수 있습니다:

   0x0202 + byte value at offset 0x0201

16비트 부트 프로토콜의 것처럼 struct boot_param의 셋업 헤더를 읽고/바꾸고/쓰는 것에 더해, 부트로더는 또한 zero-page.txt 내에 설명된 것처럼 struct boot_params의 추가 필드들을 채워야 합니다.

struct boot_params를 셋업하고 나서, 부트로더는 32/64비트 커널을 16비트 부트 프로토콜의 것과 같은 방식으로 로드할 수 있습니다.

32비트 부트 프로토콜에서는 커널은 로드된 32/64비트 커널의 시작 주소인 32비트 커널 엔트리 포인트로 점프함으로써 시작됩니다.

엔트리에서 CPU는 페이징이 꺼진 32비트 프로텍티드 모드 내에 있어야 합니다; GDT는 셀렉터 __BOOT_CS(0x10)과 __BOOT_DS(0x18)을 위한 디스크립터로 로드되어야 합니다; 두 디스크립터 모두 4G flat 세그먼트여야 합니다; __BOOT_CS는 execute/read 권한을 가져야 하고, __BOOT_DS는 read/write 권한을 가져야 합니다; CS는 __BOOT_CS여야 하고, DS, ES, SS는 __BOOT_DS여야 합니다; 인터럽트는 꺼져 있어야 합니다; %esi는 struct boot_params의 베이스 주소를 갖고 있어야 합니다; %ebp, %edi 그리고 %ebx는 0이어야 합니다.

 

**** 64비트 부트 프로토콜

64비트 CPU와 64비트 커널의 머신에서 우리는 64비트 부트로더를 사용할 수 있고, 64비트 부트 프로토콜이 필요합니다.

64비트 부트 프로토콜에서 리눅스 커널을 로딩하는 첫번째 단계는 (전통적으로 “zero page”로 알려진 struct boot_params) 부트 파라미터들을 셋업하는 것이어야 합니다. struct boot_params를 위한 메모리는 어느 곳에나 (4G 위 조차도) 할당될 수 있고, 모두 0으로 초기화됩니다. 그럼 커널 이미지 상의 offset 0x01f1의 셋업 헤더가 struct boot_params내로 로드되고 시험되어야 합니다. 셋업 헤더의 끝은 다음과 같이 계산될 수 있습니다:

   0x0202 + byte value at offset 0x0201

16비트 부트 프로토콜의 것처럼 struct boot_params의 셋업 헤더를 읽고/바꾸고/쓰는 것에 더해, 부트로더는 또한 zero-page.txt 내에 설명된 것처럼 struct boot_params의 추가 필드들을 채워야 합니다.

struct boot_params를 셋업한 후, 부트로더는 16비트 부트 프로토콜과 같은 방식으로 64비트 커널을 로드할 수 있습니다만, 커널은 4G 위에 로드될 수 있습니다.

64비트 부트 프로토콜에서 커널은 로드된 64비트 커널의 시작 주소 + 0x200인 64비트 커널 엔트리 포인트로 점프함으로써 시작됩니다.

엔트리에서, CPU는 페이징이 켜진 64비트 모드 내에 있어야 합니다. 로드된 커널의 시작 주소로부터 setup_header.init_size로의 범위와 zero page와 커맨드 라인 버퍼는 ident 맵핑을 얻습니다; GDT는 셀렉터 __BOOT_CS(0x10)과 __BOOT_DS(0x18)을 위한 디스크립터로 로드되어야 합니다; 두 디스크립터 모두 4G flat 세크먼트여야 합니다; __BOOT_CS는 execute/read 권한을 가져야 하고, __BOOT_DS는 read/write 권한을 가져야 합니다; CS는 __BOOT_DS여야 하고, DS, ES, SS는 __BOOT_DS여야 합니다; 인터럽트들은 꺼져 있어야 합니다; %rsi는 struct boot_params의 베이스 주소를 갖고 있어야 합니다.

 

**** EFI 핸드오버 프로토콜

이 프로토콜은 부트로더가 EFI 부트 스텁으로 초기화하는 것을 미루도록 할 수 있습니다. 부트로더는 커널/initrd(s)를 부트 미디어로부터 로드하고, startup_{32,64}의 시작으로부터 hdr->handover_offset 바이트인 EFI 핸드오버 프로토콜 엔트리 포인트로 점프하는 것이 요구됩니다.

핸드오버 엔트리 포인트를 위한 함수 원형은 다음처럼 보입니다.

    efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)

‘handle’은 EFI 펌웨어가 부트로더로 넘기는 EFI 이미지 핸들이고, ‘table’은 EFI 시스템 테이블 – 이들은 UEFI 스펙의 2.3절 “handoff state”의 첫 두 아규먼트입니다. ‘bp’는 부트로더가 할당한 boot params입니다.

부트로더는 bp 내의 다음 필드를 반드시 채워놔야 합니다.

    o hdr.code32_start
    o hdr.cmd_line_ptr
    o hdr.ramdisk_image (사용 가능하다면)
    o hdr.ramdisk_size  (사용 가능하다면)

다른 모든 필드들은 0이어야 합니다.

 

[Linux:Kernel] string 처리 개선

String copying

ssize_t strscpy(char *dest, const char *src, size_t count);

ssize_t strscpy_truncate(char *dest, const char *src, size_t count);

strscpy()는 src에서 dest로 최대 count bytes를 copy한다. source string이 count bytes보다 긴 경우를 제외하고는 copy된 bytes 수를 리턴한다. 긴 경우는 -E2BIG을 리턴한다. 다른 차이는 overflow 나는 경우는 src를 truncate하는게 아니라 dest가 empty string이 된다. 에러 체크를 항상 하면 괜찮은데, 안하는 경우, truncate된 string이 문제를 일으키는 일이 많기 때문에 이렇게 동작한다고 한다.

truncate된 string이 필요한 경우는 아래 버전을 사용하면 된다. 리턴 값은 같지만, null-terminate된 truncate된 string이 dest에 들어간다.

Integer parsing

simple_strto*() 함수가 많이 사용되지만, checkpatch가 불평하듯, kstrto*()가 더 낫다. 그런데, simple_strto*()는 “123abc”와 같은 string을 123으로 변환하는데, 이게 편리한 경우도 있다. 그래서 새로운 함수가 제안되었다.

int parse_integer(const char *s, unsigned int base, <type> *val);

사실, parse_integer()는 함수가 아니라 val의 타입에 맞는 여러가지 매크로이다. val이 unsigned short라면, 디코딩은 unsigned를 기초로 하고, 결과값이 short의 범위를 벗어나지 않는지 확인된다.

최종 결과는 val안에 담기고, 디코딩된 char 수가 리턴된다. 전체 string이 decode됐는지는 s[return_value] 가 null byte인지를 체크하면 된다. null-terminate string이면 원래 s[strlen(s)]는 ‘\0’일 테니까. 아니라면, 그 곳에 parsing하는 string이 계속 있을 거다. base가 문서화되지 않은 값 PARSE_INTEGER_NEWLINE과 or되면, 맨 마지막의 newline character는 무시-sysfs file로의 input을 parsing할 때 유용하다-된다. 아무 character도 convert되지 않으면, -EINVAL을 리턴한다. overflow인 경우 -ERANGE를 리턴한다.

출처: Improving kernel string handling(http://lwn.net/Articles/643376/)

[Linux:Kernel] Documentation/io-mapping.txt

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under GPL license).
Documentation/io-mapping.txt
번역: 양정석 <dasomoli@gmailREMOVETHIS.com>
linux/io-mapping.h 안의 io_mapping 함수들은 CPU에 I/O 디바이스들의 작은 영역을
효율적으로 맵핑하는 추상화를 제공합니다. 애초의 용도는 ioremap_wc가 커널 주소
영역을 너무 많이 소비할 때 처럼 CPU에 전체 영역을 정적으로 맵핑할 수 없을 때,
32비트 프로세서들에서 큰 그래픽 영역을 제공하기 위함입니다.
맵핑 객체는 드라이버 초기화 중에 다음을 사용하여 생성합니다
        struct io_mapping *io_mapping_create_wc(unsigned long base,
                                                unsigned long size)
                ‘base’는 맵핑 가능하게 만들어 질 영역의 버스 주소인 반면,
                ‘size’는 얼마나 크게 영역을 맵핑할 것인지를 나타냅니다.
                둘다 바이트 수 입니다.
                이 _wc 변형은 io_mapping_map_atomic_wc나 io_mapping_map_wc로만
                사용할 수 있는 맵핑을 제공합니다.
이 맵핑 객체로, 개별 페이지들이 자동적으로, 혹은 아니게 필요한 스케줄링 환경에
따라 맵핑될 수 있습니다. 물론, 어토믹 맵핑은 더 효율적입니다:
        void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
                                       unsigned long offset)
                ‘offset’은 정의된 맵핑 영역 안에서의 오프셋입니다. 생성 함수
                에서 지정된 영역을 넘어서서 주소를 접근하는 것은 정의되지
                않은 결과를 불러옵니다. 페이지 정렬되지 않은 오프셋을
                사용하는 것도 정의되지 않은 결과를 불러옵니다. 반환 값은
                CPU 주소 공간 안의 한 페이지를 가리킵니다.
                이 _wc 변형은 페이지로의 write-combining 맵핑을 반환하고,
                io_mapping_create_wc에 의해 생성된 맵핑에만 사용가능합니다.
                태스크가 이 맵핑된 페이지를 잡고 있는 동안 슬립하지 않음을
                알아두세요.
        void io_mapping_unmap_atomic(void *vaddr)
                ‘vaddr’은 반드시 마지막 io_mapping_map_atomic_wc 호출에
                의해 반환된 값이어야 합니다. 이것은 지정된 페이지를 맵핑
                해제하고 그 태스크가 다시 한번 잠들 수 있게 합니다.
여러분이 그 락을 잡은 동안 슬립해야할 필요가 있다면, 극히 더 느리긴 하지만,
어토믹이 아닌 변형을 사용할 수 있습니다.
        void *io_mapping_map_wc(struct io_mapping *mapping,
                                unsigned long offset)
                이것은 태스크가 맵핑된 페이지를 잡고 있는 동안 슬립할 수 있다는
                것을 제외하면 io_mapping_map_atomic_wc와 같이 동작합니다.
        void io_mapping_unmap(void *vaddr)
                이것은 io_mapping_map_wc로 매핑된 페이지들이 사용되는 것을
                제외하면 io_mapping_unmap_atomic과 같이 동작합니다.
드라이버에 가까운 시간에, io_mapping 객체는 반드시 해제되어야만 합니다:
        void io_mapping_free(struct io_mapping *mapping)
현재 구현:
이들 함수의 초기 구현은 이미 구현된 맵핑 메카니즘을 사용해서 오직 추상 계층만
제공하고 새로운 기능은 없습니다.
64비트 프로세서에서 io_mapping_create_wc는 자원으로의 영구적으로 커널이 볼 수
있는 맵핑을 생성하는 전체 영역을 위해서 ioremap_wc를 호출합니다. 그 map_atomic과
map 함수들은 ioremap_wc에 의해 반환되는 가상 주소의 기준점으로부터의 요청된
오프셋을 더합니다.
HIGHMEM이 정의된 32비트 프로세서에서는 io_mappinc_map_atomic_wc가
kmap_atomic_pfn을 지정된 페이지를 어토믹하게 맵핑하는데 사용됩니다;
kmap_atimic_pfn은 디바이스 페이지와 사용될 것이라고 정말 여겨지지 않았습니다만,
이 용도를 위한 효율적인 맵핑을 제공합니다.
HIGHMEM 정의가 없는 32비트 프로세서에서는 io_mapping_map_atomic_wc와
io_mapping_map_wc 모두 새로운 맵핑을 모든 프로세서에 알리기 위해서 IPI를 수행하는
극악하게 비효율적인 함수인 ioremap_wc를 사용합니다. 이것은 극적인 성능 저하를
가져옵니다.

[Linux:Kernel] Documentation/printk-formats.txt

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under GPL license).

변수가 아래 타입이라면,           printk형식 지시자를 사용하세요:
———————————————————
                int                     %d 나 %x
                unsigned int            %u 나 %x
                long                    %ld 나 %lx
                unsigned long           %lu 나 %lx
                long long               %lld 나 %llx
                unsigned long long      %llu 나 %llx
                size_t                  %zu 나 %zx
                ssize_t                 %zd 나 %zx

가공되지 않은 포인터 값은 %p로 출력되는 것이 ‘좋습니다’. 커널은 포인터
형식을 위해 다음의 확장된 형식 지시자를 지원합니다:

심볼/함수 포인터:

        %pF     versatile_init+0x0/0x110
        %pf     versatile_init
        %pS     versatile_init+0x0/0x110
        %pSR    versatile_init+0x9/0x110
                (__builtin_extract_return_addr() 변환으로)
        %ps     versatile_init
        %pB     prev_fn_of_versatile_init+0x88/0x88

        심볼과 함수 포인터를 출력하기 위해서, (‘S’)로 오프셋과 함께, 혹은 (‘s’)로
        오프셋 없이, ‘S’와 ‘s’ 지시자들로 심볼 이름을 나타냅니다. KALLSYMS 없는
        커널 상에서 사용되면, 심볼 주소가 대신 출력됩니다.

        ‘B’ 지시자는 오프셋과 함께 심볼 이름을 나타내고, 스택 트레이스를 출력할
        때 사용되어야 합니다. 이 지시자는 Tail-Call이 사용되고, noreturn GCC 속성으로
        표시되었을 때 일어날 컴파일러 최적화의 효과를 고려하게 합니다.

        ia64, ppc64, 그리고 parisc64 아키텍처에서 함수 포인터들은 실제로는
        가장 먼저 풀어야 할 함수 기술자들입니다. ‘F’와 ‘f’ 지시자는 이 해결을
        수행하여 ‘S’와 ‘s’ 지시자와 같은 기능을 제공합니다.

커널 포인터:

        %pK     0x01234567 나 0x0123456789abcdef

        권한이 없는 사용자에게 가려져야 할 커널 포인터를 출력하기 위해서 사용.
        %pK의 동작은 kptr_restrict sysctl에 의존적입니다.
        – 더 자세한 사항은 Documentation/sysctl/kernel.txt를 보세요.

구조체 자원:

        %pr     [mem 0x60000000-0x6fffffff flags 0x2200] or
                [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
        %pR     [mem 0x60000000-0x6fffffff pref] or
                [mem 0x0000000060000000-0x000000006fffffff pref]

        구조체 자원을 출력하기 위해 사용. ‘R’과 ‘r’ 지시자는 디코딩된 플래그
        멤버들이 있게(‘R’) 혹은 없게(‘r’) 자원을 출력합니다.

phys_addr_t 타입의 물리 주소:

        %pa[p]  0x01234567 나 0x0123456789abcdef

        CPU 데이터 경로의 너비와 상관없이, 빌드 옵션에 의해서 다양하게 될 수 있는
        phys_addr_t 타입(그리고 resource_size_t 같은 그 변형)의 출력을 위해서 사용.
        참조로 넘김.
        

dma_addr_t 타입의 DMA 주소:

        %pad    0x01234567 나 0x0123456789abcdef

        CPU 데이터 경로의 너비와 상관없이, 빌드 옵션에 의해서 다양하게 될 수 있는
        dma_addr_t 타입의 출력을 위해서 사용. 참조로 넘김.

16진수 문자열의 비가공 버퍼:
        %*ph    00 01 02  …  3f
        %*phC   00:01:02: … :3f
        %*phD   00-01-02- … -3f
        %*phN   000102 … 3f

        명확한 구분자로 된 16진수 문자열로 작은 버퍼(64 바이트 길이까지의)를
        출력할 때 사용. 더 큰 버퍼는 print_hex_dump()의 사용을 고려하세요.

MAC/FDDI 주소:

        %pM     00:01:02:03:04:05
        %pMR    05:04:03:02:01:00
        %pMF    00-01-02-03-04-05
        %pm     000102030405
        %pmR    050403020100

        16진수 표기로 된 6바이트 MAC/FDDI 주소를 출력할 때 사용. ‘M’과
        ‘m’ 지시자는 바이트 구분자가 있게(‘M’) 혹은 없게(‘m’) 주소를 출력합니다.
        기본 바이트 구분자는 콜론(‘:’)입니다.

        FDDI 주소들이 쓰이는 곳에서 ‘F’ 지시자는 기본 구분자 대신에 대시(‘-‘)
        구분자를 사용하기 위해서 ‘M’ 지시자 이후에 사용될 수 있습니다.

        블루투스 주소를 위해서 리틀 엔디언으로 된 블루투스 주소의 보이는 형태의
        거꾸로 된 바이트 순서 맞춤을 사용하기 위해서 ‘R’ 지시자가 쓰이면 좋습니다.

IPv4 주소:

        %pI4    1.2.3.4
        %pi4    001.002.003.004
        %p[Ii]4[hnbl]

        IPv4의 점으로 구분된 10진수 주소를 출력할 때 사용. ‘I4’와 ‘i4’ 지시자는
        앞 쪽 0들이 있게(‘i4’) 혹은 없게(‘I4’) 주소를 출력합니다.

        덧붙는 ‘h’, ‘n’, ‘b’, 그리고 ‘l’ 지사자들은 각각 호스트, 네트워크,
        빅 또는    리틀 엔디언 주소를 나타내는데 사용됩니다. 아무 지시자가 없다면,
        기본 네트워크/빅 엔디언 오더가 사용됩니다.

IPv6 주소:

        %pI6    0001:0002:0003:0004:0005:0006:0007:0008
        %pi6    00010002000300040005000600070008
        %pI6c   1:2:3:4:5:6:7:8

        IPv6 네트워크-오더 16비트 16진수 주소를 출력할 때 사용. ‘I6’와 ‘i6’
        지시자는 콜론 구분자가 있게(‘I6’) 혹은 없게(‘i6’) 주소를 출력합니다.
        앞 쪽의 0들은 항상 사용됩니다.
        
        덧붙는 ‘c’ 지시자는 ‘I’ 지시자와 함께 http://tools.ietf.org/html/rfc5952에
        쓰여 있는 압축된 IPv6 주소를 출력하는데 사용할 수 있습니다.

IPv4/IPv6 주소 (일반적인, 포트와 함께, flowinfo, 범위):

        %pIS    1.2.3.4         나 0001:0002:0003:0004:0005:0006:0007:0008
        %piS    001.002.003.004 나 00010002000300040005000600070008
        %pISc   1.2.3.4         나 1:2:3:4:5:6:7:8
        %pISpc  1.2.3.4:12345   나 [1:2:3:4:5:6:7:8]:12345
        %p[Ii]S[pfschnbl]

        그 타입이 AF_INET인지 AF_INET6인지 구분할 필요 없이 IP 주소를 줄력할 때
        사용. ‘IS’ 또는 ‘iS’를 통해 지정된 유효한 ‘struct socketaddr’로의
        포인터는 이 형식 지시자에게 넘겨질 수 있습니다.

        덧붙는 ‘p’, ‘f’, 그리고 ‘s’ 지시자는 포트(IPv4, IPv6), flowinfo(IPv6),
        범위(IPv6)를 지정하는데 사용됩니다. 포트는 “:” 접두어를 갖고, flowinfo는
        ‘/’, 그리고 스코프는 ‘%’를 갖고, 각각 실제 값이 뒤 따릅니다.

        IPv6 주소의 경우에 http://tools.ietf.org/html/rfc5952에서 기술된
        압축된 IPv6 주소는 지시자 ‘c’를 사용하면 사용됩니다. IPv6 주소는
        추가적인 지시자        ‘p’, ‘f’, ‘s’의 경우에
        https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07 에
        제안된 것처럼 ‘[‘, ‘]’로 둘러싸입니다.

        IPv4 주소의 경우, 덧붙는 ‘h’, ‘n’, ‘b’, 그리고 ‘l’ 지시자가 잘 사용될 수
        있고, IPv6 주소의 경우에는 무시됩니다.

        더 많은 예제:

        %pISfc          1.2.3.4         나 [1:2:3:4:5:6:7:8]/123456789
        %pISsc          1.2.3.4         나 [1:2:3:4:5:6:7:8]%1234567890
        %pISpfc         1.2.3.4:12345   나 [1:2:3:4:5:6:7:8]:12345/123456789

UUID/GUID 주소:

        %pUb    00010203-0405-0607-0809-0a0b0c0d0e0f
        %pUB    00010203-0405-0607-0809-0A0B0C0D0E0F
        %pUl    03020100-0504-0706-0809-0a0b0c0e0e0f
        %pUL    03020100-0504-0706-0809-0A0B0C0E0E0F

        16바이트 UUID/GUID 주소를 출력하기 위해 사용. 덧붙는 ‘l’, ‘L’, ‘b’,
        그리고, ‘B’ 지시자는 리틀 엔디언 오더를 소문자(‘l’) 또는 대문자(‘L’)
        16진수 문자로 – 그리고 빅 엔디언 오더를 소문자(‘b’) 또는 대문자(‘B’)
        16진수 문자로 표시하는데 사용됩니다.

        아무 추가 지시자도 붙지 않으면 기본으로 리틀 엔디언 오더에 소문자로
        출력될 것입니다.

dentry 이름:
        %pd{,2,3,4}
        %pD{,2,3,4}

        dentry 이름을 출력하는데 사용; 만약 우리가 d_move()로 경쟁 상태를 만들면,
        그 이름은 오래된 것과 새 것이 섞일 것입니다. 웁스를 일으키지 않습니다.
        %pd dentry는 우리가 사용하곤 했던 %s dentry->d_name.name와 같지만 더
        안전합니다. %pd<n>은 마지막 n 컴포넌트를 출력합니다. %pD는 struct file에
        같은 동작을 합니다.

struct va_format:

        %pV

        struct va_fotmat 구조체를 출력하는데 사용. 이들은 다음과 같은 va_list와
        형식 문자열을 포함합니다:

        struct va_format {
                const char *fmt;
                va_list *va;
        };

        형식 문자열이나 va_list 인자들의 정확성을 확인하기 위한 어떤 메카니즘 없이
        이 기능을 사용하지 마세요.

u64는 %llu/&llx로 ‘출력해야’ 합니다:

        printk(“%llu”, u64_var);

s64는 %lld/%llx로 ‘출력해야’ 합니다:

        printk(“%lld”, s64_var);

Example:
<type>이 그 크기의 설정 옵션(예를 들면, sector_t, blkcnt_t)이나 그 크기의 아키텍처
(예를 들면, tcflag_t)에 의존적이라면, 가능한 가장 큰 타입의 형식 지시자를 쓰고
명시적으로 형을 변환하세요.
예제:

        printk(“test: sector number/total blocks: %llu/%llu\n”,
                (unsigned long long)sector, (unsigned long long)blockcount);

다시 알림: sizeof() 결과는 size_t 타입입니다.

여러분의 협력과 주의에 감사합니다.
By Randy Dunlap <rdunlap@infradead.org> and
Andrew Murray <amurray@mpc-data.co.uk>
그리고 우리말 번역에 양정석 <dasomoli@gmail.com>

[Linux:Kernel] AArch64 리눅스의 메모리 배치

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/arm64/memory.txt

     AArch64 리눅스의 메모리 배치
     ============================

Author: Catalin Marinas <catalin.marinas@arm.com>
번역  : 양정석 <dasomoli@gmailREMOVETHIS.com>
Date  : 20 February 2012

이 문서는 AArch64 리눅스 커널이 사용하는 가상 메모리 배치를 설명합니다.
이 아키텍처는 4KB 페이지 크기의 4단계 변환 테이블과 64KB 페이지 크기의
3단계 변환 테이블을 허용합니다.

AArch64 리눅스는 유저와 커널 양 쪽 모두 39비트 (512GB) 가상 주소를 허용하는
4KB 페이지 설정의 3단계 변환 테이블을 사용합니다. 64KB 페이지는 오직
2단계 변환 테이블이 사용되지만 메모리 배치는 같습니다.

유저 주소는 63:39 비트가 0으로 셋팅되는 반면, 커널 주소는 같은 곳의 비트에
1로 셋팅됩니다. TTBRx 선택은 가상 주소의 비트 63에 의해 결정됩니다.
swapper_pg_dir은 오직 커널 (전역) 맵핑만 포합하는 반면,
유저 pgd는 오직 유저 (비전역) 맵핑만 포함합니다. swapper_pgd_dir 주소는
TTBR1으로 쓰여지고, TTBR0로 절대 쓰여지지 않습니다.


4KB 페이지의 AArch64 리눅스 메모리 배치:

시작 크기 용도
———————————————————————–
0000000000000000 0000007fffffffff 512GB 유저

ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc

ffffffbbffff0000 ffffffbbffffffff  64KB [guard page]

ffffffbc00000000 ffffffbdffffffff   8GB vmemmap

ffffffbe00000000 ffffffbffbbfffff  ~8GB [guard, 추후 vmmemap]

ffffffbffa000000 ffffffbffaffffff  16MB PCI I/O 공간

ffffffbffb000000 ffffffbffbbfffff  12MB [guard]

ffffffbffbc00000 ffffffbffbdfffff   2MB 고정 맵핑

ffffffbffbe00000 ffffffbffbffffff   2MB [guard]

ffffffbffc000000 ffffffbfffffffff  64MB 모듈들

ffffffc000000000 ffffffffffffffff 256GB 커널 논리 메모리 맵


64KB 페이지의 AArch64 리눅스 메모리 배치:

시작 크기 용도
———————————————————————–
0000000000000000 000003ffffffffff   4TB 유저

fffffc0000000000 fffffdfbfffeffff  ~2TB vmalloc

fffffdfbffff0000 fffffdfbffffffff  64KB [guard page]

fffffdfc00000000 fffffdfdffffffff   8GB vmemmap

fffffdfe00000000 fffffdfffbbfffff  ~8GB [guard, 추후 vmmemap]

fffffdfffa000000 fffffdfffaffffff  16MB PCI I/O 공간

fffffdfffb000000 fffffdfffbbfffff  12MB [guard]

fffffdfffbc00000 fffffdfffbdfffff   2MB 고정 맵핑

fffffdfffbe00000 fffffdfffbffffff   2MB [guard]

fffffdfffc000000 fffffdffffffffff  64MB 모듈들

fffffe0000000000 ffffffffffffffff   2TB 커널 논리 메모리 맵


4KB 페이지의 변환 테이블 탐색:

+——–+——–+——–+——–+——–+——–+——–+——–+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+——–+——–+——–+——–+——–+——–+——–+——–+
 |                 |         |         |         |         |
 |                 |         |         |         |         v
 |                 |         |         |         |   [11:0]  페이지 내의 오프셋
 |                 |         |         |         +-> [20:12] L3 인덱스
 |                 |         |         +———–> [29:21] L2 인덱스
 |                 |         +———————> [38:30] L1 인덱스
 |                 +——————————-> [47:39] L0 인덱스 (미사용)
 +————————————————-> [63] TTBR0/1


64KB 페이지의 변환 테이블 탐색:

+——–+——–+——–+——–+——–+——–+——–+——–+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+——–+——–+——–+——–+——–+——–+——–+——–+
 |                 |    |               |              |
 |                 |    |               |              v
 |                 |    |               |            [15:0]  페이지 내의 오프셋
 |                 |    |               +———-> [28:16] L3 인덱스
 |                 |    +————————–> [41:29] L2 인덱스 (38:29 만 사용)
 |                 +——————————-> [47:42] L1 인덱스 (미사용)
 +————————————————-> [63] TTBR0/1

KVM을 사용할 때, 하이퍼바이저는 커널 페이지를 EL2에서 커널 VA로부터 고정된
오프셋(커널 VA의 상위 24비트를 0으로 셋팅한)에 맵핑합니다:

시작 크기 용도
———————————————————————–
0000004000000000 0000007fffffffff 256GB HYP 내에서 맵핑된 커널 객체

[Linux:Kernel] AArch64 리눅스 부팅(AArch64 Linux Booting)

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/arm64/booting.txt

AArch64 리눅스 부팅

===================

Author: Will Deacon <will.deacon@arm.com>
번역  : 양정석 <dasomoli@gmailREMOVETHIS.com>
Date  : 07 September 2012

이 문서는 Russell King의 ARM 부팅 문서에 기초하고 AArch64 리눅스 커널의
모든 공개 릴리즈와 연관됩니다.

AArch64 예외 모델은 몇 개의 예외 단계(EL0 – EL3)으로, 그 중 EL0와 EL1은
시큐어와 논-시큐어 구성을 가지는 것으로 구성되어 있습니다. EL2는
하이퍼바이저 단계이고 논-시큐어 모드에서만 존재합니다. EL3는 가장 높은
단계이고, 시큐어 모드에서만 존재합니다.

이 문서의 목적에 따라, 우리는 ‘부트 로더’ 용어를 간단히 리눅스 커널로
제어를 넘기기 전에 CPU(들) 상에서 실행되는 모든 소프트웨어로 정의하여
사용할 것입니다. 이것은 시큐어 모니터와 하이퍼바이저 코드를 포함할 것이고,
또는 최소 부팅 환경을 준비하기 위한 한 줌의 명령들이 될 수도 있습니다.

기본적으로, 부트 로더는 다음을 (최소한) 제공해야 합니다:

1. RAM을 셋업하고 초기화
2. 디바이스 트리를 셋업
3. 커널 이미지를 압축 해제
4. 커널 이미지를 호출
1. RAM을 셋업하고 초기화
————————

요구 사항: 필수

부트 로더는 커널이 시스템 상의 임시 데이터 저장 공간으로 사용할 모든
RAM을 찾아서 초기화할 것으로 여겨집니다. 이는 머신 의존적인 방법으로
수행됩니다. (자동으로 모든 RAM의 크기를 재고 위치시키는데 내부
알고리즘을 사용하거나, 머신 안의 RAM에 대한 지식을 사용하거나, 또는
부트 로더 설계자가 맞춰 보는 다른 방법을 사용할 수도 있습니다.)
2. 디바이스 트리를 셋업
———————–

요구 사항: 필수

디바이스 트리 조각 (dtb)는 8 바이트 경계로 커널 이미지의 시작으로부터
512 메가 바이트 내에, 그리고 2 바이트 경계에 걸치지 않도록 위치해야만
합니다. 이것은 커널이 초기 페이지 내이블 내의 하나의 섹션 맵핑을 사용해서
조각을 맵핑할 수 있도록 해줍니다.
3. 커널 이미지를 압축 해제
————————–

요구 사항: 선택

AArch64 커널은 현재 압축 해제기를 제공하지 않고, 그래서 압축된 Image 타겟
(예를 들면, Image.gz)이 사용된다면 부트 로더에 의한 압축 해제
(gzip, 기타 등)를 요구합니다. 이 요구 사항을 구현하지 않은 부트로더들을
위해서 압축되지 않은 Image 타겟이 현재 대신 이용 가능합니다.
4. 커널 이미지를 호출
———————

요구 사항: 필수

압축 해제된 커널 이미지는 다음과 같은 64바이트 헤더를 포함합니다:

  u32 code0;
/* 실행 가능 코드 */
  u32 code1; /* 실행 가능 코드 */
  u64 text_offset; /* 이미지 로딩 오프셋 */
  u64 res0 = 0; /* 여분으로 예약 */
  u64 res1 = 0; /* 여분으로 예약 */
  u64 res2 = 0; /* 여분으로 예약 */
  u64 res3 = 0; /* 여분으로 예약 */
  u64 res4 = 0; /* 여분으로 예약 */
  u32 magic = 0x644d5241; /* 매직 넘버, 리틀 엔디언, “ARM\x64” */
  u32 res5 = 0;       /* 여분으로 예약 */
헤더 설명:

– code0/code1 은 stext로의 뜀을 책임집니다.
– EFI를 통해 부팅할 때, code0/code1은 초기에 건너 뜁니다. res5는
  PE 헤더로의 offset이고, PE 헤더는 EFI 진입 포인트(efi_stub_entry)를
  가집니다. 그 코드 조각이 작업을 끝내면, 보통의 부팅 프로세스를 재개하기
  위해서 code0 로 점프합니다.
  
이미지는 시스템 RAM의 시작으로부터 지정된 오프셋(현재는 0x80000)에
위치하고, 거기서 호출되어야만 합니다. 시스템 RAM의 시작은 2MB로 정렬되어져
있어야 합니다.

커널로 점프하기 전에, 다음 조건을 만족해야만 합니다:

– 모든 DMA 가능 장치들을 중지시켜 메모리가 가짜 네트워크 패킷이나
  디스크 데이터로 인해 깨지지 않도록 하세요. 이것은 많은 디버깅 시간을
  절약시켜 줄 것입니다.
  
– 주요 CPU 일반-목적(general-purpose) 레지스터 셋팅
  x0 = 시스템 RAM 내의 디바이스 트리 조각(dtb)의 물리 주소
  x1 = 0 (차후 용도를 위해 예약)
  x2 = 0 (차후 용도를 위해 예약)
  x3 = 0 (차후 용도를 위해 예약)  
  
– CPU 모드
  모든 형태의 인터럽트는 PSTATE.DAIF(Debug, Serror, IRQ 그리고 FIQ)로
  마스킹되어져야 합니다.
  CPU는 EL2(가상화 확장에 접근하기 위해서 추천함) 또는 논-시큐어 EL1 에
  있어야 합니다.

– 캐시, MMU
  MMU는 반드시 꺼져야 합니다.
  명령 캐시는 켜지거나 꺼져 있을 수 있습니다.
  로딩된 커널 이미지에 해당하는 주소 범위는 PoC로 깨끗해야 합니다.
  시스템 캐시나 켜진 캐시와 연관된 다른 마스터들의 존재 안에서,
  이것은 보통, 셋/웨이 연산보다는 VA에 의한 캐시 관리를 필요로 합니다.
  VA 연산에 의한 구조화된 캐시 관리를 준수하는 시스템 캐시는 설정되어져야
  하고, 켜지게 될 것 입니다.
  VA 연산에 의한 구조화된 캐시 관리를 따르지 않는(권장하지 않음) 시스템
  캐시는 설정되고 꺼져야만 합니다.

– 구조화된 타이머
  CNTFRQ는 반드시 타이머 주기로 프로그램되어야 하고, CNTVOFF는 모든
  CPU들의 일관된 값으로 프로그램되어야 합니다. 만약 EL1에서 커널로
  진입한다면, CNTHCTL_EL2는 반드시 셋팅된 EL1PCTEN(비트 0)을 가져야 합니다.

– 연관성
  커널에 의해 부팅될 모든 CPU들은 커널로의 진입 상의 같은 연관 도메인의
  일부가 되어야 합니다. 이것은 각 CPU 상의 관리 연산의 수신을 켜는
  ‘구현에 따라 정의된’ 초기화를 요구할 것입니다.
  
– 시스템 레지스터
  커널이미지가 진입하는 그 예외 레벨에서 모든 쓰기 가능한 구조화된 시스템
  레지스터들은 ‘알려지지 않은’ 상태 내의 실행을 막기 위해서 더 높은 예외
  레벨에서 소프트웨어에 의해 초기화되어야만 합니다.

위에 쓰여진 CPU 모드, 캐시, MMU, 구조화된 타이머, 연관성과 시스템 레지스터들에
대한 요구사항은 모든 CPU에 적용됩니다. 모든 CPU는 같은 예외 레벨 안에서
커널로 진입해야 합니다.

부트로더는 각 CPU가 다음과 같은 관례로 커널로 진입할 것으로 생각합니다:

– 주 CPU는 커널 이미지의 첫 명령으로 직접 점프해야만 합니다. 이 CPU에 의해
  넘겨진 디바이스 트리 조각은 각 CPU 노드의 ‘enable-method’ 프로퍼티를
  포함해야만 합니다. 지원되는 enable-method 들은 아래에서 설명합니다.

  부트로더는 이들 디바이스 트리 프로퍼티를 생생하고 커널 진입보다 먼저
  조각 안에 그들을 끼워 넣을 것입니다.

– “spin-table” enable-method 의 CPU들은 그들의 cpu 노드 내에
  하나의 ‘cpu-release-addr’ 프로퍼티를 가져야 합니다. 이 프로퍼티는
  자연스럽게 정렬된 64비트의 0으로 초기화된 메모리 위치를 나타냅니다.

  이 CPU들은 예약된 영역 안에 포함되어야만 하는, 그들의 cpu-release-addr
  위치를 폴링하는 (디바이스 트리 안의 /memreserve/ 영역에 의해 커널로
  전달되는) 메모리의 예약된 영역 안의 커널 밖에서 돌아야 합니다.
  wfe 명령은 비지-루프(busy-loop)의 부하를 줄이기 위해서 추가될 것이고,
  sev는 주 CPU에 의해 일어날 것입니다. cpu-release-addr에 의해
  가리켜지는 위치를 읽는 것이 0이 아닌 값을 반환할 때, 그 CPU는 이 값으로
  점프해야 합니다. 그 값은 하나의 64비트 리틀 엔디언 값으로 쓰여질
  것이므로 CPU들은 읽은 값을 그리로 점프하기 전에 그들 원래의 엔디언으로
  변환해야 합니다.

– “psci” enable method의 CPU들은 커널의 밖(즉, memory 노드 안에 커널로
  기술된 메모리의 그 영역 밖, 또는 디바이스 트리 안의 /memreserve/ 영역에
  의해 커널로 기술된 메모리의 예약된 영역 안)에 남아 있어야 합니다.
  커널은 커널 내로 CPU들을 가져오기 위해서 ARM DEN 0022A
  (“Power State Coordination Interface System Software on ARM processors”)
  문서 안에 설명된 것처럼 CPU_ON 호출들을 일으킬 것입니다.
  
  디바이스 트리는 하나의 ‘psci’ 노드를
  Documentation/devicetree/bindings/arm/psci.txt 안에 설명된대로
  포함해야만 합니다.

– 두번째 CPU 일반-목적 레지스터 셋팅
  x0 = 0 (차후 용도를 위해 예약)
  x1 = 0 (차후 용도를 위해 예약)
  x2 = 0 (차후 용도를 위해 예약)
  x3 = 0 (차후 용도를 위해 예약)

[Linux:Kernel] 동적 디버그 사용법(dynamic debug howto.txt)

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/dynamic-debug-howto.txt

번역: 양정석<dasomoli@gmailREMOVETHIS.com>

소개

====

이 문서는 어떻게 동적 디버그 (Dynamic Debug:dyndbg) 기능을 사용하는지 설명합니다.

동적 디버그는 여러분이 추가적인 커널 정보를 얻을 수 있도록 동적으로 커널 코드를 켜고/끌

수 있도록 설계되었습니다. 현재는 CONFIG_DYNAMIC_DEBUG가 설정되어 있다면, 모든

pr_debug()/dev_dbg() 그리고 print_hex_dump_debug()/

print_hex_dump_bytes() 호출은 호출하는 지점마다(per-callsite) 동적으로 켜질

수 있습니다.

CONFIG_DYNAMIC_DEBUG가 설정되어 있지 않으면, print_hex_dump_debug()는

그저 print_hex_dump(KERN_DEBUG)의 축약입니다.

print_hex_dump_debug()/print_hex_dump_bytes()에서 만약 그것이 변하지 않는

문자열이라면 형식 문자열(format string)은 그 ‘prrefix_str’ 인자입니다;

또는 ‘prefix_str’ 이 빌드 시 동적인 경우라면 “hexdump”.

동적 디버그는 더 유용한 기능들도 가집니다:

 * 0이나 1의 조합으로 매칭해서 디버깅 문장을 끄고 켤 수 있도록 하는 간단한 쿼리 언어:

   – 소스 파일 이름

   – 함수 이름

   – (행 번호의 범위를 포함하는) 행 번호

   – 모듈 이름

   – 형식 문자열

 * debugfs 제어 파일 제공: 여러분을 안내하는데 도움이 되도록, 알려진 디버그 문장들의

   완전한 목록을 보이도록 읽혀질 수 있는 <debugfs>/dynamic_debug/control.

동적 디버그 동작 제어하기

=========================

pr_debug()/dev_dbg()의 동작은 이 기능의 용도에 따라 ‘debugfs’ 파일 시스템 내의

제어 파일에 쓰는 것을 통해 제어됩니다. 이어서, 우리는 제어 파일을 알아봅니다:

<debugfs>/dynamic_debug/contorl. 예를 들어, 여러분이 소스 파일 ‘svcsock.c’의

1603번째 행에서 출력을 켜기를 원한다면, 간단히 이렇게 하세요:

nullarbor:~ # echo ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

여러분이 문법을 틀린다면, 쓰기가 실패할 것입니다:

nullarbor:~ # echo ‘file svcsock.c wtf 1 +p’ >
<debugfs>/dynamic_debug/control

-bash: echo: write error: Invalid argument

동적 디버그 동작 보기

=====================

여러분은 다음을 통해 현재 설정된 모든 디버그 문장의 동작을 볼 수 있습니다:

nullarbor:~ # cat <debugfs>/dynamic_debug/control

# filename:lineno [module]function flags format

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ “SVCRDMA Module Removed, deregister RPC RDMA transport\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ “\011max_inline       : %d\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ “\011sq_depth         : %d\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ “\011max_requests     : %d\012”


여러분은 또한 이 데이터에 표준 유닉스 텍스트 조작 필터를 적용할 수 있습니다. 예를 들면,

nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control  | wc -l

62

nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l

42

세번째 열은 현재 각 디버그 문장을 호출하는 곳마다의 켜짐 플래그(이 플래그의 정의는

아래를 보세요)를 보여줍니다. 아무 플래그도 설정되지 않은, 기본 값은 “=_” 입니다.

그래서 여러분은 모든 디버그 문장 호출처를 기본값이 아닌 플래그로 볼 수 있습니다:

nullarbor:~ # awk ‘$3 != “=_”‘ <debugfs>/dynamic_debug/control

# filename:lineno [module]function flags format

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p “svc_process: st_sendto returned %d\012”

명령 언어 레퍼런스

==================

어휘적인 수준에서, 하나의 명령은 스페이스나 탭으로 나뉘어진 단어 순서로 구성됩니다.

그래서 이들은 모두 동등합니다:

nullarbor:~ # echo -c ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

nullarbor:~ # echo -c ‘  file   svcsock.c     line  1603 +p  ‘ >
<debugfs>/dynamic_debug/control

nullarbor:~ # echo -n ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

명령 제출은 write() 시스템 호출로 경계지어집니다. 여러 명령은 ‘;’ 나 ‘\n’ 으로

나뉘어져서 함께 쓰여질 수 있습니다.

  ~# echo “func pnpacpi_get_resources +p; func pnp_assign_mem +p” \

     > <debugfs>/dynamic_debug/control

여러분의 쿼리 집합이 크다면, 역시 이를 일괄적으로 수행할 수 있습니다:

  ~# cat query-batch-file > <debugfs>/dynamic_debug/control

다른 방법은 와일드카드를 사용하는 것입니다. 매치 규칙은 ‘*’ (0개나 그 이상의 문자들과

매치)과 ‘?’ (정확히 하나의 문자와 매치)를 지원합니다. 예를 들면, 여러분은 모든 usb

드라이버들을 매치시킬 수 있습니다:

  ~# echo “file drivers/usb/* +p” > <debugfs>/dynamic_debug/control

문법적인 수준에서, 매치 명세(match-spec)들, 그 뒤에 플래그 변경 명세(flags-spec)

의 순서로 구성됩니다.

command ::= match-spec* flags-spec

매치 명세들은 플래그 변경 명세를 어디에 적용해야 하는지를 위해 알려진 pr_debug()

호출처의 부분 집합을 고르는데 사용됩니다. 각 짝들 사이에 암묵적인 AND로 하나의 쿼리처럼

그들을 생각하세요. 매치 명세의 빈 목록은 모든 디버그 문장 호출처를 선택함을 알아두세요.

매치 명세는 비교되는 호출처의 속성을 제어하는 하나의 키워드, 그리고 비교될 하나의 값으로

구성됩니다. 가능한 키워드들은:

match-spec ::= ‘func’ string |
      ‘file’ string |
      ‘module’ string |
      ‘format’ string |
      ‘line’ line-range

line-range ::= lineno |
      ‘-‘lineno |
      lineno’-‘ |
      lineno’-‘lineno

// 알림: line-range 스페이스를 포함할 수 없습니다. 예를 들면,

// “1-30″은 유효한 범위이지만, “1 – 30″은 아닙니다.

lineno ::= unsigned-int

각 키워드의 뜻은:

func

    주어진 문자열은 각 호출처의 함수 이름과 비교됩니다 예를 들면:

    func svc_tcp_accept

file

    주어진 문자열은 전체 경로 이름이나 소스 루트의(src-root) 상대 경로 이름, 또는 각

    호출처의 소스 파일의 경로를 제외한 이름(basename)과 비교됩니다. 예를 들면:

    file svcsock.c

    file kernel/freezer.c

    file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c

module

    주어진 문자열은 각 호출처의 모듈 이름과 비교됩니다. 모듈 이름은 “lsmod” 에서 보여지는

    문자열입니다. 즉, 디렉토리나 .ko 접미사가 없고, ‘-‘는 ‘_’로 변경됩니다. 예를 들면:

    module sunrpc

    module nfsd

format

    주어진 문자열은 동적 디버그 형식 문자열 내에서 검색됩니다. 그 문자열은 전체 형식과

    매치될 필요는 없고 오직 일부만 매치되면 된다는 것을 알아두세요. 공백 문자들과 다른

    특수 문자들은 C의 8진수 문자 이스케이프 \ooo 표현을 사용해서 쓰여질 수 있습니다.

    예를 들면, 스페이스 문자는 \040 입니다. 다른 방식으로, 문자열을 쌍따옴표 문자(“) 나

    따옴표(‘)로 둘러쌀 수 있습니다.

    예제:

    format svcrdma:
   // NFS/RDMA 서버 pr_debug 들에서 많음

    format readahead
   // readahead 캐시 안의 pr_debug 들

    format nfsd:\040SETATTR // 공백 문자로 형식을 매치하는 한가지 방법

    format “nfsd: SETATTR”  // 공백 문자로 형식을 매치하는 더 깔끔한 방법

    format ‘nfsd: SETATTR’  // 공백 문자로 형식을 매치하는 또 다른 방법

line

    주어진 행 번호 또는 행 번호의 범위는 각 pr_debug() 호출처의 행 번호와 비교됩니다.

    하나의 행 번호는 호출처 행 번호와 정확히 매치됩니다. 행 번호의 범위는 처음과 마지막의

    행 번호 안의 호출처와 매치됩니다. 첫번째 수가 없는 것은 파일의 첫번째 줄을 의미하고,

    행 번호가 없는 것은 파일의 마지막 줄을 의미합니다. 예를 들면: 

    line 1603
   // 정확히 1603번 줄

    line 1600-1605  // 1600번에서 1605번 줄까지의 여섯 줄

    line -1605
   // 1번 줄에서 1605번 줄까지의 1605 줄

    line 1600-
   // 1600번 줄에서 파일의 끝까지의 모든 줄

플래그 명세는 하나 또는 그 이상의 플래그 성질이 따르는 하나의 변경 동작으로 구성됩니다.

변경 동작은 하나의 성질입니다:

  –    주어진 플래그 제거

  +    주어진 플래그 추가

  =    주어진 플래그로 플래그를 설정

플래그들은 다음과 같습니다:

  p    pr_debug() 호출처 켜기

  f    출력된 메시지 안에 함수 이름을 포함

  l    출력된 메시지 안에 행 번호를 포함

  m    출력된 메시지 안에 모듈 이름을 포함

  t    인터럽트 컨텍스트에서 생성되지 않은 메시지 안에 스레드 ID 포함.

  _    플래그가 설정되지 않음. (또는 입력 상의 다른 것들로 설정)

print_hex_dump_debug()와 print_hex_dump_bytes()에서는, 오직 ‘p’ 플래그가

다른 플래그들이 무시되는 것을 의미합니다.

보여줄 때, 플래그들은 ‘=’이 앞에 옵니다(연상 기호: 무슨 플래그가 현재 동일한지).

Note the regexp ^[-+=][flmpt_]+$ matches a flags specification.

To clear all flags at once, use “=_” or “-flmpt”.

정규표현 ^[-+=][flmpt_]+$ 는 플래그 명세와 매치함을 알아두세요.

모든 플래그를 없애기 위해서, “=_” 나 “-flmpt”를 사용하세요.

부트 프로세스 동안의 디버그 메시지

==================================

부트 프로세스 동안의 코어 코드와 빌트인 모듈 디버그 메시지를 활성화 하기 위해서, 유저 공간과

debugfs 가 존재하기 전에도, dyndbg=”QUERY”, module.dyndbg=”QUERY”, 또는

ddebug_query=”QUERY”(ddebug_query는 dyndbg에 의해 구식이 되었고, 더 이상 사용하지

않습니다)를 사용할 수 있습니다. QUERY는 위에 설명된 문법을 따르지만, 1023 문자를 넘을 수

없습니다. 여러분의 부트로더는 제한으로 더 적은 수를 쓰고 있을 수 있습니다.

이들 dyndbg 파라미터들은 ddebug 테이블이 처리된 후에, arch_initcall 의 일부로

바로 처리됩니다. 그래서 여러분은 이 부트 파라미터를 통해 이 arch_initcall 이후에

모든 코드 안의 디버그 메시지를 켤 수 있습니다.

예를 들면, x86 시스템 상에서 ACPI 활성화는 subsys_initcall 이고,

   dyndbg=”file ec.c +p”

는 여러분의 머신(일반적으로 랩탑)이 임베디드 컨트롤러를 가진다면, ACPI 셋업동안 초기 임베디드

컨트롤러 트랜잭션을 보여줄 것입니다.

PCI (또는 다른 장치들의) 초기화는 또한 디버깅 목적의 이 부트 파라미터 사용의 유력한

후보들입니다.

foo 모듈이 빌트-인이 아니라면, foo.dyndbg 는 여전히 부트 타임에 아무 효과 없이 처리될

것입니다만, 모듈이 이후에 로딩될 때 처리될 것입니다. dyndbg_query= 과 순수한 dyndbg= 은

부트 시에만 처리됩니다.

모듈 초기화 시점의 디버그 메시지

================================

“modprobe foo”가 호출될 때, modprobe는 foo.params를 위해 /proc/cmdline을 스캔하고,

“foo.”을 벗겨서 제거하고, 이를 modprobe args 나 /etc/modprob.d/*.conf 파일 안에

주어진 파라미터들과 함께 다음 순서로 커널에게 넘긴다:

1. # /etc/modprobe.d/*.conf를 통해 주어진 파라미터들

   options foo dyndbg=+pt

   options foo dyndbg # +p로 기본

2. # boot args에서 주어진 foo.dyndbg, “foo.” 는 벗겨져서 제거되어 전달됨

   foo.dyndbg=” func bar +p; func buz +mp”

3. # modprobe로의 args

   modprobe foo dyndbg==pmf # 이전 설정을 덮어 씀

이들 dyndbg 쿼리들은 가장 마지막에 말한 것이 마지막에 적용되도록, 순서대로 적용됩니다.

이것은 boot args가 /etc/modprobe.d(정확하게는 1이 시스템 전체, 2는 커널이나 부트에

의존적임)로부터 이들을 수정하거나 덮어 쓰도록, 그리고 modeprbe args 가 둘 다를 덮어쓰도록

합니다.

foo.dyndbg=”QUERY” 형식 안에서, 쿼리는 반드시 “foo 모듈”을 제외해야 합니다.

“foo”는 param-name 으로부터 추출되고, “QUERY” 내의 각 쿼리에 적용되고, 오직

각 타입의 1 match-spec만 적용됩니다.

dyndbg 옵션은 “가짜” 모듈 파라미터입니다. 이는 다음을 의미합니다:

– 모듈들은 그를 명시적으로 정의할 필요가 없습니다.

– 모든 모듈은 그들이 pr_debug를 사용하든 말든, 아무 말 없이 이를 얻을 수 있습니다.

– 그것은 /sys/module/$module/parameters 안에 나타나지 않습니다. 이를 보기 위해서,

  제어 파일을 grep 하거나, /proc/cmdline 을 검사하세요.
CONFIG_DYNAMIC_DEBUG 커널에서는 디버그 메시지가 더이상 필요하지 않다면, 부트-타임에
주어진 (또는 컴파일 동안 -DDEBUG 플래그에 의해 켜진) 어떠한 셋팅도 이후에 sysfs
인터페이스를 통해 끌 수 있습니다.

   echo “module module_name -p” > <debugfs>/dynamic_debug/control

예제

====

// svcsock.c 파일의 1603번째 줄의 메시지를 켜기

nullarbor:~ # echo -n ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

// svcsock.c 파일 안의 모든 메시지 켜기

nullarbor:~ # echo -n ‘file svcsock.c +p’ >
<debugfs>/dynamic_debug/control

// NFS 서버 모듈의 모든 메시지 켜기

nullarbor:~ # echo -n ‘module nfsd +p’ >
<debugfs>/dynamic_debug/control

// svc_process() 함수 안의 모든 12 메시지를 켜기

nullarbor:~ # echo -n ‘func svc_process +p’ >
<debugfs>/dynamic_debug/control

// svc_process() 함수 안의 모든 12 메시지를 끄기

nullarbor:~ # echo -n ‘func svc_process -p’ >
<debugfs>/dynamic_debug/control

// NFS가 호출하는 READ, READLINK, READDIR 그리고, READDIR+를 위한 메시지 켜기

nullarbor:~ # echo -n ‘format “nfsd: READ” +p’ >
<debugfs>/dynamic_debug/control

// “usb” 문자열을 포함하는 경로의 메시지 켜기

nullarbor:~ # echo -n ‘*usb* +p’ > <debugfs>/dynamic_debug/control

// 모든 메시지 켜기

nullarbor:~ # echo -n ‘+p’ > <debugfs>/dynamic_debug/control

// 모든 켜진 메시지에 모듈과 함수 추가

nullarbor:~ # echo -n ‘+mf’ > <debugfs>/dynamic_debug/control

// boot-args 예제, 가독성을 위해 줄바꿈과 주석을 넣음

Kernel command line: …

  // dyndbg=값 처리 안에서 어떻게 되어가고 있는지 보기

  dynamic_debug.verbose=1

  // 2 빌트인 안의 pr_debug 켜기, #cmt 는 제거됨

  dyndbg=”module params +p #cmt ; module sys +p”

  // 나중에 로딩되는 모듈 안의 2 함수 안의 pr_debug를 켜기

  pc87360.dyndbg=”func pc87360_init_device +p; func pc87360_find +p”

[Linux:Kernel] PM Quality Of Service 인터페이스

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).
Documentation/power/pm_qos_interface.txt
번역: 양정석(dasomoli@gmailREMOVETHIS.com)
PM Quality Of Service 인터페이스.
이 인터페이스는 커널과 유저 모드에 그 파라미터 중 하나로 드라이버, 서브 시스템,
그리고 유저 공간 애플리케이션들에 의한 성능 기대 사항을 등록하기 위한
인터페이스를 제공합니다.
두가지 다른 PM QoS 프레임워크가 이용가능합니다:
1. cpu_dma_latency, network_latency, network_throughput을 위한 PM QoS 클래스들.
2. per-device PM QoS 프레임워크는 per-device 지연 제약 사항과 PM QoS 플래그를
관리하기 위한 API 를 제공합니다.
각 파라미터는 단위를 정의했습니다:
 * 지연(latency): usec
 * 만료(timeout): usec
 * 처리용량: kbs (킬로 비트 / 초)
1. PM QoS framework
이 인프라 구조는 여러개의 misc 디바이스 노드들을 구현된 파라미터 당 하나로
노출합니다. 파라미터들 구현 집합은 pm_qos_power_init() 과 pm_qos_params.h 에
의해 정의됩니다. 드라이버로부터 런타임에 설정 가능하거나 변경 가능한 사용 가능
파라미터들을 갖는 것이 오용되기 너무 쉬운 것으로 보여지기 때문에 이렇게
수행됩니다.
각 파라미터를 위해 성능 요구에 대한 리스트가 취합된(aggregated) 목표 값으로
관리됩니다. 취합된 목표 값은 그 요구 목록이나 그 리스트의 개체들로의 변경으로
갱신됩니다. 일반적으로 그 취합된 목표 값은 간단히 파라미터 리스트 개체들 안에
잡힌 요청 값의 최고 또는 최저 값입니다.
알림: 그 취합된 목표 값은 어토믹(atomic) 변수로 구현됩니다. 그래서 취합된 값을
읽는 것은 어떤 락킹 메카니즘도 필요 없습니다.
커널 모드로부터 이 인터페이스의 사용은 간단합니다:
void pm_qos_add_request(handle, param_class, target_value):
는 개체 하나를 그 리스트 안에 목표 값으로 식별된 PM QoS 클래스를 위해 삽입할
것입니다. 이 리스트로의 변경 위에서 새로운 목표는 재계산되고, 어떤 등록된
통지자(notifier)가 그 목표 값이 지금과 다를 때만 호출됩니다. pm_qos의
클라이언트는 다른 pm_qos API 함수들 안에서 추후에 사용될 때를 위해 반환된
핸들을 저장할 필요가 있습니다.
void pm_qos_update_request(handle, new_target_value):
는 그 핸들이 가리키는 리스트 개체를 새로운 목표 값으로 갱신하고, 그 목표가
바뀌면 취합된 목표, 통지(notifictation) 트리 호출을 재계산합니다.
void pm_qos_remove_request(handle):
는 개체를 제거합니다. 제거 후에는 취합된 목표를 갱신하고, 그 목표가 요청 제거의 결과로 바뀌면, 통지 트리를 호출할 것입니다.
int pm_qos_request(param_class):
는 주어진 PM QoS 클래스를 위한 취합된 값을 반환합니다.
int pm_qos_request_active(handle):
는 그 요청이 여전히 살아있는지를 반환합니다. 즉, PM QoS 클래스 제약 사항 리스트
로부터 제거되지 않았다는 것입니다.
int pm_qos_add_notifier(param_class, notifier):
는 통지 콜백 함수를 PM QoS 클래스로 추가합니다. 그 콜백은 PM QoS 클래스를 위한
취합된 값이 바뀌었을 때 호출됩니다.
int pm_qos_remove_notifier(int param_class, notifier):
는 PM QoS 클래스를 위한 통지 콜백 함수를 제거합니다.
유저 모드에서는:
프로세스들만 pm_qos 요청을 등록할 수 있습니다. 프로세스의 자동적인 청소 작업을
제공하기 위해서, 인터페이스는 프로세스에게 다음과 같은 방법으로 그 파라미터
요청을 등록하도록 요구합니다:
지정된 파라미터의 기본 pm_qos 목표를 등록하기 위해서, 프로세스는
/dev/[cpu_dma_latency, network_latency, network_throughput] 중 하나를
열어야만 합니다.
디바이스 노드가 연 것을 유지하는 동안 그 프로세스는 파라미터 상의 등록된
요청을 가집니다.
요청된 목표 값을 변경하기 위해서, 그 프로세스는 s32 값을 열린 디바이스 노드에
쓸 필요가 있습니다. 아니면, 유저 모드 프로그램이 16진수 문자열을 10 글자 길이의
형식의 값, 예를 들면, “0x12345678″로 쓸 수 있습니다. 이것은 pm_qos_update_request
호출로 변환됩니다.
목표 값의 유저 모드 요청을 지우려면, 간단히 디바이스 노드를 닫으세요.
2. PM QoS per-device 지연 프레임워크
각 개별 디바이스를 위한 성능 요청의 리스트는 취합된 목표 값으로 관리됩니다.
취합된 목표 값은 요청 리스트나 그 리스트의 개체로의 변경으로 갱신됩니다.
일반적으로 그 취합된 목표 값은 간단히 파라미터 리스트 개체 안에 잡힌 요청 값의
최고, 또는 최소 값입니다.
알림: 그 취합된 목표 값은 어토믹(atomic) 변수로 구현됩니다. 그래서 취합된 값을
읽는 것은 어떤 락킹 메카니즘도 필요 없습니다.
커널 모드로부터 이 인터페이스 사용은 다음과 같습니다:
int dev_pm_qos_add_request(device, handle, value):
는 개체 하나를 그 리스트 안으로 목표 값으로 식별된 디바이스를 위해 삽입할
것입니다. 이 리스트로의 변경 위해서 새로운 목표는 재계산되고, 어떤 등록된
통지자가 그 목표 값이 지금과 다를 때만 호출됩니다. dev_pm_qos의 클라이언트는
다른 dev_pm_qos API 함수들 안에서 추후에 사용될 때를 위해 그 핸들을 저장할
필요가 있습니다.
int dev_pm_qos_update_request(handle, new_value):
는 그 핸들이 가리키는 리스트 개체를 새로운 목표 값으로 갱신하고, 그 목표가
바뀌면 새로운 취합된 목표, 통지 트리 호출을 재계산합니다.
int dev_pm_qos_remove_request(handle):
는 개체를 제거합니다. 제거 후에는 취합된 목표를 갱신하고, 그 목표가 요청 제거의
결과로 바뀌면, 통지 트리를 호출할 것입니다.
s32 dev_pm_qos_read_value(device):
주어진 디바이스의 제약 사항 라스트를 위한 취합 값을 반환합니다.
통지 메카니즘:
per-device PM QoS 프레임워크는 2개의 다르고 구별되는 통지 트리를 가집니다:
per-device 통지 트리와 전역 통지 트리
int dev_pm_qos_add_notifier(device, notifier):
디바이스를 위한 통지 콜백 함수를 추가합니다.
디바이스 제약사항 리스트의 취합된 값이 바뀔 때, 콜백이 호출됩니다.
int dev_pm_qos_remove_notifier(device, notifier):
디바이스를 위한 통지 콜백 함수를 제거합니다.
int dev_pm_qos_add_global_notifier(notifier):
프레임워크의 전역 통지 트리 안에 통지 콜백 함수를 추가합니다.
어떤 디바이스를 위한 취합된 값이 바뀔 때, 콜백이 호출됩니다.
int dev_pm_qos_remove_global_notifier(notifier):
프레임워크의 전역 통지 트리로부터 통지 콜백 함수를 제거합니다.
유저모드에서는:
per-device 지연 제약 사항으로의 유저 공간 접근을 위한 API는 아직 제공되지
않습니다. – 아직 토의 중.

[Linux:Kernel] CPU 토폴로지

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/cputopology.txt

번역: 양정석(dasomoli@gmailREMOVETHIS.com)

CPU 토폴로지는 sysfs를 통해 노출됩니다. 항목(속성들)은 /proc/cpuinfo와
유사합니다.

1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:

        cpuX의 물리적인 패키지 ID. 일반적으로 물리적인 소켓 번호에
        해당하지만, 실제 값은 아키텍처와 플랫폼에 따라 다릅니다.

2) /sys/devices/system/cpu/cpuX/topology/core_id:

        cpuX의 CPU 코어 ID. 일반적으로 (커널의 것 보다는) 하드웨어
        플랫폼의 식별자입니다. 실제 값은 아키텍처와 플랫폼에 따라
        다릅니다.

3) /sys/devices/system/cpu/cpuX/topology/book_id:

        cpuX의 Book ID. 일반적으로 (커널의 것 보다는) 하드웨어 플랫폼의
        식별자입니다. 실제 값은 아키텍처와 플랫폼에 따라 다릅니다.

4) /sys/devices/system/cpu/cpuX/topology/thread_siblings:

        cpuX와 같은 코어 내부의 cpuX의 하드웨어 스레드들의 내부 커널 맵

5) /sys/devices/system/cpu/cpuX/topology/core_siblings:

        같은 물리적 패키지 ID(physical_package_id) 내부의 cpuX의
        하드웨어 스레드들의 내부 커널 맵

6) /sys/devices/system/cpu/cpuX/topology/book_siblings:

        같인 Book ID(book_id) 내부의 cpuX의 하드웨어 스레드들의 내부
        커널 맵

아키텍처에 자연스러운 방법으로 구현하기 위해서, 새로운 소스 파일,
drivers/base/topology.c는 4 에서 6 개의 속성들을 드러냅니다. sysfs
파일들에 관련된 두 book 은 CONFIG_SCHED_BOOK 이 선택되었을 경우에만
생성될 것입니다.

이 기능을 지원하는 아키텍처를 위해서, include/asm-XXX/topology.h 안에
이들 매크로들 중 몇가지가 정의되어야만 합니다:
#define topology_physical_package_id(cpu)
#define topology_core_id(cpu)
#define topology_book_id(cpu)
#define topology_thread_cpumask(cpu)
#define topology_core_cpumask(cpu)
#define topology_book_cpumask(cpu)

**_id의 타입은 int 입니다.
sibling의 타입은 (const) struct cpumask * 입니다.

모든 아키텍처에 일관되도록, include/linux/topology.h 는
include/asm-XXX/topoloty.h 에서 정의하지 않는 위들 매크로 중 무엇을 위한
기본 정의를 제공합니다:
1) physical_package_id: -1
2) core_id: 0
3) thread_siblings: 그냥 주어진 CPU
4) core_siblings: 그냥 주어진 CPU

Book(CONFIG_SCHED_BOOK)을 지원하지 않는 아키텍처에는 topology_book_id() 와
topology_book_cpumask() 의 기본 정의가 없습니다.
추가적으로, CPU 토폴로지 정보는 /sys/devices/system/cpu 아래에서 제공되고,
이들 파일을 포함합니다. 출력의 내부 소스는 브라켓들(“[]”) 안에 있습니다.

    kernel_max: 커널 설정[NR_CPUS-1]에서 허용되는 최고 CPU 인덱스

    offline:    핫플러그 오프(HOTPLUGGED off:cpu-hotplug.txt 참고)되었거나,
                커널 설정(위의 kernel_max)에서 허용되는 CPU들의 제한을
                초과핬기 때문에 온라인이 아닌 CPU들.
                [~cpu_online_mask + cpus >= NR_CPUS]

    online:     온라인이고 스케줄 중인 CPU들 [cpu_online_mask]

    possible:   자원을 할당받았고, 지금 존재하면 온라인이 될 수 있는
                CPU들. [cpu_possible_mask]

    present:    시스템에 현재 존재하고 있는 것으로 식별된 CPU들.
                [cpu_present_mask]

위 출력의 형식은 cpulist_parse()[<linux/cpumask.h>]와 호환됩니다.
아래 예제가 있습니다.

이 예제에서, 64개의 CPU들이 시스템 내부에 있지만, CPU 32-63은 32로
된 NR_CPUS 설정 옵션에 의해 0..31 로 제한된 커널 최고값을 초과했습니다.
CPU 2와 4-31들은 온라인이 아니지만, 존재(present)하고, 가능(possbile)하므로
온라인이 될 수 있습니다.

     kernel_max: 31
        offline: 2,4-31,32-63
         online: 0-1,3
       possible: 0-31
        present: 0-31

이 예제에서, NR_CPUS 설정 옵션은 128이지만, 커널은 possible_cpus=144로
시작되었습니다. 시스템 내에 4개의 CPU가 있고, cpu2는 수동으로 오프라인이
되었습니다(그리고, 그 하나의 CPU만 온라인이 될 수 있습니다).

     kernel_max: 127
        offline: 2,4-127,128-143
         online: 0-1,3
       possible: 0-127
        present: 0-3

possible_cpus=숫자 시작 파라미터는 다양한 cpumask 의 더 많은 정보로
좋은 cpu-hotplug.txt 를 보세요.

[Linux:Kernel] 오픈 펌웨어(Open Firmware) 없이 리눅스/ppc 커널 부팅하기

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL License).

Documentation/devicetree/booting-without-of.txt

        오픈 펌웨어(Open Firmware) 없이 리눅스/ppc 커널 부팅하기
        ——————————————————–

(c) 2005 Benjamin Herrenschmidt <benh at kernel.crashing.org>,
    IBM Corp.
(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
    Freescale Semiconductor, FSL SOC and 32-bit additions
(c) 2006 MontaVista Software, Inc.
    Flash chip node definition

번역: 양정석<dasomoli@REMOVETHISgmail.com>

차례
====

  I – 도입
    1) arch/arm의 진입 포인트(Entry point)
    2) arch/powerpc의 진입 포인트
    3) arch/x86의 진입 포인트

  II – DT 블록 형식
    1) 헤더
    2) 디바이스 트리 일반론
    3) 디바이스 트리 “구조” 블록
    4) 디바이스 트리 “문자열들” 블록

  III – 디바이스 트리에서 필요한 내용
    1) 셀(cells)과 주소 표현에 관한 기록
    2) “compatible” 프로퍼티에 대한 기록
    3) “name” 프로퍼티에 대한 기록
    4) 노드와 프로퍼티 이름과 문자셋에 대한 기록
    5) 필요 노드와 프로퍼티들
      a) 루트 노드
      b) /cpus 노드
      c) /cpus/* 노드들
      d) /memory 노드(들)
      e) /chosen 노드
      f) /soc<SOC이름> 노드

  IV – “dtc”, 디바이스 트리 컴파일러(device tree compiler)

  V – 부트로더에 대한 권장 사항

  VI – 시스템-온-칩 디바이스와 노드들
    1) SOC의 자식 노드들 정의하기
    2) 현재의 OF 명세없이 디바이스들 나타내기

  VII – 디바이스들의 인터럽트 정보 지정하기
    1) interrupt 프로퍼티
    2) interrupt-parent 프로퍼티
    3) OpenPIC 인터럽트 컨트롤러
    4) ISA 인터럽트 컨트롤러

  VIII – 디바이스 전원 관리 정보 지정하기 (sleep 프로퍼티)

  부록 A – MPC8540의 예제 SOC 노드


개정 정보
=========

   May 18, 2005: Rev 0.1 – Initial draft, no chapter III yet.

   May 19, 2005: Rev 0.2 – Add chapter III and bits & pieces here or
                           clarifies the fact that a lot of things are
                           optional, the kernel only requires a very
                           small device tree, though it is encouraged
                           to provide an as complete one as possible.

   May 24, 2005: Rev 0.3 – Precise that DT block has to be in RAM
                         – Misc fixes
                         – Define version 3 and new format version 16
                           for the DT block (version 16 needs kernel
                           patches, will be fwd separately).
                           String block now has a size, and full path
                           is replaced by unit name for more
                           compactness.
                           linux,phandle is made optional, only nodes
                           that are referenced by other nodes need it.
                           “name” property is now automatically
                           deduced from the unit name

   June 1, 2005: Rev 0.4 – Correct confusion between OF_DT_END and
                           OF_DT_END_NODE in structure definition.
                         – Change version 16 format to always align
                           property data to 4 bytes. Since tokens are
                           already aligned, that means no specific
                           required alignment between property size
                           and property data. The old style variable
                           alignment would make it impossible to do
                           “simple” insertion of properties using
                           memmove (thanks Milton for
                           noticing). Updated kernel patch as well
                         – Correct a few more alignment constraints
                         – Add a chapter about the device-tree
                           compiler and the textural representation of
                           the tree that can be “compiled” by dtc.

   November 21, 2005: Rev 0.5
                         – Additions/generalizations for 32-bit
                         – Changed to reflect the new arch/powerpc
                           structure
                         – Added chapter VI


 ToDo:
        – Add some definitions of interrupt tree (simple/complex)
        – Add some definitions for PCI host bridges
        – Add some common address format examples
        – Add definitions for standard properties and “compatible”
          names for cells that are not already defined by the existing
          OF spec.
        – Compare FSL SOC use of PCI to standard and make sure no new
          node definition required.
        – Add more information about node definitions for SOC devices
          that currently have no standard, like the FSL CPM.


I – 도입
========

리눅스/ppc64 커널, 그리고 더 특정지어서, 오래된 IBM p시리즈/i시리즈
쌍 밖의 새로운 플랫폼 타입의 추가 개발 동안, 커널 진입과 부트 로더
<-> 커널 인터페이스에 관련된 엄격한 몇가지 규칙이 시행되도록 결정되었고,
ppc32 커널 진입 포인트와 그 방법이 되었던 것 같은 퇴보를 피하기 위해서,
새 플랫폼이 커널에 추가되어야 했습니다. 기존의 i시리즈 플랫폼은 이
계획(scheme)에 앞서 있어서 이들 규칙을 깹니다만, 그들을 적절히 따르지
않는 새로운 보드 지원은 하나도 메인 트리에 받아들여지지 않을 것입니다.
게다가 ppc32와 ppc64의 arch/powerpc로의 플랫폼 통합의 완료 이후에는,
새로운 32비트 플랫폼과 arch/powerpc 내로 옮기는 32비트 플랫폼은 이 룰을
잘 따르도록 요구될 것입니다.

아래에서 더 자세히 정의될 주된 요구사항은 오픈 펌웨어 명세(Open Firmware
specification) 이후에 정의된 형식의 디바이스 트리가 있느냐 하는 것입니다.
그러나 임베디드 보드 업체들의 삶이 더 쉽게 만들기 위해서, 커널은
시스템 내의 모든 디바이스를 표현한 디바이스 트리를 요구하지는 않고,
실제로 있는 노드와 항목들만 요구합니다. 이는 섹션 III에서 더 자세히
설명될 겁니다만, 예를 들면, 커널은 여러분에게 시스템 내의 모든 PCI
디바이스를 위한 노드를 만들 것을 요구하지 않습니다. 인터럽트 경로 정보와
다른 것 가운데에서 메모리/IO 범위를 제공하기 위해 PCI 호스트 브리지를
위한 노드 하나를 가지는 것이 요구 사항입니다. 또한 온칩 디바이스와
특별히 맞춰지지 않는 다른 버스들에 대한 노드들을 존재하는 OF 명세 안에
정의하는 것을 권장합니다. 이것은 커널이 모든 종류의 하드 코딩된 테이블
없이, 그들을 감지(probe)해서 드라이버를 디바이스와 맞출 수 있는 방법으로
대단한 유연성을 제공합니다. 또한 보드 업체들에게 커널 코드에 큰 영향없이,
또는 특정 경우로 집어넣는 일 없이 마이너 하드웨어 업그레이드를 하도록
더 유연하게 만듭니다.

1) arch/arm의 진입 포인트(Entry point)
————————————–

   커널 이미지의 시작점에 커널로의 하나의 진입 포인트가 있습니다. 그
   진입 포인트는 두가지 호출 규약을 지원합니다. 그 인터페이스의 요약이
   여기 기술되어 있습니다. 부팅 요구사항의 전체 설명은
   Documentation/arm/Booting 안에 문서화되어 있습니다.

        a) ATAGS 인터페이스. 펌웨어로부터의 최소한의 정보가 커널로
        미리 정의된(predefined) 파라메터의 태그를 붙인 리스트(tagged list)
        로 넘겨집니다.

                r0 : 0

                r1 : 머신 타입 넘버(Machine type number)

                r2 : 시스템 RAM 안의 태그를 붙인 리스트의 물리 주소

        b) 평면(flattened) 디바이스 트리 블록으로 진입. 펌웨어는 r2 안에서
        평면 디바이스 트리 블록(dtb)의 물리 주소를 로딩하고, r1 은 사용되지
        않습니다만, Documentation/arm/Booting 내에 설명된 것처럼 유효한 머신
        넘버를 사용하는 좋은 관례도 고려됩니다.

                r0 : 0

                r1 : 유효한 머신 타입 넘버. 디바이스 트리를 사용할 때,
                하나의 머신 타입 넘버가 SoC의 계열 또는 클래스를 나타내는데
                할당되곤 할 것입니다.

                r2 : (챕터 II에 정의된) RAM 안의 디바이스 트리 블록으로의
                물리적 포인터(physical pointer). 디바이스트리는 시스템 RAM 안
                어느 곳에나 위치할 수 있습니다만, 64비트 경계(boundary) 안에
                정렬되어야 합니다.

   커널은 ATGAS와 디바이스트리 부팅을 r2에 의해 가리켜지는 메모리를 읽고,
   평면 디바이스 트리 블록의 매직 값(0xd00dfeed) 또는 r2 에서 0x4 오프셋
   위치의 ATAG_CORE 값(0x54410001)을 살펴봄으로써 구별할 것입니다.

2) arch/powerpc의 진입 포인트
—————————–

   커널 이미지의 시작에 커널로의 하나의 진입 포인트가 있습니다. 그 진입
   포인트는 두가지 호출 규약을 지원합니다:

        a) 오픈 펌웨어로 부팅. 여러분의 펌웨어가 오픈 펌웨어(IEEE 1275)와
        호환되거나, OF 호환 클라이언트 인터페이스 API(나온 말들이 필요없는
        “interpret” 콜백이 지원되는)를 제공하면, 다음으로 커널로 진압할 수
        있습니다:

              r5 : IEEE 1275 powerpc로의 바인딩에 의해 정의되는 OF 콜백
              포인터. 32비트 클라이언트 인터페이스만 현재 지원됨.

              r3, r4 : 있거나, 또는 0이면, initrd의 주소와 길이

              MMU는 켜져 있거나 꺼져 있을 수 있습니다; 커널은
              arch/powerpc/kernel/prom_init.c 안에 위치한 분기 코드를
              오픈 펌웨어로부터 디바이스-트리와 다른 정보를 추출하고,
              평명화 디바이스-트리를 b에 서술한대로 만들기 위해 실행할
              것입니다). prom_init()은 그 후, 두번째 방법으로 커널을
              재진입할 것입니다. 이 분기 코드는 그 시점에 모든 예외를
              처리하는 펌웨어 컨텍스트에서 실행됩니다.

        b) 평면화 디바이스-트리 블록으로 직접 진입. 이 진입 포인트는 a)에
        의해 OF 분기 코드 후에 호출되고, 오픈 펌웨어 클라이언트 인터페이스를
        지원하지 않는 부트로더에 의해 직접 호출될 수 있습니다. 또한,
        “kexec”에 의해 이전에 실행되던 것에서부터 새로운 커널의 “핫” 부팅을
        구현하는데 사용될 수 있습니다. 이 방법은 방법 a) 가 간단히
        표준 오픈 펌웨어로서, 그래서 그를 정의하고 PowerPC 플랫폼으로의
        그 바인딩을 정의하는 다양한 표준 문서들에 따라 구현되어야 하는,
        제가 이 문서 내에서 더 자세히 설명할 방법입니다. 그래서, 그 진입
        포인트 정의는 다음처럼 됩니다:

                r3 : 램(RAM) 내의 (챕터 II에 정의된)디바이스-트리로의
                물리적 포인터

                r4 : 커널 그 자체로의 물리적 포인터. 이것은 어셈블리 코드에
                의해 여러분이 MMU를 켜거 1:1 맵핑이 아닌 상태로 커널로
                진입하는 경우에 적절히 MMU 를 끄기 위해 사용됩니다.

                r5 : NULL (방법 a와 구별하기 위함)

        SMP 진입에 관한 알림: 여러분의 펌웨어는 여러분의 다른 CPU 들을
        여러분이 신경쓸 필요가 없는 경우에 소프트 리셋이나 어떤 다른
        수단을 통해 수행할 수 있는 롬(ROM) 내의 어떤 슬립 루프나 스핀 루프에
        두거나, 모든 CPU로 커널 진입을 해야만 할 것입니다. 방법 b)로
        하는 방법은 이 문서의 이후 개정판에서 설명될 것입니다.

   보드 지원들(플랫폼들)은 설정 옵션들이 전용이 아닙니다. 임의의
   보드 지원들은 하나의 커널 이미지로 빌드될 수 있습니다. 커널은
   디바이스-트리의 내용에 기초하여 주어진 플랫폼에서 사용될 함수 집합을
   “알” 것입니다. 그래서 여러분은 다음처럼 해야만 합니다:

        a) arch/powerpc/Kconfig 내에 _불린(boolean)_ 옵션으로,
        PPC_PSERIES, PPC_PMAC 과 PPC_MAPLE의 예제를 따라, 여러분의
        플랫폼 지원을 추가하세요. 나중 것이 아마 시작하기 좋은 보드 지원
        예제가 될 것입니다.

        b) 여러분의 주 플룟폼 파일을
        “arch/powerpc/platforms/myplatform/myboard_setup.c” 로 생성하고
        여러분의 CONFIG_ 옵션의 조건 아래서 Makefile 에 추가하세요.
        이 파일은 일반적인 코드가 여러분의 플랫폼에 따른 코드를 얻어 사용할
        다양한 콜백을 포함하는 “ppc_md” 타입의 구조체를 정의할 것입니다.

  플랫폼 기능이 같은 코어 아키텍처를 사용할 때이긴 하지만, 하나의 커널
  이미지가 여러 플랫폼을 지원할 것입니다. 하나의 커널 빌드는 책 E 와
  고전적인 Powerpc 아키텍처의 설정 둘 다를 지원할 수는 없습니다.

3) arch/x86의 진입 포인트
————————-

  code32_start에 커널로의 하나의 32비트 진입 포인트, 압축 해제기
  (리얼 모드 진입 포인트는 보호 모드 안으로 전환되면 같은 32비트 진입
  포인트로 갑니다)가 있습니다. 그 진입 포인트는 Documentation/x86/boot.txt
  안에 문서화된 하나의 호출 규약을 지원합니다.
  (챕터 II 안에 정의된) 디바이스 트리 블록으로의 물리적 포인터는 적어도
  부트 프로토콜 2.09를 요구하는 setup_data 를 통해 넘겨집니다. 그 타입
  (type) 필드는 다음처럼 정의됩니다.

  #define SETUP_DTB                      2

  이 디바이스 트리는 “부트 페이지(boot page)”로의 확장처럼 사용됩니다.
  그처럼 부트 페이지에 의해 이미 대신되는 데이터를 파싱 / 고려하지 않습니다.
  이것은 메모리 크기, 예약된 범위(reserved ranges), 커맨드 라인 인자,
  또는 initrd 주소를 포함합니다. 검색할 수 없는 정보, 아니면 인터럽트 경로나
  I2C 버스 뒤의 디바이스 리스트 같은 정보를 간단히 보유합니다.

II – DT 블록 형식
=================


이 챕터는 커널로 넘기는 평면 디바이스 트리의 실제 형식을 정의합니다.
그 실제 내용과 커널 요구사항은 이후에 설명됩니다. 여러분은 오픈 펌웨어
상세(representation)로부터 생성될 평면 디바이스 트리인
arch/powerpc/kernel/prom_init.c 또는 파일 시스템 상세로부터 생성될
kexec 툴의 일부인 fs2dt 유틸리티를 포함하여 다양한 곳의 형식을 조작하는
코드 예제를 찾을 수 있습니다. uboot 같은 부트로더는 이후에 좀 더 이야기할
조금 더 많은 지원이 기대됩니다.


주의: 그 블록은 주 메모리 안에 있어야 합니다. 주 메모리 외에 다른 매핑없이
리얼 모드와 가상 모드 모두 에서 접근 가능해야 합니다. 간단한 플래시
부트로더를 작성하는 중이라면, 그 블록을 커널로 넘기기 전에 RAM으로 복사해야
합니다.


1) 헤더
——-

   커널은 include/linux/of_fdt.h 안에 boot_param_header 구조체로 대강 설명된
   한 메모리 영역을 가리키는 물리 주소를 넘겨 받습니다:

struct boot_param_header {
        u32     magic;                  /* 매직 워드 OF_DT_HEADER */
        u32     totalsize;              /* DT block의 전체 크기 */
        u32     off_dt_struct;          /* 구조의 오프셋 */
        u32     off_dt_strings;         /* 문자열들의 오프셋 */
        u32     off_mem_rsvmap;         /* 메모리 예약맵의 오프셋 */
        u32     version;                /* 형식 버전 */
        u32     last_comp_version;      /* 마지막 호환되는 버전 */

        /* 아래는 버전 2 필드 */
        u32     boot_cpuid_phys;        /* 우리가 부팅하는 물리 CPU id */
        /* 아래는 버전 3 필드 */
        u32     size_dt_strings;        /* 문자열들 블록의 크기 */

        /* 아래는 버전 17 필드 */
        u32     size_dt_struct;         /* DT 구조 블록의 크기 */
};

   상수를 덧붙입니다:

/* 평면 디바이스 트리에 의해 사용되는 정의들 */
#define OF_DT_HEADER            0xd00dfeed      /* 4: 버전,
                                                   4: 전체 크기 */
#define OF_DT_BEGIN_NODE        0x1             /* 시작 노드: 전체 이름
                                                   */
#define OF_DT_END_NODE          0x2             /* 끝 노드 */
#define OF_DT_PROP              0x3             /* 프로퍼티: name off,
                                                   크기, 내용 */
#define OF_DT_END               0x9

   이 헤더 안의 모든 값은 빅 엔디안(big endian) 형식이고, 다양한 필드들이
   아래에 더 정밀하게 정듸됩니다. 모든 “오프셋(offset)” 값들은 헤더의
   시작으로부터의 바이트 단위 값입니다: 디바이스 트리 블록의 물리적
   베이스 주소입니다.

   – magic

     디바이스 트리 블록 헤더의 시작을 “표시하는” 매직 값입니다.
     0xd00feed 값을 포함하고, OF_DT_HEADER 상수로 정의됩니다.

   – totalsize

     이것은 헤더를 포함한 DT 블록의 전체 크기입니다. 그 “DT” 블록은
     (이 헤더 안의 오프셋들에 의해서 가리켜지는)이 챕터에서 정의하는
     모든 데이터 구조체를 갖고 있어야 합니다. 디바이스 트리 구조, 문자열들,
     메모리 예약 맵을 말합니다.

   – off_dt_struct

     이것은 헤더의 시작으로부터 디바이스 트리 “구조” 부분의 시작까지의
     오프셋입니다. (2) 디바이스 트리 를 보세요)

   – off_dt_strings

     이것은 헤더의 시작으로부터 디바이스 트리 “문자열들” 부분의
     시작까지의 오프셋입니다.

   – off_mem_rsvmap

     이것은 헤더의 시작으로부터 예약 메모리 맵의 시작까지의 오프셋입니다.
     이 맵은 64비트 정수 쌍의 리스트입니다. 각 쌍은 물리 주소와
     크기입니다. 그 리스트는 크기 0의 항목으로 끝납니다. 이 맵은
     커널에게 “예약된” 물리 메모리 영역의 리스트를 제공하고, 그래서
     특히 초반 초기화 시에, 메모리 할당에 사용되지 않습니다. 커널은
     부팅하는 동안 디바이스 트리의 평면 해제화, MMU 해시 테이블, 기타…
     등을 위한 메모리를 할당할 필요가 있습니다. 이 할당은 오픈 펌웨어
     머신 상에서의 RTAS 인스턴스나, 특정 p시리즈 상에서 iommu 에서
     사용되는 TCE 테이블 같은 치명적인 것들을 덮어씌우는 것을 피하도록
     앞의 방법으로 수행되어야만 합니다. 일반적으로, 예약 맵은 _적어도_
     이 DT 블록 자체(header, total_size)는 포함해야 합니다. 여러분이
     커널로 initrd를 넘기고 있다면, 잘 예약해야 합니다. 커널 이미지
     자체를 예약할 필요는 없습니다. 그 맵은 64 비트로 정렬되어 있어야
     합니다.
     

   – version

     이것은 이 구조체의 버전입니다. 버전 1은 여기서 멉춥니다. 버전 2는
     추가적인 필드 boot_cpuid_phys를 추가합니다. 버전 3은 커널이 부팅
     시에 그를 쉽게 재할당하고 사용되지 않는 평면 구조를 확장 후에
     해제할 수 있도록, 문자열들 블록의 크기를 추가합니다. 버전 16은
     트리 자체의 새로운 좀 더 “작은”, 그러나 이전과 호환되지는 않는
     형식을 도입합니다. 버전 17은 재할당하거나, 더 쉽게 옮길 수 있도록
     할 수 있는 추가적인 필드, size_dt_struct 를 추가합니다(이는 감지된
     정보를 기초로 디바이스 트리로 조정하는 부트 로더에 특히 유용합니다).
     여러분은 언제나 여러분의 구현 시점에 정의된 가장 높은 버전의
     구조체를 만드는 것이 좋습니다. 여러분이 명시적으로 하위 호환성에
     초점을 맞추고 있지 않다면, 현재는 버전 17입니다.
     

   – last_comp_version

     마지막 호환 버전. 이것은 여러분이 하위 호환을 제공하는 DT 블록이
     무슨 버전인지를 나타냅니다. 예를 들면, 버전 2는 버전 1과 하위
     호환(즉, 버전 1의 커널 빌드는 버전 2 형식으로 부팅됨)됩니다.
     여러분이 버전 1에서 3의 디바이스 트리를 생성한다면, 이 필드에 1을,
     버전 16이나 새로운 유닛 이름 형식을 사용하는 17의 디바이스 트리를
     생성한다면 16을 넣는 것이 좋습니다.

   – boot_cpuid_phys

     이 필드는 버전 2 헤더에만 존재합니다. 그것은 어떤 CPU ID 가 커널
     진입점을 호출하는지를 나타냅니다. 이것은 다른 것들 중에서도 kexec에
     의해서 사용됩니다. 만약 여러분이 SMP 시스템 상에 있다면, 이 값은
     커널 진입점을 호출하는 CPU에 해당하는 디바이스 트리 안의 CPU 노드의
     “reg” 프로퍼티의 내용과 맞아야 합니다(요구되는 디바이스 트리 내용에
     대한 더 많은 정보는 다른 챕터를 보세요).

   – size_dt_strings

     이 필드는 버전 3과 그 이후 헤더에만 존재합니다. 그것은
     (off_dt_strings로 주어지는 오프셋에서 시작하는) 디바이스 트리의
     “문자열들” 섹션의 크기를 줍니다. 

   – size_dt_struct

     이 필드는 버전 17과 그 이후 헤더에만 존재합니다. 그것은
     (off_dt_struct로 주어지는 오프셋에서 시작하는) 디바이스 트리의
     “구조” 섹션의 크기를 줍니다.

   그래서 DT 블록의 전형적인 배치는 (여러 부분들이 저 순서일 필요는
   없지만) 다음과 같습니다(주소는 위에서 아래로 진행):


             ——————————
     base -> |  struct boot_param_header  |
             ——————————
             |   (정렬을 위한 공간) (*)   |
             ——————————
             |       메모리 예약 맵       |
             ——————————
             |     (정렬을 위한 공간)     |
             ——————————
             |                            |
             |     디바이스 트리 구조     |
             |                            |
             ——————————
             |     (정렬을 위한 공간)     |
             ——————————
             |                            |
             |   디바이스 트리 문자열들   |
             |                            |
      —–> ——————————
      |
      |
      — (base + totalsize)

  (*) 정렬을 위한 공간이 반드시 있지는 않습니다; 그 존재와 크기는 개개의
      데이터 블록의 다양한 정렬 요구 사항에 달려 있습니다.


2) 디바이스 트리 일반론
———————–

디바이스 트리 그 자체는 두가지 다른 블록, 구조 블록과 문자열들 블록으로
나뉘어 집니다. 둘 모두 4바이트 경계로 정렬될 필요가 있습니다.

먼저, 저장 형식을 상세히 하기 전에 디바이스 트리 개면에 대해 빠르게
설명해 봅시다. 이 챕터는 커널을 위한 노드와 프로퍼티들의 요구 타입의
자세한 사항을 설명하지는 _않습니다_. 이것은 챕터 III에서 나중에 합니다.

디바이스 트리 배치는 오픈 펌웨어 IEEE 1275 디바이스-트리 의 정의를
강력하게 상속받습니다. 그것은 기본적으로 각 노드가 두가지 혹은 그 이상의
이름있는 프로퍼티를 가지는 노드들의 하나의 트리입니다. 프로퍼티는
값을 가질 수도, 가지지 않을 수도 있습니다.

그것은 하나의 트리입니다. 그래서 부모가 없는 루트 노드를 제외한 각 노드는
오직 하나의 부모를 갖습니다.

하나의 노드는 2개의 이름을 갖습니다. 실제 노드 이름은 일반적으로 노드
프로퍼티 리스트 안의 값이 0으로 끝나는 문자열인 “이름(name)” 타입의
프로퍼티 안에 포함되고, 이는 (오픈 펌웨어 안에 있는 것처럼) 형식 정의의
버전 1에서 3까지에서는 필수 사항입니다. 버전 16은 아래 정의된 유닛
이름으로부터 이를 생성할 수 있기 때문에, 그것을 선택 사항으로
만들었습니다.

같은 레벨의 같은 이름과 노드를 구분하는데 사용되는 “유닛 이름(unit
name)”도 있는데, 그것은 보통 정의가 그 노드가 부착된 버스 타입으로
특정되는 노드 이름, “@” 기호과 “유닛 주소”로 만듭니다.

유닛 이름은 그 자체로 프로퍼티로 존재하지는 않지만, 디바이스 트리
구조 안에 포함됩니다. 그것은 일반적으로 디바이스 트리 안의 “경로
(path)”를 나타내는데 사용됩니다. 실제 이들 형식에 대한 더 자세한 사항은
아래에서 나타날 것입니다.

커널의 일반적인 코드는 유닛 주소의 어떠한 정규적인 용도를 (어떤 보드
지원 코드가 한다고 하더라도) 만들지 않기 때문에, 여기서의 유닛 주소를
위한 진짜 요구 사항은 그 트리의 주어진 레벨에서의 그 노드 유닛 이름의
유일성을 확인하는 것입니다. 주소 표현 없는 노드들과 (/memory 또는
/cpus 같은) 동일한 이름의 가능하지 않은 형제는 이 명세의 문맥 안에서
유닛 주소를 생략할 것이고, 또는 기본 유닛 주소 “@0″을 사용할 것입니다.
그 유닛 이름은 “/”로 분리된 모든 부모 노드 유닛 이름들을 이어 붙인 
노드 “전체 경로(full path)”를 정의하는데 사용됩니다.


루트 노드는 정의된 이름을 갖지 않고, 여러분이 버전 3 혹은 그 이전의
형식을 사용하고 있다면 name 프로퍼티를 갖도록 요구되지 않습니다. 또한,
유닛 주소도 갖지 않습니다(유닛 주소로 @ 기호가 뒤따르지 않음). 루트
노드 유닛 이름은 그래서 빈 문자열입니다. 루트 노드로의 전체 경로는
“/” 입니다.

실제 디바이스를 실제로 나타내는 (즉, “/cpus” 같은 다른 노드를 위한
가상 “컨테이너”일 뿐인 노드가 아닌) 각 노드는 또한 특정 하드웨어와
그것과 완전한 하위 호환되는 디바이스의 옵션 리스트를 나타내는
“compatible” 프로퍼티를 갖습니다.

마지막으로, 다른 노드 안의 프로퍼티로부터 참조될 수 있는 각 노드는
“phandle” 이나 “linux,phandle” 프로퍼티를 가져야 합니다. 진짜 오픈
펌웨어 구현은 “prom_init()” 점프 코드가 “linux,phandle” 프로퍼티로
바꾸는 각 노드의 유일한 “phandle” 값을 제공합니다. 그러나, 이것은
평면 디바이스 트리가 직접 사용된다면, 선택 사항이 됩니다. 다른 노드를
“phandle”을 통해 참조하는 노드의 예는 이 문서의 이후 버전 안에서
서술될 인터럽트 트리를 배치할 때 같은 것입니다.

“phandle” 프로퍼티는 노드를 유일하게 식별하는 32 비트 값입니다.
시스템 값, 내부 포인터같은 어떠한 값을 사용하거나, 이들을 어떻게
생성하든 맘대로입니다. 유일한 요구 사항은 각 노드가 그를 위한 유일한
값을 가지는 프로퍼티를 제공하는 것 뿐입니다.

여기 간단한 디바이스 트리 예제가 있습니다. 이 예제에서, “o” 는 노드
유닛 이름이 따름을 가리킵니다. 프로퍼티들은 그 내용이 따르는 그들의
이름으로 나타납니다. “내용”은 (0으로 끝나는) ASCII 문자열 값을
나타내는 반면, <내용>은 10진수나 (0x 접두사 뒤의) 16진수로 지정되는
32비트 값을 나타냅니다. 이 시점에서, 저는 여러분에게 실제로 트리가
무엇처럼 보이는지 더 좋은 생각을 제공하기 위해서 의도적으로 “name”과
“linux,phandle” 프로퍼티를 남겨두었습니다.

  / o device-tree
      |- name = “device-tree”
      |- model = “MyBoardName”
      |- compatible = “MyBoardFamilyName”
      |- #address-cells = <2>
      |- #size-cells = <2>
      |- linux,phandle = <0>
      |
      o cpus
      | | – name = “cpus”
      | | – linux,phandle = <1>
      | | – #address-cells = <1>
      | | – #size-cells = <0>
      | |
      | o PowerPC,970@0
      |   |- name = “PowerPC,970”
      |   |- device_type = “cpu”
      |   |- reg = <0>
      |   |- clock-frequency = <0x5f5e1000>
      |   |- 64-bit
      |   |- linux,phandle = <2>
      |
      o memory@0
      | |- name = “memory”
      | |- device_type = “memory”
      | |- reg = <0x00000000 0x00000000 0x00000000 0x20000000>
      | |- linux,phandle = <3>
      |
      o chosen
        |- name = “chosen”
        |- bootargs = “root=/dev/sda2”
        |- linux,phandle = <4>

이 트리는 거의 최소한의 트리입니다. 그것은 리눅스 커널을 부팅하기 위해
필요한 노드와 프로퍼티의 최소한만큼만 멋지게 포함합니다;
즉, 루트의 기본 모델 정보, CPU들, 그리고 물리 메모리 배치입니다.
또한 그것은 /chosen을 통해 넘어오는 부가적인 정보, 예를 들면, 플랫폼
타입(필수 사항)와 커널 커맨드 라인 인자(선택 사항)을 포함합니다.


/cpus/PowerPC,970@0/64-bit 프로퍼티는 값이 없는 프로퍼티의 한 예입니다.
모든 다른 프로퍼티는 하나의 값을 가집니다. #address-cless와 $size-cells
프로퍼티가 지정하는 것은 필요로 하는 노드와 프로퍼티, 그들의 내용을
정밀하게 정의하는 챕터 IV에서 설명될 것입니다.


3) 디바이스 트리 “구조” 블록

디바이스 트리의 구조는 선형 트리 구조입니다. “OF_DT_BEGIN_NODE” 토큰은
새 노드를 시작하고, “OF_DT_END_NODE”는 노드 정의를 끝냅니다. 자식
노드들은 (그 노드 안의 노드들) “OF_DT_END_NODE” 전에 간단히 정의됩니다.
‘토큰(token)’은 32비트 값입니다. 트리는 OF_DT_END 토큰으로 끝납니다.

여기 한 노드의 기본 구조입니다:

     * (0x00000001인) OF_DT_BEGIN_NODE 토큰
     * 버전 1에서 3은 이것이 0으로 끝나고, “/”로 시작하는 노드 전체
       경로입니다. 버전 16과 그 이후에 이것은 노드 유닛 이름(또는,
       루트 노드의 빈 문자열)일 뿐입니다.
     * [다음 4바이트 경계로 공간을 정렬]
     * 각 프로퍼티는:
        * (0x00000003인) OF_DT_PROP 토큰
        * 바이트로 된 프로퍼티 값 크기인 32비트 값(또는 값이 없으면 0)
        * 프로퍼티 이름의 문자열 블록 안의 오프셋인 32비트 값
        * 있다면, 프로퍼티 값 데이터
        * [다음 4바이트 경계로 공간을 정렬]
     * [있다면, 자식 노드들]
     * (0x00000002인) OF_DT_END_NODE 토큰

그래서 노드 내용은 시작 토큰, 전체 경로, 프로퍼티의 리스트, 자식 노드의
리스트, 그리고 끝 토큰으로 요약될 수 있습니다. 모든 각 자식 노드는 위에
정의된 것 같은 그 자체가 전체 노드 구조입니다.

알림: 위의 정의는 특정 노드를 위한 모든 프로퍼티 정의들이 그 노드를 위한
어떤 보조 노드 정의보다 우선해야 함을 필요로 합니다. 프로퍼티들과 보조
노드 들이 막 섞여 있다면, 그 구조가 애매하지 않아야 하지만, 커널 파서
(parser)는 그 프로퍼티들이 먼저 올 것을 (적어도 2.6.22까지는) 요구합니다.
어떤 (평면 드리를 조작하는) 툴도 이 제약을 지켜야 합니다.

4) 디바이스 트리 “문자열들” 블록

공간을 아끼기 위해서, 일반적으로 중복되는 프로퍼티 이름들을 “문자열들”
블록 안에 별도로 저장합니다. 이 블록은 간단히 모든 프로퍼티 이름을 위한
0으로 끝나는 문자열 전부를 연이어 붙여놓은 것입니다. 구조 플록 안의
디바이스 트리 프로퍼티 정의들은 문자열들 블록의 시작으로부터의 오프셋
값을 포함할 것입니다.


III – 디바이스 트리에서 필요한 내용
===================================

경고: 이 문서 내에 정의된 모든 “linux,*” 프로퍼티들은 평면 디바이스
트리에만 적용됩니다. 만약 여러분의 플랫폼이 오픈 펌웨어의 진짜 구현이나,
오픈 펌웨어 클라이언트 인터페이스와 호환되는 구현을 사용한다면, 그들
프로퍼티들은 커널의 prom_init() 파일 내의 점프 코드에 의해서 생성될
것입니다. 예를 들면, 여러분이 여러분의 보드 모델을 감지하기 위한 코드를
넣고, 플랫폼 넘버를 셋팅해야만 하는 곳 말입니다. 그러나, 평면 디바이스
트리 진입점을 사용할 때는 prom_init() 을 지나지 않고, 그래서 여러분은
그들 프로퍼티를 스스로 제공해야만 합니다.


1) 셀(cells)과 주소 표현에 관한 기록
————————————

일반적인 룰은 다양한 오픈 펌웨어 문서들 내에 문서화되어 있습니다.
여러분이 버스를 디바이스 트리 서술하는 것을 고르고, OF 버스 바인딩이
있다면, 그 명세를 따르는 것이 좋습니다. 그러나 커널은 디바이스 트리에
의해서 설명되는 각각의 모든 독립된 디바이스나 버스를 요구하지 않습니다.

일반적으로 디바이스를 위한 주소의 형식은 부모 버스 타입에 의해
#address-cells 와 #size-cells 프로퍼티에 기초하여 정의됩니다.
그 부모의 부모 #address-celss와 #size-cells 정의들은 상속되지 않으므로
자실을 가진 모든 각각의 노드는 그들을 지정해야 합니다. 커널은 루트 노드가
직접 프로세스 버스 상에 맵핑된 디바이스들을 위한 주소들의 형식을 정의하는
이들 프로퍼티를 가질 것을 요구합니다.

이들 2 프로퍼티는 주소와 크기를 표현하기 위한 ‘cells’를 정의합니다.
예를 들면, 만약 둘 다 위에서 주어졌던 예제 트리 같이 2를 갖는다면,
주소와 크기는 모두 2 셀로 구성되고, 각각은 64비트 수(셀들은 이어 붙고,
빅 엔디안 형식일 것으로 여겨집니다)입니다. 또다른 예제는 애플 펌웨어가
그들을 하나의 주소를 위한 두 셀과 크기를 위한 하나의 셀로 정의하는
방법입니다. 대부분의 32비트 구현들은 #address-cless와 #size-cless를
32비트 값으로 표현하는 1로 정의해야 합니다. 어떤 32비트 프로세서들은
32비트 이상의 물리 주소를 혀용합니다; 이들 프로세서들은 #address-celss를
2로 정의해야 합니다.

“reg” 프로퍼티들은 언제나 버스 #address-cless와 #size-cells에 의해 
정해지는 주소와 크기의 셀의 개수인 “address size” 타입의 튜플입니다.
버스는 여러가지 주소 공간과 조어진 주소 할당(prefetchable이나 기타 등등
같은)과 연관된 다른 플래그들을 지원합니다. 이들 플래그들은 일반적으로
물리 주소의 최상위 비트에 붙습니다. 예를 들면, PCI 물리 주소는 3 셀로
만들어지는데, 가장 아래 둘이 실제 주소 자체를 포함하는 반면, 최상위
셀이 주소 공간 표현, 플래그들, 그리고 pci 버스 & 디바이스 수를 가집니다.

동적 할당 지원을 위한 버스를 위해, “reg” 안의 주소를 제공하지 않기
(0을 갖음)는 하지만, 주소가 동적으로 할당되는 것을 표시하는 플래그를
제공하고, 완전히 할당된 주소들을 갖는 개별 “assigned-addresses”
프로퍼티를 제공하는 것이 관행입니다. 자세한 사항은 PCI OF 바인딩을
보세요.

보통, 주소 공간 비트가 없고, 동적 할당도 없는 간단한 버스가 여러분의
하드웨어를 반영한다면, 존재하는 커널 주소 파싱 함수들이 틀 밖에서
실행되므로 더 좋습니다. 만약 여러분이 주소 공간 비트 같은 것들을 포함하는
더 복잡한 주소 형식으로 버스 타입을 정의한다면, 버스 번역기를 여러분의
버스 타입을 위한 최신 커널의 prom_parse.c 파일에 덧붙여야만 할 것입니다.


“reg” 프로퍼티는 조어진 버스 내의 오직 주소와 크기만 (#size-cells가 0이
아니라면) 정의합니다. 위로 주소를 바꾸기 위해서(부모 버스 주소로,
가능하면 CPU 물리 주소로), 모든 버스는 “ranges” 프로퍼티를 포함해야만
합니다. “ranges” 프로퍼티가 주어진 레벨에 없다면, 주소 변환은 불가능한
것으로, 즉, 부모 버스 상에 레지스터들이 안보이는 것으로 가정합니다.
버스를 위한 “ranges” 프로퍼티의 형식은 다음의 리스트입니다:

        버스 주소, 부모 버스 주소, 크기

“버스 주소”는 이 버스 노드가 정의하는 버스의 형식 안에 있습니다. 즉,
PCI 브릿지에서는 PCI 주소가 될 겁니다. 그래서 (버스 주소, 크기) 는
자식 디바이스의 주소의 범위를 정의합니다. “부모 버스 주소”는 이 버스의
부모 버스의 형식 안에 있습니다. 예를 들면, PCI 호스트 컨트롤러에서는
CPU 주소가 될 것입니다. PCI<->ISA 브릿지에서는 PCI 주소가 될 겁니다.
이것은 그 범위의 시작이 맵핑된 부모 버스 내의 베이스 주소를 정의합니다.

64비트 보드 지원을 위해서, 저는 2/2 형식이나 크기가 보통 하나의 32비트
워드 안에 들어가기 때문에 약간 더 작은 애플의 2/1 형식을 추천합니다.
새로운 32비트 보드 지원은 그 프로세서가 2/1 형식이 권장되는 32비트
이상의 물리 주소를 지원하기 전까지는 1/1 형식을 사용해야 합니다. 

아니면, 그 레지스터들이 식별 맵핑 변환을 사용하는 부모 버스 상에서 보임을
나타내는 것으로, “ranges” 프로퍼티를 빈 상태로 둡니다. 다른 말로 하면,
그 부모 버스 주소 공간은 자식 버스 주소 공간과 같다는 것입니다.

2) “compatible” 프로퍼티에 대한 기록
————————————

이들 프로퍼티들은 선택 사항입니다만, 디바이스와 루트 노드 안에서
권장됩니다. “compatible” 프로퍼티의 형식은 이어진 0으로 끝나는 문자열의
하나의 리스트입니다. 그들은 디바이스가 그들의 유사한 디바이스 계열과의
호환성을, 어떤 경우에는 하나의 드라이버가 그들의 실제 이름과 상관없이
여러 디바이스들과 맞춰지는 것을 나타낼 수 있습니다. 

3) “name” 프로퍼티에 대한 기록
——————————

OldWorld 매킨토시 같은 오픈 펌웨어의 초기 사용자들은 “name” 프로퍼티에
실제 디바이스 이름을 사용하는 경향이 있었던 반면, 오늘날에는 디바이스
클래스(종종 device_type과 같은)에 더 가까운 이름을 사용하는 것이
좋은 실제 예제로 고려됩니다. 예를 들면, 오늘날에는, 이더넷 컨트롤러는
“ethernet”으로, 그 칩 타입/모델을 정확히 정의하는 추가적인 “model”
프로퍼티, 하나의 드라이버가 하나 이상의 이들 칩을 드라이버할 수 있는
경우 그 계열을 정의하는 “compatible” 프로퍼티로 이름 지어집니다.
그러나, 커널은 보통 “name” 프로퍼티 상에 어떤 제한도 두지 않습니다;
그것은 간단히 표준을 따르고, 그 진화에 가능한한 가까이하고자 하는
좋은 관례입니다.


새로운 형식 버전 16은 “name” 프로퍼티를 선택 사항으로 만들었음을 또한,
알아두세요. 어느 노드에 그게 없다면, 그 노드의 유닛 이름이 그 이름을
재구성하는데 사용됩니다. 즉, “@” 기호 전의 그 유닛 이름의 일부가
사용됩니다(또는 “@” 기호가 없다면, 전체 유닛 이름).

4) 노드와 프로퍼티 이름과 문자셋에 대한 기록
——————————————–

오픈 펌웨어가 8859-1의 더 유연한 용법을 제공하는 반면, 이 명세는
더 제한적인 규칙을 강제합니다. 노드와 프로퍼티들은 ASCII 문자들,
‘a’에서 ‘z’, ‘0’에서 ‘9’, ‘,’, ‘.’, ‘_’, ‘+’, ‘#’, ‘?’, 그리고 ‘-‘로만
조합되어야 합니다. 노드 이름은 추가적으로 대문자들 ‘A’에서 ‘Z’
(프로퍼티 이름은 소문자여야 합니다. 애플과 같은 업체들은 이 규칙을
존중하지 않는다는 사실은 여기서 무관합니다)를 허용합니다. 추가적으로,
노드와 프로퍼티 이름들은 언제나 ‘a’에서 ‘z'(또는 노드 이름에 ‘A’에서
‘Z’) 안의 문자로 시작해야 합니다.

노드와 프로퍼티 이름 모두, 문자의 최대 개수는 31입니다. 노드 이름의
경우, 이것은 유닛 이름의 맨 왼쪽의 이름(순수한 “name” 프로퍼티)이고,
그 제한 너머로 확장될 수 있는 유닛 주소를 포함하지 않습니다.

5) 필요 노드와 프로퍼티들
————————-
  이들이 현재 필요한 모두입니다. 그러나, 오픈 펌웨어로 PCI 바인딩 안에
  PCI 호스트 브릿지를 문서화하고, 여러분의 인터럽트 트리를 OF 인터럽트
  트리 명세 안에 문서화하여 노출하는 것을 강력히 권장합니다.
  

  a) 루트 노드

  루트 노드는 존재하기 위해서 몇가지 프로퍼티가 필요합니다:

    – model : 이것은 여러분의 보드 이름/모델입니다.
    – #address-cells : “root” 디바이스의 주소 표현
    – #size-cells: “root” 디바이스의 크기 표현
    – compatible : 여기서 그들의 방법으로 보통 찾을 수 있는 보드 “계열”,
      예를 들면, 커널 내의 같은 플랫폼 코드로 보통 구동될 수 있는
      유사한 배치의 2 보드 모델이 있다면, 여러분은 정확한 보드 모델을
      SOC 모델을 나타내는 항목에 따른 compatible 프로퍼티 내에 지정할
      것 입니다.

  루트 노드는 또한 아무거나 일련 번호같은 여러분의 보드에 따른 추가적인
  프로퍼티를 추가하는 곳 입니다. 표준이 정의하는 어떤 것과 충돌할만한
  어떤 “맞춤형” 프로퍼티가 있다면, 벤터 이름과 콤마를 앞에 붙이는 것이
  권장됩니다.

  b) /cpus 노드

  이 노드는 모든 개별 CPU 노드들의 부모입니다. 어떤 지정 요구 사항도
  없긴하지만 일반적으로 적어도 다음을 가지는 것이 좋은 관례입니다:

               #address-cells = <00000001>
               #size-cells    = <00000000>

  이것은 한 CPU의 “주소”가 하나의 셀이고, 의미없는 크기를 가지고
  있음을 정의합니다. 이것이 필요하진 않지만, 커널은 한 CPU 노드의 “reg”
  프로퍼티를 읽을 때의 형식을 추정하고 아래를 볼 것입니다.

  c) /cpus/* 노드들

  그래서 /cpus 아래에서, 여러분은 머신 상의 모든 개별 CPU의 노드를
  생성한다고 추측할 수 있습니다. CPU 이름에 어떤 지정 제한은 없지만,
  <아키텍처>,<코어> 로 부르는 게 일반적입니다. 예를 들면, 애플은
  PowerPC,G5를 사용하는 반면, IBM 은 PowerPC,970FX를 사용합니다.
  그러나 일반적인 이름 관례는 모든 개별 cpu 노드에 간단히 ‘cpu’를
  사용하고, 특정 cpu 코어를 식별하기 위해서 compatible 프로퍼티를
  사용하는 것이 더 좋다고 합니다.

  필수 프로퍼티:

    – device_type : “cpu”가 되어야만 함.
    – reg : 이것은 물리적 CPU 넘버입니다. 하나의 32비트 셀이고, 또한,
      전체 경로 안의 유닛 이름을 재구성하기 위한 유닛 넘버로써 그냥
      사용됩니다. 예를 들면, 2 CPU에서 전체 경로는 다음과 같습니다:
        /cpus/PowerPC,970FX@0
        /cpus/PowerPC,970FX@1
      (유닛 주소는 0으로 시작할 필요는 없습니다)
    – d-cache-block-size : 하나의 셀, 바이트로 된 L1 데이터 캐시 블록
      크기 (*)
    – i-cache-block-size : 하나의 셀, 바이트로 된 L1 명령 캐시 블록 크기
    – d-cache-size : 하나의 셀, 바이트로 된 L1 데이터 캐시 크기
    – i-cache-size : 하나의 셀, 바이트로 된 L1 명령 캐시 크기

(*) 캐시 “블록” 크기는 캐시 관리 명령 동작 상의 크기입니다. 역사적으로,
이 문서는 여기서 올바르지 않은 캐시 “라인” 크기를 사용합니다. 커널은
캐시 블록 크기를 더 선호할 것이고, 하위 호환성을 위해 캐시 라인 크기로
후퇴할 것입니다.

  권장 프로퍼티:

    – timebase-frequency : Hz로 된 시간 축의 주파수를 나타내는 셀. 이것은
      일반적인 코드에 의해 직접 사용되지는 않지만, 이 값을 기초로 커널
      시간 축/감쇠기 보정을 셋팅하기 위해 p시리즈 코드를 복사/붙여넣기하는
      것도 괜찮습니다.
    – clock-frequency : Hz로 된 CPU 코어 클럭 주파수를 나타내는 셀.
      새로운 프로퍼티는 64비트 값으로 정의될 것이지만, 여러분의 주파수가
      < 4GHz 이면, 하나의 셀로 충분합니다. 여기서는 위에서처럼 좋게,
      일반적인 코드는 이 프로퍼티를 사용하지 않습니다만, p시리즈나
      Maple 것을 재사용하는 것도 괜찮습니다. 미래의 커널 버전은 이를 위한
      일반적인 코드를 제공할 것입니다.
    – d-cache-line-size : 한 셀, 블록 크기와 다르다면, 바이트로 된
      L1 데이터 캐시 라인 크기
    – i-cache-line-size : 한 셀, 블록 크기와 다르다면, 바이트로 된
      L1 명령 캐시 라인 크기

  CPU 들을 소프트-리셋하는데 사용되는 메카니즘에 관한 어떤 정보같은
  여러분의 보드에 관련되어 찾은 어떤 프로퍼티를 추가하는 것도 괜찮습니다.
  예를 들면, 애플은 그들을 소프트 리셋함으로써 두번째 CPU들을 시작하면서
  CPU 소프트 리셋 라인을 위한 GPIO 넘버를 “soft-reset” 프로퍼티로
  넣었습니다.


  d) /memory 노드(들)

  여러분 보드의 물리 메모리 배치를 정의하기 위해서, 여러분은 하나 또는
  그 이상의 memory 노드(들)을 생성해야 합니다. 여러분은 원하는대로,
  하나의 노드에 모든 메모리 범위를 그 reg 프로퍼티에 넣거나, 또는 여러
  노드를 생성할 수 있습니다. 전체 경로에 사용되는 유닛 주소(@ 부분)는
  주어진 노드에 의해 정의된 메모리의 첫번째 범위의 주소입니다. 여러분이
  하나의 메모리 노드를 사용한다면, 일반적으로 @0이 될 것입니다.
  
  필수 프로퍼티:

    – device_type : “memory”가 되어야 함.
    – reg : 이 프로퍼티는 여러분 보드의 모든 물리 메모리 범위를 갖습니다.
      루트 노드의 #address-cells와 #size-cells로 각각 정의된 셀들을
      모두 이어 붙인 주소들/크기들의 하나의 리스트입니다. 예를 들면,
      이들 프로퍼티 둘 다 앞에서 주어진 예제처럼 2를 갖고, 6Gb 램의
      970 베이스 모델이 보통 다음처럼 여기서 “reg” 프로퍼티를 갖을 수
      있습니다:

      00000000 00000000 00000000 80000000
      00000001 00000000 00000001 00000000

      이것은 0에서 시작하는 0x80000000 바이트 범위와 0x10000000에서
      시작하는 0x10000000 바이트 범위입니다. 여러분은 2Gb 과 4Gb 사이의
      IO 홀을 대신하는 메모리가 없음을 볼 수 있습니다. 어떤 업체는
      더 작은 세그먼트로 이들 범위를 나누는 것을 더 선호합니다만,
      커널은 신경쓰지 않습니다.

  e) /chosen 노드

  이 노드는 약간 “특별”합니다. 보통, 오픈 펌웨어가 인자들이나, 또는
  기본 입/출력 디바이스와 같은 어떤 환경 변수 정보를 두는 곳입니다.

  이 명세는 약간의 필수 요소를 갖습니다만, 또한 보통 OF 클라이언트
  인터페이스로 부팅할 때 prom_init() 분기 코드에 의해 재구성되는 몇가지
  리눅스에만 필요한 프로퍼티를 정의합니다. 그러나 여러분은 평면화
  형식을 사용했을 때 여러분 스스로 제공해야만 합니다.

  권장 프로퍼티:

    – bootargs : 이것은 커널로 전달되는 0으로 끝나는 문자열입니다.
    – linux,stdout-path : 이것은 만약 있다면, 여러분의 표준 콘솔
      디바이스의 전체 경로입니다. 보통, 여러분 보드에 시리얼 디바이스가
      있다면, 커널이 그를 기본 콘솔로 고르도록 여기서 펌웨어 내에
      기본 콘솔로 그 하나를 전체 경로를 두고 싶을 것입니다.

  u-boot 은 그를 사용하는 플랫폼을 위해 chosen 노드를 생성하고 내부를
  채움을 알아두세요.

  (알림: 지금은 구식이 된 관례는 주 인터럽트 컨트롤러를 가리키는
  phandle 값을 가지는 interrupt-controller 로 불리는 프로퍼티를
  /chosen 아래에 포함하는 것입니다)

  f) /soc<SOC이름> 노드

  이 노드는 시스템-온-칩(SOC)를 표현하는데 사용되고, 프로세서가 SoC라면
  반드시 있어야 합니다. 최고 레벨 soc 노드는 SoC 상의 모든 디바이스에
  대한 전역 정보를 포함합니다. 노드 이름은 SoC의 메모리-맵핑된
  레지스터S의 기초 주소인 SoC의 유닛 주소를 포함해야 합니다. SoC의
  이름은 “soc”로 시작해야하고, 나머지 이름은 soc의 부품 번호를 나타내야
  합니다. 예를 들면, MPC8540의 soc 노드는 “soc8540″이 될 겁니다.
  

  필수 프로퍼티:

    – ranges : 메모리 맵핑된 SoC 레지스터의 SoC 주소의 변환을
      설명하도록 지정하여 정의되어야 함.
    – bus-frequency: SoC 노드의 버스 주파수를 포함. 보통 이 필드의
      값은 부트 로더에 의해 채워집니다.
    – compatible : SoC의 정확한 모델


  권장 프로퍼티:

    – reg : 이 프로퍼티는 SOC 노드 그 자체적으로 사용되는 메모리 맵핑된
      레지스터들의 주소와 크기를 정의합니다. 자식 디바이스 레지스터들은
      포함하지 않습니다 – 이들은 각 자식 노드 내에 정의될 것입니다.
      그 “reg” 프로퍼티 내에 지정된 주소는 SOC 노드의 유닛 주소와
      맞아야 합니다.
    – #address-cells : “soc” 디바이스의 주소 표현. 이 필드의 형식은
      디바이스 레지스터들이 메모리 맵핑됐느냐에 따라 다양할 것입니다.
      메모리 맵핑된 레지스터들에 대해서 이 필드는 레지스터들의 주소를
      나타내는데 필요한 셀의 수를 나타낼 것입니다. MMIO를 사용하지 않는
      SOC에서는 필요한 정보를 나타내는 충분한 셀을 포함하는 특별한 주소
      형식으로 정의되어져야 합니다. #address-cells를 정의하는데 대한
      자세한 사항은 위의 1) 을 보세요.
    – #size-cells : “soc” 디바이스의 크기 표현
    – #interrupt-cells : 인터럽트를 표현하는데 사용되는 셀의 너비를
      정의합니다. 보통 이 값은 인터럽트 번호를 표현하는 32비트 수 하나와
      인터럽트 감지와 레벨을 표현하는 32비트 수 하나를 포함하는 <2>
      입니다. 이 필드는 오직 SOC가 인터럽트 컨트롤러를 포함할 때만
      포함됩니다.

  SOC 노드는 플랫폼이 사용하는 각 개별 SOC 디바이스를 위한 자식 노드들을
  포함할 것 입니다. 노드들은 SOC 상에 존재는 하지만 특정 플랫폼에서
  사용되는 디바이스들은 생성되지 않아야 합니다. SOC 의 일부인 디바이스를
  어떻게 지정하는지에 대한 더 많은 정보는 챕터 VI를 보세요.

  MPC8540의 SOC 노드 예제:

        soc8540@e0000000 {
                #address-cells = <1>;
                #size-cells = <1>;
                #interrupt-cells = <2>;
                device_type = “soc”;
                ranges = <0x00000000 0xe0000000 0x00100000>
                reg = <0xe0000000 0x00003000>;
                bus-frequency = <0>;
        }



IV – “dtc”, 디바이스 트리 컴파일러(device tree compiler)
========================================================


dtc 소스 코드는 다음에서 찾을 수 있습니다.
<http://git.jdl.com/gitweb/?p=dtc.git>

경고: 이 버전은 아직 초기 개발 단계에 있습니다; 결과 디바이스 트리
“바이너리 객체”는 커널에 아직 유효하지 않습니다. 현재 생성되는 블록은
무엇보다도 유용한 예약 맵(빈 것을 생성하도록 고쳐질 것이고 부트로더가
채울 것입니다)이 없습니다. 에러 처리도 작업이 필요하고, 버그들이
숨어 있고, 또…


dtc는 기본적으로 주어진 형식의 디바이스-트리를 취해서 다른 형식으로
디바이스-트리를 출력합니다. 현재 제안되는 형식은 다음과 같습니다:

  입력 형식:
  ———-

     – “dtb”: “바이너리 객체” 형식, 즉, 바이너리 객체 내의 모든 헤더로
       된 평면 디바이스-트리 블록
     – “dts”: “소스” 형식. 이것은 디바이스-트리의 “소스”를 포함하는
        텍스트 파일입니다. 이 형식은 이 챕터 이후에 정의됩니다.
     – “fs” 형식. 이것은 노드들이 디렉토리들이고, 프로퍼티들이 파일들인
        /proc/device-tree 의 출력과 동등한 표현입니다.
        

 출력 형식:
 ———-

     – “dtb”: “바이너리 객체” 형식
     – “dts”: “소스” 형식
     – “asm”: 어셈블리 언어 파일. 이것은 디바이스-트리 “바이너리 객체”
       를 생성하는 가스에 의해 얻어질 수 있는 파일입니다. 이 파일은
       간단히 여러분의 Makefile에 붙을 수 있습니다. 추가적으로, 그
       어셈블리 파일은 사용될 수 있는 심볼들을 노출합니다.


dtc 툴의 문법은

    dtc [-I <입력-형식>] [-O <출력-형식>]
        [-o 출력-파일이름] [-V 출력_버전] 입력_파일이름


“출력_버전”은 생성될 “바이너리 객체” 형식이 무슨 버전인지 정의합니다.
지원되는 버전은 1,2,3, 그리고 16입니다. 기본은 현저 버전 3 이지만,
지나면 버전 16 으로 바뀔 겁니다.

덧붙여, dtc는 linux의 유일성, phandle 프로퍼티들, 문자열들의 유효함,
기타… 와 같은 트리 상의 다양한 자체 검사를 수행합니다.

.dts “소스” 파일은 C 와 C++ 스타일 주석을 지원하는 “C” 같은 형식이다.

/ {
}

위는 “디바이스-트리” 정의이다. 최고 레벨에 현재 지원되는 단하나의
문장입니다.

/ {
  property1 = “string_value”;   /* 0으로 끝나는 문자열을 포함하는
                                 * 프로퍼티를 정의
                                 */

  property2 = <0x1234abcd>;     /* 수로 된 32비트 값(16진수)을
                                 * 포함하는 프로퍼티를 정의
                                 */
                                 

  property3 = <0x12345678 0x12345678 0xdeadbeef>;
                                /* 수로 된 32비트 16진수 값들(셀들)
                                 * 3 개를 포함하는 프로퍼티를 정의
                                 */
  property4 = [0x0a 0x0b 0x0c 0x0d 0xde 0xea 0xad 0xbe 0xef];
                                /* 내용이 바이트들의 임의의 배열인
                                 * 프로퍼티를 정의
                                 */

  childnode@address {   /* 유닛 이름이 “address의 childnode”인
                                 * “childnode” 가 이름인 자식노드를
                                 * 정의
                                 */

    childprop = “hello\n”;      /* 자식 노드의 “childprop” 프로퍼티를
                                 * 정의(이 경우는 문자열)
                                 */
  };
};

노드들은 다른 노드들, 기타… 를 포함할 수 있어서 트리의 계층적 구조를
정의합니다.

문자열은 C에서의 일반적인 특수 문자들을 지원합니다: “\n”, “\t”, “\r”,
“\(8진수 값)”, “\x(16진수 값)”.

또한, cpp (gcc 전처리기)를 통해 여러분의 소스파일을 파이프로 흘려보낼
수 있어서 #include 의 것, 상수를 위한 #define, 기타… 를 사용할 수
있습니다.

마지막으로, phandle의 자동 생성, labels(asm 파일로 노출되어 여러분이
프로퍼티 내용을 가리킬 수 있고, 디바이스 트리로 연결한 어떠한 것으로부터
쉽게 변경할 수 있음), 어떤 셀들 안의 수로 된 값 대신 노드(컴파일 타임에
phandle에 의해 대체됨)를 “가리키는” label 또는 path, asm 파일로 예약 맵
주소를 노출하기, 컴파일 타임에 예약 맵 내용을 지정하는 능력, 기타…
같은 다양한 옵션들이 계획되어 있지만, 아직 구현되어 있지는 않습니다.

컴파일러에 구조 정의들의 개념을 추가하는 것이 더 낫겠지만, 우리는
.h 를 포함하는 파일을 (PCI 프로퍼티들 또는 인터럽트 맵 같은)몇가지
프로퍼티를 유용하게 감지하는 일반적인 정의들로 제공할 것입니다.


V – 부트로더에 대한 권장 사항
=============================


여기에 다양한 몇가지 제안되었던 생각들/권장 사항들이 있습니다. 이 모든
것들이 정의되고 구현되었습니다.

  – 부트로더는 디바이스-트리 그 자체를 사용할 수 있기를 원하고,
    조작하기(물리 메모리 크기나 커널 인자들 같은, 어떤 프로퍼티를
    추가하고/편집하고)를 원합니다. 이 시점에서 두가지 선택이 있을 수
    있습니다. 부트로더가 직접 평면화 형식 상에서 작업하거나, 또는,
    부트로더가 그 자신의 포인터들로 된(커널 것과 비슷한) 내부 트리
    표현을 갖거나 말입니다. 앞에 것이 편집/수정에 약간 더 어렵고,
    뒤에 것이 아마도 트리 구조를 처리하는 약간 더 복잡한 코드를
    필요로 합니다. 상대적으로 프로퍼티나 노드들의 “추가”가 쉽고,
    그저 메모리 이동으로 삭제하는것이 쉽게 설계되었습니다. 이런
    목적으로 내부 오프셋이나 포인터를 포함하지 않습니다.

  – 평면화 트리 형식으로부터 직접 노드들을 열거하고, 프로퍼티를
    탐색하기 위한 예제 코드는 커널 파일 drivers/of/fdt.c 안에서 찾을
    수 있습니다. of_scan_flat_dt() 함수, early_init_devtree() 안의
    그 사용 예, 그리고, 해당하는 다양한 early_init_dt_scan_*() 콜백들
    을 살펴 보세요. 그 코드는 GPL 부트로더에서 재사용 될 수 있고,
    그 코드의 작성자로서, 저는 GPL이 아닌 부트로더로 이 코드의 일부,
    또는 전부를 통합하길 원하는 업체들과 자유 라이센스를 토론할 수
    있다는 것이 행복합니다(참고가 필요합니다; 여기서 누가 ‘나’인가?
    (who is ‘I’ here?) —gcl 2011년 1월 31일)



VI – 시스템-온-칩 디바이스와 노드들
===================================

많은 회사들이 지금 프로세서 코어(CPU)와 많은 주변 장치가 한 조각의
실리콘 상에 존재하는 시스템-온-칩 프로세서 개발을 시작하고 있습니다.
이들 SOC들에 대해, SOC 노드는 SOC를 구성하는 디바이스들에 대한 자식
노드들을 정의하는데 사용되어야 합니다. 플랫폼들이 커널을 부팅하기 위해
이 모델을 사용하는 것이 필요하지 않은데 반해, 모든 SOC 구현들은
SOC 상의 디바이스들을 기술하는데 가능한 한 완전한 평면-디바이스-트리로
정의하고자 장려됩니다. 이것은 많은 양의 커널 코드의 일반화를 가능하게
할 것입니다.


1) SOC의 자식 노드들 정의하기
—————————–

SOC의 일부인 각 개별 디바이스들은 SOC 노드 내에 그들만의 노드 항목을
가질 것입니다. SOC 내에 포함된 각 개별 디바이스들을 위해, 유닛 주소
프로퍼티는 이 디바이스의 부모의 주소 공간 안의 메모리 맵핑된
레지스터들을 위한 주소 오프셋을 나타냅니다. 그 부모의 주소 공간은
최고 레벨 soc 노드 내의 “ranges” 프로퍼티로 정의됩니다. SOC 노드 아래에
직접 존재하는 각 개별 노드의 “reg” 프로퍼티는 자식 주소 공간으로부터
부모 SOC 주소 공간으로의 주소 맵핑, 디바이스의 메모리-맵핑된 레지스터
파일의 크기를 포함해야만 합니다.

SOC 내부에 존재하는 많은 디바이스들을 위해, 디바이스 트리 노드의 형식을
미리 정의하는 명세들이 있습니다. 모든 SOC 자식 노드들은 이 문서에서
알리는 곳 외에는 이 명세를 따라야 합니다.

MPC8540의 일부 SOC 노드 정의 예제를 부록 A에서 보세요.


2) 현재의 OF 명세없이 디바이스들 나타내기
—————————————–

현재, 주로 보드들이 현재 오픈 펌웨어를 사용하여 부팅되지 않는 SoC들을
포함하고 있기 때문에, 오픈 펌웨어 명세의 일부로 정의된 표준 표현이 없는
SOC 상의 많은 디바이스들이 있습니다. 새로운 디바이스의 바인딩 문서는
Documentation/devicetree/bindings 디렉토리에 추가되어야 합니다.
그 디렉토리는 더 많고 많은 SoC들에 디바이스 트리 지원을 확장할 것입니다.


VII – 디바이스들의 인터럽트 정보 지정하기
=========================================

디바이스 트리는 하드웨어 시스템의 버스들과 디바이스들을 하드웨어의
물리적 버스 토폴로지와 유사한 형식으로 표현합니다.

추가로, 하드웨어 내의 인터럽트의 계층과 경로를 표현하는 논리적인
‘인터럽트 트리’가 존재합니다.

인터럽트 트리 모델은 “오픈 펌웨어 권장 용례: 인터럽트 맵핑 버전 0.9
(Open Firmware Recommended Practice: Interrupt Mapping Version 0.9)”
안에 완전히 서술되어 있습니다. 이 문서는
<http://www.openfirmware.org/ofwg/practice/> 에서 이용 가능합니다.

1) interrupt 프로퍼티
———————

하나의 인터럽트 컨트롤러로 인터럽트를 생성하는 디바이스들은 
OF 인터럽트 맵핑 문서 내에 서술된 관례적인 OF 표현을 사용해야 합니다.

인터럽트를 생성하는 각 개별 디바이스는 ‘interrupt’ 프로퍼티를 가져야만
합니다. 인터럽트 프로퍼티 값은 디바이스의 그 인터럽트 또는 인터럽트들을
서술하는 임의의 개수의 ‘interrupt specifier’ 값들입니다.

인터럽트 지시자의 인코딩은 디바이스가 인터럽트 트리 내에 위치한
인터럽트 도메인에 따라 결정됩니다. 인터럽트 도메인의 루트는 그의
#interrupt-cells 프로퍼티 내에 인터럽트 지시자를 인코딩하는데 필요한
32비트 셀들의 수를 정합니다. 도메인들의 더 자시한 설명은 OF 인터럽트
맵핑 문서를 보세요.

예를 들면, OpenPIC 인터럽트 컨트롤러의 바인딩은 #interrupt-cells 값으로
인터럽트 번호와 레벨/감지 정보를 위해 2를 지정합니다. OpenPIC 인터럽트
도메인 내의 모든 인터럽트 자식들은 그들의 인터럽트 프로퍼티 내에
인터럽트 당 2 셀을 사용합니다.

PCI 버스 바인딩은 어느 인터럽트 핀(INTA,INTB,INTC,INTD)이 사용되는지
인코딩하기 위해서 #interrupt-cell 값으로 1을 지정합니다.

2) interrupt-parent 프로퍼티
—————————-

interrupt-parent 프로퍼티는 인터럽트 트리 내의 디바이스 노드와 그의
인터럽트 부모 간의 명시적인 링크를 정의하기 위해서 지정됩니다. 이
interrupt-parent 값은 부모 노드의 phandle 입니다.

interrupt-parent 프로퍼티가 한 노드를 정의하지 않으면, 그의 인터럽트
부모는 그 노드의 _디바이스 트리_ 계층 내의 조상으로 추정합니다.

3) OpenPIC 인터럽트 컨트롤러
—————————-

OpenPIC 인터럽트 컨트롤러는 인터럽트 정보를 인코딩하는데 2셀을
필요로 합니다. 첫번째 셀은 인터럽트 번호를 정의합니다. 두번째 셀은
감지와 레벨 정보를 정의합니다.

감지와 레벨 정보는 다음처럼 인코딩되어야 합니다:

        0 = 로우(Low)에서 하이(High)로의 엣지(Edge) 감지 타입이 활성
        1 = 엑티브 로우(active low) 레벨(level) 감지 타입이 활성
        2 = 엑티브 하이(active high) 레벨 감지 타입이 활성
        3 = 하이에서 로우로의 엣지 감지 타입이 활성

4) ISA 인터럽트 컨트롤러
————————

ISA PIC 인터럽트 컨트롤러는 인터럽트 정보를 인코딩하는데 2셀을
필요로 합니다. 첫번째 셀은 인터럽트 번호를 정의합니다. 두번째 셀은
감지와 레벨 정보를 정의합니다.

ISA PIC 인터럽트 컨트롤러는 다음에 나열된 ISA PIC 인코딩으로 붙어야
합니다.

        0 = 엑티브 로우(active low) 레벨(level) 감지 타입이 활성
        1 = 엑티브 하이(active high) 레벨 감지 타입이 활성
        2 = 하이(High)에서 로우(Low)로의 엣지(Edge) 감지 타입이 활성
        3 = 로우에서 하이로의 엣지 감지 타입이 활성

VIII – 디바이스 전원 관리 정보 지정하기 (sleep 프로퍼티)
========================================================

SoC 상의 디바이스들은 그 디바이스의 자체 레지스터 블록으로부터 떨어져나가는
저-전력 상태로 디바이스를 두는 메카니즘을 종종 갖고 있습니다. 어떤 때는,
이 정보가 cell-index 프로퍼티가 꽤 설명할 수 있는 것보다 좀 복잡합니다.
그래서 각 이런 형태의 개별 디바이스는 이들 연결을 서술하는 “sleep”
프로퍼티를 포함할 것 입니다.

sleep 프로퍼티는 하나 또는 그 이상의 각각이 슬립 컨트롤러로의 phandle,
그 뒤에 0 또는 그 이상의 셀의 컨트롤러에-따른(contrller-specific)
슬립 지시자로 구성된, 슬립 자원들로 구성됩니다.

가능한 저전력 모드가 무슨 종류인지의 의미들은 슬립 컨트롤러에 의해
정의됩니다. 지원될 저전력 모드의 타입 예제는:

 – 다이내믹(Dynamic): 디바이스가 아무때나 꺼지고 켜짐.
 – 시스템 서스펜드(System Suspend): 디바이스가 꺼지거나 시스템 서스펜드
   동안 깬 상태로 남아있도록 요청할 것입니다.
 – 퍼머넌트(Permanent): 디바이스가 영원히 꺼집니다(다음 하드 리셋 전까지)

어떤 디바이스는 각각 다른 것들과 클럭 도메인을 공유할 것 입니다. 그런 것들은
디바이스가 사용 중인 것이 없을 때에만 서스펜드 상태가 됩니다. 정당할 때는,
이들 노드들이 버스가 sleep 프로퍼티를 갖는 곳에서 가상 버스 상에 있어야만
합니다. 클럭 도메인이 이런 형태로 꽤 그룹 지어진 디바이스들 간에 공유되면,
(그 필요성이 나타나기 전까지 표준화된 슬립-맵을 정의하는 것을 기다려야 하는
것을 제외하면, 인터럽트 넥서스와 유사하게)가상 슬립 컨트롤러를 생성해야
합니다.

부록 A – MPC8540의 예제 SOC 노드
================================

        soc@e0000000 {
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = “fsl,mpc8540-ccsr”, “simple-bus”;
                device_type = “soc”;
                ranges = <0x00000000 0xe0000000 0x00100000>
                bus-frequency = <0>;
                interrupt-parent = <&pic>;

                ethernet@24000 {
                        #address-cells = <1>;
                        #size-cells = <1>;
                        device_type = “network”;
                        model = “TSEC”;
                        compatible = “gianfar”, “simple-bus”;
                        reg = <0x24000 0x1000>;
                        local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x00 ];
                        interrupts = <0x29 2 0x30 2 0x34 2>;
                        phy-handle = <&phy0>;
                        sleep = <&pmc 0x00000080>;
                        ranges;

                        mdio@24520 {
                                reg = <0x24520 0x20>;
                                compatible = “fsl,gianfar-mdio”;

                                phy0: ethernet-phy@0 {
                                        interrupts = <5 1>;
                                        reg = <0>;
                                        device_type = “ethernet-phy”;
                                };

                                phy1: ethernet-phy@1 {
                                        interrupts = <5 1>;
                                        reg = <1>;
                                        device_type = “ethernet-phy”;
                                };

                                phy3: ethernet-phy@3 {
                                        interrupts = <7 1>;
                                        reg = <3>;
                                        device_type = “ethernet-phy”;
                                };
                        };
                };

                ethernet@25000 {
                        device_type = “network”;
                        model = “TSEC”;
                        compatible = “gianfar”;
                        reg = <0x25000 0x1000>;
                        local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x01 ];
                        interrupts = <0x13 2 0x14 2 0x18 2>;
                        phy-handle = <&phy1>;
                        sleep = <&pmc 0x00000040>;
                };

                ethernet@26000 {
                        device_type = “network”;
                        model = “FEC”;
                        compatible = “gianfar”;
                        reg = <0x26000 0x1000>;
                        local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x02 ];
                        interrupts = <0x41 2>;
                        phy-handle = <&phy3>;
                        sleep = <&pmc 0x00000020>;
                };

                serial@4500 {
                        #address-cells = <1>;
                        #size-cells = <1>;
                        compatible = “fsl,mpc8540-duart”, “simple-bus”;
                        sleep = <&pmc 0x00000002>;
                        ranges;

                        serial@4500 {
                                device_type = “serial”;
                                compatible = “ns16550”;
                                reg = <0x4500 0x100>;
                                clock-frequency = <0>;
                                interrupts = <0x42 2>;
                        };

                        serial@4600 {
                                device_type = “serial”;
                                compatible = “ns16550”;
                                reg = <0x4600 0x100>;
                                clock-frequency = <0>;
                                interrupts = <0x42 2>;
                        };
                };

                pic: pic@40000 {
                        interrupt-controller;
                        #address-cells = <0>;
                        #interrupt-cells = <2>;
                        reg = <0x40000 0x40000>;
                        compatible = “chrp,open-pic”;
                        device_type = “open-pic”;
                };

                i2c@3000 {
                        interrupts = <0x43 2>;
                        reg = <0x3000 0x100>;
                        compatible  = “fsl-i2c”;
                        dfsrr;
                        sleep = <&pmc 0x00000004>;
                };

                pmc: power@e0070 {
                        compatible = “fsl,mpc8540-pmc”, “fsl,mpc8548-pmc”;
                        reg = <0xe0070 0x20>;
                };
        };