Làm cách nào để biết blob cây thiết bị (tệp dtb) nào tôi đang sử dụng?

Tôi đang làm việc với TS-4900, một 'Máy tính trên Mô-đun' được cắm vào một ván chân đế, chạy Yocto Linux. Nó sử dụng U-Boot để khởi động, và được cho là dựa trên mô hình của ván chân tường, nó chọn tập tin dtb phù hợp để bắt đầu, và có thể nếu nó không xác định được vị trí bên phải, nó sẽ quay trở lại mô hình 'chung' cho mô-đun của tôi.

Nhưng làm thế nào / ở đâu nó xác định đúng? Làm thế nào tôi có thể biết .dtb nào đã được sử dụng hoặc đặt cái nào sẽ được sử dụng?

Dưới đây là các thông báo khởi động của 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...)

Tôi đến muộn về vấn đề này, nhưng tôi đã triển khai kịch bản này và tôi sẽ giải quyết vấn đề này cho bất kỳ ai tìm thấy điều này bằng công cụ tìm kiếm internet.

Máy tính trên mô-đun này có thể được đặt trên hầu hết mọi giá đỡ TS hoặc bảng chân đế tùy chỉnh và chúng tôi muốn nó tự động hoạt động mà không cần người dùng phải điều chỉnh cây thiết bị được sử dụng. Chúng tôi có một thanh ghi dịch chuyển 8 đầu vào trên bất kỳ bảng vận chuyển cụ thể nào có id duy nhất cho ván chân tường. Trên TS-8550, đây là 0x13. http://wiki.embeddedarm.com/wiki/TS-4900#Baseboard_ID

Vì vậy, trong U-Boot, bbdetectlệnh chúng tôi đã thêm đọc GPIO được kết nối với thanh ghi thay đổi này và đặt biến môi trường $ baseboardid. Trước tiên, U-Boot sẽ cố gắng tải một cây thiết bị cụ thể của baseboard tại /boot/imx6${cpu}-ts4900-${baseboardid}.dtb. Nếu không tìm thấy, nó sẽ sử dụng cây thiết bị dự phòng tại /boot/imx6${cpu}-ts4900.dtb. Tệp sau này có các mặc định lành mạnh sẽ hoạt động trên bất kỳ bảng vận chuyển nào. TS-8550 không cần bảng vận chuyển cụ thể của ván chân tường để nó rơi trở lại cây thiết bị tiêu chuẩn và tiếp tục khởi động.

Để trả lời câu hỏi ban đầu của bạn,

cat /proc/device-tree/model

Tất cả các cây thiết bị của chúng tôi sẽ có một mô hình hơi khác trong cây thiết bị.
Ví dụ, dự phòng an toàn là:

• "Hệ thống công nghệ i.MX6 Quad TS-4900 (Cây thiết bị mặc định)"

Hoặc bảng vận chuyển TS-TPC-8390 với cây thiết bị cụ thể:

• "Hệ thống công nghệ i.MX6 Quad TS-4900 (TS-TPC-8390)"

Khi U-Boot thực thi lệnh khởi động, nó cung cấp địa chỉ bộ nhớ cho kernel và địa chỉ bộ nhớ cho blob cây thiết bị. Do đó, trước lệnh này, nó phải tải các tệp này vào bộ nhớ. Dựa trên các tin nhắn bạn cung cấp, chúng tôi thấy rằng hai tệp không được tải từ thẻ eMMC / SD:

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

Có thể các tệp này đơn giản là không có mặt, đường dẫn của chúng bị sai hoặc thiết bị không chính xác: phân vùng đã được cung cấp cho lệnh tải U-Boot. Trong mọi trường hợp, lệnh thất bại. Tại thời điểm này, có vẻ như bộ tải khởi động cố gắng tải một cây thiết bị "mặc định" - có thể được lưu trữ trên cùng một phương tiện như chính bộ tải khởi động.

Để tìm hiểu chính xác những gì đang xảy ra, bạn sẽ muốn tạm dừng quá trình khởi động tại bộ tải khởi động và truy cập vào dấu nhắc lệnh U-Boot. Từ đây, bạn có thể nhập:

printenv

Điều này sẽ in ra các biến môi trường U-boot. Nhiều trong số các biến này tham chiếu các biến khác. Một số biến này thường được thực thi như tập lệnh, vì vậy bạn có thể thấy tập lệnh khởi động, tập lệnh tải kernel & fdt, v.v. Để tìm ra trình tự khởi động, hãy tìm một biến có tên là bootcmd (hoặc một cái gì đó tương tự). Đây thường là những gì cuối cùng được chạy tại thời điểm khởi động. Bạn sẽ cần phải theo dõi trình tự khởi động từ thời điểm này thông qua nhiều biến, nhưng bạn sẽ thấy các lệnh tải được sử dụng để tải FDT vào bộ nhớ. Nếu bạn muốn đăng đầu ra của printenv , chúng tôi có thể xác định logic chính xác được sử dụng ở đây.