[Windows] USB 3.0 연결 확인 방법

다른 방법보다 이게 제일 확실한 것 같다.

https://www.aida64.com/downloads 에서 AIDA64를 설치한다.

설치 후 실행 화면에서 아래와 같이 “장치” 아래의 “USB 장치”를 선택한다.

그럼 그 오른쪽에 연결된 장치들이 쭉 나타난다. 3.0인지 확인하고 싶은 디바이스를 선택한다. 오른쪽 아래의 현재 속도에 보면 High (2.0) 인지, 혹은 3.0 장치인데 2.0 허브에 물렸는지, 혹은 Super (3.0) 으로 잘 연결되어 있는지가 나타난다.

[Linux] fstab의 구조와 옵션

fstab이란?

fstab은 Linux 시스템의 file system table을 뜻한다. mount를 쉽게 하기 위한 configuration table이다.

fstab의 구조

6개의 항목이 순서대로 구성되어야 한다.

  1. 디바이스 (Device): 보통 mount되는 디바이스의 이름 혹은 UUID이다. 예를 들면, sda1
  2. 마운트 위치 (Mount point): mount될 디렉토리의 위치
  3. 파일 시스템 타입 (File System Type): 사용되는 file system의 type
  4. 옵션 (Options): mount 옵션. 여러개를 쓸 때는 콤마(,)로 구분한다.
  5. 백업 동작 (Backup Operation): 0은 백업하지 않음. 1은 dump로 backup을 할지를 결정. 오래된 backup 방법이라서 0으로 설정해서 사용하지 않도록 한다.
  6. 파일 시스템 체크 순서 (File System Check Order): 0은 fsck로 체크하지 않음. 1은 root file system, 다른 파티션들은 2로 설정되어야 한다. 3, 4, … 로 한다고 해서 순서가 되지 않으므로 순서를 설정하지 않도록 한다. 그냥 다른 모든 파티션은 2이다.

예제

proc            /proc           proc    defaults          0       0
PARTUUID=5e3da3da-01  /boot           vfat    defaults          0       2
PARTUUID=5e3da3da-02  /               ext4    defaults,noatime  0       1
UUID=678dcc13-1b44-4ee8-80cf-7f186587054d       /mnt/NAS        ext4    defaults,noatime,rw     0       2
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

다른 mount 옵션

  • auto / noauto: 부팅 시에 자동으로 mount할지 말지.
  • exec / noexec: 그 파티션이 바이너리를 실행할 수 있는지 아닌지. 보통 보안 목적으로 noexec로 설정된다.
  • ro / rw: ro는 읽기 전용 (read-only), rw는 읽기 쓰기 (read-write)
  • nouser / user: user가 mount권한을 갖을지 말지.
  • atime / noatime / relatime: access time (atime) 을 기록할지 말지. relatime은 access time이 atime data가 마지막으로 update된 (mtime) 이후에 파일이 수정되었을 때, 또는 마지막으로 access된 후 일정 시간 (기본값은 하루)이 지난 후에만 업데이트한다.
  • suid / nosuid: suid와 sgid 비트 동작을 허용할지 말지.
  • dev / nodev: character나 block special device를 interpret할지 말지.
  • defaults: 기본값을 사용. rw, suid, dev, exec, auto, nouser, async 와 같다.

참고 자료

[HTML5&CSS] HTML5 기본 구조

처음 doc type을 정한다. HTML5부터는 매우 심플하다.

<!DOCTYPE HTML>

 

HTML 태그로 시작한다. lang attribute로 어느 언어인지를 명시한다.

<html lang=”en”></html>

 

html 태그 안에는 head와 body가 들어간다.

먼저 head 안에 들어갈 내용을 살펴보자.

head의 필수 태그는 title이다. title 태그 전에 meta 태그로 charset을 명시해준다.

meta 태그로 해당 페이지의 description을 적어주면 좋다.

meta 태그로 디바이스의 width와 초기 scale로 viewport도 적어준다.

<head>

<meta charset=”utf-8″>

<title>DasomOLI’s example1</title>

<meta name=”description” content=”The purpose of this page is for showing a example of HTML5 basic structure”>

<meta name=”viewport” content=”width=device-width, initial-scale=1″>

</head>

 

body 태그 안엔 보일 내용을 내용의 목적에 맞는 태그를 사용해서 적는다.

대표적인 태그는 제목을 적을 때 사용하는 heading <h1>, <h2> 등의 태그와 리스트를 작성할 때 사용하는 unordered list <ul>, ordered list <ol>, 그리고 그 아래 항목을 적을 때 사용하는 list item <li>, 문단을 작성할 때 사용하는 paragraph <p> 태그 등이 있다.

<body>
<h1>DasomOLI’s example1</h1>
<p>Hello HTML5!</p>
</body>

모두 합치면 다음과 같을 것이다.

<!DOCTYPE HTML>
<html lang=”en”>
  <head>
    <metacharset=”utf-8″>
    <title>DasomOLI’s example1</title>
    <metaname=”description”content=”The purpose of this page is for showing a example of HTML5 basic structure”>
    <metaname=”viewport”content=”width=device-width, initial-scale=1″>
  </head>
  <body>
    <h1>DasomOLI’s example1</h1>
    <p>Hello HTML5!</p>
  </body>
</html>

완성된 html 은 w3c에서 제공하는 validator (https://validator.w3.org/)를 통해 유효성을 검사할 수 있다.

 

[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>;
                };
        };

[Linux:Kernel] 리눅스와 디바이스 트리(Linux and device tree)

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

리눅스와 디바이스 트리

