Перейти к содержанию
    

обновление прошивки через эзернет-чо требуется.

4 minutes ago, Arlleex said:

Но можно, конечно, в образе прошивки хранить CRC32 этой прошивки и при старте загрузчика сравнивать всю прошивку с CRC32 во Flash. И тогда можно делать флажок в ОЗУ. Но, как мне кажется, проверять CRC32 всей прошивки всегда в загрузчике - расточительство... Хотя имеет место быть. ИМХО.

Не можно, а просто-таки нужно. Расточительством тут и не пахнет - safety first.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, aaarrr said:

Не можно, а просто-таки нужно. Расточительством тут и не пахнет - safety first.

Примерно это делается у меня в девайсах на CPU, которые грузятся с QSPI Flash и загружают исполняемый образ в ОЗУ. Сначала тестируется DDR SDRAM, потом смотрится валидность прошивки в QSPI Flash. Только потом - старт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 минут назад, Arlleex сказал:

Но можно, конечно, в образе прошивки хранить CRC32 этой прошивки и при старте загрузчика сравнивать всю прошивку с CRC32 во Flash. И тогда можно делать флажок в ОЗУ. Но, как мне кажется, проверять CRC32 всей прошивки всегда в загрузчике - расточительство... Хотя имеет место быть. ИМХО.

Нужно и CRC принятой прошивки проверять и прошивку с имеющейся во флешь сравнивать (не CRC, а именно прошивку). А в чём расточительство? Вы вон ждёте по 5 сек (!) при каждом старте, а эта проверка она - на порядки быстрее.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, jcxz said:

Нужно и CRC принятой прошивки проверять и прошивку с имеющейся во флешь сравнивать (не CRC, а именно прошивку). А в чём расточительство? Вы вон ждёте по 5 сек (!) при каждом старте, а эта проверка она - на порядки быстрее.

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

Возможно, это и правильно. Но это работает только в том случае, если внешняя флешка есть, куда прошивку складировать можно.

Опять же, сравнивать прошивки - каждый раз при старте МК или один раз после прошивки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

21 минуту назад, Arlleex сказал:

Опять же, сравнивать прошивки - каждый раз при старте МК или один раз после прошивки?

Перед началом прошивки. Перед стиранием первого сектора program flash. После - прошивки сравнивать уже поздно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, jcxz сказал:

Когда я вёл ПО для линейки устройств (с похожим железом и похожими прошивками (сборка из единых исходников условной компиляцией), то имел в заголовочном файле ID аппаратного исполнения устройства, для которого делается сборка. Соответственно все #if ... #endif выполнялись согласно этого ID.

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

Сейчас я отказался от такого решения. Одна прошивка на всех, в защищенной от записи области загрузчика прибит гвоздями ID, частота кварца и остальные существенные параметры железа. Приложение ветвится исходя из этого ID и использует остальные паремнтры для правильной работы. Избавишись от вороха #if, и зоопарка прошивок, сопровождать проекты стало значительно легче. Размер приложений стал некриминально больше, размеры памяти программ нынче не жмут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, jcxz сказал:

Я это говорю не на пустом месте:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, jcxz said:

Перед началом прошивки. Перед стиранием первого сектора program flash. После - прошивки сравнивать уже поздно.

Ну, секунду. Вот, допустим, есть внешняя QSPI-Flash. Я в нее загрузил образ новой прошивки и дал команду загрузчику. МК перезагрузился, зашел в загрузчик. Теперь он должен сравнить CRC32 и образ той прошивки, которая сейчас прошита во Flash МК (приложение) с CRC32 и образом новой прошивки, которая лежит в QSPI-Flash (пословно) перед стиранием первого сектора? Так если прошивка-то новая, она априори не сойдется ни в CRC32, ни в образе. Тогда в чем смысл? Не обновляться на то же самое? Я, видимо, не совсем понимаю, что Вы имели ввиду.

Изменено пользователем Arlleex

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, Сергей Борщ сказал:

Избавишись от вороха #if, и зоопарка прошивок, сопровождать проекты стало значительно легче. Размер приложений стал некриминально больше, размеры памяти программ нынче не жмут.

У нас аппаратные исполнения отличаются друг от друга железом (набором внешних микросхем) и даже могут иметь разные МК. Но ПО при этом - общее. Так что без #if...#endif - никак.

2 часа назад, Kabdim сказал:

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

В общем случае, при рукожопии, никакой бутлоадер не поможет. Ибо можно в ПО так накосячить, что зависнет и сторожевик не поможет. Так что от фактора рукожопости ничего не спасёт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, Arlleex сказал:

Не обновляться на то же самое?

Да, именно так. Даже если часть секторов flash в старом и новом ПО совпадают - зачем их обновлять?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, jcxz said:

Да, именно так. Даже если часть секторов flash в старом и новом ПО совпадают - зачем их обновлять?

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

Кстати, молодежно будет ставить вспомогательный чип, как теперь делается на всех отладках, с DAPLink-ом.
Эта штука при любых обстоятельствах прошьет основной микроконтроллер, а за одно и отладчиком может работать. 
Если Ethernet через SPI, то и Ethernet перехватит и коня на скаку остановит ... словом  сорсы  DAPLink открыты.  Там тоже есть свой загрузчик, если что.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, jcxz said:

Да, именно так. Даже если часть секторов flash в старом и новом ПО совпадают - зачем их обновлять?

Ну да, согласен, благодарю за пояснение.

 

3 hours ago, Kabdim said:

Ну во-первых црц как раз сойтись вполне может и на разных прошивках.

Вероятность очень мала, но она есть, конечно же. Сейчас я просто проверяю после прошивки именно целостность записанного образа с желаемым (который я подготовил на ПК) лишь сверкой CRC32. Этим я гарантирую хочу сказать, что после прошивки во Flash будет именно то, что я хотел, а не что-то другое. Хотя, с учетом малой вероятности получения одного CRC32 на разных прошивках (или Flash, истертая до дыр, по стечению метеорного потока Персеиды, посчитает CRC32 правильно, а реальный образ будет не верным) будет правильным после записи каждой единицы прошивки (байт, слово, страница) - сразу проверить ее с тем, чем прошивали (пришедший пакет с очередным куском прошивки). Так будет прям вообще надежно, ИМХО.

 

Кстати. Читал тут где-то, что Flash-память обладает эффектом рассасывания заряда на плавающем затворе (проявляется при очень частом стирании/записи или при выключении питания в момент записи). Может случиться так, что во время установки 0 в битах, если в это время пропадает питание, энергии будет не достаточно для полного обогащения затвора электронами, вследствие чего можно наблюдать эффект, когда записанный байт сегодня читается хорошо, а месяц спустя, например, некоторый бит превратится из 0 в 1. Хотя может этом уже паранойя....

Изменено пользователем Arlleex

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

16 hours ago, jcxz said:

Именно поэтому предпочитаю выносить процесс приёма прошивки в рабочее ПО - так гораздо богаче функционал.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, haker_fox said:

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

Собственно говоря, об этом я и писал выше. Нужны какие-то более изворотливые алгоритмы обновления ПО. Например:

1. В обработчике команды "ОБНОВИТЬ ПО", посланной ПК, из работающего (пока что) пользовательского приложения микроконтроллера сначала проверяем в энергонезависимой памяти флажок "нужно обновить ПО", что он равен 0, и только в этом случае устанавливаем его в 1. Если он и был в 1, то сбрасываем его в 0 и работаем дальше по приложению - в загрузчик не входим.

2. Уйти в перезагрузку.

3. МК сбрасывается, видит, что флажок установлен в 1 (назовем это состоянием обновления ПО пока что "неподтвержденного функционала"). Под неподтвержденным функционалом я понимаю как раз уязвимость, когда пользовательское ПО не сможет принимать команды на переход в загрузчик (для п. 1).

4. Стандартные действия - прием, проверка и прошивка нового ПО.

5. После успешной прошивки - переходим на основное приложение. Теперь отправляем либо ту же самую команду на прошивку, либо жмем другую кнопочку, назовем ее "МК, если ты еще живой, то слушай: я уверен, что ты сможешь еще обновиться, если что", которая шлет команду, обрабатываемую в МК наравне  с командой на прошивку. Этим обеспечится гарантия, что механизм входа в загрузчик из новой версии ПО будет возможен в дальнейшем.

6. МК принимает эту команду, смотрит на флажок: там была записана 1. Это значит, что ПО обновили и оно способно обновляться в дальнейшем ("подтвержденный функционал"). Только теперь МК сбрасывает флажок в 0 и работает дальше.

ИМХО, такой алгоритм позволяет обезопаситься и от проблем по питанию во время прошивки, и от криворуко написанного пользовательского ПО.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...