Embedded Linux - cơ chế để triển khai các bản cập nhật firmware?

Question

Tôi đang xem xét phát triển dự án Yocto cho một dự án Linux nhúng (một ứng dụng công nghiệp) và tôi có một vài câu hỏi cho những người có kinh nghiệm với Linux nhúng nói chung - Yocto trải nghiệm tiền thưởng. Chỉ cần để có được một ý tưởng về những gì đang được thường được thực hiện trong bản cập nhật firmware.

Tôi có một vài yêu cầu, đó là xác thực, một giao thức truyền thông an toàn, một số loại khôi phục nếu bản cập nhật không thành công. Ngoài ra, nếu có một cách để dần dần phát hành các bản vá trên các hạm đội của các thiết bị thì đó cũng sẽ là thú vị như tôi muốn tránh các thiết bị bricked trong lĩnh vực này.

Làm thế nào để bạn triển khai các bản cập nhật/bản vá lỗi cho các thiết bị hiện trường - và mất bao lâu để phát triển nó? Có những cân nhắc nào khác mà tôi đang bỏ sót không?

Answer 1

Nếu bạn có đủ bộ nhớ flash, bạn có thể thực hiện các thao tác sau. Tạo hai phân vùng giống nhau, một cho hệ thống trực tiếp, một cho bản cập nhật. Hãy để hệ thống kéo hình ảnh được cập nhật lên một phương thức bảo mật và ghi nó trực tiếp vào phân vùng khác. Nó có thể đơn giản như cắm vào ổ flash, với ổ cắm USB phía sau một tấm khóa (bảo mật vật lý), hoặc sử dụng ssh/scp với các khóa người dùng và máy chủ thích hợp. Hoán đổi các phân vùng với sfdisk hoặc chỉnh sửa cài đặt của bộ nạp khởi động chỉ nếu hình ảnh được tải xuống và ghi chính xác. Nếu không, thì không có gì xảy ra, chương trình cơ sở cũ tồn tại và bạn có thể thử lại sau. Nếu bạn cần phát hành dần dần, sau đó cho phép khách hàng chọn một hình ảnh dựa trên byte cuối cùng của địa chỉ MAC của họ. Tất cả điều này có thể được thực hiện với một vài shellscripts đơn giản trong một vài giờ. Hoặc một vài ngày với thực sự kiểm tra nó :)

Answer 2

Mặc dù bạn chắc chắn có thể sử dụng rpm, deb hoặc ipk để nâng cấp, cách ưa thích của tôi (ít nhất là từ nhỏ đến kích thước hợp lý) là có hai hình ảnh được lưu trữ trên flash và chỉ cập nhật hình ảnh rootfs hoàn chỉnh.

Hôm nay tôi có thể xem xét meta-swupdate nếu tôi bắt đầu làm việc với Linux nhúng bằng cách sử dụng OpenEmbedded/Yocto Project.

Những gì tôi đã sử dụng cho bản thân mình và nhiều khách hàng là một cái gì đó như thế này:

• Một container nâng cấp tập tin đó là một tarball gồm một tarball (sau đây gọi là tập tin nâng cấp), MD5SUM của tệp nâng cấp và thường là chữ ký gpg.
• Tập lệnh cập nhật được lưu trữ trong hình ảnh đang chạy. Tập lệnh này chịu trách nhiệm giải nén vùng chứa bên ngoài của tệp nâng cấp, xác minh tính chính xác của tệp nâng cấp bằng md5sum và thường để xác minh chữ ký mã hóa (thường dựa trên gpg). Nếu tệp cập nhật vượt qua các thử nghiệm này, tập lệnh cập nhật sẽ tìm kiếm tập lệnh nâng cấp bên trong tệp cập nhật và thực thi điều này.
• Kịch bản nâng cấp bên trong tệp cập nhật thực hiện nâng cấp thực tế, tức là viết lại hình ảnh không chạy, trích xuất và viết lại hạt nhân và nếu các bước này thành công, hãy hướng dẫn bộ tải khởi động sử dụng hạt nhân và hình ảnh mới thay vì hiện đang chạy hệ thống.

Lợi ích của việc có tập lệnh thực hiện nâng cấp thực tế bên trong tệp nâng cấp, là bạn có thể làm bất cứ điều gì bạn cần trong tương lai chỉ bằng một bước. Tôi đã thực hiện các hình ảnh nâng cấp đặc biệt để nâng cấp FW của các modem đính kèm hoặc trích xuất một số thông tin chẩn đoán bổ sung thay vì thực hiện nâng cấp thực tế. Sự linh hoạt này sẽ được đền bù trong tương lai.

Để làm cho hệ thống đáng tin cậy hơn, bộ tải khởi động sử dụng tính năng khởi động, có thể là số lần khởi động và nếu số này vượt quá ngưỡng, ví dụ 3, bộ tải khởi động chọn khởi động ảnh khác (như hình ảnh được cấu hình để được khởi động được coi là bị lỗi). Điều này đảm bảo rằng hình ảnh bị hỏng hoàn toàn, hình ảnh được lưu trữ khác sẽ tự động được khởi động.

Rủi ro chính với lược đồ này là bạn nâng cấp lên hình ảnh có cơ chế nâng cấp bị hỏng. Thông thường, chúng tôi cũng thực hiện một số loại cơ chế phục hồi trong bộ nạp khởi động, sao cho bộ nạp khởi động có thể reflash một hệ thống hoàn toàn mới; mặc dù cơ chế cứu hộ này thường có nghĩa là phân vùng dữ liệu (được sử dụng để lưu trữ cấu hình, cơ sở dữ liệu, vv) cũng sẽ bị xóa. Đây là một phần cho an ninh (không rò rỉ thông tin) và một phần để đảm bảo rằng sau khi hoạt động cứu hộ này trạng thái hệ thống sẽ hoàn toàn được biết đến với chúng tôi. (Đó là một lợi ích lớn khi điều này được thực hiện bởi một kỹ thuật viên thiếu kinh nghiệm ở xa).

Answer 3

@Anders answer hoàn toàn exaustive và rất tốt. Điều duy nhất tôi có thể thêm như một gợi ý để bạn là để suy nghĩ về một số điều:

• Có ứng dụng của bạn một kết nối internet/USB/thẻ SD để lưu trữ một hoàn rootfs mới? Làm việc với Linux nhúng không giống như viết firmware 128K trên Cortex M3 ..
• Người dùng cuối cùng của bạn có khả năng thực hiện cập nhật không?
• Ứng dụng của bạn có được cài đặt trong khu vực có thể truy cập được điều khiển từ xa không?

Khoảng thời gian bạn cần phát triển giải pháp hoàn chỉnh/mạnh mẽ/ổn định không phải là một câu hỏi đơn giản, nhưng ghi chú là điểm then chốt của ứng dụng tác động đến cảm giác thị trường của ứng dụng của bạn. Đặc biệt là trong những ngày đầu/tháng triển khai đầu tiên, nơi thường được gửi thông tin cập nhật để sửa lỗi nhỏ/lớn tuổi trẻ.