———————-
디바이스 트리 데이터를 위한 리눅스 사용 모델
저자: Grant Likely <grant.likely@secretlab.ca>
번역: 양정석 <dasomoli@gmailREMOVETHIS.com>
이 글은 리눅스가 디바이스 트리를 어떻게 사용하는지를 설명합니다.
디바이스 트리 데이터 포멧의 개요는 devicetree.org[1]에 있는 디바이스
트리 용법 페이지에서 찾을 수 있습니다.
[1] http://devicetree.org/Device_Tree_Usage
“오픈 펌웨어 디바이스 트리” 또는 간단히 디바이스 트리(DT)는 하드웨어를
서술하기 위한 데이터 구조와 언어입니다. 더 정확하게는, 어떤 운영 체제에
의해 읽혀져서 운영 체제가 그 머신의 상세 사항을 하드 코딩할 필요 없게
하는 한 하드웨어의 서술입니다.
구조적으로, DT는 이름있는 노드들로 이루어진 하나의 트리, 또는 사이클이
없는 그래프이고, 노드들은 임의의 데이터를 캡슐화하는 이름있는 프로퍼티
를 임의의 개수만큼 갖습니다. 또한 한 노드에서 자연스러운 트리 구조의
밖 다른 곳으로 임의의 연결을 만들 수 있는 메카니즘도 존재합니다.
개녑적으로, 데이터 버스, 인터럽트 라인, GPIO 연결, 그리고 부속 장치들을
포함하는 일반적인 하드웨어 속성을 서술하기 위해서 트리 안에서 데이터가
어떻게 나타나야 하는지를 위한 ‘바인딩’이라고 부르는 사용 용법의 공통
부분이 정의됩니다.
가능한 한 많이, 이미 존재하는 지원 코드의 사용을 최대화하기 위해서
이미 존재하는 바인딩을 사용해서 하드웨어가 서술됩니다. 그러나 프로퍼티와
코드 이름은 간단한 문자열이기 때문에, 이미 존재하는 바인딩을 확장하거나,
새로운 노드와 속성을 정의하는 것으로 새로운 것을 하나 생성하는 것은
쉽습니다. 그러나, 이미 존재하는 것에 대한 어떤 과제를 먼저 하지 않고,
새로운 바인딩을 생성하는 것은 조심하세요. 이전에 어떻게 기존 시스템에서
i2c 디바이스들이 열거되는지를 먼저 파악하지 않고 생성된 새로운 바인딩
때문에 현재 두가지 다른, 호환되지 않는 i2c 버스를 위한 바인딩이 있습니다.
1. 역사
——-
DT는 원래 오픈 펌웨어로부터 어떤 (운영 체제 같은)클라이언트 프로그램에게
데이터를 전달하기 위한 통신 방법의 일종으로 오픈 펌웨어에 의해서
생성되었습니다. 운영 체제는 런타임에 하드웨어의 구성을 알아내기 위해서
디바이스 트리를 사용했고, 그럼으로써 하드 코딩된 정보 없이 (모든
디바이스를 위한 드라이버가 가용함을 가정하여) 이용 가능한 하드웨어의
한 주류를 지원하였습니다.
오픈 펌웨어는 PowerPC 와 SPARC 플랫폼에서 일반적으로 사용되었기 때문에,
이들 아키텍처의 리눅스의 지원은 오랫동안 디바이스 트리를 사용했습니다.
2005년에, PowerPC 리눅스가 많은 코드 정리와 32비트와 64비트 지원을
통합하기 시작했을 때, 오픈 펌웨어를 사용하느냐와 상관없이 모든 PowerPC
플랫폼 상에서 DT 지원이 필요하다는 결정이 내려집니다. 이것을 하기 위해서
진짜 오픈 펌웨어 구현을 필요로 하지 않는 바이너리 덩이로 커널로 전달할 수
있는 평면 디바이스 트리(FDT: Flattened Device Tree)라고 불리는
DT 표현방법이 만들어 졌습니다. U-Boot, kexec, 그리고 다른 부트로더들이
디바이스 트리 바이너리(dtb: Device Tree Binary)를 전달하기 위한, 그리고
부팅 타임에 dtb를 수정하기 위한 두가지를 지원하기 위해서 수정되었습니다.
DT는 또한 PowerPC 부트 래퍼 (arch/powerpc/boot/*)에 추가되어 dtb가 기존의
DT가 아닌 것을 아는 펌웨어의 부팅을 지원하기 위한 커널 이미지와 함께
싸여질 수 있게 되었습니다.
조금 지나서부터는, FDT 구조는 모든 아키텍처에 사용가능하도록 일반화
되었습니다. 이 것이 쓰여지는 시점에, 6개의 메인 라인 아키텍처(arm,
microblaze, mips, powerpc, sparc, 그리고 x86)와 1개의 메인 라인은
아닌 아키텍처(nios)가 여러 단계의 DT 지원을 하고 있습니다.
2. 데이터 모델
————–
만약 여러분이 이미 디바이스 트리 용법[1] 페이지를 읽지 않았다면,
지금 가서 읽으세요. 괜찮아요. 내가 기다리죠….
2.1 하이 레벨 뷰
—————-
이해를 위해 가장 중요한 것은, DT가 간단히 하드웨어를 서술하는 하나의
데이터 구조라는 것입니다. 그에 관한 마법 같은 것은 없어요. 그리고, 
마법을 사용해서 모든 하드웨어 설정 문제를 날려버리도록 하지도 않습니다.
그게 하는 것은 리눅스 커널 안에서 (혹은 그 문제를 위한 다른 운영체제
안에서) 그 보드로부터의 하드웨어 설정과 디바이스 드라이버 지원의
결합을 끊는 언어를 제공하는 것입니다. DT를 사용하는 것은 보드와 디바이스
지원이 데이터 중심(Data driven)이 되도록 합니다; 머신마다 하드 코딩된
선택들 대신 커널로 전달된 데이터에 기조한 셋업 결정을 내리기.
이상적으로는, 데이터 중심 플랫폼 셋업은 더 적은 코드 중복을 가져오고,
하나의 커널 이미지로 광범위한 하드웨어 지원을 쉽게 만듭니다.
리눅스는 DT 데이터를 다음 세가지 주요 목적을 위해 사용합니다:
1) 플랫폼 식별,
2) 런타임 환경 설정,
3) 디바이스 실제 장착
2.2 플랫폼 식별
—————
무엇보다도 먼저, 커널은 그 특정 머신을 식별하기 위해서 DT 안의 데이터를
사용할 것입니다. 완벽한 세상에서, 모든 플랫폼의 상세 사항은 디바이스
트리에 의에서 완벽히 일관되고 신뢰성있게 서술될 것이므로, 그 특정
플랫폼은 커널에게 문제가 되지 않습니다. 하드웨어가 완벽하지 않음에도,
커널은 초기 부팅 동안 그 머신을 식별해야만 하고 그로 인해 그 머신
의존적인 수정 사항을 실행할 수 있는 기회를 가집니다.
대부분의 경우에, 그 머신 식별은 엉뚱하고, 그 커널은 대신 머신의 코어
CPU나 SoC에 기초한 셋업 코드를 선택할 것입니다. ARM 을 예로 들면,
arch/arm/kernel/setup.c 안의 setup_arch() 는 machine_desc 테이블을
검색하고, 디바이스 트리 데이터와 가장 알맞은 machine_desc를 고르는
arch/arm/kernel/devtree.c 안에 있는 setup_machine_fdt()를 호출할
것입니다. 루트 디바이스 트리 노드 안에 있는 ‘compatible’ 프로퍼티에서
찾고 (궁금하다면, arch/arm/include/asm/mach/arch.h 내에 정의된)
struct machine_desc 안의 dt_compat 리스트와 비교함으로써 가장 알맞은
것을 결정합니다.
‘compatible’ 프로퍼티는 그 머신의 정확한 이름으로 시작하는 문자열의
정렬된 리스트를 포함하고, 그 보드와 가장 크게 호환되는 것에서부터
가장 적은 순으로 정렬된 보드들의 부가 리스트가 뒤따릅니다. 예를 들면,
TI BeagleBoard를 위한 루트 compatible 프로퍼티와 BeagleBoard xM 보드
같은 그 후계자는 각각:
compatible = “ti,omap3-beagleboard”, “ti,omap3450”, “ti,omap3”;
compatible = “ti,omap3-beagleboard-xm”, “ti,omap3450”, “ti,omap3”;
여기서 “ti,omap3-beagleboard-xm” 은 정확한 모델을 지정합니다. 그것은
또한 OMAP 3450 SoC, 그리고 일반적인 omap3 계열과 호환된다고 주장합니다.
여러분은 그 리스트를 가장 크게 특징적인 것(정확한 보드)에서 가장 적게
특징적인 것(SoC 계열)로 정렬함을 알아챌 수 있을 것입니다.
영리한 독자는 Bealge xM 은 또한 원래의 Beagle 보드와 호환된다고 주장함에
주목할 수 있습니다. 그러나, 같은 제품 라인이고, 한 보드가 다른 것과
호환된다고 주장할 때, 무엇을 의미하는지 정확히 못박기 어려울 지라도,
보통 한 보드에서 다른 것으로의 하이 레벨의 변경이 있는 한, 하나는 그
보드 레벨에서 그렇게 하는 것에 대한 경고를 받아야 합니다. 최고 레벨에서
한 쪽의 경고가 잘못되고, 한 보드가 다른 것과 호환된다고 주장하지 않는
것이 더 낫습니다. 유의할만한 예외는 싣는 보드로 한 CPU 모듈이 붙여졌을
때 같이, 한 보드가 다른 보드를 싣고 있을 때 입니다.
compatible 값에 대해 하나 더. compatible 프로퍼티 안에 사용되는 어떤
문자열도 그게 나타내는 것에 대해서 문서화되어야만 합니다. compatible
문자열에 대한 문서를 Documentation/devicetree/bindings 안에 추가하세요.
ARM 으로 돌아가서, 각각의 machine_desc에 대해서, 커널은 compatible
프로퍼티 안에 어떤 dt_compat 리스트 항목이 나타나지는 않는지 살펴봅니다.
하나가 그렇다면, 그 machine_desc는 그 머신으로 들어가기 위한 후보가
됩니다. machine_desc 의 전체 테이블을 검색한 후에, setup_machine_fdt()는
각 machine_desc 와 비슷한 compatible 프로퍼티 내의 항목을 기초로
‘가장 호환되는’ machine_desc를 반환합니다. 비슷한 machine_desc을
아무것도 찾지 못했다면, NULL 을 반환합니다.
이 동작 방식 뒤에 숨어있는 이유는 대부분의 경우에 그들이 모두 같은
SoC나 Soc의 같은 계열을 사용한다면, 하나의 machine_desc가 많은 수의
보드를 지원할 수 있다는 관측 때문입니다. 그러나 변함없이 특정 보드는
일반적인 경우에는 쓸데없는 특정 셋업 코드를 필요로 한다는 예외가
있습니다. 특별한 경우들은 일반적인 셋업 코드 안의 문제를 일으킬 수 있는
보드(들)을 위한 명시적인 검사에 의해 처리될 수 있습니다만, 크게 서둘러
그렇게 하는 것은 몇가지 경우보다 더 많아질 경우, 추하고 (또는)
관리할 수 없게 됩니다.
대신에 compatible 리스트는 dt_compat 리스트 안에 “더 적은 compatible”
값을 지정함으로써 일반적인 machine_desc가 광범위한 공용 보드들을 지원할
수 있도록 합니다. 위의 예에서, 일반적인 보드 지원은 “ti,omap3” 또는
“ti,omap3450″과 호환된다고 주장할 수 있습니다.. 원래의 beagleboard 에서
부팅 초기에 특별한 특수 조치 코드가 필요한 버그가 발견된다면, 새로운
machine_desc 는 그 특수 조치를 구현해서 “ti,omap3-beagleboard” 에만
맞게 되도록 추가할 수 있습니다.
PowerPC는 각 machine_desc 로부터 .probe() 를 호출하고, TRUE를 반환하는
첫번째 것이 사용되는 약간 다른 동작 방식을 사용합니다. 그러나, 이 접근법은
compatible 리스트의 우선 순위를 반영하지 않고, 아마도 새로운 아키텍처
지원을 위해서는 피해야 합니다.
2.3 런타임 환경 설정
——————–
대부분의 경우에, 하나의 DT는 펌웨어에서 커널로 데이터를 주고 받을 수
있는 하나밖에 없는 방법이 될 것이고, 그래서 또한 런타임에 initrd 이미지의
위치와 커널 파라미터 문자열 같은 환경 설정 데이터를 넘기는데 사용되기
시작합니다.
이 데이터의 대부분은 /chosen 노드 안에 포함되고, 리눅스가 부팅될 때,
이와 같은 것들이 보일 것입니다:
chosen {
bootargs = “console=ttyS0,115200 loglevel=8”;
initrd-start = <0xc8000000>;
initrd-end = <0xc8200000>;
};
bootargs 프로퍼티는 커널 인자들을 포함하고, initrd-* 프로퍼티들은 initrd
덩이의 주소와 크기를 정의합니다. initrd-end 는 initrd 이미지 이후의
첫번째 주소임에 유의하세요. 그래서 이것은 struct resource의 일반적인
용법과 일치하지 않습니다. chosen 노드는 또한 옵션으로 플랫폼 의존적인
환경 설정 데이터를 위한 임의의 개수의 추가 프로퍼티들을 포함할 수 있습니다.
초기 부팅 동안, 아키텍처 셋업 코드는 페이징이 셋업되기 전에 디바이스
트리를 파싱하는 다른 헬퍼 콜백들과 of_scan_flat_dt()를 여러번 호출합니다.
of_scan_flat_dt() 코드는 디바이스 트리를 스캔하고 초기 부팅 동안 필요한
정보를 추출하는 헬퍼를 사용합니다. 일반적으로 early_init_dt_scan_chosen()
헬퍼는 커널 파라미터를 포함하는 chosen 노드를 파싱하는데,
early_init_dt_scan_root()는 DT 주소 공간 모델을 초기화하는데, 그리고,
early_init_dt_scan_memory()는 사용 가능한 RAM의 위치와 크기를 결정하는데
사용됩니다.
ARM 상에서 setup_machin_fdt() 함수는 맞는 그 보드를 지원하는
machine_desc를 선택한 후에 디바이스 트리의 초기 스캐닝을 책임집니다.
2.4 디바이스 실제 장착
———————-
보드가 식별되고 난 후에, 그리고 초기 환경 설정 데이터가 파싱된 후에는,
커널 초기화가 보통의 방법으로 수행될 수 있습니다. 이 프로세스의 어떤
시점에, unflatten_device_tree()가 더 효율적인 런타임 표현 방식으로 데이터를
변환하기 위해서 호출됩니다. 이것은 또한 ARM 에서의 machine_desc
.init_early(), .init_irq(), 그리고 init_machine() 훅 같은 머신 의존적인
셋업 훅 때 실행되기 시작할 것입니다. 이 절의 나머지는 ARM 구현으로부터의
예제를 사용합니다. 그러나 모든 아키텍처에서 DT를 사용할 때 이와 같은
것들을 잘 수행할 것입니다.
이름에서 추측할 수 있듯이, .init_early() 는 부트 프로세스 내에서 일찍
실행될 필요가 있는 어떤 머신 의존적인 셋업을 위해 사용되고, .init_irq() 는
인터럽트 처리를 셋업하는데 사용됩니다. DT를 사용하는 것은 이들 함수들의
행위를 실제로 바꾸지 않습니다. DT가 제공되면 .init_early() 와 .init_irq()
모두 플랫폼에 대한 추가 데이터를 얻기 위해서 아무 DT 쿼리 함수
(include/linux/of*.h 안의 of_*)나 호출할 수 있습니다.
DT 안에서 가장 흥미로운 훅은 플랫폼에 대한 데이터로 리눅스 디바이스
모델을 실제 장착시키는 주된 책임을 가지는 .init_machine() 입니다.
역사적으로, 이것은 정적인 클럭 구조체, platform_devices, 그리고 보드 지원
.c 파일 안의 다른 데이터의 합을 정의함, 그리고 .init_machine() 안에서
일제히 등록되는 것으로써 임베디드 플랫폼 상에서 구현되었습니다. DT가
사용될 때, 각 플랫폼을 위한 하드 코딩된 정적 디바이스들 대신, 디바이스의
리스트가 DT를 파싱함으로써 얻어질 수 있고, 디바이스 구조체들을 동적으로
할당할 수 있습니다.
가장 간단한 경우는 .init_machine() 이 그냥 platform_devices 뭉치를 등록할
책임만을 가지고 있을 때 입니다. 한 platform_device 는 리눅스에서 하드웨어에
의해 찾을 수 없는 메모리 또는 I/O 매핑된 디바이스, 그리고 ‘복합적인’ 또는
‘가상의’ (이들 이후에는 또 다른) 디바이스로 사용되는 하나의 개념입니다.
DT 에서는 ‘플랫폼 디바이스’ 용어가 없는 반면, 플랫폼 디바이스는 대충 그
트리의 루트에 있는 디바이스 노드와 간단한 메모리 매핑된 버스 노드들의 자식에
해당합니다.
지금이 예제를 펼쳐 볼 좋은 시간인 것 같네요. 여기 NVIDIA Tegra 보드에 대한
디바이스 트리의 일부가 있습니다.
/{
compatible = “nvidia,harmony”, “nvidia,tegra20”;
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
chosen { };
aliases { };
memory {
device_type = “memory”;
reg = <0x00000000 0x40000000>;
};
soc {
compatible = “nvidia,tegra20-soc”, “simple-bus”;
#address-cells = <1>;
#size-cells = <1>;
ranges;
intc: interrupt-controller@50041000 {
compatible = “nvidia,tegra20-gic”;
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >;
};
serial@70006300 {
compatible = “nvidia,tegra20-uart”;
reg = <0x70006300 0x100>;
interrupts = <122>;
};
i2s1: i2s@70002800 {
compatible = “nvidia,tegra20-i2s”;
reg = <0x70002800 0x100>;
interrupts = <77>;
codec = <&wm8903>;
};
i2c@7000c000 {
compatible = “nvidia,tegra20-i2c”;
#address-cells = <1>;
#size-cells = <0>;
reg = <0x7000c000 0x100>;
interrupts = <70>;
wm8903: codec@1a {
compatible = “wlf,wm8903”;
reg = <0x1a>;
interrupts = <347>;
};
};
};
sound {
compatible = “nvidia,harmony-sound”;
i2s-controller = <&i2s1>;
i2s-codec = <&wm8903>;
};
};
.init_machine() 때, Tegra 보드 지원 코드는 이 DT를 살펴보고, 어떤 노드를
platform_devices 로 생성해야 할 지를 결정할 필요가 있을 것입니다.
그러나, 이 트리를 살펴보고, 즉시 어떤 종류의 디바이스가 각 노드로
표현된 것인지는 한 노드가 한 디바이스를 표현한 것이 전부일 지라도
명확하지 않을 것입니다. /chosen, /aliases, 그리고 /memory 노드는
디바이스를 나타내지 않는(아마 분명히, 메모리는 디바이스로 고려될 수
있겠지만) 정보를 전달하기 위한 노드들 입니다. /soc 노드의 자식들은
메모리 매핑된 디바이스지만, codec@1a 는 i2c 디바이스이고, sound 노드는
디바이스가 아니지만, 그보다는 다른 디바이스들이 오디오 서브 시스템을
만들기 위해서 함께 연결되어 있다고 표현합니다. 저는 이 보드 설계에
매우 익숙하기 때문에 각 디바이스가 무엇인지 압니다만, 커널은 어떻게
이 노드들로 무엇을 해야 할 지 알 수 있을까요?
그 트릭은 커널이 트리의 루트에서 시작하고, ‘compatible’ 프로퍼티를 가진
노드들을 살피는 겁니다. 첫째, 일반적으로 ‘compatilbe’ 프로퍼티를 가진
어떤 노드는 어떤 종류의 디바이스를 표현한다고 가정하고, 둘째, 그 트리의
루트에 있는 어떤 노드는 직접 프로세서 버스에 붙거나, 또는 다른 방식으로
설명할 수 없는 기타 시스템 디바이스라고 가정할 수 있습니다. 각 트리
노드에 대해, 리눅스는 차례차례 platform_driver 로 향하게 될
platform_device 를 할당하고 등록합니다.
왜 이들 노드를 위해 platform_device 를 사용하는 것이 안전한 가정일까요?
글쎄요, 리눅스가 디바이스를 모델링하는 방법에서, 거의 모든 bus_types 는
그 디바이스들이 버스 컨트롤러의 자식이라고 가정합니다. 예를 들면,
각 i2c_client 는 i2c_master 의 한 자식입니다. 각 spi_device 는 SPI 버스의
한 자식이고요. 유사하게 USB, PCI, MDIO, 기타도 그렇습니다. 같은 계층 구조는
DT에서도 역시 I2C 디바이스 노드들은 오직 I2C 버스 노드의 한 자식으로만
나타나는 데서 찾을 수 있습니다. SPI, MDIO, USB. 기타도 동일합니다. 부모
디바이스의 특정 타입을 필요로 하지 않는 디바이스는 오직 리눅스
/sys/devices 트리의 바닥에서 행복하게 살 platform_devices(그리고,
amba_devices, 이후에 나올 다른 것들)입니다. 그래서 한 DT 노드가 그 트리의
루트 노드라면, 정말로 아마도 그것은 하나의 platform_device로 등록되는 것이
최선입니다.
리눅스 보드 지원 코드는 그 트리의 루트에 있는 디바이스를 찾기 시작하기
위해서 platform_populate(NULL, NULL, NULL, NULL) 를 호출합니다. 그 트리의
루트로부터 시작할 때, 시작 노드(첫번째 NULL), 부모 struct device(마지막
NULL)을 줄 필요가 없고, 우리는 매치 테이블을 (아직) 사용하고 있지 않기
때문에, 그 파라미터들은 모두 NULL 입니다. 오직 디바이스를 등록할 필요가
있는 한 보드를 위해서, .init_machine() 은 of_platform_populate() 함수를
위해서를 제외하면 완전히 텅 빌 수 있습니다.
Tegra 예제에서, 이것이 /soc 와 /sound 노드의 이유입니다. 그러나 SoC
노드의 자식에 대해서는 뭘까요? 그들도 플랫폼 디바이스로 등록되어야만
하지 않을까요? 리눅스 DT 지원에서, 자식 디바이스를 위한 일반적인 동작은
그 부모의 디바이스 드라이버에 의해서 드라이버 .probe() 때 등록되는
것입니다. 그래서 i2c 버스 디바이스 드라이버는 각 자식 노드를 위한
i2c_client 를 등록할 것이고, SPI 버스 드라이버는 그 spi_device 자식을
등록할 것이고, 유사하게 다른 bus_types도 그럴 겁니다. 이 모델에 따라
드라이버는 SoC 노드로 바인드하고, 그 자식들 각 노드를 간단히
platform_devices로 등록하도록 작성될 수 있습니다. 보드 지원 코드는
SoC 디바이스를 할당하고 등록할 것이고, (이론적인) SoC 디바이스
드라이버는 SoC 디바이스로 바인드할 수 있고, 그 .probe() 훅 안에서
soc/interrupt-controller, /soc/serial, /soc/i2s, 그리고 /soc/i2c 를 위한
platform_devices 를 등록합니다. 쉽죠, 어때요?
실제로, 더 많은 platform_devices 처럼 어떤 platform_devices의 자식을
등록하는 것은 일반적인 패턴으로 나타납니다. 그리고 그 디바이스 트리 지원
코드는 그를 반영하고 위의 예제를 더 간단하게 만듭니다.
of_platform_populate() 의 두번째 인자는 of_device_id 테이블이고, 그 테이블
안의 한 항목과 매치되는 어떤 노드는 또한 그 등록된 자식 노드를 얻을
것입니다. Tegra 의 경우에 그 코드는 이것처럼 볼 수 있습니다:
static void __init harmony_init_machine(void)
{
/* … */
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
“simple-bus” 는 ePAPR 1.0 스펙 안에 간단한 메모리 매핑된 버스를 나타내는
한 프로퍼티로 정의됩니다. 그래서 of_platform_populate() 코드는
simple-bus 호환 노드는 언제나 가로지를 것임을 그저 가정하도록 작성될 수
있습니다. 그러나, 우리는 한 인자를 그 안으로 넣을 수 있어서 보드 지원
코드는 언제나 그 기본 동작을 오버라이드할 수 있습니다.
[i2c/spi/기타 자식 디바이스 추가에 대한 논의가 추가될 필요가 있음]
부록 A: AMBA 디바이스
———————
ARM Primecells 들은 하드웨어 찾기와 전력 관리를 위한 지원을 포함하는
ARM AMBA 버스에 붙는 특정 종류의 디바이스입니다. 리눅스에서,
struct amba_device 와 amba_bus_type 은 Primecell 디바이스를 표현하는데
사용됩니다. 그러나, 약간 성가신 것은 ABMA 버스 상의 모든 디바이스가
Primecells은 아니고, 리눅스를 위해 amba_device 와 platform_device
인스턴스 둘 다 같은 버스 세그먼트의 형제가 되는 것이 일반적입니다. 
DT를 사용할 때, 이것은 platform_device 또는 amba_device 중에 어느 하나로
각 노드를 등록해야 하는지 결정해야만 하기 때문에 of_platform_populate()
에 문제를 만듭니다. 이것은 불행히 그 디바이스 생성 모델이 약간
복잡합니다. 그러나 그 해결책은 너무 깊이 퍼져 있어서 나타나지 않습니다.
만약 “arm,amba-primecell”과 호환되는 한 노드가 있으면,
of_platform_populate() 는 그것을 platform 디바이스 대신 amba_device 로
등록할 것입니다.

[Linux:Kernel] 레귤레이터 드라이버 인터페이스

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

Documentation/power/regulator/regulator.txt

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

레귤레이터 드라이버 인터페이스

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

레귤레이터 드라이버 인터페이스는 비교적 간단하고, 레귤레이터 드라이버가

그들의 서비스들을 코어 프레임워크에 등록하도록 디자인되었습니다.

등록

====

드라이버들은 레귤레이터를 다음 호출로 등록할 수 있습니다 :-

struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
const struct regulator_config *config);

이것은 그 레귤레이터 수용능력과 동작들을 레귤레이터 코어에 등록할 것입니다.

레귤레이터들은 다음 호출로 등록을 해제할 수 있습니다 :-

void regulator_unregister(struct regulator_dev *rdev);

레귤레이터 이벤트

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

레귤레이터들은 이벤트들(예를 들면, 과열, 저전압, 기타)을 컨슈머 드라이버로

다음 호출을 통해 보낼 수 있습니다 :-

int regulator_notifier_call_chain(struct regulator_dev *rdev,
 unsigned long event, void *data);

[Linux:Kernel] 레귤레이터 머신 드라이버 인터페이스

이 문서의 저작권은 GPL license를 따릅니다(This document is released under the GPL license).
Documentation/power/regulator/machine.txt
번역: 양정석 <dasomoli@gmailREMOVETHIS.com>
레귤레이터 머신 드라이버 인터페이스
===================================
레귤레이터 머신 드라이버 인터페이스는 보드/머신 의존적인 초기화 코드가
레귤레이터 서브 시스템을 설정하도록 의도되었습니다.
다음 머신을 생각해봅시다 :-
  레귤레이터-1 -+-> 레귤레이터-2 –> [컨슈머 A @ 1.8 – 2.0V]
                |
                +-> [컨슈머 B @ 3.3V]
                
