Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.137.161.222] |
|
Страницы: (51) « Первая ... 49 50 [51] ( Перейти к последнему сообщению ) |
Сообщ.
#751
,
|
|
|
Программный таймер - всегда прерываемый. В данном случае это организованный в программе счётчик полученных периодических прерываний от HPET.
При каждом SMI он будет остановлен, как и процесс, время выполнения которого (без учёта прерываний) я хочу знать. Понял. Спасибо за информацию. И ещё вопрос. Не совсем по теме, правда. Я не нашёл на этом форуме ни одной статьи о среде UEFI. Это странно. Уже то, что на любую флешку с FAT32 можно не глядя положить файл \EFI\BOOT\BOOTx64.EFI - и она тут же станет загрузочной, всё намного упрощает. Далее, код запускается сразу в 64-битном Long Mode, без каких-либо ограничений. Чтобы поднять остальные ядра в этом режиме, никаких таблиц больше создавать не нужно. Почему я не вижу радости? |
Сообщ.
#752
,
|
|
|
Цитата t0serg @ Программный таймер - всегда прерываемый. В данном случае это организованный в программе счётчик полученных периодических прерываний от HPET. При каждом SMI он будет остановлен, как и процесс, время выполнения которого (без учёта прерываний) я хочу знать. У HPET есть 64х битовый счтечик (можно считать через mmio-регистр), он нарастает независимо от SMI. Добавлено Цитата t0serg @ Я не нашёл на этом форуме ни одной статьи о среде UEFI. Это странно. Уже то, что на любую флешку с FAT32 можно не глядя положить файл \EFI\BOOT\BOOTx64.EFI - и она тут же станет загрузочной, всё намного упрощает. Далее, код запускается сразу в 64-битном Long Mode, без каких-либо ограничений. Чтобы поднять остальные ядра в этом режиме, никаких таблиц больше создавать не нужно. Почему я не вижу радости? С UEFI никогда не работал. По мне это вещь скорее вредная, чем полезная, пролоббированная мелкомягкими и с костылями переносящаяся на другие платформы. Всегда загружался только через свой классический загрузчик. Перейти в PM32(64) - нск. строк кода. |
Сообщ.
#753
,
|
|
|
Иначе говоря, мне нужно знать время выполнения участка кода без времени, потраченного на обработку SMI. И есть два возможных решения: 1) запретить SMI; 2) оставить SMI, но использовать для счёта времени не HPET, а аналог переменной-счётчика DOS по адресу 0040:006C - тот счётчик останавливался при запрете прерываний или на время их обработки, что и требуется для получения правильного результата. HPET у меня тикает раз в 70 нс, это 240 тактов процессора. Думаю, SMI отнимет куда больше.
Цитата shm @ Intel это. Мелкомягким сделали предложение, от которого нельзя отказаться. Они не настолько мягкие, чтобы сначала разрешить всё, а потом самим же пытаться запретить. Такое бывает лишь при смене руководства.С UEFI никогда не работал. По мне это вещь скорее вредная, чем полезная, пролоббированная мелкомягкими Цитата shm @ Да уж. Проще добавить костыль, чем выкинуть лишние куски и поправить код.и с костылями переносящаяся на другие платформы. Цитата shm @ Понимаю. Всегда загружался только через свой классический загрузчик. Перейти в PM32(64) - нск. строк кода. |
Сообщ.
#754
,
|
|
|
Цитата t0serg @ а аналог переменной-счётчика DOS по адресу 0040:006C - тот счётчик останавливался при запрете прерываний или на время их обработки, что и требуется для получения правильного результата. Для этого нужен обработчик прерывания. Добавлено Цитата t0serg @ Intel это. Изначально да. Но потом туда напихали кучу идей от MS. Добавлено Цитата t0serg @ Проще добавить костыль, чем выкинуть лишние куски и поправить код. Понимаешь в чем суть: тот же ACPI созданный при активном участии MS повторяет модель оборудования Windows. |
Сообщ.
#755
,
|
|
|
Цитата shm @ Да. Но это на крайний случай. Если не получится отключить SMI, попробую запускать код на другом ядре процессора и мерить время выполнения там.Для этого нужен обработчик прерывания. Цитата shm @ UEFI – не MS Windows. Скорее уж это MS-DOS (BIOS+BDOS). Как в среде MS-DOS, тут только мы решаем, что использовать, а что нет. И как использовать – тоже.тот же ACPI созданный при активном участии MS повторяет модель оборудования Windows. Драйвер под Windows – это драйвер только под Windows. Драйвер под UEFI – это драйвер для Windows, Linux, KolibriOS, множества ненаписанных ОС и самодостаточных программ. Мне интересно, есть ли объективные причины неприятия UEFI или всё дело в том, что мелкомягкие расплачиваются за монополию своего имени? P.S. Кто виноват, что файл EFI, через который грузится Linux, начинается с "MZ" и в нём можно прочитать "This program cannot be run in DOS mode"? У меня ничего такого нет, замечательно грузится чистый COFF. |
Сообщ.
#756
,
|
|
|
С вашего позволения присоединюсь, тк. тема поддержки USB под DOS мне интересна. Занимался данным вопросом и давно слежу за этой темой.
Была поставлена задача сделать поддержку в среде MS-DOS USB DVD-ROMа.Сделать стандартными уже имеющимися средствами не получалось, а разбираться с UHCI xHCI и тд. было уж очень неохота и не было времени. Кроме того при программировании контроллера из ОС отвалится поддержка USB клавиатуры и мыши и еще ее придется делать. Решение пришло с неожиданной стороны. Современные UEFI BIOS уже имеют внутри себя драйвер USB, который обеспечивает поддержку Legacy устройств в тч поддерживают флешку в DOS (если загрузиться с ней). Для взаимодействия DOS кода с данным драйвером используется уже упомянутый SMI.Данный API не документирован (во всяком случае я нигде ничего не нашел, но как я понял довольно стар и стандартен (я смотрел AMI BIOS) хотя отдельные функции и меняются от версии к версии. Со некоторыми функциями этого API удалось разобраться. Также был написан почти полноценный драйвер DVD-ROM использующий обработчик Int 13 функция AX=50D7h. Функция описана в стандарте EDD-3 и позволяет посылать пакеты напрямую устройству. К сожалению данная функция поддерживается далеко не всеми BIOS. В планах модернизировать драйвер для организации доступа к устройству именно непосредственно через SMI средствами драйвера BIOS. В дальнейшем возможно создание драйверы флешки/жесткого диска USB с поддержкой хот-плага не прерывающего legacy-эмуляцию в BIOS. Но осталось понять насколько данный API стандартен для разных плат. В связи этим, интересующихся данным способом поддержки USB в DOS или обладающих документацией по данному API прошу в тему (или в личку). |
Сообщ.
#757
,
|
|
|
Скептически отношусь ко всем этим шаманствам с BIOS.
Цитата Noiser7 @ из ОС отвалится поддержка USB клавиатуры и мыши и еще ее придется делать. Сделать поддержку мышки по равнению с хост-контроллером - капля в море. |
Сообщ.
#758
,
|
|
|
Цитата shm @ Скептически отношусь ко всем этим шаманствам с BIOS. Ну почему сразу шаманствам? Пока все получается. Цитата shm @ Сделать поддержку мышки по равнению с хост-контроллером - капля в море. А делать приходится не только поддержку мыши, но и клавиатуры и др. устройств. Больно красивое решение получается и не влияет на поддержку других устройств, т.к. не нужно отбирать контроллер у BIOS. |
Сообщ.
#759
,
|
|
|
Цитата Noiser7 @ Ну почему сразу шаманствам? Пока все получается. Я понимаю, что пока получается. Просто, если потребуется запустить на другой материнке с другим BIOS'ом, то будет fail. Хост-контроллеры по крайней мере стандартизованы. Цитата Noiser7 @ но и клавиатуры Поддержка клавиатуры, ровно как и мыши, реализуется очень просто и в минимальное время. Цитата Noiser7 @ др. устройств Каких? |
Сообщ.
#760
,
|
|
|
Цитата shm @ Каких? Ну, например, USB Floppy. Но это так, лирика... Вообще мне бы не очень хотелось вступать в полемику о преимуществах того или иного способа доступа к USB. Понятно,что у каждого есть определенные достоинства и недостатки. Интересен обмен опытом с теми,кто пробовал описанный мной способ или хотел бы попробовать. |
Сообщ.
#761
,
|
|
|
Доброго времени суток.
Не совсем под dos, но близко. Требуется подключить к некоторой плате (имеющей USB 2.0 host контроллер) USB Mass Storage. На Full-speed всё работает, а вот на High-speed начинаются проблемы. 1. Обнаружилось, что после инициализации хоста для прохождения энумерации требуется некоторая задержка. Так и должно быть? 2. (Самое важное) На одной из имеющихся флешек не проходит энумерация даже с этой задержкой. Запрос GET_DESCRIPTOR проходит, а SET_ADDRESS завершается NAK'ом на SETUP (!) фазе. Такого быть не должно в принципе, но если происходит, то что это может означать? Может я слишком быстро шлю запросы, т. к. миллисекундные задержки между запросами как-бы решают проблему. Спасибо. |