Каковы методы для обеспечения безопасного обновления программного обеспечения во встроенных системах - PullRequest
11 голосов
/ 18 мая 2009

Обновление программного обеспечения для встраиваемых устройств часто имеет возможность «замуровать» устройство, например, если произойдет сбой питания в процессе написания программного обеспечения для FLASH. Два вопроса:

  1. Каковы некоторые передовые практики для реализации механизма обновления, чтобы минимизировать вероятность того, что устройство будет «заблокировано»?
  2. Каковы некоторые рекомендации по обеспечению отказоустойчивости процесса обновления, чтобы можно было восстановить такие события, как сбои питания при установке программного обеспечения во FLASH?

Ответы [ 9 ]

11 голосов
/ 18 мая 2009

Все зависит от того, насколько критично приложение. Два основных подхода (резервное копирование и загрузчик) также иногда комбинируются.

Многие системы имеют загрузчик только для чтения (например, redboot ), а затем два банка флэш-памяти (чаще всего на одном чипе). Затем у загрузчика есть флаг, чтобы выбрать банк для загрузки. Флаг будет меняться в зависимости от событий, таких как обновления (неудачные или успешные) и т. Д.

Таким образом, при обновлении работающая версия копирует новую загрузку в резервный банк, проверяет контрольную сумму, переключает флаг загрузки и затем перезагружает устройство. Устройство перезагружается в новом банке, с новой загрузкой. После перезагрузки новая загрузка может скопировать себя в резервный банк.

Часто также имеется сторожевой таймер с аппаратным сбросом. Таким образом, если встроенное ПО сходит с ума, оно не запускает сторожевой таймер, аппаратный сброс перезагружает устройство, а загрузчик будет искать нормальную загрузку.

Проект Open Mesh является хорошим примером такого подхода.

4 голосов
/ 18 мая 2009

Более конкретно ...

Загрузите заменяющее изображение в область памяти, не перезаписывая ЛЮБОЕ текущее пространство программы. Дождитесь завершения загрузки, затем вычислите и сравните CRC.

Если пространство действительно является проблемой, вы можете сделать что-то вроде 'резервного копирования по умолчанию' AKA 'режим восстановления', но гораздо проще не делать этого разрушительно.

Если вы действительно-гладко ... вы можете сделать одно обновление записи во FLASH, чтобы устройство загрузилось из нового местоположения кода. Это будет пинг / понг между двумя полностью отдельными разделами кода. Это самый безопасный способ сделать это:

  • ВСЕГДА имеет не обновляемый загрузчик восстановления (Nano-загрузчик), который может сигнализировать о загрузке нового кода, если что-то пойдет не так.
  • Два отдельных программных пространства
  • В каждом программном пространстве есть поле «CRC», «номер записи» (больше, чем номер другой кодовой страницы) и «неверное» слово (все F - не требуется стирание для обновления «недействительного»). маркер)
  • После завершения загрузки проверьте CRC. Если это хорошо, запишите маркер 'invalid' в программном пространстве старой версии.
  • Нано-загрузчик проверяет маркер 'invalid', чтобы узнать, с чего загружаться. В случае, если они оба действительны, сделайте проверку CRC. Если они все еще действительны, тогда возьмите более высокую запись номера записи

О, и когда люди говорят контрольную сумму ... не "проверяйте сумму" ... Сделайте правильный CRC.

2 голосов
/ 21 мая 2009

По моему опыту, все сводится к тому, сколько вы стоите, если вы можете позволить себе иметь вдвое больше места для кода / данных на устройстве и можете перезагрузиться, это просто, сохраните новую версию во всем вашем дополнительном пространстве. выполните правильную проверку контрольной суммы на новом изображении, и я также рекомендую глубже проверить образ новой прошивки, так как он может быть подделан, если вы этого не сделаете, например, какой-то зашифрованный ключ, гарантирующий происхождение нового изображения. Вы можете сделать это и с внешней памятью, например, в одном проекте, использующем PIC, у меня был внешний EEPROM для нового образа прошивки и флаг, который, если установлен при загрузке, загрузит новый образ из EEPROM.

