Приветствую, подскажите пожалуйста, существует ли способ программно отключить возможность загрузки прошивки через Usb. Суть в том, что разрабатывается клон устройства под существующие закрытые драйвера, в процессе ренумерации подгружающий оригинальную прошивку заменяя ней написанную мною, протокол известен. В ходе чтения EZ-USB Technical Reference Manual, я понял, что все реализовано через вендорспец. команду 0хА0. Но как запретить на нее реагировать, или изменить поведение при ее получении способа так и не увидел.
Подскажите, может есть идеи.

Вот это предложение не понятно. Или речь идет о том, что кто-то установил на Вашем компьютере выполнение скрипта для CyUsb.sys, а Вы теперь мучитесь (см. подраздел "Execute a script at start-up" в разделе "Modifying CyUSB.INF" файла "CyUSB.pdf" или "CyUSB.chm").

Используйте свой собственный драйвер устройства USB (или фильтр-драйвер), который не будет пропускать "вендорспец. команду 0хА0". И не используйте VID и PID, являющиеся собственностью Cypress (возможно уже это поможет).

Да как то сумбурно написал.
В общем разрабатываю устройство которое будет определятся системой как NVIDIA® 3D Vision™ . Устройство будет использовать драйвера от NVIDIA и поддерживать работу с альтернативными 3Д очками. В процессе установки драйвер посылает устройству, запрос с командой 0хА0, которая обрабатывается CY7C68013A автоматически, и происходит загрузка прошивки для оригинального устройства (заменяя написанную мной). Вот меня и интересует вопрос возможно ли как то средствами прошивки избежать обработки запроса с командой 0хА0.
Фильтр-драйвер, я отношу к последним средствам на ровне с патчем дров.
Жаль устройство практически готово, прошивка написана и такой облом.

Вряд ли.
Но Вы можете отлавливать момент ренумерации после заливки драйвером его прошивки и, придерживая Bus reset, перезалить свою прошивку с EEPROM, после этого отпустить Bus reset.
Но придётся добавлять какой-нибудь мелкий контроллер или пару микросхем логики.

Чесно говоря я не представляю как это можно реализовать на практике.

То есть, предлагаете добавить аппаратный watchdog. Firmware FX2LP должно периодически инвертировать состояние вывода контроллера, подключенного ко входу сброса watchdog-а. Тогда, через некоторое время после загрузки чужой прошивки watchdog выдаст аппаратный Reset и произойдет загрузка штатной прошивки из EEPROM. Все это работает для FX2 (CY7C68013), но не для FX2LP. На время выдачи аппаратного Reset FX2LP отключается от USB (раздел "3.2 Automatic Disconnect and Reconnect on Hard Reset" в файле "fx2_to_fx2lp.pdf"). После снятия Reset произойдет загрузка штатной прошивки, затем подключение к USB и драйвер снова загрузит "чужую" прошивку. Процесс будет циклически повторяться...


А что, действительно в NVIDIA Stereoscopic 3D USB controller используется CY7C68013A?

Да, CY7C68013A-100. Могу скинуть фотку если интересно.

NVIDIA выбрала этот контролер для ”ПИРАМИДКИ” в силу критичности таймингов, работа устрайства возможна только в режиме USB 2.0 Hi Speed, а контролеров с поддержкой этого режима сами знаете раз два и обчелся. CY7C68013A самый часто используемый и проверенный. Вот на нем и сделали.
В самих беспроводных очках использован AVR.

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

Прошивка лежит в драйвере nvstusb.sys, причем в трех ипостасиях. Судя по хеадерам, устройство имеет несколько версий. В логах ЮСБ снифера снятого с реального устройства, на который я опирался стоит версия продукта 0300. Да драйвера подписаны ибо существуют только под Висту и Вин7. Ну скажем переподписать тестовой подписью не проблема, меня такой вариант устроит, но как быть с разной длиной моей прошивки и оригинальной, просто забить 0х00. В драйвере прошивка в формате hex.

Если Ваша прошивка имеет меньший объем, то можно и "просто забить 0х00". Драйвер должен сам понять по полям hex, где заканчивается прошивка.

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


Вообще то в четырех и в таком порядке: VID_0955&PID_0007, VID_0955&PID_7004, VID_0955&PID_7002, VID_0955&PID_7003. Причем в формате iic (подраздел "3.4.3 Serial EEPROM Present, First Byte is 0xC2" из EZ-USB® Technical Reference Manual (EZ-USB_TRM.pdf)), а не Intel Hex.

Поиск начала iic блока по последовательности: c2 55 09, поиск конца iic блока по последовательности: 80 01 E6 00 00 00

Нет, я предполагал что после после загрузки прошивки драйвером фёрмваре будет делать ренумерацию (только перепутал disconnect с bus reset), но оно, конечно, может этого и не делать.

Спасибо Konst_777, четвертой не заметил. Завтра буду пробовать, отпишусь

Докладываю, патчинг прошел успешно, виндовс принял драйвер. Кусок старой прошивки не забивал нулями, так и оставил, на функционал не повлиял. Драйвер подписал тестовой подписью, при помощи утилитки dseo13b, кстати для драйвописателей очень удобна все в одном флаконе для Тестового режима Вин 7 / Виста.
Еще раз спасибо всем принявшим участие в обсуждении.
Если у кого будут альтернативные идеи по теме ветки буду благодарен.

Альтернативных идей пока нет, а вопрос есть. Почему не получилось сделать полный клон? Тогда можно было использовать для FX2LP firmware от NVIDIA и не нужно было бы модифицировать драйвер.

Основная задача реализовать поддержку сторонних очков, более дешевых но не хуже оригинальных (ED, XpanD). Поэтому софт по любому надо писать самому. В моем распоряжении плата с CY7C68013A-56, делаю на нем для себя и группы товарищей упрощенный по железу вариант. И для данной задачи этого достаточно, происходит обработка 8 битовых пакетов, их синхронизация, и дерганье портом исходя из необходимого протокола. На порт повешены ИК-диоды через полевик-драйвер вот и все. Копию железа сделать можно в принципе достаточно любой китайской тестбоард CY7C68013A-100/128, но зачем. Я дизасемблировал прошивку и получил довольно полное представление о функционале сего девайса и считаю железо избыточным. Да и разбираться с новыми контролерами мое хобби...

Все таки, почему нужен High Speed? Почему не достаточно Full Speed? Вы не проверяли, а будет ли работать Ваш клон в режиме Full Speed? Если да, то можно выбрать для клона дешевый контроллер (не FX2LP) с малым количеством выводов, со встроенным генератором (не нужен внешний кварц), с SPI. И будет нормальная реакция на "вендорспец. команду 0хА0". Правда, обновлять firmware будет менее удобно.

Да, пробовали все режимы, я делал на AVR, один товарищ пробовал на PIC с аппаратным контролером, Даже в режиме Фулспид (пакеты с периодом 1 мс) есть запаздывание, а вот на Хайспид (пакеты с периодом 125 мкс) все успевает. Из доступного мне подходящего железа есть только AT32UC3A3, но относительно дороговата. Можно конечна и от Техас Индастрис что то попробовать, но с доступность их чипов у нас проблемы.