Встроенный Linux - механизм развертывания обновлений прошивки?

Я рассматриваю возможность разработки проекта Yocto для встроенного Linux-проекта (промышленного приложения), и у меня есть несколько вопросов для тех, у кого есть опыт работы со встроенным Linux в целом - Yocto обладает бонусом. Просто нужно понять, что обычно делается в обновлениях прошивки.

У меня есть несколько требований: аутентификация, протокол защищенной связи, некоторый тип отката, если обновление не сработало. Кроме того, если есть способ постепенно выпускать патч через флот устройств, это также будет интересно, поскольку я хочу избежать использования кирпичных устройств в поле.

Как вы развертываете обновления/исправления для полевых устройств сегодня - и как долго это нужно для его разработки? Есть ли какие-то другие соображения, которые мне не хватает?

Ответ 1

Хотя вы, конечно, можете использовать rpm, deb или ipk для своих обновлений, мой предпочтительный способ (по крайней мере, для изображений с небольшим размером до разумного размера) состоит в том, чтобы иметь два изображения, хранящиеся на флешке, и обновлять только полные изображения rootfs.

Сегодня я, вероятно, посмотрю мета-swupdate, если я начну работать со встроенным Linux, используя OpenEmbedded/Yocto Project.

То, что я использовал для себя и нескольких клиентов, - это нечто большее:

Файл обновления контейнера, который представляет собой tarball, состоящий из другого tarball (далее называемого файлом обновления), md5sum файла обновления и часто gpg-подпись.
Программа обновления script хранится в запущенном изображении. Этот script отвечает за распаковку внешнего контейнера файла обновления, проверку правильности файла обновления с помощью md5sum и часто проверку криптографической подписи (обычно на основе gpg). Если файл обновления проходит эти тесты, программа обновления script ищет обновление script внутри файла обновления и выполняет это.
Обновление script внутри файла обновления выполняет фактическое обновление, то есть обычно перезаписывает неиспользуемое изображение, извлекает и переписывает ядро, и если эти шаги будут успешными, попросите загрузчик использовать вместо этого новое ядро и изображение текущей системы.

Преимущество использования script, выполняющего фактическое обновление внутри файла обновления, заключается в том, что вы можете делать все, что вам нужно в будущем, за один шаг. Я сделал специальные изображения для обновления, которые обновляют FW подключенных модемов, или которые извлекли некоторую дополнительную диагностическую информацию вместо фактического обновления. Такая гибкость будет в будущем окупаться.

Чтобы сделать систему еще более надежной, пользователи-загрузчики имеют функцию bootcount, которая может содержать количество попыток загрузки, и если это число превышает пороговое значение, например 3, загрузчик выбирает загрузку другого изображения (как изображение, настроенное для загрузки, считается ошибочным). Это гарантирует, что изображение полностью повреждено, другое сохраненное изображение будет автоматически загружено.

Основной риск с этой схемой заключается в том, что вы обновляете изображение, механизм которого не работает. Обычно мы также реализуем какой-то механизм восстановления в загрузчике, так что загрузчик может перепрограммировать совершенно новую систему; хотя этот механизм спасения обычно означает, что раздел данных (используемый для хранения конфигураций, баз данных и т.д.) также будет удален. Это отчасти для обеспечения безопасности (не утечки информации) и отчасти для обеспечения того, чтобы после этой операции по спасению состояние системы было полностью известно нам. (Это большое преимущество, когда это выполняется неопытным техником далеко).

Ответ 2

Если у вас достаточно флеш-памяти, вы можете сделать следующее. Сделайте два идентичных раздела, один для живой системы, другой для обновления. Позвольте системе вытащить обновленное изображение по защищенному методу и записать его непосредственно в другой раздел. Это может быть так же просто, как подключить флэш-накопитель с разъемом USB за заблокированной пластиной (физическая защита) или с помощью ssh/scp с соответствующими хост файлами и ключами пользователя. Перемените разделы с помощью sfdisk или отредактируйте настройку вашего загрузчика только, если изображение загружено и написано правильно. Если нет, то ничего не происходит, старая прошивка продолжает работать, и вы можете повторить попытку позже. Если вам нужны постепенные выпуски, позвольте клиентам выбрать изображение на основе последнего байта своего MAC-адреса. Все это может быть реализовано с помощью нескольких простых shellscripts за несколько часов. Или несколько дней с фактическим тестированием:)

Ответ 3

@Ответ на Anders является полным exaustive и очень хорошим. Единственное, что я могу добавить в качестве предложения для вас, это подумать над некоторыми вещами:

Имеет ли ваше приложение подключение к Интернету/USB/SD-карту для хранения завершить новые rootfs? Работа с встроенным Linux не похожа на прошивку 128K на Cortex M3..
Предоставляет ли ваш конечный пользователь возможность выполнять обновление?
Установлено ли ваше приложение в доступной зоне с дистанционным управлением?

О том, как вам нужно разработать полное/надежное/стабильное решение, - не простой вопрос, а заметки, которые являются ключевым моментом приложения, которое влияет на рыночное чувство вашего приложения. Особенно в первые дни/месяц первого развертывания, где обычно отправляются обновления, чтобы исправить маленькие/большие молодежные ошибки.