컨슈머 A 와 B 를 위한 드라이버는 그들의 전원 공급 제어에 따라 그에 맞는
레귤레이터에 맵핑되어야만 합니다. 이 맵핑은 각 레귤레이터를 위한
struct regulater_consumer_supply 생성에 의한 머신 초기화 코드 안에 담겨 있을
수 있습니다.
struct regulator_consumer_supply {
        const char *dev_name;   /* consumer dev_name() */
        const char *supply;     /* consumer supply – e.g. “vcc” */
};
예를 들면, 위의 머신을 위해서는
static struct regulator_consumer_supply regulator1_consumers[] = {
{
        .dev_name       = “dev_name(consumer B)”,
        .supply         = “Vcc”,
},};
static struct regulator_consumer_supply regulator2_consumers[] = {
{
        .dev    = “dev_name(consumer A”),
        .supply = “Vcc”,
},};
이 것은 레귤레이터-1을 ‘Vcc’ 공급원으로 컨슈머 B를 위해 맵핑하고,
레귤레이터-2를 ‘Vcc’ 공급원에 컨슈머 A를 위해 맵핑합니다.
각 레귤레이터 파워 도메인을 위한 제약 사항들은 바로 struct regulator_init_data를
정의함으로써 등록될 수 있습니다. 이 구조체는 또한 컨슈머를 그들의 공급
레귤레이터로 맵핑합니다 :-
static struct regulator_init_data regulator1_data = {
        .constraints = {
                .name = “Regulator-1”,
                .min_uV = 3300000,
                .max_uV = 3300000,
                .valid_modes_mask = REGULATOR_MODE_NORMAL,
        },
        .num_consumer_supplies = ARRAY_SIZE(regulator1_consumers),
        .consumer_supplies = regulator1_consumers,
};
그 name 필드는 다른 레귤레이터들을 위한 공급원들의 설정을 위해, 그리고
로그 기록과 다른 분석 출력 결과를 위한 용도를 위해서 그 보드를 실제로
설명하는 것으로 셋팅되어야 합니다. 보통 그 회로도 내의 공급 선로를 위한
이름이 좋습니다. name이 주어지지 않으면 서브 시스템이 하나를 선택할 것입니다.
레귤레이터-1은 레귤레이터-2로 전력을 공급합니다. 레귤레이터-1이 컨슈머 A가
그 공급원(레귤레이터-2)을 켤 때 켜질 수 있도록 이 관계는 그 코어에 반드시
등록되어야 합니다. 그 공급 레귤레이터는 아래의 supply_regulator 필드에 의해
셋팅됩니다:-
static struct regulator_init_data regulator2_data = {
        .supply_regulator = “Regulator-1”,
        .constraints = {
                .min_uV = 1800000,
                .max_uV = 2000000,
                .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
                .valid_modes_mask = REGULATOR_MODE_NORMAL,
        },
        .num_consumer_supplies = ARRAY_SIZE(regulator2_consumers),
        .consumer_supplies = regulator2_consumers,
};
마지막으로, 레귤레이터 디바이스들이 일반적인 관례대로 등록되어야만 합니다.
static struct platform_device regulator_devices[] = {
{
        .name = “regulator”,
        .id = DCDC_1,
        .dev = {
                .platform_data = &regulator1_data,
        },
},
{
        .name = “regulator”,
        .id = DCDC_2,
        .dev = {
                .platform_data = &regulator2_data,
        },
},
};
/* register regulator 1 device */
platform_device_register(&regulator_devices[0]);
/* register regulator 2 device */
platform_device_register(&regulator_devices[1]);

