aaarrr 56 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 4 minutes ago, Arlleex said: Но можно, конечно, в образе прошивки хранить CRC32 этой прошивки и при старте загрузчика сравнивать всю прошивку с CRC32 во Flash. И тогда можно делать флажок в ОЗУ. Но, как мне кажется, проверять CRC32 всей прошивки всегда в загрузчике - расточительство... Хотя имеет место быть. ИМХО. Не можно, а просто-таки нужно. Расточительством тут и не пахнет - safety first. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 129 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба Just now, aaarrr said: Не можно, а просто-таки нужно. Расточительством тут и не пахнет - safety first. Примерно это делается у меня в девайсах на CPU, которые грузятся с QSPI Flash и загружают исполняемый образ в ОЗУ. Сначала тестируется DDR SDRAM, потом смотрится валидность прошивки в QSPI Flash. Только потом - старт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 172 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 11 минут назад, Arlleex сказал: Но можно, конечно, в образе прошивки хранить CRC32 этой прошивки и при старте загрузчика сравнивать всю прошивку с CRC32 во Flash. И тогда можно делать флажок в ОЗУ. Но, как мне кажется, проверять CRC32 всей прошивки всегда в загрузчике - расточительство... Хотя имеет место быть. ИМХО. Нужно и CRC принятой прошивки проверять и прошивку с имеющейся во флешь сравнивать (не CRC, а именно прошивку). А в чём расточительство? Вы вон ждёте по 5 сек (!) при каждом старте, а эта проверка она - на порядки быстрее. А я даже новую прошивку сравниваю по секторам flash со старой, перед тем как стирать и шить новую. Чтобы скорость обновления увеличить и ресурс флешь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 129 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба Just now, jcxz said: Нужно и CRC принятой прошивки проверять и прошивку с имеющейся во флешь сравнивать (не CRC, а именно прошивку). А в чём расточительство? Вы вон ждёте по 5 сек (!) при каждом старте, а эта проверка она - на порядки быстрее. А я даже новую прошивку сравниваю по секторам flash со старой, перед тем как стирать и шить новую. Чтобы скорость обновления увеличить и ресурс флешь. Возможно, это и правильно. Но это работает только в том случае, если внешняя флешка есть, куда прошивку складировать можно. Опять же, сравнивать прошивки - каждый раз при старте МК или один раз после прошивки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 172 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 21 минуту назад, Arlleex сказал: Опять же, сравнивать прошивки - каждый раз при старте МК или один раз после прошивки? Перед началом прошивки. Перед стиранием первого сектора program flash. После - прошивки сравнивать уже поздно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 117 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 2 часа назад, jcxz сказал: Когда я вёл ПО для линейки устройств (с похожим железом и похожими прошивками (сборка из единых исходников условной компиляцией), то имел в заголовочном файле ID аппаратного исполнения устройства, для которого делается сборка. Соответственно все #if ... #endif выполнялись согласно этого ID. Когда я использовал такой же подход - у меня для каждого ID были свои ключи шифрования образа приложения. Загрузчик не дает записать образ, зашифрованный неправильными ключами. Сейчас я отказался от такого решения. Одна прошивка на всех, в защищенной от записи области загрузчика прибит гвоздями ID, частота кварца и остальные существенные параметры железа. Приложение ветвится исходя из этого ID и использует остальные паремнтры для правильной работы. Избавишись от вороха #if, и зоопарка прошивок, сопровождать проекты стало значительно легче. Размер приложений стал некриминально больше, размеры памяти программ нынче не жмут. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 2 часа назад, jcxz сказал: Я это говорю не на пустом месте: У меня тоже опыт. На текущем месте работы всё железо заливается смолой, к непредусмотренным пинам не подлезешь без приведения устройств в нетоварный вид, жтаг запрещается еще бутлоадером исходя из политик безопасности, места под запасную прошивку - нет. А жизненный опыт - в цепочке подготовки производства срукожопили и сделали архив с прошивкой не от того устройства. Валидный. Если бы бутлоадер не имел запасного плана, железо отправилось бы в утиль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 129 2 ноября, 2018 Опубликовано 2 ноября, 2018 (изменено) · Жалоба 2 hours ago, jcxz said: Перед началом прошивки. Перед стиранием первого сектора program flash. После - прошивки сравнивать уже поздно. Ну, секунду. Вот, допустим, есть внешняя QSPI-Flash. Я в нее загрузил образ новой прошивки и дал команду загрузчику. МК перезагрузился, зашел в загрузчик. Теперь он должен сравнить CRC32 и образ той прошивки, которая сейчас прошита во Flash МК (приложение) с CRC32 и образом новой прошивки, которая лежит в QSPI-Flash (пословно) перед стиранием первого сектора? Так если прошивка-то новая, она априори не сойдется ни в CRC32, ни в образе. Тогда в чем смысл? Не обновляться на то же самое? Я, видимо, не совсем понимаю, что Вы имели ввиду. Изменено 2 ноября, 2018 пользователем Arlleex Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба Ну во-первых црц как раз сойтись вполне может и на разных прошивках. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 172 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 2 часа назад, Сергей Борщ сказал: Избавишись от вороха #if, и зоопарка прошивок, сопровождать проекты стало значительно легче. Размер приложений стал некриминально больше, размеры памяти программ нынче не жмут. У нас аппаратные исполнения отличаются друг от друга железом (набором внешних микросхем) и даже могут иметь разные МК. Но ПО при этом - общее. Так что без #if...#endif - никак. 2 часа назад, Kabdim сказал: А жизненный опыт - в цепочке подготовки производства срукожопили и сделали архив с прошивкой не от того устройства. Валидный. Если бы бутлоадер не имел запасного плана, железо отправилось бы в утиль. В общем случае, при рукожопии, никакой бутлоадер не поможет. Ибо можно в ПО так накосячить, что зависнет и сторожевик не поможет. Так что от фактора рукожопости ничего не спасёт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 172 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 1 час назад, Arlleex сказал: Не обновляться на то же самое? Да, именно так. Даже если часть секторов flash в старом и новом ПО совпадают - зачем их обновлять? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 2 ноября, 2018 Опубликовано 2 ноября, 2018 · Жалоба 2 hours ago, jcxz said: Да, именно так. Даже если часть секторов flash в старом и новом ПО совпадают - зачем их обновлять? Обновлять может и не надо, но протестировать чтение со специальным фабричным логическим уровнем стоит. Эт как минимум позволит предупредить грядущие сбои. Кстати, молодежно будет ставить вспомогательный чип, как теперь делается на всех отладках, с DAPLink-ом. Эта штука при любых обстоятельствах прошьет основной микроконтроллер, а за одно и отладчиком может работать. Если Ethernet через SPI, то и Ethernet перехватит и коня на скаку остановит ... словом сорсы DAPLink открыты. Там тоже есть свой загрузчик, если что. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 129 2 ноября, 2018 Опубликовано 2 ноября, 2018 (изменено) · Жалоба 2 hours ago, jcxz said: Да, именно так. Даже если часть секторов flash в старом и новом ПО совпадают - зачем их обновлять? Ну да, согласен, благодарю за пояснение. 3 hours ago, Kabdim said: Ну во-первых црц как раз сойтись вполне может и на разных прошивках. Вероятность очень мала, но она есть, конечно же. Сейчас я просто проверяю после прошивки именно целостность записанного образа с желаемым (который я подготовил на ПК) лишь сверкой CRC32. Этим я гарантирую хочу сказать, что после прошивки во Flash будет именно то, что я хотел, а не что-то другое. Хотя, с учетом малой вероятности получения одного CRC32 на разных прошивках (или Flash, истертая до дыр, по стечению метеорного потока Персеиды, посчитает CRC32 правильно, а реальный образ будет не верным) будет правильным после записи каждой единицы прошивки (байт, слово, страница) - сразу проверить ее с тем, чем прошивали (пришедший пакет с очередным куском прошивки). Так будет прям вообще надежно, ИМХО. Кстати. Читал тут где-то, что Flash-память обладает эффектом рассасывания заряда на плавающем затворе (проявляется при очень частом стирании/записи или при выключении питания в момент записи). Может случиться так, что во время установки 0 в битах, если в это время пропадает питание, энергии будет не достаточно для полного обогащения затвора электронами, вследствие чего можно наблюдать эффект, когда записанный байт сегодня читается хорошо, а месяц спустя, например, некоторый бит превратится из 0 в 1. Хотя может этом уже паранойя.... Изменено 2 ноября, 2018 пользователем Arlleex Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 59 3 ноября, 2018 Опубликовано 3 ноября, 2018 · Жалоба 16 hours ago, jcxz said: Именно поэтому предпочитаю выносить процесс приёма прошивки в рабочее ПО - так гораздо богаче функционал. А не возникнет такая ситуация: вы обновили рабочее ПО, а там - необнаруженная вовремя ошибка. И как раз загрузочная часть неработает корректно. Устройство - кирпич) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 129 3 ноября, 2018 Опубликовано 3 ноября, 2018 · Жалоба 3 hours ago, haker_fox said: А не возникнет такая ситуация: вы обновили рабочее ПО, а там - необнаруженная вовремя ошибка. И как раз загрузочная часть неработает корректно. Устройство - кирпич) Собственно говоря, об этом я и писал выше. Нужны какие-то более изворотливые алгоритмы обновления ПО. Например: 1. В обработчике команды "ОБНОВИТЬ ПО", посланной ПК, из работающего (пока что) пользовательского приложения микроконтроллера сначала проверяем в энергонезависимой памяти флажок "нужно обновить ПО", что он равен 0, и только в этом случае устанавливаем его в 1. Если он и был в 1, то сбрасываем его в 0 и работаем дальше по приложению - в загрузчик не входим. 2. Уйти в перезагрузку. 3. МК сбрасывается, видит, что флажок установлен в 1 (назовем это состоянием обновления ПО пока что "неподтвержденного функционала"). Под неподтвержденным функционалом я понимаю как раз уязвимость, когда пользовательское ПО не сможет принимать команды на переход в загрузчик (для п. 1). 4. Стандартные действия - прием, проверка и прошивка нового ПО. 5. После успешной прошивки - переходим на основное приложение. Теперь отправляем либо ту же самую команду на прошивку, либо жмем другую кнопочку, назовем ее "МК, если ты еще живой, то слушай: я уверен, что ты сможешь еще обновиться, если что", которая шлет команду, обрабатываемую в МК наравне с командой на прошивку. Этим обеспечится гарантия, что механизм входа в загрузчик из новой версии ПО будет возможен в дальнейшем. 6. МК принимает эту команду, смотрит на флажок: там была записана 1. Это значит, что ПО обновили и оно способно обновляться в дальнейшем ("подтвержденный функционал"). Только теперь МК сбрасывает флажок в 0 и работает дальше. ИМХО, такой алгоритм позволяет обезопаситься и от проблем по питанию во время прошивки, и от криворуко написанного пользовательского ПО. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться