2011-04-25 29 views

Trả lời

2

Không có cách nào được xác định để thực hiện việc này. Khi khởi động Linux, u-boot không còn chạy nữa và RAM của nó được khai hoang để sử dụng Linux. Linux thậm chí không biết về khởi động u. Cũng không phải nó đã được khởi động bởi u-boot.

Nếu bạn thực sự muốn làm điều này, cách duy nhất để làm điều đó là thêm phiên bản khởi động u vào dòng lệnh của hạt nhân, viết mã để quét hình ảnh khởi động trong flash cho phiên bản của nó hoặc nastier.

+0

Nếu không có cách nào được xác định để thực hiện việc này, có các cách đáng tin cậy để trích xuất dữ liệu từ flash bạn đã khởi động từ đó. Một cách chống đạn để thực hiện điều này là chuyển phiên bản khởi động u của bạn tới hạt nhân (uboot = blah) và sau đó đọc/proc. Nếu bạn muốn chắc chắn rằng bạn biết chắc chắn phiên bản nào bạn đã khởi động, không chỉ là những gì trên flash. – synthesizerpatel

1

Trong thiết bị của tôi UBoot tự động tạo ra một biến "ver" môi trường có chứa phiên bản của nó:

U-Boot > printenv 
baudrate=115200 
ethact=FEC ETHERNET 
ethaddr=24-db-ad-00-00-08 
bootdelay=3 
bootcmd=bootm fc080000 - fc060000 
bootargs=console=ttyCPM0,115200n8 rdinit=/sbin/init 
stdin=serial 
stdout=serial 
stderr=serial 
ver=U-Boot 2009.03-svn9684 (Mar 08 2010 - 17:08:32) 

Environment size: 253/131068 bytes 
U-Boot > 

tôi không sử dụng fw_printenv, nhưng tôi sẽ tưởng tượng rằng biến này được thông qua cùng là tốt. Có lẽ bạn đã có một cái gì đó tương tự trong hệ thống của bạn?

UPDATE (2012/05/23): tôi thêm fw_printenv để hình ảnh linux của tôi và có thể khẳng định rằng tôi xem "ver" biến:

[[email protected] /]# fw_printenv 
baudrate=115200 
ethact=FEC ETHERNET 
ethaddr=24-db-ad-00-00-08 
stdin=serial 
stdout=serial 
stderr=serial 
ver=U-Boot 2009.03-svn9684 (Mar 11 2010 - 09:43:08) 
bootcmd=bootm fc080000 - fc060000 
bootdelay=3 
bootargs=console=ttyCPM0,115200n8 rdinit=/sbin/init panic=10 mem=32m 
[[email protected] /]# 
+0

Điều này "hoạt động tốt" cho đến khi bạn cập nhật U-Boot của bạn. Sau thời điểm đó và trừ khi bạn thay đổi một số biến môi trường và nói 'lưu' từ dấu nhắc U-Boot, bạn sẽ nhận được phiên bản U-Boot cũ của bạn theo cách này. Đó là vì fw_printenv cung cấp quyền truy cập vào môi trường được lưu trữ, chứ không phải cho môi trường hiện tại (nơi U-Boot mới của bạn sẽ đưa phiên bản của nó). Giải pháp sẽ là kiểm tra U-Boot nếu các giá trị được lưu trữ và hiện tại cho 'ver' khác nhau và tái flash môi trường nếu có, nhưng điều đó cũng có thể mang lại một số hiệu ứng không mong muốn. –

0

Bạn không thể dựa vào fw_printenv nếu bạn muốn biết phiên bản khởi động u.

fw_printenv chỉ tìm phân vùng printenv và kết xuất dữ liệu của nó. Vì vậy, nó là OK cho các biến bình thường, nhưng nó không OK cho biến "ver", đó là năng động, và có giá trị được khởi tạo bởi u-boot khi nó khởi động. Giá trị của biến này không còn sau khi thoát u-boot, trừ khi bạn lưu nó vào môi trường theo cách thủ công.

Ví dụ, trên tàu của tôi, nếu tôi in "ver" biến từ dấu nhắc u-boot:

U-Boot >  printenv ver 
ver=U-Boot 2009.11-00393-g5ca9497-dirty (Nov 26 2012 - 11:08:44) 

Đây là phiên bản thực sự của u-boot, đến từ u-boot của chính nó.

Bây giờ, nếu tôi khởi động hội đồng quản trị của tôi và sử dụng fw_printenv:

[email protected] # fw_printenv | grep ver= 
ver=U-Boot 2009.11-00323-gbcc6e0e (Sep 21 2012 - 11:07:19) 

Như bạn có thể thấy, đó là khác nhau. Bởi vì nó xảy ra mà tôi có một biến "ver" được xác định trong môi trường của tôi. Và nó không phù hợp với phiên bản khởi động u thực sự.

Tất nhiên, tôi có thể quay lại khởi động u, sử dụng "saveenv" để cập nhật giá trị "ver" trong môi trường. Sau đó, hai giá trị sẽ khớp nhau. Nhưng sau đó, tôi nên luôn luôn cập nhật môi trường sau khi thay đổi u-boot.

Vì vậy, kết luận của tôi là sử dụng fw_printenv để có được phiên bản khởi động u chắc chắn không phải là một ý tưởng hay.

1

Cố gắng đọc uboot phiên bản theo cách này: phân vùng uboot

  1. Find, ví dụ.cho MTD thiết bị:

    cat/proc/mtd

  2. Đối với/dev/mtd5:

    cat/dev/mtd5 | hexdump -C -n 64

14

Nếu U-boot nằm ở mtd0, bạn có thể nhận được thông tin phiên bản như sau:

[email protected]:/proc# strings /dev/mtd0 | grep U-Boot  
U-Boot 1.1.4-g1c8343c8-dirty (Feb 28 2014 - 13:56:54) 
U-Boot 
Now running in RAM - U-Boot at: %08lx 
+0

Tôi đã sử dụng phiên bản tương tự này, mở rộng grep để chính xác hơn một chút 'U-Boot [0-9] * \. [0-9] *. * \\ (Build. *)' Thành trở về ít hơn. Điều này có thể được tối ưu hóa nếu bạn có một ý tưởng chung về nơi mà hình ảnh u-boot của bạn sống trên thiết bị flash. Nếu bạn biết thực tế là nó nằm trong megabyte đầu tiên, bạn có thể sử dụng dd để loại bỏ meg dữ liệu đầu tiên trước khi bạn chạy các chuỗi trên đó để tiết kiệm thời gian xử lý. – synthesizerpatel

+0

Cảm ơn. Sử dụng dd để tiết kiệm thời gian xử lý. –

1

Một alternative solution là để đọc các phiên bản trực tiếp từ u-boot tệp nhị phân (thậm chí có thể được nhúng trong tệp hình ảnh chứa các tệp nhị phân khác cũng như trình khởi động giai đoạn đầu tiên) với ví dụ mmcblk0boot0 như phân vùng (thiết bị mmcblk0) bootloader nằm trong:

sudo grep -a --null-data U-Boot /dev/mmcblk0boot0 

Site lưu ý: Có làm việc không chỉ đối với Arch Linux nhưng ví dụ Ubuntu cũng vậy.

Các vấn đề liên quan