[Linux:Kernel] 리눅스 전압과 전류 레귤레이터 프레임워크

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


Documentation/power/regulator/overview.txt


리눅스 전압과 전류 레귤레이터 프레임워크

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

이것에 관하여

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

이 프레임워크는 전압과 전류 레귤레이터를 제어하기 위한 표준 커널 인터페이스를

제공하기 위해서 디자인 되었습니다.

그 의도는 시스템으로 하여금 전력을 절약하고 더 긴 배터리 수명을 위해 동적으로

레귤레이터의 전원 출력을 제어할 수 있도록 하는 데 있습니다. 이 것은 (전압 출력을

제어 가능한 곳에서)전압 조절 장치와 (전류 제한이 제어 가능한)전류 제어, 둘 다

적용합니다.

(C) 2008  Wolfson Microelectronics PLC.

저자: Liam Girdwood <lrg@slimlogic.co.uk>

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

용어

====

이 문서 안에서는 몇몇 용어가 사용됩니다:-

  o 레귤레이터   – 다른 디바이스로 전력을 공급하는 전자 장치.

                   어떤 것들은 그들의 출력 전압과 (또는) 전류를 제어할 수 있는

                   데 반해 대부분의 레귤레이터는 그들의 출력을 켜고 끌 수 있습니다.

                   입력 전압 -> 레귤레이터 -> 출력 전압

                   

  o PMIC         – 전력 관리 칩(Power Management IC). 한 IC는 여러개의 레귤레이터와

                   종종 다른 서브 시스템을 포함합니다.

  o 컨슈머       – 레귤레이터에 의해 전력이 공급되는 전자 장치.

                   컨슈머는 두가지 타입으로 분류할 수 있습니다:-

                   

                   정적: 컨슈머는 그 공급 전압이나 전류 제한을 바꾸지 않습니다.

                   그저 그 전원 공급을 켜거나 끄는 것만을 필요로 합니다. 그 공급

                   전압은 하드웨어, 부트로더, 펌웨어나 커널 보드 초기화 코드에

                   의해서 결정됩니다.

  o 파워 도메인  – 레귤레이터, 스위치의 출력 전원 또는 다른 파워 도메인에 의한

                   그 입력 전원이 공급되는 전자 회로.

                   

                   그 공급 레귤레이터는 스위치(들) 뒤에 있을 것입니다. 예를 들면,

                   

                   레귤레이터 -+-> 스위치-1 -+-> 스위치-2 –> [컨슈머 A]

                               |             |

                               |             +-> [컨슈머 B], [컨슈머 C]

                               |

                               +-> [컨슈머 D], [컨슈머 E]

                

                   저것은 하나의 레귤레이터와 세 개의 파워 도메인입니다:

                   

                   도메인 1: 스위치-1, 컨슈머 D와 E.

                   도메인 2: 스위치-2, 컨슈머 B와 C.

                   도메인 3: 컨슈머 A.

                   

                   그리고 이것은 “공급자들” 관계를 나타냅니다:

                   

                   도메인-1 –> 도메인-2 –> 도메인-3.

                   

                   하나의 파워 도메인은 다른 레귤레이터들에 의해 전원이 공급되는

                   레귤레이터들을 갖을 것입니다. 예를 들면,

                   

                   레귤레이터-1 -+-> 레귤레이터-2 -+-> [컨슈머 A]

                                 |

                                 +-> [컨슈머 B]

                                 

                   이 것은 우리에게 두 개의 레귤레이터와 두 개의 파워 도메인을 줍니다:

                   

                   도메인 1: 레귤레이터-2, 컨슈머 B

                   도메인 2: 컨슈머 A

                   

                   그리고 하나의 “공급자들” 관계:

                   

                   도메인-1 –> 도메인-2

  o 제약 사항    – 제약 사항은 성능과 하드웨어 보호를 위한 전원 레벨을 정의하는데

                   사용되고는 합니다. 제약 사항은 세 개의 레벨이 존재합니다:

                   

                   레귤레이터 레벨: 이것은 레귤레이터 하드웨어 동작 파라미터에

                   의해서 정의되고, 레귤레이터 데이터 시트 내에서 정해집니다.

                   예를 들면,

                   

                     – 전압 출력은 800mV -> 3500mV 범위 안 입니다.

                     – 레귤레이터 전류 출력 제한은 20mA @ 5V 아니면 10mA @10V 입니다.

                     

                   파워 도메인 레벨: 이것은 커널 레벨 보드 초기화 코드에 의해서

                   소프트웨어 내에서 정의됩니다. 그것은 파워 도메인을 특정 전원

                   범위로 제약하는데 사용되곤 합니다. 예를 들면,

                   

                     – 도메인-1 전압은 3300mV

                     – 도메인-2 전압은 1400mV -> 1600mV

                     – 도메인-3 전류 제한은 0mA -> 20mA.

                     

                   컨슈머 레벨: 이것은 컨슈머 드라이버가 동적으로 전압이나 전류 제한

                   레벨을 셋팅함에 의해서 정의됩니다.

                   

                   예를 들면, 컨슈머 백라이트 드라이버가 전류 증가를 위해 5mA 에서

                   10mA 로 LCD 광도 증가를 위해 요청을 합니다. 이 것은 다음과 같은

                   레벨을 통해 진행됩니다 :-

                   

                   컨슈머: LCD 밝기를 증가할 필요가 있다. 밝기 테이블(컨슈머 드라이버는

                   같은 레퍼런스 디바이스 상에서를 기초로 여러 다른 개인 설정을 사용하기도

                   한다) 안에서 살펴보고 다음 전류 mA 값을 요청하라.

                   

                   파워 도메인: 새로운 전류 제한이 이 도메인과 시스템 상태(예를 들면,

                   배터리 전원, USB 전원)를 위한 동작 제한들 내에 있는가

                   

                   레귤레이터 도메인: 새로운 전류 제한이 입력/출력 전압을 위한 레귤레이터

                   동작 파라미터 내에 있는가

                   

                   만약 그 레귤레이터가 모든 제약사항 테스트를 동과하면 새로운 레귤레이터

                   값이 적용됩니다.

