DEVICE TREES, OVERLAYS AND PARAMETERS
오번역이 있을수 있습니다.
잘못된 곳을 알려주시면 수정하도록 하겠습니다. ^^
Raspberry Pi's latest kernels and firmware, including Raspbian and NOOBS releases, now by default use Device Tree (DT) to manage some resource allocation and module loading. This change is to alleviate the problem of multiple drivers contending for system resources, and to allow HAT modules to be auto-configured.
라즈베리안과 NOOBS릴리즈를 포함하여 라즈베리파이의 최신 커널과 펌웨어는 기본적으로 특정한 리소스 할당과 모듈 로딩을 관리하기 위한 디바이스 트리(DT)를 기본적으로 사용한다. 이러한 변화는 시스템 리소스에 대해 경합하는 여러 드라이버의 문제를 해소하고 HAT 모듈을 자동으로 구성 할 수 있도록 한다.
The current implementation is not a pure Device Tree system - there is still board support code that creates some platform devices - but the external interfaces (I2C, I2S, SPI), and the audio devices that use them, must now be instantiated using a Device Tree Blob (DTB) passed to the kernel by the loader (start.elf).
현재 구현은 순수 디바이스 트리 시스템이 아니고 어떤 플렛폼 디바이스를 만드는 보드 지원 코드이다. 외부 인터페이스(I2C,I2C,SPI)와 그것을 사용하는 오디오 디바이스는 로더(start.elf)에 의해 커널로 연결되는 Device Tree Blob(DTB)를 이용해서 인스턴스화 해야 한다.
The main impact of using Device Tree is to change from everything on, relying on module blacklisting to manage contention, to everything off unless requested by the DTB. In order to continue to use external interfaces and the peripherals that attach to them, you will need to add some new settings to your config.txt. See Part 3 for more information, but in the meantime here are a few examples:
디바이스 트리를 사용하는 주요 효과는 경합을 관리하기 위한 모듈 블렉리스팅에 의존 하는 모든 것을 실행하는 것으로부터 DTB에 의해 요청하지 않는 경우, 해제하는 것 까지 변경하는 것이다. 외부 인터페이스와 그들에 연결되어 있는 주변장치를 사용하는 것을 계속하기 위해서는 새로운 설정을 config.txt.에 추가해야 한다. 추가적인 정보를 위해서는 Part 3 를 참고하라, 그러나 여기서는 약간의 예를 제시한다.
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment one of these lines to enable an audio interface
#dtoverlay=hifiberry-amp
#dtoverlay=hifiberry-dac
#dtoverlay=hifiberry-dacplus
#dtoverlay=hifiberry-digi
#dtoverlay=iqaudio-dac
#dtoverlay=iqaudio-dacplus
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Uncomment this to override the defaults for the lirc-rpi module
#dtparam=gpio_out_pin=16
#dtparam=gpio_in_pin=17
#dtparam=gpio_in_pull=down
PART 1: DEVICE TREES
A Device Tree (DT) is a description of the hardware in a system. It should include the name of the base CPU, its memory configuration, and any peripherals (internal and external). A DT should not be used to describe the software, although by listing the hardware modules it does usually cause driver modules to be loaded. It helps to remember that DTs are supposed to be OS-neutral, so anything which is Linux-specific probably shouldn't be there.
디바이스 트리(DT)는 시스템의 하드웨어에 대한 설명이다. 베이스 CPU의 이름, 메모리 환경설정, 그리고 주변장치(내부와 외부)을 포함한다. DT는 하드웨어 모듈 목록에 의해 드라이버 모듈을 로딩되도록 하지만 소프트웨어를 설명하는 것으로 사용되어져서는 안된다. 그것은 DT들이 OS중립적이라는 것을 기억하는 데 도움이되며, 그래서 어떤 것은 리눅스 규격에는 없다.
A Device Tree represents the hardware configuration as a hierarchy of nodes. Each node may contain properties and sub nodes. Properties are named arrays of bytes, which may contain strings, numbers (big-endian), arbitrary sequences of bytes, and any combination thereof. By analogy with a filesystem, nodes are directories and properties are files. The locations of nodes and properties within the tree can be described using a path, with slashes as separators and a single slash (/) to indicate the root.
디바이스 트리는 노드의 계층으로서 하드웨어 구성을 나타낸다. 각 노드는 속성들과 서브 노드들을 담고 있다. 속성들은 문자열, 숫자들(빅인디언), 임의의 바이트 시퀀스,등 특정 조합으로 되어 있다. 파일 시스템과 유사하여 노드들은 디렉토리이고 속성들은 파일들이다. 트리내의 노드들의 위치와 속성은 분리 기호이고 루트를 표시하기 위한 싱글 슬래시 (/) 페스를 이용해서 설명된다.
1.1: BASIC DTS SYNTAX (기본 DTS 구문)
[ This section borrows heavily from the elinux wiki ]
Device Trees are usually written in a textual form known as Device Tree Source (DTS) and stored in files with a .dts suffix. DTS syntax is C-like, with braces for grouping and semicolons at the end of each line. Note that DTS requires semicolons after closing braces - think of C structs rather than functions. The compiled binary format is referred to as Flattened Device Tree (FDT) or Device Tree Blob (DTB), and is stored in .dtb files.
디바이스 트리는 보통 Device Tree Source (DTS)로 알려진 텍스트 형태로 쓰여지고, .dts 확장자를 갖는 파일로 저장된다. DTS 구문은 그룹핑을 위한 괄호와 각 라인의 끝에 세미콜론을 갖는 C언어 형태이다. DTS는 괄호를 닫은 후에 세미콜론이 요구된다(C의 함수보다는 구조체로 생각하면 된다.) 컴파일된 바이너리 형식은 Flattened Device Tree (FDT) 또는 Device Tree Blob (DTB)를 참조하면된다. 그리고 .dtb 파일로 저장된다.
The following is a simple tree in the .dts format:
/dts-v1/;
/include/ "common.dtsi";
/ {
node1 {
a-string-property = "A string";
a-string-list-property = "first string", "second string";
a-byte-data-property = [0x01 0x23 0x34 0x56];
cousin: child-node1 {
first-child-property;
second-child-property = <1>;
a-string-property = "Hello, world";
};
child-node2 {
};
};
node2 {
an-empty-property;
a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
child-node1 {
my-cousin = <&cousin>;
};
};
};
/node2 {
another-property-for-node2;
};
This tree contains:
· a required header -- /dts-v1/.
· The inclusion of another DTS file, conventionally named *.dtsi and analogous to a .h header file in C - see An aside about /include/ below.
· a single root node: /
· a couple of child nodes: node1 and node2
· some children for node1: child-node1 and child-node2
· a label (cousin) and a reference to that label (&cousin) - see Labels and References below.
· several properties scattered through the tree
· a repeated node (/node2) - see An aside about /include/ below.
Properties are simple key-value pairs where the value can either be empty or contain an arbitrary byte stream. While data types are not encoded in the data structure, there are a few fundamental data representations that can be expressed in a Device Tree source file.
속성들은 값이 비어 있거나 임의의 바이트 스트림을 포함하는 간단한 키값쌍이다 . 데이터 유형은 테이터 구조로 부호화 되지 않지만 디바이스 트리 파일내에 표현할 수 있는 몇 가지 기본 데이터 표현있다.
Text strings (NUL-terminated) are indicated with double quotes: 텍스트 문자열은(NUL-종료된) 따옴표로 표시된다.
string-property = "a string";
'Cells' are 32-bit unsigned integers delimited by angle brackets: 셀은 32-bit unsigned integers를 꺽쇠괄호로 구분된다.
cell-property = <0xbeef 123 0xabcd1234>;
Arbitrary byte data is delimited with square brackets, and entered in hex: 임의의 바이트 데이터는 대괄호로 구분되고, 16진수로 입력된다.
binary-property = [01 23 45 67 89 ab cd ef];
Data of differing representations can be concatenated together using a comma: 서로 다른 데이터의 표현은 콤마를 이용해서 함께 연결될 수 있다.
mixed-property = "a string", [01 23 45 67], <0x12345678>;
Commas are also used to create lists of strings: 콤마는 문자열 목록을 만들기 위해 사용될 수 있다.
string-list = "red fish", "blue fish";
1.2: AN ASIDE ABOUT /INCLUDE/
The /include/ directive results in simple textual inclusion, much like C's#include directive, but a feature of the Device Tree compiler leads to different usage patterns. Given that nodes are named, potentially with absolute paths, it is possible for the same node to appear twice in a DTS file (and its inclusions). When this happens, the nodes and properties are combined, interleaving and overwriting properties as required - later values override earlier ones.
간단한 텍스트 포함하는 /include/ 지시문 결과는 C언어의 #include 지시문과 같다. 그러나 디바이스 트리 컴파일러의 기능은 다른 사용 패턴으로 연결된다. 노드가 잠재적으로 절대 경로와 이름을 지정하는 점을 감안, 동일한 노드가 DTS파일에 두 번 표시 할 수 있다.(그리고 그것의 inclusions) 이것이 나타났을 때, 노드와 속성은 결합되고 요구되는 속성들을 끼워넣고 덮어쓰기 한다. – 최신 값들이 기존 것을 덮어 씌운다.
In the example above, the second appearance of /node2 causes a new property to be added to the original:
위의 예제에서, /node2 의 두번째 출현은 오리지널에 추가될 새로운 속성이 된다.
/node2 {
an-empty-property;
a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
another-property-for-node2;
child-node1 {
my-cousin = <&cousin>;
};
};
It is thus possible for one .dtsi to overwrite, or provide defaults for, multiple places in a tree.
이것은 .dtsi 를 덮어씌우는 것이 가능하거나 트리의 여러 위치에 기본값을 제공하는 것이 가능하다.
1.3: LABELS AND REFERENCES
It is often necessary for one part of the tree to refer to another, and there are four ways to do this:
트리의 한부분을 서로 참조하는 것이 가끔 필요하고, 4가지 방법이 있다.
1. Path strings ( 경로 문자열 )
Paths should be self-explanatory, by analogy with a filesystem -/soc/i2s@7e203000 is the full path to the I2S device in BCM2835 and BCM2836. Note that although it is easy to construct a path to a property (for example, /soc/i2s@7e203000/status), the standard APIs don't do that; you first find a node, then choose properties of that node.
경로는 파일시스템 유추에 의해 따로 설명이 필요 없어야 한다. -/soc/i2s@7e203000 는 BCM2835와 BCM2836의 I2S의 전체경로이다. 비록 속성에 대한 경로를 구축하기는 쉽지만(예를 들어 /soc/i2s@7e203000/status) 표준 API는 그렇게 하지 않는다; 먼저 노드를 찾고, 다음에 그 노드의 속성을 선택한다.
2. Phandles(??)
A phandle is a unique 32-bit integer assigned to a node in its phandleproperty. For historical reasons, you may also see a redundant, matchinglinux,phandle. phandles are numbered sequentially, starting from 1; 0 is not a valid phandle. They are usually allocated by the DT compiler when it encounters a reference to a node in an integer context, usually in the form of a label (see below). References to nodes using phandles are simply encoded as the corresponding integer (cell) values; there is no markup to indicate that they should be interpreted as phandles, as that is application defined.
Phandle은 phandle 속성 노드에 할당된 고유의 32-bit 정수이다. 역사적 이유로, 중복해서 볼 수 있으며 linux,phandle에 연결된다.?? Phandle는 순차적으로 1부터 넘버링되며, ;0으로 시작은 유효하지 않는다. DT 컴파일러가 정수 문맥의 노드를 참조할 때, DT 콘트롤러에 의해 일반적으로 할당되며 보통 라벨의 형식이 된다. Phandles를 이용하여 노드를 참조하는 것은 정수값으로 간단히 부호화된다. 즉 어플리케이션 정의 이기 때문에 phandles로 해석되어야 하는 것을 나타 내기 위해 어떤 표시하는 것이 없다.
3. Labels
Just as a label in C gives a name to a place in the code, a DT label assigns a name to a node in the hierarchy. The compiler takes references to labels and converts them into paths when used in string context (&node) and phandles in integer context (<&node>); the original labels do not appear in the compiled output. Note that labels contain no structure; they are just tokens in a flat, global namespace.
C에서 레이블이 단지 코드에 위치의 이름을 주는 것 처럼, DT 레이블은 계층내 노드에 이름을 할당한다. 컴파일러는 레이블을 참조 받고, 정수 문맥(<&node>)의 Phandle과 문자열 문맥(&node) 이 사용될 때 그들을 경로로 변환한다.: 원래 레이블은 컴파일 된 출력에 표시되지 않는다.
(참고) 레이블들은 구조체를 담고있지 않으며 그들은 단지 flat(실수형 data?), 글로벌 네임스페이스(전역명칭)로 변환한다.
4. Aliases
Aliases are similar to labels, except that they do appear in the FDT output as a form of index. They are stored as properties of the /aliases node, with each property mapping an alias name to a path string. Although the aliases node appears in the source, the path strings usually appear as references to labels (&node), rather then being written out in full. DT APIs that resolve a path string to a node typically look at the first character of the path, treating paths that do not start with a slash as aliases that must first be converted to a path using the /aliases table.
인덱스의 형태와 같은 FDT 출력으로 나타는 것을 제외하고는 별칭은 레이블과 비슷하다. 별칭 이름과 경로 문자열의 각 속성 맵핑을 갖는 /aliases 노드의 속성으로 저장된다. 비록 별칭 노드가 소스에서 나타나지만 경로 문자열은 전체 기록보다는 보통 레이블 (&node) 참조한다. 일반적으로 경로의 첫 문자를 보는 노드에서 문자열을 해석하는 DT API는 /aliases 테이블을 이용하는 첫번째로 경로를 변환되어야 하는 별칭은 슬레시부터 시작하지 않고 경로를 처리한다.
1.4: DEVICE TREE SEMANTICS (디바이스 트리 의미)
How to construct a Device Tree, and how best to use it to capture the configuration of some hardware, is a large and complex subject. There are many resources available, some of which are listed below, but several points deserve mentioning in this document:
디바이스 트리를 어떻게 설정하고, 어떤 하드웨어의 구성을 캡쳐하는데 그것을 최고로 잘 이용하는 것은 규모가 크고 복잡한 주제이다. 많은 가능한 리소스가 있고 아래 열거된 것중에 몇가지 포인트는 문서내에 언급되는 될것이다.
compatible properties are the link between the hardware description and the driver software. When an OS encounters a node with a compatible property, it looks it up in its database of device drivers to find the best match. In Linux, this usually results in the driver module being automatically loaded, provided it has been appropriately labelled and not blacklisted.
Compatible(호환) 속성들은 하드웨어 설명과 드라이버 소프트웨어 사이를 연결한다. 호환 속성을 갖는 노들을 OS가 만나면, 최상의 매치를 찾기 위해 장치 드라이버의 데이터 베이스에서 찾아 본다. 리눅스에서, 이것은 자동으로 로드되는 디라이버 모듈의 일반적인 결과이며, 블렉리스트되지 않고 적절히 레이블 되는 것을 제공한다.
The status property indicates whether a device is enabled or disabled. If the status is ok, okay or absent, then the device is enabled. Otherwise,status should be disabled, so the device will be disabled. It can be useful to place devices in a .dtsi file with the status set to disabled. A derived configuration can then include that .dtsi and set the status for the devices which are needed to okay.
status 속성은 디바이스의 사용 여부를 나타낸다. 만약 status 가 ok, okay 또는 absent라면 장치는 사용된다. 그렇지않다면, ,status 는 disabled, 되어져야 한다. 장치를 해제하기 위해서는, disabled.로 셋팅된 상태를 갖는 .dtsi 파일에 디바이스(장치)를 배치하는 것이 유용할 수 있다. 유도(파생)된 구성은 .dtsi 에 okay로 장치 상태를 셋팅하는 것을 포함할 수 있다.
Here are some articles about writing Device Trees: (여기 DT 기록에 대한 몇 개의 기사물이 있다.)
PART 2: DEVICE TREE OVERLAYS (디바이스 트리 덮어 씌우기)
A modern SoC (System-on-Chip) is a very complicated device; a complete Device Tree could be hundreds of lines long. Taking that one step further and placing the SoC on a board with other components only makes matters worse. To keep that manageable, particularly if there are related devices that share components, it makes sense to put the common elements in .dtsi files, to be included from possibly multiple .dts files.
최근의 SOC는 매우 복잡한 장치이다. 복잡한 디바이스 트리는 수백 라인이 길이이다. 한단계 더 나아가 다른 구성 요소를 갖는 보드의 SoC를 배치하는 것은 상황을 악화시킨다. 구성 요소를 공유하는 장치가 연계되어 있다면, 일반적으로 .dtsi 파일에 공통 요소를 넣어둘 필요가 있으며, 여러 .dts 파일로부터 포함되도록 할 필요가 있다.
But when a system like Raspberry Pi supports optional plug-in accessories, such as HATs, the problem grows further. Ultimately, each possible configuration requires a Device Tree to describe it, but once you factor in different base hardware (models A, B, A+, and B+) and gadgets only requiring the use of a few GPIO pins that can coexist, the number of combinations starts to multiply rapidly.
그러나 라즈베리파이와 같은 시스템이 HATs와 같은 선택적 플러그인 액세서리를 지원할때는 문제는 더 증가한다. 근본적으로 각각 가능한 구성은 그것을 설명하기 위한 디바이스 트리를 요구한다. 그러나 서로 다른 기본 하드웨어( A,B,A+,B+)와 공존할 수 있는 소수의 GPIO를 사용하는 장치를 고려하면 조합의 수는 급속히 증가한다.
What is needed is a way to describe these optional components using a partial Device Tree, and then to be able to build a complete tree by taking a base DT and adding a number of optional elements. Well, you can, and these optional elements are called "overlays".
부분적인 디바이스 트리를 이용하여 이러한 임의의 구성 요소들을 설명하기 위한 방법이 필요하고, 그리고 나서 임의의 구성 요소와 베이스 DT를 갖는 전체 트리를 구축 할 수 있도록 하기 위함이다. 즉, 이러한 선택적 요소들은 오버레이라고 할 수 있다.
2.1: FRAGMENTS (조각?)
A DT overlay comprises a number of fragments, each of which targets one node and its subnodes. Although the concept sounds simple enough, the syntax seems rather strange at first:
DT 오버레이는 어떤 노드와 하위노드를 대상으로 하는 각각의, 많은 단편들을 포함한다. 개념은 간단하게 들릴지 모르겠지만, 처음에는 구문이 이상해 보인다.
// Enable the i2s interface
/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2708";
fragment@0 {
target = <&i2s>;
__overlay__ {
status = "okay";
};
};
};
The compatible string identifies this as being for BCM2708, which is the base architecture of the BCM2835 part. For the BCM2836 part you could use a compatible string of "brcm,bcm2709", but unless you are targeting features of the ARM CPUs then the two architectures ought to be equivalent, so sticking to "brcm,bcm2708" is reasonable. Then comes the first (and in this case only) fragment. Fragments are numbered sequentially from zero. Failure to adhere to this may cause some or all of your fragments to be missed.
compatible 문자열은 BCM2835 파트의 기본 아키텍쳐인 BCM2708을 정의한다. BCM2836의 경우 “BRCM, bcm2709”의 호환되는 문자열을 사용할 수 있지만, 두 아키텍처가 같아야 하는 ARM CPU의 기능을 타겟으로 하지 않는다면, “brcm, bcm2708”이 합리적이다 다음으로 오는 것이 fragment이다. Fragment는 0부터 순차적으로 번호가 붙여진다. 이것을 준수 하지않으면 당신의 fragment의 전부를 놓칠 수 있는 원인이 된다.
Each fragment consists of two parts: a target property, identifying the node to apply the overlay to; and the __overlay__ itself, the body of which is added to the target node. The example above can be interpreted as if it were written like this:
각 fragment는 두 개의 부분으로 구성된다. : 오버레이에 적용하기 위한 노드를 식별하는 target 속성은 __overlay__ 자체로, 대상 노드에 추가되는 바디에 노드를 식별한다. 위의 예제에서 기록된 것 처럼 해석될 수 있다.
/dts-v1/;
/ {
compatible = "brcm,bcm2708";
};
&i2s {
status = "okay";
};
The effect of merging that overlay with a standard Raspberry Pi base Device Tree (bcm2708-rpi-b-plus.dtb, for example), provided the overlay is loaded afterwards, would be to enable the I2S interface by changing its status to okay. But if you try to compile this overlay, using:
표준 라즈베리파이 기본 장치 트리( 예를 들어 bcm2708-rpi-b-plus.dtb)와 오버레이 병합 효과는, 오버레이가 나중에 로드되는 것이 제공되며, status를 okay 로 변경하여 I2C 인터페이스를 활성화 하는 것이다. 그러나 만약 당신이 이 오버레이를 아래와 같이 컴파일 한다면
dtc -I dts -O dtb -o 2nd.dtbo 2nd-overlay.dts
you will get an error: 에러가 발생할 것이다.
Label or path i2s not found (레이블 또는 경로 i2s를 찾을 수 없다.)
This shouldn't be too unexpected, since there is no reference to the base .dtb or.dts file to allow the compiler to find the i2s label.
Trying again, this time using the original example and adding the -@ option to allow unresolved references:
이것은 역시 예상치 못했던 것으로, 컴파일러는 i2s 레이블를 찾을 수 있도록 베이스 .dtb 또는 .dts 파일에 대한 참조가 없기 때문입니다. 이번에는 위의 예제에 해결되지 않은 참조들을 허가하기 위한 -@ 옵션을 추가해 보자
dtc -@ -I dts -O dtb -o 1st.dtbo 1st-overlay.dts
If dtc returns an error about the third line then it doesn't have the extensions required for overlay work. Run sudo apt-get install device-tree-compilerand try again - this time, compilation should complete successfully. Note that a suitable compiler is also available in the kernel tree as scripts/dtc/dtc, built when the dtbs make target is used:
만약 dtc 가 셋째줄에 대한 오류를 리턴 한다면 오버레이 작업을 위한 요구되는 확장자를 가지고 있지 않다는 것이다. sudo apt-get install device-tree-compiler를 설치하고 다시 시도해라. 이번에는 컴파일을 성공적으로 완료해야 한다.
(참고) 적합한 컴파일러는 dtbs make target이 이용될 때 만들어진 scripts/dtc/dtc의 커널 트리에서 역시 가능하다.
It is interesting to dump the contents of the DTB file to see what the compiler has generated: 컴파일러가 생성한 것을 보기 위해 DTB 파일의 내용을 덤프해 보면 재밌다.
$ fdtdump 1st.dtbo
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x106 (262)
// off_dt_struct: 0x38
// off_dt_strings: 0xe8
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x1e
// size_dt_struct: 0xb0
/ {
compatible = "brcm,bcm2708";
fragment@0 {
target = <0xdeadbeef>;
__overlay__ {
status = "okay";
};
};
__fixups__ {
i2s = "/fragment@0:target:0";
};
};
After the verbose description of the file structure, there is our fragment. But look carefully - where we wrote &i2s it now says 0xdeadbeef, a clue that something strange has happened. After the fragment is a new node, __fixups__. This contains a list of properties mapping the names of unresolved symbols to lists of paths to cells within the fragments that need patching with the phandle of the target node, once that target has been located. In this case, the path is to the0xdeadbeef value of target, but fragments can contain other unresolved references which would require additional fixes.
파일 구조의 상세한 설명 후에, 우리의 fragment가 있다. 그러나 주의 깊게 봐야 한다. 우리 기록했던 &i2s 는 0xdeadbeef로 표현되어 있어, 무언가 이상한 일이 발생했다는 단서이다. Fragment는 새로운 노드 , __fixups__ 에 있다. 이것은 타깃 노드의 phandle를 갖는 패칭을 필요로 하는 fragments내의 셀의 경로 에 해석되지 않은 심볼의 이름들의 속성 맵핑의 리스트를 담고 있다. 이러한 경우, target의 0xdeadbeef 값이 경로이지만, fragments는 추가 수정이 요구되는 또다른 해석되지 않은 레퍼런스를 포함할 수 있다.
If you write more complicated fragments, the compiler may generate two more nodes: __local_fixups__ and __symbols__. The former is required if any node in the fragments has a phandle, because the programme performing the merge will have to ensure that phandle numbers are sequential and unique, but the latter is the key to how unresolved symbols are dealt with.
Back in section 1.3 it says that "the original labels do not appear in the compiled output", but this isn't true when using the -@ switch. Instead, every label results in a property in the __symbols__ node, mapping a label to a path, exactly like thealiases node. In fact, the mechanism is so similar that when resolving symbols, the Raspberry Pi loader will search the "aliases" node in the absence of a__symbols__ node. This is useful because by providing sufficient aliases, we can allow an older dtc to be used to build the base DTB files.
만약, 더 복잡한 fragments를 작성한다면, 컴파일러는 __local_fixups__ 와 __symbols__ 인 두개 이상의 노드를 만들것이다. 만약 fragments의 어떤 노드가 phandle을 가지고 있다면 전자가 요구될 것이다. 병합을 수행하는 프로그램은 순차적이고 유일한 phandle 번호를 반드시 보장해야 하기 때문이며, 후자는 해석되지 않은 심볼을 어떻게 다루어야 하는지 열쇠가 된다 섹션 1.3으로 돌아가서, “컴파일된 결과에 오리지널 레이블은 나타나지 않는다” “그러나 -@ 스위치를 사용했을 때는 사실이 아니다.” 대신, __symbols__ 노드 특성의 모든 레이블 결과들은, 정확하게 aliases 노드 처럼 경로에 레이블을 맵핑한다. 실제로, 메커니즘은 심볼을 해석할때와 유사하며, 라즈베리파이 로더는 __symbols__ 노드의 부재로 aliases 노드를 검색할 것이다.
UPDATE: The Dynamic Device Tree support in the kernel requires a different format of "local fixups" in the overlay. To avoid problems with old and new styles of overlay coexisting, and to match other users of overlays, the old "name-overlay.dtb" naming scheme has been replaced with "name.dtbo" from 4.4 onwards. Overlays should be referred to by name alone, and the firmware or utility that loads them will append the appropriate suffix. For example:
(업데이트) 커널에서 다이나믹 디바이스 트리 지원은 오버레이에서 "local fixups" 의 다른 형식 을 요구한다. 오버레이의 기존과 신규 스타일이 공존하는 문제를 피하고, 오버레이의 다른 사용자들을 연결하기 위해서 기존 "name-overlay.dtb" 이름 지정 방식은 4.4이후로 계속해서 "name.dtbo"으로 변경되었다. 아래 예를 참조하라.
dtoverlay=awesome-overlay # This is wrong
dtoverlay=awesome # This is correct
2.2: DEVICE TREE PARAMETERS
To avoid the need for lots of Device Tree overlays, and to reduce the need for users of peripherals to modify DTS files, the Raspberry Pi loader supports a new feature - Device Tree parameters. This permits small changes to the DT using named parameters, similar to the way kernel modules receive parameters from modprobe and the kernel command line. Parameters can be exposed by the base DTBs and by overlays, including HAT overlays.
수많은 디바이스 트리 오버레이들이 필요해지는 것을 피하고, 주변장치의 사용자들을 위해 DTS 파일을 수정 하는 요구를 감소시키기 위해, 라즈베리파이 로더는 “새로운 기능 – 디바이스 트리 파라메터”를 지원한다. 이름 붙여진 파라메터를 사용하여 DT에 작은 변화를 허용하며, modprobe 과 커널 명령어 라인으로부터 파라메터들을 받는 커널 모듈 방법과 유사하다. 파라메터들은 베이스 DTBs와, HAT 오버레이를 포함한 오버레이에 의해 노출 될 수 있다.
Parameters are defined in the DTS by adding an __overrides__ node to the root. It contains properties whose names are the chosen parameter names, and whose values are a sequence comprising a phandle (reference to a label) for the target node, and a string indicating the target property; string, integer (cell) and boolean properties are supported.
파라메터들은 __overrides__ 노드를 루트에 추가함으로서 DTS에 정의되어 진다. 이것은 선택된 파라메터 이름들 속성을 담고, 타깃노드를 위한 phandle(레이블을 참조하라)을 순차적으로 구성하는 값과, 타깃 속성을 인식하는 문자열인 문자열, 정수(셀)과 부울 속성이 지원된다.
2.2.1: STRING PARAMETERS
String parameters are declared like this: 문자열 파라메터들은 아래와 같이 선언된다.
name = <&label>,"property";
where label and property are replaced by suitable values. String parameters can cause their target properties to grow, shrink, or be created.
Note that properties called status are treated specially; non-zero/true/yes/on values are converted to the string "okay", while zero/false/no/off becomes"disabled".
여기서 label 과 property 는 적당한 값으로 변경된다. 문자열 파라메터는 타깃 특성이 성장,축소 또는 생성될수 있다. status 로 불리는 속성은 특별히 non-zero/true/yes/on 값들로 취급되어지며, 이값들은 문자열 "okay"로 변환될 수 있으며 zero/false/no/off는 "disabled".로 변환 된다.
2.2.2: INTEGER PARAMETERS
Integer parameters are declared like this:
name = <&label>,"property.offset"; // 8-bit
name = <&label>,"property;offset"; // 16-bit
name = <&label>,"property:offset"; // 32-bit
name = <&label>,"property#offset"; // 64-bit
where label, property and offset are replaced by suitable values; the offset is specified in bytes relative to the start of the property (in decimal by default), and the preceding separator dictates the size of the parameter. In a change from earlier implementations, integer parameters may refer to non-existent properties or to offsets beyond the end of an existing property.
여기서, label, property , offset 는 적당한 값에 의해 변경되어 진다. 오프셋은 속성의(기본적으로 십진수임) 시작에 상응하는 바이트들로 정의되며, 선행 분리기호는 매개변수(파라메터)의 크기를 지시한다. 초기 구현으로부터의 변경시, 정수 파라메터는 존재하지 않는 속성을 참조하거나 존재하는 속성의 오프셋의 뒤를 참조할 수 있다.
2.2.3: BOOLEAN PARAMETERS
Device Tree encodes boolean values as zero-length properties; if present then the property is true, otherwise it is false. They are defined like this:
디바이스 트리는 길이가 없는 속성들의 부울값으로 부호화한다.: 만약 현재의 속성이 true 경우, 그렇치않으면 false이다. 그들은 다음과 같이 정의 된다.
boolean_property; // Set 'boolean_property' to true
Note that a property is assigned the value false by not defining it. Boolean parameters are declared like this:
(참고) 속성이 정의되지 않으므로서 false 값으로 할당된다. 부울 파라메터는 다음과 같이 정의 된다.
name = <&label>,"property?";
where label and property are replaced by suitable values. Boolean parameters can cause properties to be created or deleted.
여기서 label 과 property 는 적절한 값으로 대체된다. 부울 파라메터는 만들거나 삭제하기 위한 속성을 야기할 수 있다.
2.2.4 OVERLAY/FRAGMENT PARAMETERS
The DT parameter mechanism as described has a number of limitations, including the inability to change the name of a node and to write arbitrary values to arbitrary properties when a parameter is used. One way to overcome some of these limitations is to conditionally include or exclude certain fragments.
수많은 제한으로 설명되는 DT 파라메터 원리는, 노드 이름을 변경할 수 없는 것과, 파라메터가 사용될 때, 임의의 속성에 임의의 값들을 기록하는 것을 포함한다. 몇가지 이런 제한을 극복하기 위한 방법은 특정 fragments를 조건부로 포함 또는 제외하는 것이다.
A fragment can be excluded from the final merge process (disabled) by renaming the __overlay__ node to __dormant__. The parameter declaration syntax has been extended to allow the otherwise illegal zero target phandle to indicate that the following string contains operations at fragment or overlay scope. So far, four operations have been implemented:
Fragment는 __overlay__ 노드를 __dormant__.로 이름을 변경하는 것으로 최종 병합 프로세스(사용안 함) 제외 될 수 있다. 파라메터 선언 구문는 fragment 또는 overlay 범위에서 기능을 담고있는 뒤따르는 문자를 나타내기 위한 규정에 맞지 않는 제로 타깃 phandle을 제외하고는 허용할 수 있도록 확장되었습니다. 지금껏, 4개의 동작이 구현되어 있다.
+<n> // Enable fragment <n>
-<n> // Disable fragment <n>
=<n> // Enable fragment <n> if the assigned parameter value is true, otherwise disable it
!<n> // Enable fragment <n> if the assigned parameter value is false, otherwise disable it
Examples:
just_one = <0>,"+1-2"; // Enable 1, disable 2
conditional = <0>,"=3!4"; // Enable 3, disable 4 if value is true,
// otherwise disable 3, enable 4.
The i2c-mux overlay uses this technique. i2c-mux 오버레이는 이 기술을 사용한다.
2.2.5 EXAMPLES
Here are some examples of different types of properties, with parameters to modify them: 여기에 수정할수 있는 파라메터를 갖는 속성의 다른 형태의 예제가 몇 개있다.
/ {
fragment@0 {
target-path = "/";
__overlay__ {
test: test_node {
string = "hello";
status = "disabled";
bytes = /bits/ 8 <0x67 0x89>;
u16s = /bits/ 16 <0xabcd 0xef01>;
u32s = /bits/ 32 <0xfedcba98 0x76543210>;
u64s = /bits/ 64 < 0xaaaaa5a55a5a5555 0x0000111122223333>;
bool1; // Defaults to true
// bool2 defaults to false
};
};
};
fragment@1 {
target-path = "/";
__overlay__ {
frag1;
};
};
fragment@2 {
target-path = "/";
__dormant__ {
frag2;
};
};
__overrides__ {
string = <&test>,"string";
enable = <&test>,"status";
byte_0 = <&test>,"bytes.0";
byte_1 = <&test>,"bytes.1";
u16_0 = <&test>,"u16s;0";
u16_1 = <&test>,"u16s;2";
u32_0 = <&test>,"u32s:0";
u32_1 = <&test>,"u32s:4";
u64_0 = <&test>,"u64s#0";
u64_1 = <&test>,"u64s#8";
bool1 = <&test>,"bool1?";
bool2 = <&test>,"bool2?";
only1 = <0>,"+1-2";
only2 = <0>,"-1+2";
toggle1 = <0>,"=1";
toggle2 = <0>,"=2";
not1 = <0>,"!1";
not2 = <0>,"!2";
};
};
2.2.6: PARAMETERS WITH MULTIPLE TARGETS
There are some situations where it is convenient to be able to set the same value in multiple locations within the Device Tree. Rather than the ungainly approach of creating multiple parameters, it is possible to add multiple targets to a single parameter by concatenating them, like this:
디바이스 트리내에 여러위치에 같은 값을 입력하는 것이 가능한 편리한 몇가지 상태가 있다. 여러 파라메터를 만드는 어색한 방식보다, 여러 타깃에 그들을 연결하여 하나의 파라메터를 적용하는 것이 가능하다.
__overrides__ {
gpiopin = <&w1>,"gpios:4",
<&w1_pins>,"brcm,pins:0";
...
};
(example taken from the w1-gpio overlay)
Note that it is even possible to target properties of different types with a single parameter. You could reasonably connect an "enable" parameter to a statusstring, cells containing zero or one, and a proper boolean property.
(참고) 이것은 싱글 파라메터를 갖는 다른 형식의 속성들을 대상으로 하는 것도 가능하다. 0,또는 1을 갖는 셀과 적절한 부울 속성의 status 문자열에 적절하게 "enable" 파라메터를 연결할 수 있다.
2.2.7: FURTHER OVERLAY EXAMPLES (추가적인 오버레이 예제들)
There is a growing collection of overlay source files hosted in the Raspberry Pi/Linux GitHub repository here.
라즈베리파이/리눅스 GitHub 저장소에 오버레이 파일의 수집이 계속되고 있는 호스팅이 here.에 있다.
PART 3: USING DEVICE TREES ON RASPBERRY PI
3.1: OVERLAYS AND CONFIG.TXT
On a Raspberry Pi it is the job of the loader (one of the start.elf images) to combine overlays with an appropriate base device tree, and then to pass a fully resolved Device Tree to the kernel. The base Device Trees are located alongside start.elf in the FAT partition (/boot from Linux), named bcm2708-rpi-b.dtb,bcm2708-rpi-b-plus.dtb, bcm2708-rpi-cm.dtb, and bcm2709-rpi-2-b.dtb. Note that Model As and A+s will use the "b" and "b-plus" variants, respectively. This selection is automatic, and allows the same SD card image to be used in a variety of devices.
라즈베리파이에서 로더의 역할은 충분한 베이스 디바이스 트리를 갖는 오버레이들을 조합하는 것이고, 완벽하게 해석된 디바이스 트리를 커널에 연결하기 위함이다. 디바이스 트리는 FAT 파티션(리눅스의 /boot)에 start.elf 와 같이 위치한다. 이름은 bcm2708-rpi-b.dtb,bcm2708-rpi-b-plus.dtb, bcm2708-rpi-cm.dtb, 과 bcm2709-rpi-2-b.dtb 이다.
(참고) 모델 A는 A+, b는 b+의 각각 변종 모델을 갖는다. 이 선택은 자동으로, 그리고 다양한 디바이스가 사용되는 동일한 SD 카드 이미지를 허용한다.
Note that DT and ATAGs are mutually exclusive. As a result, passing a DT blob to a kernel that doesn't understand it causes a boot failure. To guard against this, the loader checks kernel images for DT-compatibility, which is marked by a trailer added by the mkknlimg utility; this can be found in the scripts directory of a recent kernel source tree. Any kernel without a trailer is assumed to be non-DT-capable.
(참고) DT와 ATAG는 상호 배타적이다. 그 결과로, 이해되지 않는 커널에 DT blob를 연결하는 것은 부트 실패를 야기한다. 이를 방지하기 위해, 로더는 mkknlimg 유틸리티에 의해 예고로 추가되는 것에 의해 표시되는 DT-호환성에 대한 커널 이미지를 확인하다; 이것은 최신 커널 소스 트리의 scripts 디렉토리에서 찾을 수 있다. 트레일러가 없는 특정 커널은 non-DT-capable로 가정한다.
A kernel built from the rpi-4.4.y tree (and later) will not function without a DTB, so from the 4.4 releases onwards, any kernel without a trailer is assumed to be DT-capable. You can override this by adding a trailer without the DTOK flag or by putting device_tree= in config.txt, but don't be surprised if it doesn't work. N.B. A corollary to this is that if the kernel has a trailer indicating DT capability thendevice_tree= will be ignored.
Rpi-4.4y 트리(그리고 후속)으로부터 구축한 커널은 4.4 릴리즈 이후에, DTB 없이 작동하지 않으며 트레일러 없는 특정 커널은 DT-capable로 가정한다. Config.txt의 device_tree= 에 넣는 것에 의해, 또는 DTOK 플레그 없는 트레일러를 추가하는 것에 의해 이것을 오버라이드 할 수 있다. 하지만, 만약 그것이 동작하지 않더라도 놀라지 마라. (주의)이에 대한 추론은 만약 커널이 DT 능력을 나타내는 트레일러를 가지고 있다면, device_tree= 는 무시될 것이다.
The loader now supports builds using bcm2835_defconfig, which selects the upstreamed BCM2835 support. This configuration will causebcm2835-rpi-b.dtb and bcm2835-rpi-b-plus.dtb to be built. If these files are copied with the kernel, and if the kernel has been tagged by a recent mkknlimg, then the loader will attempt to load one of those DTBs by default.
로더는 상위 BCM2835 지원을 선택하는 bcm2835_defconfig를 이용해서 구축하는 것을 지원한다. 이 구성은 bcm2835-rpi-b.dtb 와 bcm2835-rpi-b-plus.dtb 가 빌드되게 할 것이다. 만약 이들 파일이 커널에 카피되고, 커널이 최근 mkknlimg에 의해 태그된다면 로더는 기본적으로 이들 DTB중 하나를 로드하는 것을 시도할 것이다.
In order to manage Device Tree and overlays, the loader supports a number of newconfig.txt directives:
디바이스 트리와 오버레이를 관리하기 위해, 로더는 새로운 config.txt 지시들을 지원한다.
dtoverlay=acme-board
dtparam=foo=bar,level=42
This will cause the loader to look for overlays/acme-board.dtbo in the firmware partition, which Raspbian mounts on /boot. It will then search for parameters foo and level, and assign the indicated values to them.
이것은 로더가 Raspbian이 마운트하는 /boot 에 있는 펌웨어 파티션내의 overlays/acme-board.dtbo 를 지켜보는 것을 야기할 것이다. 이것은 파라메터 foo 와 level 을 검색하고 그것들에 표시된 값을 할당할 것이다.
The loader will also search for an attached HAT with a programmed EEPROM, and load the supporting overlay from there; this happens without any user intervention.
로더는 또한 프로그램된 EEPROM을 갖는 추가된 HAT를 위해 검색할 것이고 거기서 지원하는 오버레이를 로드할 것이다. ; 이것은 사용자의 개입없이 발생한다.
There are several ways to tell that the kernel is using Device Tree: 커널이 디바이스 트리를 사용하고 있다는 것을 이야기하기 위한 몇가지 방법이 있다.
- The "Machine model:" kernel message during bootup has a board-specific value such as "Raspberry Pi 2 Model B", rather than "BCM2709".
- Some time later, there may also be another kernel message saying "No ATAGs?" -- this is expected.
/proc/device-tree exists, and contains subdirectories and files that exactly mirror the nodes and properties of the DT.
With a Device Tree, the kernel will automatically search for and load modules that support the indicated, enabled devices. As a result, by creating an appropriate DT overlay for a device, you save users of the device from having to edit/etc/modules; all of the configuration goes in config.txt, and in the case of a HAT, even that step is unnecessary. Note, however, that layered modules such asi2c-dev still need to be loaded explicitly.
디바이스 트리가 있다면, 커널은 지정된, 활성화 장치를 지원하는 모듈을 자동으로 찾고 로드할 것이다. 그 결과로, 장치에 대한 적절한 DT 오버레이를 생성하여, /etc/modules 를 수정해야 하는 것으로부터 장치의 사용자들을 저장할 수 있다.; 모든 설정은 불필요한 단계 조차도 config.txt 와 HAT의 안으로 들어 간다.
(참고) 그러나 i2c-dev와 같은 계층 모듈은 아직 분명하게 로드할 필요가 있다.
The flipside is that because platform devices don't get created unless requested by the DTB, it should no longer be necessary to blacklist modules that used to be loaded as a result of platform devices defined in the board support code. In fact, current Raspbian images ship without a blacklist file.
역설적으로 플렛폼 디바이스는 DTB에 의해 요구되지 않는다면 만들어지지 않기 때문에 보드 지원 코드에 정의된 플렛폼 디바이스의 결과로서 로드 되어 사용되는 블랙리스트 모듈이 이 더 이상 필요없을 것이다. 사실, 현재의 라즈베리안 이미지는 블랙리스트 파일 없이 제공된다.
3.2: DT PARAMETERS
As described above, DT parameters are a convenient way to make small changes to a device's configuration. The current base DTBs support parameters for enabling and controlling the onboard audio, I2C, I2S and SPI interfaces without using dedicated overlays. In use, parameters look like this:
위에서 설명된 것 처럼, DT 파라메터는 디바이스의 설정에서 작은 변경을 만드는 편리한 방법이다. 혀재 기본 DTB는 오디오,I2C,I2S 그리고 SPI 인터페이스를 복잡한 오버레이없이 콘드롤하고 설정할 수 있는 파라메터를 지원한다. 사용에 있서, 파라메터는 다음과 같다.
dtparam=audio=on,i2c_arm=on,i2c_arm_baudrate=400000,spi=on
Note that multiple assignments can be placed on the same line, but ensure you don't exceed the 80-character limit.
(참고) 중복할당이 동일한 라인에 놓여질 수 있다. 그러나 80자를 넘서지 않도록 확실 하라.
A future default config.txt may contain a section like this:
향후 기본config.txt 이 다음과 같은 섹션을 포함할 수 있다.
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
If you have an overlay that defines some parameters, they can be specified either on subsequent lines like this:
만약 특정 파라메터들을 정의한 오버레이를 가지고 있다면 그것들은 다음과 같이 정의되어 있을 수 있다.
dtoverlay=lirc-rpi
dtparam=gpio_out_pin=16
dtparam=gpio_in_pin=17
dtparam=gpio_in_pull=down
or appended to the overlay line like this: 또는 오버레이 라인에 다음처럼 추가 될수 있다.
dtoverlay=lirc-rpi:gpio_out_pin=16,gpio_in_pin=17,gpio_in_pull=down
Note here the use of a colon (:) to separate the overlay name from its parameters, which is a supported syntax variant.
여기서 콜론의 사용은 오버레이 이름과 구문 변경이 지원되는 파라메터를 분리하기 위해서 이다.
Overlay parameters are only in scope until the next overlay is loaded. In the event of a parameter with the same name being exported by both the overlay and the base, the parameter in the overlay takes precedence; for clarity, it's recommended that you avoid doing this. To expose the parameter exported by the base DTB instead, end the current overlay scope using:
다음 오버레이가 로드 될때까지 오버레이 파라메터는 범위에 있다. 기본 오버레이와 오버레이 양쪽에 의해 내보내게 되는 같은 이름을 갖는 파라메터의 경우 오버레이안에 파라메터가 분명하게 먼저 갖기 위해서는 이런 일을 피하는 것을 추천한다. 베이스 DTB 대신에 내보내지는 파라메터를 노출하기위해서, 현재의 오버레이 범위를 다음 명령어를 이용해서 끝내라.
3.3: BOARD-SPECIFIC LABELS AND PARAMETERS
Raspberry Pi boards have two I2C interfaces. These are nominally split: one for the ARM, and one for VideoCore (the "GPU"). On almost all models, i2c1 belongs to the ARM and i2c0 to VC, where it is used to control the camera and read the HAT EEPROM. However, there are two early revisions of the Model B that have those roles reversed.
라즈베리파이 보드는 2개의 I2C 인터페이스를 갖는다. 이들은 보통 나누어지는데, 하나는 ARM에 대해, 하나는 VideoCore(GPU)을 위해서 이다. 거의 모든 모델에서 i2c1 는 ARM에 속하고 i2c0 는 카메라 콘트롤과 HAT EEPROM을 읽기위해 사용되는 VC 속한다. 하지만, 두개의 초기 버전인 Medel B는 반대로 되어 있다.
To make it possible to use one set of overlays and parameters with all Pis, the firmware creates some board-specific DT parameters. These are:
모든 라즈베리파이를 갖는 오버레이와 파라메터의 단일 셋을 사용하는 것이 가능하게 만들기 위해서는 펌웨어가 특정 보드-규격 DT 파라메터를 만들어야 한다. 그것들은 다음과 같다.
i2c/i2c_arm
i2c_vc
i2c_baudrate/i2c_arm_baudrate
i2c_vc_baudrate
These are aliases for i2c0, i2c1, i2c0_baudrate, and i2c1_baudrate. It is recommended that you only use i2c_vc and i2c_vc_baudrate if you really need to - for example, if you are programming a HAT EEPROM. Enabling i2c_vccan stop the Pi Camera being detected.
이들 별칭은 i2c0, i2c1, i2c0_baudrate, i2c1_baudrate 이다. 예를 들어 만약 a HAT EEPROM을 프로그래밍한다면 i2c_vc 과 i2c_vc_baudrate 만을 사용하는 것을 추천한다. i2c_vc을 설정하는 것은 검출된 Pi 카메라를 멈추게 할 수 있다.
For people writing overlays, the same aliasing has been applied to the labels on the I2C DT nodes. Thus, you should write:
오버레이 쓰기 위한 사람을 위해, 동일한 별칭은 I2C DT 노드에 레이블로 적용할 수 있다. 따라서, 다음과 같이 작성해야 한다.
fragment@0 {
target = <&i2c_arm>;
__overlay__ {
status = "okay";
};
};
Any overlays using the numeric variants will be modified to use the new aliases.
변수를 사용하는 특정 오버레이는 새로운 aliases를 이용하여 수정될 것이다.
3.4: HATS AND DEVICE TREE
A Raspberry Pi HAT is an add-on board for a "Plus"-shaped (A+, B+ or Pi 2 B) Raspberry Pi with an embedded EEPROM. The EEPROM includes any DT overlay required to enable the board, and this overlay can also expose parameters.
라즈베리파이 HAT는 플러서 모양의(A+,B+,Pi2B) 임베디드 EEPROM을 갖는 라즈베리파이를 위한 추가 기능 보드이다. EEPROM은 보드를 작동하기 위해 요구되는 특정 DT 오버레이를 포함하고, 이 오버레이는 역시 파라메터를 노출할 수 있다.
The HAT overlay is automatically loaded by the firmware after the base DTB, so its parameters are accessible until any other overlays are loaded, or until the overlay scope is ended using dtoverlay=. If for some reason you want to suppress the loading of the HAT overlay, put dtoverlay= before any other dtoverlay ordtparam directive.
HAT 오버레이는 베이스 DTB후에 펌웨어에 의해 자동으로 로드 되어 진다. 따라서, 다른 오버레이가 로드되거나 오버레이 범위가 dtoverlay=. 를 이용해서 끝날 때 까지 파라메터는 접근할 수 있다. 만약 어떤 이유로 인해서 HAT 오버레이의 로딩을 억제하기 원한다면, 다른 dtoverlay 나 dtparam 을 지정하기 전에 dtoverlay=을 넣어야 한다.
3.5: DYNAMIC DEVICE TREE
As of Linux 4.4, the RPi kernels support the dynamic loading of overlays and parameters. Compatible kernels manage a stack of overlays that are applied on top of the base DTB. Changes are immediately reflected in /proc/device-tree and can cause modules to be loaded and platform devices to be created and destroyed.
리눅스 4.4인 RPi 커널은 오버레이 및 파라메터의 동적로드를 지원한다. 호환된는 커널들은 베이스 DTB의 상단에 적용되는 오버레이의 스텍을 관리한다. 변경사항은 즉시 /proc/device-tree와 모듈과 만들어진 플레폼 디바이스에 로드되어지므로 파괴의 원인이 될 수 있다.
The use of the word "stack" above is important - overlays can only be added and removed at the top of the stack; changing something further down the stack requires that anything on top of it must first be removed.
위의 단어 “stack”의 사용은 중요하다. 오버레이들이 스텍의 상단에서 단지 추가되고 제거 될수 있다.; 스택 아래로 뭔가를 더 변경한다면, 스택의 상단의 무엇가는 제거 되는 것이 요구된다.
There are some new commands for managing overlays: 오버레이를 관리하기 위한 몇 가지 새로운 명령이 있다.
3.5.1 THE DTOVERLAY COMMAND
dtoverlay is a command line utility that loads and removes overlays while the system is running, as well as listing the available overlays and displaying their help information:
dtoverlay 는 시스템이 동작하는 동안 오버레이를 제거하거나 로드하기 위한 명령어 라인 유틸리티이다. 뿐만 아니라 가능한 오버레이와 그것들의 도움말 정보를 목록화 한다.
pi@raspberrypi ~ $ dtoverlay -h
Usage:
dtoverlay <overlay> [<param>=<val>...]
Add an overlay (with parameters)
dtoverlay -r [<overlay>] Remove an overlay (by name, index or the last)
dtoverlay -R [<overlay>] Remove from an overlay (by name, index or all)
dtoverlay -l List active overlays/params
dtoverlay -a List all overlays (marking the active)
dtoverlay -h Show this usage message
dtoverlay -h <overlay> Display help on an overlay
dtoverlay -h <overlay> <param>.. Or its parameters
where <overlay> is the name of an overlay or 'dtparam' for dtparams
Options applicable to most variants:
-d <dir> Specify an alternate location for the overlays
(defaults to /boot/overlays or /flash/overlays)
-n Dry run - show what would be executed
-v Verbose operation
Unlike the config.txt equivalent, all parameters to an overlay must be included in the same command line - the dtparam command is only for parameters of the base DTB.
config.txt 등가와는 다르게, 오버레이에서 모든 파라메터들은 동일한 명령어 라인을 포함해야 한다. dtparam 명령어는 오직 베이스 DTB의 파라메터를 위한 것이다.
Two points to note: 두가지 유의해야 한다.
1. Command variants that change kernel state (adding and removing things) require root privilege, so you may need to prefix the command with sudo.
커널 상태(추가,삭제하는 것)를 변경하는 명령 변수는 루트 권한이 요구된다. 따라서 명령에 sudo. 접두사가 필요할 것이다.
- Only overlays and parameters applied at run-time can be unloaded - an overlay or parameter applied by the firmware becomes "baked in" such that it won't be listed by
dtoverlay and can't be removed.
오직 오버레이와 파라메터가 런타임시 적용하면, 언로드되고 펌웨어에 의해 적용되면 dtoverlay 에 의해 목록화 되지 않고, 제거 되지 않는 그런 “baked-in” 된다.
3.5.2 THE DTPARAM COMMAND
dtparam creates an overlay that has the same effect as using a dtparam directive in config.txt. In usage it is largely equivalent to dtoverlay with an overlay name of -, but there are a few small differences:
dtparam 은 config.txt. 에 직접적으로 dtparam을 사용하는 것과 같은 동일한 효과를 갖는 오버레이를 만든다. 이러한 사용은 dtoverlay 가 – 오버레이 이름을 갖는 거의 동등하지만, 약간의 차이가 있다
1. dtparam will list the help information for all known parameters of the base DTB. Help on the dtparam command is still available using dtparam -h.
dtparam 은 기본 DTB의 모든 알려진 파라메터들을 위한 도움말 정보를 리스트할것이다. Dtparam 명령어의 도움말은 dtparam -h.을 사용하므로서 가능하다.
- When indicating a parameter for removal, only index numbers can be used (not names).
제거하기 위한 파라메터를 나타낼 때, 인덱스 번호(이름이 아님)가 사용된다.
3.5.3 GUIDELINES FOR WRITING RUNTIME-CAPABLE OVERLAYS
This area is poorly documented, but here are some accumulated tips: 이영역은 대략 문서화 되어있지만, 축척된 팁이 있다.
· The creation or deletion of a device object is triggered by a node being added or removed, or by the status of a node changing from disabled to enabled, or vice versa. Beware - the absence of a "status" property means the node is enabled.
디바이스 객체의 제거나 생성은 제거되거나 추가되는 노드에 의해 트리거 되거나 비활성화로부터 활성화(또는 그반대도 마찬가지) 되어지는 변화하는 노드의 상태에 의해 트리거 된다.
(주의) “status” 속성의 부재는 노드가 활성화되는 것을 의미한다.
· Don't create a node within a fragment that will overwrite an existing node in the base DTB - the kernel will rename the new node to make it unique. If you want to change the properties of an existing node, create a fragment that targets it.
베이스 DTB내에 존재하는 노드가 덮어 씌여지는 fragment 내의 노드를 생성하지 말아라. – 커널은 그것을 고유하게 만들기 위해 새노드의 이름을 변경할 것이다. 만약 존재하고 있는 노드의 속성을 변경하고 싶다면 그것을 대상으로 하는 fragment을 생성하라.
- ALSA doesn't prevent its codecs and other components from being unloaded while they are in use. This can lead to kernel exceptions when an overlay is unloaded if a codec is deleted before the card using it. Experimentation found that devices are deleted in the reverse of fragment order in the overlay, so placing the node for the card after the nodes for the components allows an orderly shutdown.
ALSA(Advanced Linux Sound Architecture )는 그들이 사용되는 동안 언로드 되어지는 것으로부터 다른 컴포넌트와 코덱을 막지 않는다. 이것은 카드가 그것을 사용하기 전에 코덱 제거시 오버레이가 언로드 될 때 커널 예외상황을 야기할 수 있다. 오버레이에서 fragment 주문의 역으로 제거되는 디바이스를 실험에서 찾았다. 그래서, 컴포넌트에 대한 노드후에 카드를 위한 노드를 두는 것은 순차적으로 종료하는 것을 허용한다.
3.5.4 CAVEATS (주의 사항)
The loading of overlays at runtime is a recent addition to the kernel, and so far there is no accepted way to do this from userspace. By hiding the details of this mechanism behind commands the aim is to insulate users from changes in the event that a different kernel interface becomes standardised.
동작중 오버레이의 로딩은 커널에 최신 추가이며, 사용자 영역으로부터 이것을 하기위한 허용된 방법이 없다. ??????????
· Some overlays work better at run-time than others. Parts of the Device Tree are only used at boot time - changing them using an overlay will not have any effect.
어떤 오버레이는 다른 것 보다 런타임에 더 잘 작동한다. 디바이스 트리의 파트들은 단지 부팅타임에 사용되어진다. 오버레이를 사용하는 그들을 변경하는 것은 아무런 영향을 주지 않는다.
· Applying or removing some overlays may cause unexpected behaviour, so it should be done with caution. This is one of the reasons it requires sudo.
적용 또는 제거하는 특정 오버레이는 예상하지 못한 상태를 야기할 수 있다. 따라서 주의해서 진행해야 한다. 이유중 하나는 그것이 sudo.를 요구한다는 것이다.
· Unloading the overlay for an ALSA card can stall if something is actively using ALSA - the LXPanel volume slider plugin demonstrates this effect. To enable overlays for sound cards to be removed, the lxpanelctl utility has been given two new options -- alsastop and alsastart -- and these are called from the auxiliary scripts dtoverlay-pre and dtoverlay-post before and after overlays are loaded or unloaded, respectively.
ALSA card에 대한 오버레이의 언로딩은 무언가가 ALSA를 활동적으로 사용한다면 멈추게 할 수 있다. LXPanel 볼륨 슬라이더 플러그인이 이효과를 보여준다. 사운드카드의 오버레이를 제거 할 수 있도록하기 위해 lxpanelctl 유틸리티는 2개의 옵션이 주어진다. alsastop 과 alsastart – 이들은 오버레이들이 각각 로드 또는 언로드 전후 dtoverlay-pre 그리고 dtoverlay-post의 보조 스크립트로부터 호출되어 진다.
· Removing an overlay will not cause a loaded module to be unloaded, but it may cause the reference count of some modules to drop to zero. Runningrmmod -a twice will cause unused modules to be unloaded.
오버레이의 제거는 로드된 모듈을 언로드 되도록 야기하지 않는다. 그러나 이것은 특정 모듈의 참조 횟수를 제로까지 떨어뜨리는 것을 야기할 수 있다. rmmod -a 를 두번 실행하는 것은 사용되지 않는 모듈을 언로드 되도록 한다.
· Overlays have to be removed in reverse order. The commands will allow you to remove an earlier one, but all the intermediate ones will be removed and re-applied, which may have unintended consequences.
오버레이는 역순으로 제거 되어져야만 한다. 명령어는 선행하는 어떤 것을 제거하기 위해 허용하지만, 의도하지 않은 결과를 초래할 수 있는 모든 중간 것들은 제거되거나 다시 적용될것이다.
- Adding clocks under the /clocks node at run-time doesn't cause a new clock provider to be registered, so
devm_clk_get will fail for a clock created in an overlay.
런타임시 /clock 노드 아래에 클럭들을 추가하는 것은 등록되기 위한 새로운 클럭 공급자를 야기하지 않는다 .그래서 devm_clk_get 은 오버레이내에 생성되어진 클럭에 대해 실패할 것이다.
3.6: SUPPORTED OVERLAYS AND PARAMETERS (지원되는 오버레이와 파라메터)
As it is too time-consuming to document the individual overlays here, please refer to the README file found alongside the overlay .dtbo files in /boot/overlays. It is kept up-to-date with additions and changes.
여기서 개별 오버레이의 문서화는 너무 많은 시간이 소요된다. /boot/overlays 의 오버레이 .dtbo 파일과 나란히 있는 README 파일을 참고 바란다.
(참고할 것) /boot/overlays내의 overlay 파일들은 README 파일을 제외하고 모두 *.dtbo(overlay dtb 파일이라는 뜻인듯) 따라서 컴파일되어 있으므로 열어도 소스가 보이지 않음. 보기 위해서는 아래와 같이 개별파일을 변환해야 함
Sudo dtc -I dtb –O dts –o *.dtb /boot/overlays/*.dtbo
PART 4: TROUBLESHOOTING AND PRO TIPS
4.1: DEBUGGING
The loader will skip over missing overlays and bad parameters, but if there are serious errors, such as a missing or corrupt base DTB or a failed overlay merge, then the loader will fall back to a non-DT boot. If this happens, or if your settings don't behave as you expect, it is worth checking for warnings or errors from the loader:
로더는 오버레이를 누락하거나 나쁜 파라메터를 무시할 것이다. 그러나, 누락하거나 또는 베이스 DTB를 손상하거나, 또는 오버레이 통합에 실패하는 것과 같은 중요한 에러가 있다면, 로더는 non-DT boot로 다시 떨어질 것이다. 이것이 발생한다면, 또는 설정이 예상대로 동작하지 않는다면 로더로부터 에러나 경고에 대해서 확인할 필요가 있다.
Extra debugging can be enabled by adding dtdebug=1 to config.txt.
추가 디버깅은 to config.txt에.dtdebug=1 을 추가하여 설정할 수 있다.,
If the kernel fails to come up in DT mode, this is probably because the kernel image does not have a valid trailer. Use knlinfo to check for one, and themkknlimg utility to add one. Both utilities are included in the scripts directory of current Raspberry Pi kernel source trees.
만약 커널이 DT 모드로 들어가는 것이 실패한다면, 이것은 아마도 커널 이미지가 유효한 트레일러를 가지고 있지 않기 때문이다. 그것을 확인하기 위해 knlinfo 사용하고 mkknlimg 유틸리티로 추가하라. 두 가지 유틸리티는 현재의 라즈베리파이 커널 소스 트리의 scripts 디렉토리에 포함되어 있다.
You can create a human-readable representation of the current state of DT like this: 현재 상태의 DT를 사람이 읽을 수 있는 표현 방식으로 만들려면 다음과 같이 하라
dtc -I fs /proc/device-tree
This can be useful to see the effect of merging overlays onto the underlying tree.
이것은 트리 밑으로 오버레이들을 병합하는 효과를 보는데 유용할 수 있다.
If kernel modules don't load as expected, check that they aren't blacklisted in/etc/modprobe.d/raspi-blacklist.conf; blacklisting shouldn't be necessary when using Device Tree. If that shows nothing untoward, you can also check that the module is exporting the correct aliases by searching/lib/modules/<version>/modules.alias for the compatible value. Otherwise, your driver is probably missing either:
만약 커널 모듈이 예상처럼 로드 되지 않는다면, /etc/modprobe.d/raspi-blacklist.conf 에 블랙리스트가 없는지 확인하라.; 블랙리스팅은 디바이스 트리가 사용될 때 필요하지 않다. 별다른 것이 없다면, compatible 값을 위한 /lib/modules/<version>/modules.alias 을 검색하여 확인할 수 있다. 그렇지 않으며, 아마도 드라이버가 다음의 둘중 하나 처럼 없을 것이다.
.of_match_table = xxx_of_match,
or:
MODULE_DEVICE_TABLE(of, xxx_of_match);
Failing that, depmod has failed or the updated modules haven't been installed on the target filesystem.
그것이 실패한다는, depmod 가 실패이거나 업데이트 모듈이 대상 파일 시스템에 설치 되지 않았을 것이다.
4.2: TESTING OVERLAYS USING DTMERGE AND DTDIFF
Alongside the dtoverlay and dtparam commands is a utility for applying an overlay to a DTB - dtmerge. To use it you first need to obtain your base DTB, which can be obtained in one of two ways:
dtoverlay 와 dtparam 명령어를 나란히 DTB에 오버레이를 적용하기 위한 유틸리티이다. - dtmerge. 이것을 사용하기 위해 다음의 두가지 방법중 하나로 먼저 베이스 DTB를 획득할 필요가 있다.
a) generate it from the live DT state in /proc/device-tree: /proc/device-tree 의 라이브 DT 상태로부터 그것을 만들어라.
dtc -I fs -O dtb -o base.dtb /proc/device-tree
This will include any overlays and parameters you have applied so far, either in config.txt or by loading them at runtime, which may or may not be what you want. Alternatively...
이것은 원했거나 원하지 않았거나 Config.txt 이거나 동작중에 그것들을 로딩한 것에 의해 지금까지 적용했던 어떤 오버레이와 파라메터들을 포함할 것이다. 양자택일로….
b) copy it from the source DTBs in /boot. This won't include overlays and parameters, but it also won't include any other modifications by the firmware. To allow testing of all overlays, the dtmerge utility will create some of the the board-specific aliases ("i2c_arm", etc.), but this means that the result of a merge will include more differences from the original DTB than you might expect. The solution to this is to use dtmerge to make the copy:
/boot내의 소스 DTB들로부터 복사하라. 이것은 오버레이와 파라메터들을 포함하지 않을 것이지만, 이것은 또한 펌웨어에 의해 어떤 다른 수정도 포함하지 않을 것이다. 모든 오버레이의 테스트를 허용하기 위해서, dtmetge 유틸리티는 어떤 보드-교유의 별칭(“i2c_arm”, etc)을 생성할 것이지만, 이것은 예상했던것과 원본 DTB로부터 더 차이를 포함하는 병합의 결과를 의미한다. 이것의 해결책은 복사를 만들기 위한 dtmerge를 사용하는 것이다.
dtmerge /boot/bcm2710-rpi-3-b.dtb base.dtb -
(the - indicates an absent overlay name).
- 표시는 부재하는 오버레이 이름을 나타낸다.
You can now try applying an overlay or parameter:
지금 오버레이나 파라메터 적용을 시도할 수 있다.
dtmerge base.dtb merged.dtb - sd_overclock=62
dtdiff base.dtb merged.dtb
which will return:
--- /dev/fd/63 2016-05-16 14:48:26.396024813 +0100
+++ /dev/fd/62 2016-05-16 14:48:26.396024813 +0100
@@ -594,7 +594,7 @@
};
sdhost@7e202000 {
- brcm,overclock-50 = <0x0>;
+ brcm,overclock-50 = <0x3e>;
brcm,pio-limit = <0x1>;
bus-width = <0x4>;
clocks = <0x8>;
You can also compare different overlays or parameters.
역시, 다른 오버레이나 파라메터를 비교할 수 있다.
dtmerge base.dtb merged1.dtb /boot/overlays/spi1-1cs.dtbo
dtmerge base.dtb merged2.dtb /boot/overlays/spi1-2cs.dtbo
dtdiff merged1.dtb merged2.dtb
to get:
--- /dev/fd/63 2016-05-16 14:18:56.189634286 +0100
+++ /dev/fd/62 2016-05-16 14:18:56.189634286 +0100
@@ -453,7 +453,7 @@
spi1_cs_pins {
brcm,function = <0x1>;
- brcm,pins = <0x12>;
+ brcm,pins = <0x12 0x11>;
phandle = <0x3e>;
};
@@ -725,7 +725,7 @@
#size-cells = <0x0>;
clocks = <0x13 0x1>;
compatible = "brcm,bcm2835-aux-spi";
- cs-gpios = <0xc 0x12 0x1>;
+ cs-gpios = <0xc 0x12 0x1 0xc 0x11 0x1>;
interrupts = <0x1 0x1d>;
linux,phandle = <0x30>;
phandle = <0x30>;
@@ -743,6 +743,16 @@
spi-max-frequency = <0x7a120>;
status = "okay";
};
+
+ spidev@1 {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ compatible = "spidev";
+ phandle = <0x41>;
+ reg = <0x1>;
+ spi-max-frequency = <0x7a120>;
+ status = "okay";
+ };
};
spi@7e2150C0 {
4.3: FORCING A SPECIFIC DEVICE TREE
If you have very specific needs that aren't supported by the default DTBs (in particular, people experimenting with the pure-DT approach used by the ARCH_BCM2835 project), or if you just want to experiment with writing your own DTs, you can tell the loader to load an alternate DTB file like this:
만약 기본 DTB에 의해 지원되지 않는 매우 특별한 요구를 가지고 있다면 (특히, 사람들은 ARCH_BCM2835 프로젝트에 사용되는 Pure-DT 방식을 실험), 또는 만약 개인적인 DT를 작성하는 실험을 단지 원한다면, 다음과 같은 교체 DTB 파일을 로드하기 위해 로더에게 요청할 수 있다.
4.4: DISABLING DEVICE TREE USAGE
Since the switch to the 4.4 kernel and the use of more upstream drivers, Device Tree usage is required in RPi kernels. The method of disabling DT usage is to add:
4.4 커널로의 전환과 더 상위 드라이버의 사용 때문에 RPi 커널에 디바이스 트리 사용이 요구된다. DT 사용의 해제 방법은 config.txt 에 다음을 추가하면 된다.
to config.txt. However, if the kernel has a mkknlimg trailer indicating DT capability then this directive will be ignored.
그렇치만, 만약 커널이 DT 능력을 나타내는 mkknlimg 트레일러를 가지고 있다면 이지시는 무시된다.
4.5: SHORTCUTS AND SYNTAX VARIANTS (바로 가기 및 변형 구문)
The loader understands a few shortcuts:
로더는 몇 개의 바로가기를 이해한다.
dtparam=i2c_arm=on
dtparam=i2s=on
can be shortened to:
아래와 같은 변형구문도 가능하다.
(i2c is an alias of i2c_arm, and the =on is assumed). It also still accepts the long-form versions: device_tree_overlay and device_tree_param.
(i2c 는 i2c_arm별칭이고, =on 이 가정된다.). 이것은 역시 device_tree_overlay 와 device_tree_param.등 긴형식의 버전도 여전히 받아들인다.
The loader used to accept the use of whitespace and colons as separators, but support for these has been discontinued for simplicity and so they can be used within parameter values without quotes.
로더는 분리기호로 콜론과 공백의 사용을 수용하지만, 이들에 대한 지원은 단순화를 위해 중단되었다. 그래서 그들은 따옴표(인용부호) 없이 파라메터 변수값 내에서 사용할 수 있다.
(참고)https://www.raspberrypi.org/documentation/configuration/device-tree.md#part3
DOCUMENTATION > CONFIGURATION > DEVICE-TREE
(Data sheet)4343W.pdf
