Информация низкоуровнего доступа к внутренней flash микроконтроллеров от NXP явлается секретом. А также является секретом как первоначально прошивается bootloader на предприятии изготавливающем эти чипы.
Поэтому я был бы весьма признателен, если конить поможет пролить свет на эти "секреты". Ведь производитель некоторых программ загрузчиов имеют представление как в LPC программить flash без IAP. Помогите кто может!

Зачем?

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

А почему хотите избавиться от IAP? Чем не устраивает?
Немного про устройство загрузчиков есть здесь
P.S. Я бы тоже не отказался узнать как ведет себя контроллер с полностью чистым флешем - срабатывает ли CRP и не блокируется ли доступ по JTAG.

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




По всей видимотси контроллер с чистым флешем ни как себя не ведёт, и наверное в этом случае имеется возможность только параллельного программирования, когда ядро контроллера не работает. Но это мои догадки. И если это так, то полностью защитить свой код во флеше нет.

Разработчики от NXP хотели сделать плохую, или хорошую, но у них не хватило информации и квалификации

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

ИМХО, ирония здесь несколько неуместна. Разработчики кристаллов почти никогда (за исключением специальных случаев, когда разрабатывается защищенная система) не заморачиваются защитой кода клиентов, CRP - это просто "бесплатный бонус. Есть - и ладно, но никто ничего не гарантирует, даже "на словах".
Навскидку - два примера:
- еще 5 лет назад я изучал загрузчик MSP430F149, прошитый в ROM. Там была найдена дыра, сегодня известная как баг "BSL03", о чем Texas был поставлен в известность. F149-й до сих пор выпускается с этой "дырой" и успешно не применяется в моих изделиях.
- "дыра" в загрузчиках для тех же LPC21xx - в версиях до 1.64 включительно также хорошо известна (даже обсуждалась у нас на форуме) и отлично свидетельствует об избытке "квалификации и информации" у разработчиков NXP. И не факт, что там (и в других загрузчиках от NXP) больше не осталось таких проблемных мест.
Далее - загрузчик от NXP, с известным протоколом и с отсутствующей криптографией, легко обойти применяя несложные методы социальной инженерии и некоторое знание психологии. Не кражей, не подкупом, не шантажом и не другими некрасивыми методами, а просто основываяясь на невнимательности сервисников/ремонтников.
Поэтому разработка своего загрузчика достаточно актуальна, притом что, например, в моей компании cуществует более чем 10-летняя традиция использования своего протокола и методики криптозащиты, которые к тому же составляют заметную часть функциональности изделий. И замалчивание деталей программирования флеша со стороны NXP вызывает недоумение и некоторое раздражение, тем что вынуждает заниматься реверс-инжинирингом (со временем я стал находить дизассемблирование все более и более скучным занятием ).
Вот такие у меня 5 коп

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

Совершенно правильно, тоже использую свой ВТОРИЧНЫЙ криптозагрузчик для раздачи upgrade направо и налево. Только при этом не страдаю маниями по поводу наличия основного загрузчика и использования его составной части IAP.

А у меня нет - невозможно объять необъятное.

В своем загрузчике баги исправить можно, в чужом - нет.

Угу. Приходит из поля прибор. Не рабочий. Вроде все OK, но не пашет. Что делает "авторизованный" сервисник/ремонтник? Запускает утилиту типа FlashMagic или Вашего isp200. Прибор "отзывается", но вот выясняется что, например, прошивка слетела - пусто в чипе, или мусор какой. Ну что ж, пытаемся прошить ВТОРИЧНЫЙ загрузчик - это ж лень проц перепаивать, а вдруг заработает. Прошили - все OK. Залили через вторичный загрузчик криптованную прошивку - все OK. Пашет! Отдаем прибор обратно в "поле", уф-ф, ставим галочку - "успешный ремонт" и берем с полки пирожок .
А контроллер-то был не простой, там "злобные конкуренты" слегка пропатчили первичный загрузчик от NXP. И, к примеру, CRP "иногда" не работает. И вся прошивочка, вторичный загрузчик, а также ключики из этого загрузчика - "того", попали к кому не надо. Хорошо еще, если изделие не особо тиражное, прошивка несертифицируемая и можно наделать уникальных ключей. Но это далеко не всегда так - у меня почти всегда ключ общий для большой серии, а иногда даже для страны производства. А заставить сервисника/ремонтника всегда проводить проверку аутентичности контроллера - это утопия.

Да ладно уж - необъятное . Месяц занудной работы максимум. В моем случае окупится - уже проверено .
К тому же сам IAP переделывать смысла и правда никакого нет. А вот изменить протокол и добавить в него сразу криптование - самое оно.

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

Загрузчик LPC2000 уже давно вскрыли дизассембированием. Юзайте google. Мы написали свой собственный загрузчик и с успехом его используем.

Ну загрузчика "LPC2000" не существует - разные семейства чипов, разные версии загрузчика даже для одного семейства. Но гуглу это конечно всеравно .

1) Значит 'Ander' знает как перепрограммировать первичный загрузчик, но не говорит.
2) Ссылки на Гугл характерны для болтунов - сам не в курсе.
3) Свои платы нужно маркировать разрушаемой гарантийной наклейкой. А чужие платы пусть отвечают по гарантии сами. Много ли здесь таких, которые копируют чужие платы и отвечают перед покупателем?

Для этого достаточно посмотреть/воспользоватся штатным upgrade бутовых загрузчиков от NXP.

Хм, а Вы сами лично шьете все загрузчики? Или таки кому-то делегируете полномочия?
Я, при всем желании, лично не смог бы - тиражи не позволят.
Понимаете, у всех разные условия. Например, у нас есть надежные и добропорядочные партнеры которые вообще встраивают наше изделие на свою PCB - сами трассируют, прошивают, запускают - у них есть вся документация, загрузчики, ключи, etc. Для них криптозащита сделана просто для общности подхода, никаких секретов нет вообще. Есть партнеры-конкуренты - с ними один способ "борьбы" - быть на шаг впереди, никакая криптозащита тут особо не поможет, но и "дарить" прошивки тоже не стоит. А есть партнеры с которыми можно работать только по принципу "утром деньги - вечером стулья". Утечка прошивок/ключей тут равнозначна банальной утечке денег.

"Надо Федя, надо" ©
Сейчас примерно так и сделано, как Вы написали. Но есть потенциально слабое звено, если его можно убрать (и в ряде случаев есть основания так сделать), то почему нет? Вообще, я считаю что в данном случае NXP решил свои проблемы за счет клиентов. У Атмела в SAM7 проблемы загрузчиков решены намного более элегантным способом.
P.S. А разве уже опубликован способ замены загрузчиков 3-ей версии (23xx/24xx)? Я что-то пропустил?

Значит правим таблицу векторов в основном загрузчике (вектор резета). В связи с етим вопрос : будут ли после этого вызываться и корректно отрабатывать функции IAP? Ктонибудь такое делал, и какой прогой заливать подправленный бутер?

Вообщето в своём изделии я предполагал следущее: набрал секретный код на клавиатуре - установил свой вектор(вырубил штатный загрузчик) и доступа к флешу контроллера нет до тех пор пока снова не набрал на клавиатуре секретный код. Но здаётся мне, что через IAP не исправить таблицу векторов штатного загрузчика - там запрет на определённые сектора.