디자인

======

프레임워크는 SoC 기반의 디바이스들을 대상으로 하고 디자인되었습니다만, SoC가

아닌 디바이스들과도 관련이 있고, 다음 네가지 인터페이스에 따라 나뉩니다:-

   1. 컨슈머 드라이버 인터페이스

      이것은 컨슈머 드라이버가 레귤레이터를 (클럭 atm으로 할 수 있는 것 같이)

      얻거나 내려 놓을 수 있고, 전류 제한, 모드, 켜고 끄기, 전압을 읽고/셋팅할

      수 있다는 것에서 커널 클럭 인터페이스와 비슷한 API 를 사용합니다. 컨슈머

      에게 그 공급 전압과 전류 제한의 완전한 제어를 허용하여야 합니다. 또한

      사용 중이 아니면 꺼져서 드라이버들이 전원 제어를 위한 레귤레이터 없이

      시스템 안에서 재사용될 수 있도록 합니다.

      

        Documentation/power/regulator/consumer.txt 를 보세요.

        

   2. 레귤레이터 드라이버 인터페이스

      이것은 레귤레이터 드라이버가 그들의 레귤레이터를 등록하고, 그 코어에

      동작을 제공할 수 있도록 합니다. 또한 레귤레이터 이벤트를 클라이언트에게

      퍼뜨리기 위한 노티파이어 호출 체인을 가집니다.

      

        Documentation/power/regulator/regulator.txt 를 보세요.

        

   3. 머신 인터페이스

      이 인터페이스는 머신 의존적인 코드를 위해서 존재하고, 각 레귤레이터를

      위한 전압/전류 도메인의 (제약사항과 함께) 생성을 가능하도록 합니다.

      버그가 있는 클라이언트 드라이버에 의한 과전압 또는 과전류에 따른

      디바이스 손상을 막는 레귤레이터 제약사항을 제공할 수 있습니다. 또한

      어떤 레귤레이터가 다른 것들에 의해 공급되는지를 나타내는 (클럭 트리와

      비슷한) 레귤레이터 트리의 생성을 하도록 합니다.

      

        Documentation/power/regulator/machine.txt 를 보세요.

        

   4. 유저스페이스 ABI.

      그 프레임워크는 또한 많은 유용한 전압/전류/동작모드 데이터를 유저스페이스에

      sysfs를 통해 드러냅니다. 이것은 디바이스 전원 소비와 상태를 들여다 보는데

      사용될 수 있습니다.

      

        Documentation/ABI/testing/sysfs-class-regulator 를 보세요.

