Желающим USB под ДОС , Welcome!!!

[StasNewOs]

usbmassbulk кстати читал, всё там знакомые понятия, как говорится пока не посмотрих как это делается будеш долго тупить.

Добавлено 20.07.12, 13:11

Цитата zakharo @ 20.07.12, 13:07

Да, никак. И без конфигурирования устройства - частенько тоже. У меня есть флешки, у которых есть две конфигурации. И которые в дефолтной конфигурации вообще не читаются. Чтобы их читать, надо установить конфигурацию 1.
Вообще этап конфигурирования USB устройства - адресация, чтение дескрипторов и установка конфигурации - обязателен. Иначе как ты поймешь, что к порту подключена именно флешка, а не клавиатура, принтер, мышь или, скажем, вебкамера? Устройств с разъемами USB очень много.

тоже верно

Добавлено 20.07.12, 13:14
Вообще у дисковых объектов моих есть свой буфер 512мб, претполагается читать все дескрипторы туда и переносить от туда инфу, текст в сам объект.

Добавлено 20.07.12, 13:16
Все типы дескрипторов хорошо описаны,с этим проблем нету, но я не допанимаю куда эта инфа приходит после отправки qTd getdescriptor, который я тоже умею создавать.

Сообщение отредактировано: StasNewOs - 20.07.12, 13:16

[shm]

Цитата zakharo @ 20.07.12, 13:07

И без конфигурирования устройства - частенько тоже

Практически всегда. 0-я конфигурация на подавляющем большинстве USB устройств - режим ожидания.
StasNewOs, научись наконец читать документацию, а не только готовые исходники переводить с Си на Асм. Я поражаюсь как только zakharo не надоело перепечатывать тут перевод фрагментов спецификаций.

Цитата StasNewOs @ 20.07.12, 13:00

Без получения дескриптора конфигураций сектор не прочитать.

Ну с заведомо известной моделью флешки и в заведомо известном порту вообще говоря можно. Но без установки конфигурации - даю 99%, что не получится.
StasNewOs, с точки зрения архитектуры ядра ОС работу с устройствами USB лучше абстрагировать от конкретного хост-контроллера, а именно путь будет функция наподобие SendBulkPacket(DEVICE_INFO *Info, const void *Data, size_t Size), которая дальше сама переправит вызов в нужный драйвер и он уже будет заниматься qTD и прочими вещами. В противном случае, если возникнет желание сделать поддержку другого контроллера, то возникнет огромный геморрой с переписывание драйверов всех устройств USB.

Добавлено 20.07.12, 20:06

Цитата StasNewOs @ 20.07.12, 13:09

Вообще у дисковых объектов моих есть свой буфер 512м

Зачем? А если в системе нет 512мб, что будет? Out of memory? Память конечно под дисковые структуры и те же дескрипторы USB надо резервировать, но в таких количествах. Есть такая штука ка динамически выделяемая память, есть такие понятия как локальная куча ядра и страничная адресация - рекомендую все таки почитать. В крайнем случае можно и выделит много памяти (но явно не 512Мб), но виртуальной и при необходимости отображать физическую. Благо единицы данных практически всех современных устройств позволяют фрагментировать данные в физической памяти регионами <= 4Кб. Я честно говоря вообще с трудом понимаю зачем нужны 512Мб, ты в ядре память под файловые данные резервируешь что ли? Так этим должны заниматься приложения, ядро лишь проверяет, что памяти достаточно и при необходимости выделяет физические страницы.

Добавлено 20.07.12, 20:23

Цитата StasNewOs @ 20.07.12, 13:09

но я не допанимаю куда эта инфа приходит после отправки qTd getdescriptor

Никуда, ты ее должен сам принять. ЕМНИП в конце надо еще пустой пакет отправить.

Сообщение отредактировано: shm - 20.07.12, 20:23

[StasNewOs]

Я вообще С+ подобные не знаю (сам код мне трудно понять, ничего не писал на нём, на дельфи тока) и в своей системе делаю сам всё по спецификациям и конечный алгоритм всегда за мной, главное для меня понять куда, что и как, потом записываю на АСМ в свои объекты.
Буфер 512байт конечно(пардон, у меня вся система не больше 10мб) только для принятия туда инфы и потом первый сектор.
Как принять, по прерыванию ждать и потом искать по всей оперативке чтоли?
Переводы печатать не прошу, а только объяснить куда что идёт.

Сообщение отредактировано: StasNewOs - 21.07.12, 01:39

[zakharo]

Все адреса памяти - в qTD. И откуда послать, и куда принять.

[shm]

Цитата StasNewOs @ 21.07.12, 01:37

Переводы печатать не прошу, а только объяснить куда что идёт.

Enhanced Host Controller Interface Specification Revision 1.0, page 41.

Добавлено 21.07.12, 08:47

Цитата StasNewOs @ 21.07.12, 01:37

Я вообще С+ подобные не знаю

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

Добавлено 21.07.12, 08:53
Кстати в книгах Кулакова и Агурова переведено достаточное количество инфы по этой теме.

Сообщение отредактировано: shm - 21.07.12, 08:54

[zakharo]

В общих чертах процедура получения любого дескриптора выглядит так: посылаем на endpoint 0 пакет типа SETUP, в qTD ставим адрес (физический) блока соответствующего запроса (REQUEST), потом с этой же конечной точки получаем пакет типа IN, там в qTD ставим адрес, куда контроллер запишет принятую информацию, а потом посылаем еще пакет типа OUT нулевой длины - для подтверждения. Соответственно, получается очередь из трех qTD.
Умный человек shm правильно говорит - лучше всего сразу делать многоуровневую систему. Уровень управления контроллером - это раз, над ним - уровень аппаратно-независимых control- и bulk-транзакций, там же можно сделать начальное конфигурирование, еще над ним - Mass Storage, а еще над ним - SCSI. Тогда очень легко будет добавлять другие типы контроллеров и устройств.

Сообщение отредактировано: zakharo - 21.07.12, 10:58

[StasNewOs]

Цитата

потом с этой же конечной точки получаем пакет типа IN, там в qTD ставим адрес, куда контроллер запишет принятую информацию

Теперь я понял, что вы имеете в виду под получаете, т.е. в пакете in указываем адрес для получения инфы и она приходит, т.е. контроллер сначала получит пакет с информацией, что ему делать и сделает это если увидет второй пакет с адресом памяти(это всё, что мне надобыло понять).

Цитата

делать многоуровневую систему

Это не самый удачный вариант, у меня поудачнее, почитайте о нём в прошлой ссылке, там инфа о моей ОС, ваше мнение о ней будет интересно.

Цитата

Кстати в книгах Кулакова и Агурова переведено достаточное количество инфы по этой теме.

Мне не нужна куча инфы.
Могу с трудом читать С++ код, в коледже кстати курсавую на нём делал частично, но потом не пользовался, и другие языки могу понимать, но я не заглядываю в чьи то ОСи, и если дадут исходники Винды мне они будут не интересны у меня есть своя не хуже.

Сообщение отредактировано: StasNewOs - 21.07.12, 14:14

[zakharo]

Цитата StasNewOs @ 21.07.12, 13:54

т.е. контроллер сначала получит пакет с информацией, что ему делать и сделает это если увидет второй пакет с адресом памяти(это всё, что мне надобыло понять).

Не так. Контроллер четко выполняет то, что требуется в qTD. Написано - послать пакет типа SETUP из памяти с адресом таким-то устройству такому-то - он и посылает. Устройство принимает этот пакет, понимает, что от него требуют дескриптор, но по собственной инициативе ответить ничего не может - оно может послать данные только в ответ на разрешение посылки от контроллера. Контроллер читает следующий qTD - там указано, что надо принять пакет (выполнить транзакцию типа IN) и положить данные по такому-то адресу. Он выставляет на шине разрешение на передачу данных от устройства, принимает данные и кладет по заданному адресу. В 3-м qTD написано, что надо послать пакет нулевой длины - он его и посылает. Все.

[shm]

Цитата StasNewOs @ 21.07.12, 13:54

Это не самый удачный вариант, у меня поудачнее

Извини, но с точки зрения теории операционных систем - это . Я еще раз рекомендую тебе вдумчиво почитать Таненбаума, именно прочитать а не бегло просмотреть что-то. Я думаю, что со временем к тебе придет более глубинное понимание данного вопроса. Сейчас же ты делаешь все по принципу: лишь бы побыстрее добавить побольше всего, при этом до конца не осознавая что ты загонишь в тупик свой проект. В конечном итоге у тебя получится много всего, но использовать это будет невозможно. Именно по этой причине у меня на данный момент нет желания каким-либо образом объединятся с тобой, да и не вижу такой возможности в силу того, что у тебя даже модульность не поддерживается. Мне же интересно сделать пусть и не многое, но "красивое" с точки зрения архитектуры, обладающие достаточной стабильностью и легкой расширяемостью.

Цитата StasNewOs @ 21.07.12, 13:54

Мне не нужна куча инфы.

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

Цитата StasNewOs @ 21.07.12, 13:54

но я не заглядываю в чьи то ОСи,

В большинстве случаев, чтобы понять как работает драйвер для какой-нить тяжеловесной ОСи, нужно хорошо понимать как устроено ее ядро. И изучение может оказаться посложнее вникания в даташиты на девайс. Я имел ввиду про конкретные примеры, которые есть та том же осдеввики. Даже упуская тот момент, что в таких примерах зачастую куча ошибок, которые ты перенесешь к себе не вникая в суть. Там еще и опускаются всякие проверки, контроль ошибок и прочие "мелочи". В том же примере для AHCI нет контроля ошибок, а про обработку ошибок в спецификации есть целая глава. В случае возникновения ошибок контроллер прерывает выполнения операций (не только текущей но и будет игнорировать все остальные) и ждет соответствующих команд восстановления. Вот примерно такие грабли и поджидают при таком подходе, в итоге жуткая нестабильность ядра.

[StasNewOs]

Цитата

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

У меня ядро объектное готово и сейчас мне действительно нужно на объекты навешивать побольше функционала, в том числе и обработку ошибок. Модули это тоже у меня объкт у которого почти все поля это адреса на функции.
В описании системы я писал что разгледел в такой объектной системе безграничные возможности, простоту реализации, использования, а про тупик я не писал, ты откуда это взял?
Если не понял принцип системы, то зачем её коментировать. У моего объекта есть стандартные поля, потом переменные, флаги, функции в нем записаны, они проектируются и конструируются. Работа идёт с ним по его адресу, по ему можно взять любую переменную или функцию(mov eax,[ebp+4] call(jmp) dword[ebp+8]), при запуске любой функции она так же имеет этот адрес и пользуется любой инфой, функцией своего объекта, в объекте есть ссылки на другие объекты и ещё много всего. Объект может быть флешкой того или иного контроллера, или диском, или ресурс из сети и при работе с ним ты можеш этого не знать, т.к. получение сектора будет функцией по одному смещению.

Цитата

Я на работе пишу драйвера исключительно по спецификациям, какой-либо примера зачастую просто не существует.

Зачем мне тогда примеры смотреть предлагаеш?

Сообщение отредактировано: StasNewOs - 22.07.12, 01:53

[shm]

Цитата StasNewOs @ 22.07.12, 01:46

Модули это тоже у меня объкт у которого почти все поля это адреса на функции.

И что он из себя представляет?

Цитата StasNewOs @ 22.07.12, 01:46

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

Я не знаю как сейчас, но без поддержки таких вещей как виртуальная память, защита ядра, и т.п. ни о никаких "безграничных возможностях" не может быть и речи.
По поводу простоты реализации - ее нет, вообще нет возможности для реализации стороннему человеку. Никому не интересно изучать код твоего ядра, чтобы что-то дописать, более того быть постоянно зависимым от твоих исходников, чтобы собрать образ. Да и документации у тебя нет никакой. И сама идея постоянной пересборки образа, чтобы протестировать очередную функцию тоже никому не интересна. Хороший вариант - это микроядро, ну или полноценная модульность с чтеко сформированным и документированным интерейсрм ядра, где большая часть ядра представляет собой фактически набор библиотек. И все это в виде отдельных исполняемых файлов, формата поддерживаемого общедоступными компиляторами (PE или ELF). Далеко не все хотят писать все на асме, да и смысла в этом особого нет.

Цитата StasNewOs @ 22.07.12, 01:46

Зачем мне тогда примеры смотреть предлагаеш?

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

[StasNewOs]

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

Сообщение отредактировано: StasNewOs - 22.07.12, 12:37

[shm]

Цитата StasNewOs @ 22.07.12, 12:33

моя система не будет требует дописывания, а сама будет давать кучу готовых объектов, компонентов, кодеков, сетевых протоколов, дров, и этим будет легко управлять и т.д.

Это физически невозможно одному человеку.

Цитата StasNewOs @ 22.07.12, 12:33

Документация есть

Посмотреть можно?

Сообщение отредактировано: shm - 22.07.12, 12:54

[StasNewOs]

Проблема возникла с тем, что первая qTD проходит(статус обнавляется в 0, ошибок нет), вторая qTD даже не наченается(статус 80h остаётся), я вообще в первой указал адрес второй как адрес первой+64байт, там её и начинал, а адрес второй как 1, она была последняя. Альтернативный адрес ставил всегда 1.
В чём может быть проблема?

Сообщение отредактировано: StasNewOs - 26.07.12, 02:29

[zakharo]

Проблемы могут быть где угодно.
Если, к примеру, контроллер поддерживает 64-битную адресацию (бит 0 в HCCPARAMS), то размеры управляющих структур будут другими. И надо устанавливать регистр CTRLDSSEGMENT. В современных машинах скорее всего 64-битная адресация поддеживается.
Если не отнять контроллер у BIOSа (называется "Pre-OS to OS Handoff Synchronization"), то BIOS будет пытаться продолжать управлять контроллером и получать прерывания от контроллера после завершения транзакций, а поскольку BIOS никакие транзакции не заказывала, то у нее снесет крышу и результат будет непредсказуемый.
В общем, надо делать все подготовительные операции в соответствии с документацией на EHCI.