Когда стартует образ ядра, имеется всего одна точка входа. Эта точка поддерживает два соглашения о вызове. Сводка интерфейса приведена здесь. Полное описание требований загрузки содержится в документе Documentation/arm/Booting.

Ядро отличает загрузку по ATAGS от загрузки по дереву устройств, путём чтения указателя памяти из r2 и проверки, имеется ли "магический код" (0xd00dfeed) плоского дерева устройств, или же, со смещением 0x4 от адреса в r2 находится значение ATAG_CORE (0x54410001).

Когда стартует образ ядра, имеется всего одна точка входа. Эта точка поддерживает два соглашения о вызове:

Поддержка платы (платформы) заключается не только в опциях конфигурации. Можно построить произвольный набор поддерживаемых плат в одном образе ядра. Ядро будет "знать" какой набор функций используется для заданной платформы на основании содержимого дерева устройств. Таким образом, Вы должны:

Образ ядра может поддерживать множество платформ, но только если особенности платформ одинаковы в архитектуре ядра. Один релиз ядра не может поддерживать конфигурационные опции как для "Book E" так и для классической архитектуры PowerPC.

Здесь есть только одна единственная точка входа в декомпрессор ядра code32_start (точка входа реального режима ведёт в ту же самую 32-битную точку входа, после того, как она переключается в защищённый режим). Эта точка входа поддерживает одно соглашение о вызове, которое описано в Documentation/x86/boot.txt

Физический указатель на блок дерева устройств (определённый в главе II) передаётся посредством запроса setup_data which, начиная с версии протокола 2.09. Тип этого поля опредлён как

#define SETUP_DTB                      2

Это дерево устройств используется как расширение "страницы загрузки" Само по себе оно не рассматривает / разбирает данные, которые уже представлены на странице загрузки. Это включает размер памяти, резервируемые диапазоны, аргументы командной строки или адрес initrd. Она просто содержит информацию, которую невозможно получить иначе, вроде обработки прерываний или списка устройств, подключённых к шине I2C.

Ядру передаётся физический адрес, указывающий на область памяти, в общих чертах описанную в include/linux/of_fdt.h и содержащую структуру boot_param_header:

struct boot_param_header {
        u32     magic;                  /* magic word OF_DT_HEADER */
        u32     totalsize;              /* total size of DT block */
        u32     off_dt_struct;          /* offset to structure */
        u32     off_dt_strings;         /* offset to strings */
        u32     off_mem_rsvmap;         /* offset to memory reserve map   */
        u32     version;                /* format version */
        u32     last_comp_version;      /* last compatible version */
        /* version 2 fields below */
        u32     boot_cpuid_phys;        /* Which physical CPU id we're booting on */
        /* version 3 fields below */
        u32     size_dt_strings;        /* size of the strings block */
        /* version 17 fields below */
        u32	size_dt_struct;		/* size of the DT structure block */
};

Определения констант:

/* Definitions used by the flattened device tree */
#define OF_DT_HEADER            0xd00dfeed      /* 4: version, 4: total size */
#define OF_DT_BEGIN_NODE        0x1             /* Start node: full nam  */
#define OF_DT_END_NODE          0x2             /* End node */
#define OF_DT_PROP              0x3             /* Property: name off,  size, content */
#define OF_DT_END               0x9

Все значения в этом файле заголовков заданы в "big endian" формате, различные поля этого заголовка более точно описаны ниже. Все значения "offset" заданы в байтах от начала заголовка; то есть от физического базового адреса блока дерева устройств.

Так выглядит типичный блок DT (его различные части не обязаны идти в этой последовательности). Адресация идёт сверху вниз:

             ------------------------------
     base -> |  struct boot_param_header  |
             ------------------------------
             |      (alignment gap) (*)   |
             ------------------------------
             |      memory reserve map    |
             ------------------------------
             |      (alignment gap)       |
             ------------------------------
             |                            |
             |    device-tree structure   |
             |                            |
             ------------------------------
             |      (alignment gap)       |
             ------------------------------
             |                            |
             |     device-tree strings    |
             |                            |
      -----> ------------------------------
      |
      |
      --- (base + totalsize)

Само по себе дерево устройст разделяется на два различных блока : блок структур и блок строк. Оба этих блока должны быть выравнены на границу 4 байт.

Для начала, давайте быстро опишем концепцию дерева устройств, до детального рассмотрения формата хранения. В этой главе не даются детали требуемых типов узлов и свойств для ядра, это будет сделано позже, в главе III.

Основные идеи дерева устройств были унаследованы из дерева устройств Open Firmware IEEE 1275. В своей основе, это дерево, состоящее из узлов. Каждый узел имеет два или более именованых свойства. Свойство может иметь или не иметь значения.