если вам не так повезло, то есть вы не можете позволить себе это место, тогда жизнь становится более интересной, и, вероятно, не существует гарантированного способа полностью избежать вероятности сбоя во время обновления. Во всех случаях загрузчик должен находиться в защищенной от записи части памяти, и, если вы можете себе это позволить, должен иметь некоторую базовую форму внешнего подключения, я сделал системы с очень простыми драйверами USB в загрузчике и системы с ДЕЙСТВИТЕЛЬНО простым UDP только сетевые стеки. Любой из них позволит вам по крайней мере получить новое представление об устройстве в случае сбоя во время обновления. В этих случаях я настоятельно рекомендую поместить загрузчик в область памяти, доступную только для чтения, вы теряете возможность обновлять его, но обновление haywire также не оставит вас с полностью заблокированным устройством. В таком случае загрузчик достаточно мал, чтобы вы могли быть почти уверены в его правильности.

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

2 голосов
/ 18 мая 2009

Чтобы ответить на оба вопроса и независимо от каких-либо конкретных аппаратных ресурсов:

  • Убедитесь, что перед запуском любого кода приложения (при запуске или после завершения загрузки) загрузчик выполняет проверку CRC приложения. Если он недействителен, загрузчик не запускает код.

  • Если загрузчик решает, что не может запустить код приложения, он должен иметь возможность сообщить об этом пользователю и начать загрузку снова.

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

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

2 голосов
/ 18 мая 2009
  1. Храните в памяти только для чтения загрузчик, независимо от того, что
  2. В загрузчике разрешите отказоустойчивый метод (например, удерживая кнопку X во время перезапуска) перезагрузить новую память программы из доступного источника ввода (SD-карта, RS232 и т. Д.).
2 голосов
/ 18 мая 2009

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

2 голосов
/ 18 мая 2009

контрольные суммы на внутренней флэш-памяти, с резервной копией по умолчанию, если CRC / Checksum не работает. Таким образом, если устройство получит неверную контрольную сумму, оно узнает, что обновление не было завершено, и может восстановить исходную / предыдущую прошивку, сохраненную на другом устройстве.

Для проверки контрольной суммы требуется некоторая предварительная загрузка (возможно, в загрузчике). Статический бит кода.

edit : в дополнение к комментариям в другом месте. Если вы хотите проверить наличие неправильной прошивки, а не только поврежденной прошивки, ваша checsum / checkdata также может инкапсулировать информацию о версии (и проверку этого заголовка). Я думаю, что маршрутизаторы Linksys делают это, что может затруднить их перепрошивку с помощью специальной прошивки.

1 голос
/ 01 декабря 2009

Я знаю, что на этот вопрос ответили, но некоторые люди нуждаются в большей надежности. Если ваш проект действительно критически важен, вы можете пойти по этому пути.

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

  1. имеет PIC или другой микроконтроллер, который может программировать флэш-память реального процессора. Вы заставляете его использовать контрольную сумму для блока данных и подключаете его через последовательный порт, USB или даже Ethernet (не смейтесь, это не так сложно). Это устройство НЕ МОЖЕТ быть перепрограммировано в поле (или, возможно, даже когда-либо), поэтому у вас всегда есть план резервного копирования. PIC могут запускать веб-серверы через PPP / SLIP или Интернет, так что сопряжение с ним НЕ обязательно будет неудобным. Google TCP-Lean. Старайтесь не болтать. (Сайт подходит для работы ). Поместите порт progrmming где-нибудь еще. Безопасность не обеспечена.

  2. Программа запускается на основном процессоре и запускает собственный загрузчик. У вас есть три программы: загрузчик, программа обслуживания и реальная программа.

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

Таким образом, у вас есть обновляемое встроенное приложение, обновляемый загрузчик и обновляемый режим обслуживания. И режим резервного копирования, который не может выйти из строя.

Надеюсь, никому это не нужно.

0 голосов
/ 18 мая 2009

На некоторых лабораторных (а не на потребительских) устройствах я видел платы, построенные на схемах программатора. В худшем случае, вы используете, можете открыть дело, подключить к программатору и перезагрузить программное обеспечение по умолчанию - или отправить его обратно для вас сделать то же самое. «Конечно, это стоит настоящих денег.

На некоторых пользовательских платах, используемых в некоторых моих проектах, были заменяемые ПЗУ. Это дешевле, но менее удобно.

...