[Linux] scnprintf()

리눅스 커널은 scnprintf 라는 함수를 제공하는데, 이 함수는 snprintf의 일종이라고 볼 수 있다.
snprintf 는 C99 표준에 의해서 버퍼에 실제로 쓰여진 길이를 리턴하지 않고, 쓰여지고자 했던 길이를 리턴하도록 되어 있다. 예를 들어 다음과 같은 소스 코드가 있다면,

#include <stdio.h>

int main(void)
{
        char buffer[10] = { 0, };
        int output = 0;

        output = snprintf(buffer, sizeof(buffer), “%ld”, 1234567890123l);
        printf(“buffer: %s, output: %d\n”, buffer, output);

        return 0;
}

대부분 생각하는 출력은 아마도 “buffer: 123456789, output:9” 와 같을텐데, 이 소스 코드에 해당하는 프로그램은 다음과 같이 output으로 원래 찍으려고 했었던 수의 출력 길이인 13을 출력한다.

dasomoli@dasomoli-ubuntu:~/src/snprintf$ ./a.out
buffer: 123456789, output: 13

그래서 커널은 snprintf 말고도 scnprintf 함수를 제공한다.

요즘은 Device driver의 제어를 위해 ioctl 함수보다는 sysfs 를 이용하는 추세인데, 이를 위한 sysfs의 show 함수에서는 scnprintf를 사용하도록 하고 있다(Documentation/filesystems/sysfs.txt).

참고 : http://lwn.net/Articles/69419/

[Linux] ioctl을 대체하는 unlocked_ioctl

기존 device driver를 제어하기 위한 방법 중 하나였던 ioctl이 2.6.36 커널부터 unlocked_ioctl 로 대체되었다.
ioctl과 unlocked_ioctl의 차이점은 ioctl이 BKL(Big Kernel Lock)로 보호되었다면, unlocked_ioctl은 BKL이 없다. 따라서 Preemptible 하게 되었으므로, ioctl의 동시성에 대해서 driver 스스로 보호하여야 한다.
driver의 제어를 위해서 ioctl보다는 sysfs를 이용하는 방향으로 가고 있는 듯 하다(http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-May/001852.html).

compat_ioctl은 64비트 시스템에서 32비트 프로세스가 ioctl을 부를 때를 위해서 만들어졌다.

참고 : http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-May/001851.html