Так как это дерево, то какждый узел имеет одно и только одного родителя. Исключение составляет только корневой узел, не имеющий родителя.

Узел имеет два имени. Фактически, имя узла обычно содержится в свойстве типа "name" в списке свойств узла, чьё значение должно быть нуль-терминированной строкой, и обязательно для версий от 1 до 3 определения формата (Как это сделано в Open Firmware). Версия 16 делает это не обязательным, так как оно может быть сгенерировано из имени устройства, определённого ниже.

Мы можем использовать одно "имя устройства" для узлов с одним именем, находящихся на однеом уровне, обычно имя таких узлов состоит из имени узла, знака "@" и последующим адресом устройства, который определяется конкретно для каждого типа шины, к которой подключено это устройство.

Имя устройства не существует само по себе, как свойство, но оно включается в структуру дерева. Типичным является использование представления "пути" в дереве устройств. Фактический формат будет описан ниже более детально.

Обычный код ядра никак не использует формальные адреса устройств (что может быть осуществлено путём выполнения некоторого кода поддержки платы), так что реальным требованием к адресу устройства только то, что имена всех устройств на данном уровне дерева являются уникальными. Узлы, у которых не задан адрес, не могут иметь братьев с таким же именем на этом уровне дерева (Например - /memory или /cpu) могут пропускать адрес устройства в контексте этой спецификации, или использовать адрес по умолчанию "@0". Имя устройства используется для определения полного пути к устройству, который представляет собой конкатенацию имён всех узлов, разделённых знаком "/".

Корневой узел не имеет определённого имени, и не обязан иметь "name", даже если Вы используете версию 3 или более ранний формат. У него так же нет и адреса устройства (нет символа "@" следующего за именем устройства). Именем узла корневого устройства является пустая строка. Полный путь к корневому узлу обозначается "/".

Каждый узел, который на самом деле представляет конкретное устройство, (это узлы, которые являются не просто виртуальными контейнерами для для других узлов, например - "/cpus"), обязаны иметь свойство "compatible", указывающее на конкретное оборудование и необязательный список устройств, с которыми обеспечивается полная обратная совместимость.

Наконец, каждый узел, на который допустимо ссылаться из свойств другого узла, должен иметь свойство "phandle" (указатель) или "linux,phandle". Настоящие реализации Open Firmware предоставляют уникальное значение "phandle", для каждого узла, который включает стартовый код "prom_init()" в свойство "linux,phandle". Однако, это становится не обязательным если напрямую используется плоское дерево устройств. Примером узла, ссылающегося на другой узел посредством "phandle", является набросок дерева прерываний, который будет опсан в следующих версиях этого документа.

Свойство "phandle" является 32-битным значение, которое однозначно идентифицирует узел. Вы вольны использовать любые значения, или систему значений, внутренние указатели, или любые сгенерированные значения, единственное требование заключается в том, что бы Вы обеспечили каждому узлу уникальное значение этого свойства.

Здесь приводится пример простейшего дерева устройств. В этом примере символ "o" обозначает узел, следующий за именем узла устройства. Свойства представлены как имя, за которым следует содержимое этого свойства. "Содержимое" представляется ASCII строкой ( с нулевым завершителем), в то время, как <содержимое> представляет 32-битное значение, заданное в десятичном или шестнадцатиричном формате (определяется префиксом 0x). Различные узлы в этом дереве будут обсуждаться позднее в этой главе. Пока я хочу дать Вам только общий смысл идеи того, как выглядит дерево устройств. Я намереваюсь сохранить свойства "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>

Это дерево - почти минимально возможное. Его достоинство заключается в том, что оно содержит минимальный набор узлов и свойств, требуемых для загрузки ядра; таким образом, оно представляет собой базовую модель информации о корне, процессорах и физической памяти. Оно так же включает в себя некотрую дополнительную информацию, передаваемую через узел /chosen, как в этом примере, тип платформы (бязательно) и аргументы командной строки ядра (опционально).

Свойство /cpus/PowerPC,970@0/64-bit является примером свойства без значения. Все другие свойства имеют значения. Смысл значений свойств #address-cells и #size-cells будет пояснён в главе V, которая точно определяет требования к узлам и свойствам и их содержимому.

Структурой дерева устройств является линеаризованная структура дерева. Токен "OF_DT_BEGIN_NODE" начинает новый узел, а токен "OF_DT_END_NODE" завершает определение узла. Потомки этого узла определяются до завершающего токена "OF_DT_END_NODE" (они являются узлами внутри узла). Токены представляют собой 32-битные значения. Дерево должно заврешаться токеном OF_DT_END.

