Jak mam sprawdzić, którego obiektu blob drzewa urządzeń (plik dtb) używam?

Pracuję z TS-4900, wbudowanym „komputerem w module” podłączonym do płyty bazowej z systemem Yocto Linux. Do uruchomienia używa U-Boota i podobno na podstawie modelu płyty głównej wybiera odpowiedni plik dtb do uruchomienia, a jeśli nie uda mu się zlokalizować właściwego, wraca do „ogólnego” dla mojego modułu.

Ale jak / gdzie to określa właściwą? Jak mogę ustalić, który plik .dtb został użyty, lub ustawić, którego należy użyć?

Poniżej znajdują się komunikaty rozruchowe 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...)

Spóźniłem się z tym, ale wdrożyłem ten skrypt i zajmę się nim każdy, kto znajdzie to za pomocą wyszukiwarki internetowej.

Ten komputer na module można umieścić na prawie dowolnym gotowym modelu TS lub niestandardowej płycie bazowej, a my chcieliśmy, aby działał automatycznie bez konieczności dostosowywania używanego drzewa urządzeń. Posiadamy 8-wejściowy rejestr przesuwny na dowolnej płycie nośnej z unikalnym identyfikatorem płyty podstawowej. W TS-8550 jest to 0x13. http://wiki.embeddedarm.com/wiki/TS-4900#Baseboard_ID

Tak więc w U-Boot bbdetectpolecenie, które dodaliśmy, odczytuje GPIO podłączone do tego rejestru przesuwnego i ustawia zmienną środowiskową $ baseboardid. U-Boot najpierw spróbuje załadować drzewo urządzeń specyficzne dla płyty głównej /boot/imx6${cpu}-ts4900-${baseboardid}.dtb. Jeśli nie uda się go znaleźć, użyje drzewa rezerwowego w /boot/imx6${cpu}-ts4900.dtb. Ten drugi plik ma rozsądne ustawienia domyślne, które będą działać na dowolnej płycie przewoźnika. TS-8550 nie potrzebuje płyty nośnej specyficznej dla płyty bazowej, więc wraca do standardowego drzewa urządzeń i kontynuuje uruchamianie.

Aby odpowiedzieć na twoje pierwotne pytanie,

cat /proc/device-tree/model

Wszystkie nasze drzewa urządzeń będą miały nieco inny model w drzewie urządzeń.
Na przykład bezpieczną rezerwą jest:

• „Systemy technologiczne i.MX6 Quad TS-4900 (Domyślne drzewo urządzeń)”

Lub płyta nośna TS-TPC-8390 z określonym drzewem urządzeń:

• „Systemy technologiczne i.MX6 Quad TS-4900 (TS-TPC-8390)”

Gdy U-Boot wykonuje polecenie rozruchu, podaje adres pamięci jądra i adres pamięci obiektu blob drzewa urządzeń. Dlatego przed tym poleceniem musi załadować te pliki do pamięci. W oparciu o dostarczone wiadomości widzimy, że nie udało się załadować dwóch plików z karty eMMC / SD:

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

Możliwe, że albo te pliki po prostu nie były obecne, ich ścieżka jest niepoprawna lub nieprawidłowe urządzenie: partycja została przekazana do polecenia ładowania U-Boot. W każdym razie polecenie nie powiedzie się. W tym momencie wydaje się, że bootloader próbuje załadować „domyślne” drzewo urządzeń - prawdopodobnie przechowywane na tym samym nośniku co sam bootloader.

Aby dowiedzieć się dokładnie, co się dzieje, musisz zatrzymać proces rozruchu w programie ładującym i uzyskać dostęp do wiersza polecenia U-Boot. Stąd możesz wprowadzić:

printenv

Spowoduje to wydrukowanie zmiennych środowiskowych U-boot. Wiele z tych zmiennych odwołuje się do innych zmiennych. Niektóre z tych zmiennych są często wykonywane podobnie jak skrypty, więc możesz zobaczyć skrypty rozruchowe, skrypty ładowania jądra i fdt itp. Aby ustalić sekwencję rozruchową, poszukaj zmiennej o nazwie bootcmd (lub coś podobnego). Zwykle jest to ostatecznie uruchamiane podczas uruchamiania. Będziesz musiał prześledzić sekwencję rozruchową od tego miejsca za pomocą wielu zmiennych, ale powinieneś zobaczyć, gdzie używane są polecenia load, aby załadować FDT do pamięci. Jeśli chcesz opublikować dane wyjściowe printenv , możemy dokładnie określić zastosowaną tutaj logikę.