Як дізнатись, який блок пристрою дерева (dtb-файл) я використовую?

Я працюю з TS-4900, вбудованим "Комп'ютером на модулі", підключеним до плінтусу, під керуванням Yocto Linux. Для запуску використовується U-Boot, і нібито, спираючись на модель плінтуса, він вибирає правильний dtb-файл для запуску, і, можливо, якщо не зможе знайти потрібний, він повернеться до «загального» для мого модуля.

Але як / де він визначає правильний? Як я можу визначити, який .dtb використовувався, або встановити, який слід використовувати?

Нижче наводяться повідомлення про завантаження U-Boot.

U-Boot 2014.10-g3ac6ec3 (Jan 29 2015 - 17:20:15)

CPU:   Freescale i.MX6SOLO rev1.1 at 792 MHz
Reset cause: POR
Board: TS-4900
Revision: C
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
SF: Detected N25Q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   using phy at 7
FEC [PRIME]
Press Ctrl+C to abort autoboot in 1 second(s)
(Re)start USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
No storage devices, perhaps not 'usb start'ed..?
Booting from the eMMC ...
** File not found /boot/boot.ub **
** File not found /boot/imx6dl-ts4900-13.dtb **
Booting default device tree
42507 bytes read in 196 ms (210.9 KiB/s)
118642 bytes read in 172 ms (672.9 KiB/s)
ICE40 FPGA reloaded successfully
4609784 bytes read in 337 ms (13 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:   Linux-3.10.17-1.0.0-technologic+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4609720 Bytes = 4.4 MiB
   Load Address: 10008000
   Entry Point:  10008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
EHCI failed to shut down host controller.
   Loading Kernel Image ... OK
   Using Device Tree in place at 18000000, end 1800d60a

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0

(Kernel startup commences...)

Я запізнююсь із цим, але я реалізував цей сценарій, і вирішу його для всіх, хто знайде це за допомогою інтернет-пошукової системи.

Цей комп'ютер на модулі можна поставити майже на будь-який інший ТС або спеціальний плінтус, і ми хотіли, щоб він автоматично працював, не потребуючи коригування дерева пристрою. У нас є 8-вхідний регістр зрушень на будь-якій платі несучої з унікальним ідентифікатором для базової плати. У TS-8550 це 0x13. http://wiki.embeddedarm.com/wiki/TS-4900#Baseboard_ID

Отже, у bbdetectдоданій нам команді U-Boot зчитується GPIO, підключений до цього регістру зрушень, і встановлюється змінна середовище $ baseboardid. U-Boot спочатку спробує завантажити дерево конкретного плінтуса на /boot/imx6${cpu}-ts4900-${baseboardid}.dtb. Якщо його не вдасться знайти, воно використовуватиме дерево резервного пристрою у /boot/imx6${cpu}-ts4900.dtb. У цьому останньому файлі встановлені значні параметри за замовчуванням, які працюватимуть на будь-якій платі оператора. TS-8550 не потребує конкретної плати несучої плати, тому вона повертається до стандартного дерева пристроїв і продовжує завантажуватися.

Щоб відповісти на своє первісне запитання,

cat /proc/device-tree/model

Усі дерева наших пристроїв матимуть дещо іншу модель у дереві пристроїв.
Наприклад, безпечний запасний варіант:

• "Технологічні системи i.MX6 Quad TS-4900 (дерево пристрою за замовчуванням)"

Або плата несучої TS-TPC-8390 з конкретним деревом пристроїв:

• "Технологічні системи i.MX6 Quad TS-4900 (TS-TPC-8390)"

Коли U-Boot виконує команду завантаження, вона надає адресу пам'яті для ядра та адресу пам'яті для блоку дерева пристрою. Тому перед цією командою вони повинні завантажувати ці файли в пам'ять. На основі наданих вами повідомлень ми бачимо, що два файли не вдалося завантажити з eMMC / SD карти:

/boot/boot.ub
/boot/imx6dl-ts4900-13.dtb

Можливо, що або цих файлів просто не було, їх шлях неправильний, або неправильний пристрій: розділ був наданий команді U-Boot load. У будь-якому випадку команда не вдається. У цей момент виявляється, що завантажувач намагається завантажити дерево "за замовчуванням" пристрою - можливо, збережене на тому ж носії, що і сам завантажувач.

Щоб дізнатись, що саме відбувається, вам потрібно зупинити процес завантаження завантажувача та отримати доступ до командного рядка U-Boot. Звідси ви можете ввести:

printenv

Це дозволить роздрукувати змінні середовища U-boot. Багато з цих змінних посилаються на інші змінні. Деякі з цих змінних часто виконуються як сценарії, тому ви можете бачити сценарії завантаження, сценарії завантаження ядра та fdt тощо. Щоб визначити послідовність завантаження, знайдіть змінну під назвою bootcmd (або щось подібне). Це, як правило, те, що в кінцевому рахунку виконується під час завантаження. Вам потрібно буде простежити послідовність завантаження з цієї точки через декілька змінних, але ви повинні побачити, де команди завантаження використовуються для завантаження FDT в пам'ять. Якщо ви хочете опублікувати вихід принтенів , ми можемо визначити точну логіку, яка використовується тут.