Здесь Вы видете базовую структуру одного узла:

Таким образом, содержимое узла можно представить как начальный токен, путь, список свойств, список дочерних узлов и завершающий токен. Каждый дочерний узел является полной структурой узла, как это определено выше.

В целях экономии памяти, имена свойств, которые обычно являются избыточными, хранятся в отдельном блоке "strings". Этот блок - просто набор нуль-терминированных строк, для всех имён строк, объединённый в единое целое. Определения свойств дерева устройств в блоке структур содержат смещения от начала блока строк.

Универсальное правило задано в различных документах Open Firmware. Если Вы решите описывать шину посредством дерева устройств и существует описание этой шины в OF, то Вы должны следовать этим спецификациям. Однако ядро не требует, что бы все устройства и шины были описаны в дереве устройств.

Как правило, формат адреса устройства определяется типом родительской шины, на основе свойств #address-cells и #size-cells. Необходимо отметить, что "дедовские" определения свойств #address-cells и #size-cells (т.е. определения в родителе родителя) не наследуются теми узлами, чьи наследники должны задавать эти свойства. Ядро требует, что бы корневой узел имел эти свойства определения формата адреса устройств, прямо подключенных к шине процессора.

Эти два свойства определяют "клетку" ( 'cell') для представления адреса и размера. Любая 'cell' - 32-битное число. Например, если оба свойства содержат значение 2, как в вышеприведённом примере, то это означает, что и адрес и размер состоят из двух клеток, т.е. каждый из них является 64-битным числом (клетки конкатенируются, подразумевается формат big endian format). Другим примером может быть путь Apple в её микропрограммах, где под адрес отводится две клетки и одна - под размер. Большинство 32-битных реализаций должны определять #address-cells и #size-cells как 1, что и означает 32-битное значение. Некоторые 32-битные процессоры допускают адресацию более 32 бит; такие процессоры должны определять #address-cells как 2.

Свойство "reg" всегда задаётся парой типа "address size", в которых количество клеток адреса и размера определяется свойствами #address-cells и #size-cells шины. Если шина поддерживает различные адресные пространства и другие флаги, относящиеся к выделению адресов на данной шине (такие, как например 'prefetchable' и т.д.) то эти флаги обычно добавляются на верхнюю часть физического адреса. Например, физический адрес PCI состоит из трёх клеток. две нижние содеражт сам фактический адрес, в то время, как старшая клетка содержит индикаторы адресного пространства, флаги и номера шины & устройства.

Для тех шин, которые поддерживают динамическое выделение адресов, на практике принято не передавать адреса в "reg" (сохраняя его нулевым), а задавать флаг, указывающий на динамическое выделение адресов и затем устанавливать специальное свойство "assigned-addresses", которое содержит правильно установленный адрес. Подробности можно посмотреть в привязке OF для PCI.

Обычно предпочтительнее использовать шины без динамического выделения адресов и битов адресного пространства, если это отражает Вашу аппаратуру, так как существующие функции разбора адресного пространства ядра будут вынуждены работать за границами. Если Вы определяете тип шины с более сложным адресным форматом, влючающим такие вещи, как биты адресного пространства, Вы должны добавить транслятор шины в файл prom_parse.c в новейшие версии ядра для обслуживания Вашей шины.

Свойство "reg" определяет адреса и размеры ( если #size-cells равно 0) только внутри заданной шины. Для перевода адресов вверх ( адресное пространство шины старшего уровня, или в физические адреса ЦП), все шины должны содержать свойство "ranges". Если это свойство отсутствует на некотором уровне, то подразумевается, что трансляция адресов невозможна, т.е. что регистры не видны на родительской шине. Формат свойства "ranges" для шины представляет собой список:

	  адрес на шине, адрес на родительской шине, размер

"адрес на шине" - формат шины, которую определяет этот узел, для PCI моста это будет PCI адрес. Таким образом (адрес на шине, размер) определяют диапазон адресов для устройств. "адрес на родительской шине" задаёт формат родительской шины, по отношению к этой шине. Например, длч хост-контролера PCI, здесь должен быть адрес ЦП. Для мостов PCI<->ISA здесь будет PCI адрес. Таким образом опеределяется базовый адрес на родительской шине, с которого начинается диапазон мапирования.

Для поддержки новых 64-битных плат, я бы рекомендовал либо формат 2/2, либо формат Apple 2/1, который чуть более компактен, так как размер обычно не превышает 32 бита. Новые 32-битные платы должны использовать формат 1/1, исключая те процессоры, которые поддерживают физическую адресацию более 32 бит, для которых рекомендовано использование формата 2/1.

Alternatively, the "ranges" property may be empty, indicating that the registers are visible on the parent bus using an identity mapping translation. In other words, the parent bus address space is the same as the child bus address space.

В то время, как Open Firmware предоставляет возможность более гибкого использования 8859-1, эта спецификация накладывает более строгие правила. Узлы и свойства должны включать в себя только ASCII символы от 'a' до 'z', от '0' до '9', ',', '.', '_', '+', '#', '?', и '-'. В именах узлов дополнительно разрешается использовать буквы верхнего регистра от 'A' до 'Z' (имена свойств должны быть в нижнем регистре. Тот факт, что производители типа Apple не одобрят это правило, к делу не относится). Кроме того, имена узлов и свойств всегда должны начинаться с символов из диапазона от 'a' до 'z' ( или от 'A' до 'Z' для имён узлов).

Максимальное количество символов в именах узлов или свойств равно 31. Для случая имён узлов, имеется в виду только самая левая часть имени устройства (т.е. настоящее свойство "name"), оно не должно включать адрес устройства, который может выйти за это ограничение.

Здесь описаны все требования, которые предъявляются в настоящее время. Однако, настоятельно рекомнедуется, что бы отображали PCI хост-мосты, как это задокументировано в привязке PCI к Open Firmware, а Ваше дерево прерываний - как задокументровано в спецификации дерева в OF.

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

      00000000 00000000 00000000 80000000
      00000001 00000000 00000001 00000000

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

Любое устройство, являющееся частью SoC, может иметь свой собственный узел внутри узла SOC. Для каждого устройства, которое включено в SOC, свойство адреса устройства представляет смещение адреса для регистров этого устройства, которые мапируются на память, в адресном пространстве родителя. Это адресное пространство родителя определяется свойством "ranges" на верхнем уровне soc узла. Свойство "reg" всех узлов, которые существуют непосредственно под узлом SOC, должно содержать адрес мапирования из дочернего адресного пространства на родительское адресное пространство SoC и размер файла мапируемых регистров этого устро

Для многих устройств, которые могут существовать внутри SoC, имеются заранее определённые спецификации в формате узла дерева устройств. Все дочерние SoC узлы должны следовать этим спецификациям, исключения из этого правила отмечены в этом документе.

Смотри приложение A в качестве примера частичного определения SOC узла для MPC8540.

В настоящее время есть много устройств, которые не имеют стандартного представления, определённого как часть Open Firmware спецификации, главным образом потому, что платы, на которых используются эти SoC устройства, загружаются без использования Open Firmware. Документация по установке для новых устройств должна добавляться в папку Documentation/devicetree/bindings. Эта папка будет расширятся по мере того, как поддержка дерева устройств будет добавляться к всё большему числу SoC устройств.

Устройства, которые генерируют прерывания в одном контроллере прерываний, должны использовать традиционное OF представление, описанное в OF документации по мапированию прерываний.

Каждое устройство, которое генрирует преывания, должно иметь свойство 'interrupt'. Значением этого свойства является произвольное число 'interrupt specifier' значений, которые описывают прерывание или прерывания для данного устройства.

Способ кодирования спецификации прерывания зависит от области прерываний, в которой находится устройство в дереве прерываний. Корень области прерываний описывается значением #interrupt-cells требующем ячеку для хранения 32-битного числа, кодирующего спецификатор прерывания. Смотрите документацию по OF мапированию прерываний для детального ознакомления с этой областью.

Например, установки для контроллера прерываний OpenPIC задаются значением 2 для переменной #interrupt-cells, что означает выделение двух ячеек для кодирования номера прерывания и информации об уровне и смысле этого прерывания. Все дочерние прерывания в области прерываний OpenPIC используют 2 ячейки на прерывание, в их свойствах прерываний.

Установки для шины PCI задают значение #interrupt-cell 1 для кодирования того, ккая именно ножка (INTA,INTB,INTC,INTD) используется.

Свойство interrupt-parent задаётся для установления явной связи между узлом устройства и его родительским прерыванием в дереве прерываний. Значением interrupt-parent является phandle, указывающий на родительский узел.

Если свойство interrupt-parent не опредлено в узле, то его родительское прерывание наследуется через иерархию узло в дереве устройств.

Контроллер прерываний OpenPIC требует 2 ячейки для кодирования информации о прерывании. Первая ячейка задаёт номер прерывания. Вторая ячейка описывает тип чувствительности и уровень прерывания.

Информация о типе чувствительности и уровне прерывания должна кодироваться следующим образом:

ISA PIC interrupt controllers require 2 cells to encode interrupt information. The first cell defines the interrupt number. The second cell defines the sense and level information.

Контроллер прерываний ISA PIC поддерживать коды ISA PIC перечисленные ниже: