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

Qraizer, насколько я помню просто так в SMM перейти нельзя, процессор переходит в это режим по сигналу SMI от чипсета, и еще вроде через APIC послать сообщение можно, но это все модельно-специфично и плохо документировано. Я думаю, что у lsvmo есть более простое решение проблемы, по крайней мере в моем загрузчике ОС, который тоже работает в "нереальном" режиме не возникало никаких ошибок на разном железе (я проводил много тестов на разном железе).

Добавлено 11.04.11, 12:31
и еще одно:

Цитата

Еще одна проблема состоит в том, что регистры процессора и чипсета, управляющие SMM, поддерживают функцию LOCK, позволяющую запретить изменение состояния указанных регистров, установив для них статус Read Only, который будет снят только после аппаратного сброса. Если BIOS, до передачи управления на загрузку ОС, активирует функцию LOCK (на большинстве платформ, протестированных автором, этого не происходит), то вмешательство внешней программы в работу SMM, а также чтение и запись SMRAM внешней программой будут невозможны.

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

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

Лучше уж тогда обработчик на "General Protection" поставить, он срабатывает и в реальном режиме (собственно из-за чего и происходит "зависание"), имеет вектор 13, в реальном режиме (а точнее при стандартной конфигурации PIC) конфликтует с IRQ5, поэтому последний на время теста лучше замаскировать. После этого можем спокойно писать за 1 мегабайт, если произошло исключения - значит предел теневой части не подходящий , в противном случае ничего не произойдет. Кстати у Кулакова на использование "General Protection" тоже роде есть пример (где то в 4 главе, но точно уже не помню).

Добавлено 11.04.11, 15:03
Хотя я не понимаю, зачем lsvmo это нужно. Даю 99,(9)%, что у него ошибка в коде и БИОС тут не причем.
И да кстати, не забываем, что ЦП в стек обработчику исключения код ошибки записывает.

Сообщение отредактировано: shm - 11.04.11, 15:05

Ну я это и предложил. Вариьруя смещения и способы обращения к памяти можно восстановить значение предела и прав доступа.

Цитата shm @ 11.04.11, 14:59

И да кстати, не забываем, что ЦП в стек обработчику исключения код ошибки записывает.

Вот это, кажись, в реальном режиме не делается, только в защищённом.

Цитата Qraizer @ 11.04.11, 17:10

Вот это, кажись, в реальном режиме не делается, только в защищённом.

Может быть, я честно говоря сам в реальном режиме #GP не пробовал обрабатывать, но по логике вещей мне кажется, что должен...

Сообщение отредактировано: shm - 11.04.11, 17:35

Цитата Qraizer @ 11.04.11, 17:10

Вот это, кажись, в реальном режиме не делается, только в защищённом.

В RM CPU тоже записывает код ошибки, собственно из-за этого всё и виснет.
GP# в RM пересекается с IRQ5 (FPU по-моему) если контроллер прерываний не перепрограммировать.
Обработчик выполняет свою работу и завершается по IRET, но если это было не IRQ, а исключение, на стеке остаётся не удалённый код ошибки, стек не сбалансирован и возврат происходит в никуда.

Цитата cppasm @ 11.04.11, 17:38

IRQ5 (FPU по-моему)

Это бывший LTP2, а на современных чипах это свободная линия, на которую BIOS вешает всякое "расширенное" оборудования. В частности у меня на нем UHC'ы висят.

Сообщение отредактировано: shm - 11.04.11, 18:01

Цитата shm @ 11.04.11, 14:59

Даю 99,(9)%, что у него ошибка в коде и БИОС тут не причем.

Изначально вопрос так и стоял. Везде, где надо было перевести GS в режим адресации свыше 1Мб, вставлял процедуру из Кулакова и всё работало. И даже последний код работает на других компах.
Но вот засада в том, что поступил супер-пупер-комп, на котором всё виснет. Убираю вызов процедуры Кулакова и тогда ничего не виснет.
Да, у Кулакова есть ошибки, но не в этой функции. И ещё раз говорю, на других компах работает.
И на этом компе очень сильно всё завязано на SMI прерывания от всего (ну так.. по наблюдениям...)

Сообщение отредактировано: lsvmo - 11.04.11, 18:18

Цитата lsvmo @ 11.04.11, 18:16

Да, у Кулакова есть ошибки, но не в этой функции.

Это кто тебе сказал?

Добавлено 11.04.11, 18:27

Цитата lsvmo @ 11.04.11, 18:16

И на этом компе очень сильно всё завязано на SMI прерывания от всего

Насколько мне известно SMI не приходят от смены режима адресации и перезаписи сегментных регистров.

Добавлено 11.04.11, 18:29
Попробуй другую процедуру использовать, а лучше напиши свою.

Добавлено 11.04.11, 18:32
Вообще Intel когда-то назвала унреал моде багом, теоретически возможно, что в каком-то ЦП решили таки это баг "исправить", но что-то я очень сомневаюсь. Ибо в традициях х86 даже баги сохранять ради совместимости. Скажи конфигурацию того компа на котором все виснет.

Добавлено 11.04.11, 18:38
Ну на крайняк SMI можно вырубить вообще. Если полностью, то это придется юзать даташиты, а частично через ACPI можно попробовать.

Сообщение отредактировано: shm - 11.04.11, 18:38

Джентльмены, как я понимаю, вся эта дискуссия имеет целью работу с регистрами контроллеров EHCI и UHCI?
Ну так чего проще - все-таки поюзать функцию 87h прерывания 15h (copy extended memory)? У Ральфа Брауна подробно описано.
Это биосовское прерывание - если биос чего и мудрит с unreal mode, так сама и разрулит.

Регистры UHCI в I/O находятся.
Доступ к расширенной памяти нужен для OHCI и EHCI.
Насчёт int 15h - это тормоза будут дикие.
Регистры пачками писать нельзя, там последовательность записи важна.
А вызывать прерывание для записи каждых 32-бит в память - это очень медленно, т.к. обработчик прерывания переходит в PM (ну или Unreal, но это врядли), копирует память и возвращается в RM.
А переключения режимов - не самые быстрые операции мягко говоря.

Цитата shm @ 11.04.11, 18:25

Скажи конфигурацию того компа на котором все виснет.

HP 7200 Elite, остальное поисковик подскажет.
Вообще, комп удивительно глючный. Плюс ко всему ещё и на 67-ом чипсете, объявленном Intel в аут.
У кого будет желание и возможность, протестите свои творения и поделитесь, пожалуйста, результатами.

P.S. (от себя лично, крик души) Не покупайте HP, а не то вы рискуете остаться с тем, что купили, один на один. Поддержки нет, никакой, кроме "А воткнут ли компьютер в розетку?".
Ни для частных, ни для корпоративных клиентов.

Цитата cppasm @ 12.04.11, 08:49

Насчёт int 15h - это тормоза будут дикие.
Регистры пачками писать нельзя, там последовательность записи важна.
А вызывать прерывание для записи каждых 32-бит в память - это очень медленно, т.к. обработчик прерывания переходит в PM (ну или Unreal, но это врядли), копирует память и возвращается в RM.
А переключения режимов - не самые быстрые операции мягко говоря.

Ну, я нормально с 15 прерыванием работаю. Правда, работаю только с mass-storage устройствами. Для OHCI эти тормоза вообще непринципиальны - там все ограничивается скоростью fullspeed (около 400 кб/с при чтении файлов). А для EHCI - вполне приемлемо получается, скорость в основном зависит от носителя. На USB-винчестере выходит 3-4 Мб/с. Я работаю в специфических условиях, вынужден экономить память, поэтому читаю/пишу посекторно, т.е. каждая SCSI команда идет на один сектор. Если же работать хотя бы кластерами, то вообще все отлично будет.

Цитата zakharo @ 12.04.11, 07:32

Ну так чего проще - все-таки поюзать функцию 87h прерывания 15h (copy extended memory)?

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

Сообщение отредактировано: shm - 12.04.11, 15:35

lsvmo, протестируй-ка.

Прикреплённый файлutest.rar (355 байт, скачиваний: 143)