Организация USB перепрошивщика... Опции

[Gizma]

Привет!

Значит нужно реализавать следующую штуку...
Есть некий девайс в который пользователь вставляет флешку, выбирает функцию смены прошивки, девайс находит *.hex в roote и себя перешивает, причем он должен перешиваться полностью, вместе с лодером с помощью которого он перешиваеться (лодер также должен уметь сгружаться с флешки некие параметры для проги...)... это все на LPC2468...

Как я себе это представляю... в начале в память зашит лодер потом прога...

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

Но это все мои измышления, наверняка сея проблема распространена и есть какие либо классические решения...
Может чего присоветуете?

П.С. Как можно програмно переустанавливать точки старта в LPC? Можно ли вообще?

[rezident]

Основной принцип - начальный bootloader не перезаписывается никогда! Потому, что в противном случае есть очень большая вероятность получить полностью неработающее устройство.
Если хочется модифицировать загрузчик: дополнить его шифрованием, поддержкой новых каналов/интерфейсов для загрузки и т.п., то с помощью основного bootloader загружается дополнительный bootloader, который и реализует все эти новые фичи.

[Gizma]

Основной принцип - начальный bootloader не перезаписывается никогда! Потому, что в противном случае есть очень большая вероятность получить полностью неработающее устройство.
Если хочется модифицировать загрузчик: дополнить его шифрованием, поддержкой новых каналов/интерфейсов для загрузки и т.п., то с помощью основного bootloader загружается дополнительный bootloader, который и реализует все эти новые фичи.

В таком случае у меня получаються 2 полностью одинаковых бутлодера просто с разными исполнительными параметрами...

Еще один довод, к примеру у меня поддержка только FAT16 в будующем потребуеться что бы работал и с FAT32 и еще несколькимим ФС да и еще просто по USB, пользователю будет не очень удобно прошивать по нескольку раз сначала перешивать лодер лодера*)) потом сам лодер, потом прогу*))


А чем собсна мой вариант плох? всегда есть возможность бэкапа или релода!

[rezident]

А чем собсна мой вариант плох? всегда есть возможность бэкапа или релода!

В том, что вектор сброса - один, а сбой в момент переназначения его являет из себя далеко ненулевую вероятность. Как там в законах Мерфи? "Если вероятность неприятности отлична от нуля, то она обязательно произойдет", как-то так примерно