На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Перед отправкой сообщения внимательно прочтите правила раздела!!!
1. Запрещается обсуждать написание вирусов, троянов и других вредоносных программ!
2. Помните, что у нас есть FAQ раздела Assembler и Полезные ссылки. Посмотрите, возможно, там уже имеется решение вашего вопроса.

3. Настоятельно рекомендуем обратить особое внимание на правила форума, которые нарушаются чаще всего:
  3.1. Заголовок темы должен кратко отражать её суть. Темы с заголовками типа "Срочно помогите!" или "Ассемблер" будут отправляться в Корзину для мусора.
  3.2. Исходники программ обязательно выделяйте тегами [code]...[/code] (одиночные инструкции можно не выделять).
  3.3. Нежелательно поднимать старые темы (не обновлявшиеся более года) без веской на то причины.

Не забывайте также про главные Правила форума!

Добро пожаловать и приятного вам общения!!! ;)
 
Модераторы: Jin X, Qraizer
Страницы: (51) « Первая ... 49 50 [51]   ( Перейти к последнему сообщению )  
> Желающим USB под ДОС , Welcome!!!
    Программный таймер - всегда прерываемый. В данном случае это организованный в программе счётчик полученных периодических прерываний от HPET.
    При каждом SMI он будет остановлен, как и процесс, время выполнения которого (без учёта прерываний) я хочу знать.

    Цитата shm @
    Кстати, через ACPI можно отключить все SMI, которые связаны с APM.
    Понял. Спасибо за информацию.

    И ещё вопрос. Не совсем по теме, правда.
    Я не нашёл на этом форуме ни одной статьи о среде UEFI. Это странно. Уже то, что на любую флешку с FAT32 можно не глядя положить файл \EFI\BOOT\BOOTx64.EFI - и она тут же станет загрузочной, всё намного упрощает. Далее, код запускается сразу в 64-битном Long Mode, без каких-либо ограничений. Чтобы поднять остальные ядра в этом режиме, никаких таблиц больше создавать не нужно. Почему я не вижу радости?
      Цитата t0serg @
      Программный таймер - всегда прерываемый. В данном случае это организованный в программе счётчик полученных периодических прерываний от HPET.
      При каждом SMI он будет остановлен, как и процесс, время выполнения которого (без учёта прерываний) я хочу знать.

      У HPET есть 64х битовый счтечик (можно считать через mmio-регистр), он нарастает независимо от SMI.

      Добавлено
      Цитата t0serg @
      Я не нашёл на этом форуме ни одной статьи о среде UEFI. Это странно. Уже то, что на любую флешку с FAT32 можно не глядя положить файл \EFI\BOOT\BOOTx64.EFI - и она тут же станет загрузочной, всё намного упрощает. Далее, код запускается сразу в 64-битном Long Mode, без каких-либо ограничений. Чтобы поднять остальные ядра в этом режиме, никаких таблиц больше создавать не нужно. Почему я не вижу радости?

      С UEFI никогда не работал. По мне это вещь скорее вредная, чем полезная, пролоббированная мелкомягкими и с костылями переносящаяся на другие платформы. Всегда загружался только через свой классический загрузчик. Перейти в PM32(64) - нск. строк кода.
      Сообщение отредактировано: shm -
        Иначе говоря, мне нужно знать время выполнения участка кода без времени, потраченного на обработку SMI. И есть два возможных решения: 1) запретить SMI; 2) оставить SMI, но использовать для счёта времени не HPET, а аналог переменной-счётчика DOS по адресу 0040:006C - тот счётчик останавливался при запрете прерываний или на время их обработки, что и требуется для получения правильного результата. HPET у меня тикает раз в 70 нс, это 240 тактов процессора. Думаю, SMI отнимет куда больше.

        Цитата shm @
        С UEFI никогда не работал. По мне это вещь скорее вредная, чем полезная, пролоббированная мелкомягкими
        Intel это. Мелкомягким сделали предложение, от которого нельзя отказаться. Они не настолько мягкие, чтобы сначала разрешить всё, а потом самим же пытаться запретить. Такое бывает лишь при смене руководства.

        Цитата shm @
        и с костылями переносящаяся на другие платформы.
        Да уж. Проще добавить костыль, чем выкинуть лишние куски и поправить код.

        Цитата shm @
        Всегда загружался только через свой классический загрузчик. Перейти в PM32(64) - нск. строк кода.
        Понимаю.
          Цитата t0serg @
          а аналог переменной-счётчика DOS по адресу 0040:006C - тот счётчик останавливался при запрете прерываний или на время их обработки, что и требуется для получения правильного результата.

          Для этого нужен обработчик прерывания.

          Добавлено
          Цитата t0serg @
          Intel это.

          Изначально да. Но потом туда напихали кучу идей от MS.

          Добавлено
          Цитата t0serg @
          Проще добавить костыль, чем выкинуть лишние куски и поправить код.

          Понимаешь в чем суть: тот же ACPI созданный при активном участии MS повторяет модель оборудования Windows.
          Сообщение отредактировано: shm -
            Цитата shm @
            Для этого нужен обработчик прерывания.
            Да. Но это на крайний случай. Если не получится отключить SMI, попробую запускать код на другом ядре процессора и мерить время выполнения там.

            Цитата shm @
            тот же ACPI созданный при активном участии MS повторяет модель оборудования Windows.
            UEFI – не MS Windows. Скорее уж это MS-DOS (BIOS+BDOS). Как в среде MS-DOS, тут только мы решаем, что использовать, а что нет. И как использовать – тоже.
            Драйвер под Windows – это драйвер только под Windows. Драйвер под UEFI – это драйвер для Windows, Linux, KolibriOS, множества ненаписанных ОС и самодостаточных программ.

            Мне интересно, есть ли объективные причины неприятия UEFI или всё дело в том, что мелкомягкие расплачиваются за монополию своего имени?

            P.S. Кто виноват, что файл EFI, через который грузится Linux, начинается с "MZ" и в нём можно прочитать "This program cannot be run in DOS mode"? У меня ничего такого нет, замечательно грузится чистый COFF.
              С вашего позволения присоединюсь, тк. тема поддержки 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 прошу в тему (или в личку).
                Скептически отношусь ко всем этим шаманствам с BIOS.
                Цитата Noiser7 @
                из ОС отвалится поддержка USB клавиатуры и мыши и еще ее придется делать.

                Сделать поддержку мышки по равнению с хост-контроллером - капля в море.
                Сообщение отредактировано: shm -
                  Цитата shm @
                  Скептически отношусь ко всем этим шаманствам с BIOS.


                  Ну почему сразу шаманствам? Пока все получается.
                  Цитата shm @
                  Сделать поддержку мышки по равнению с хост-контроллером - капля в море.



                  А делать приходится не только поддержку мыши, но и клавиатуры и др. устройств.
                  Больно красивое решение получается и не влияет на поддержку других устройств,
                  т.к. не нужно отбирать контроллер у BIOS.
                    Цитата Noiser7 @
                    Ну почему сразу шаманствам? Пока все получается.

                    Я понимаю, что пока получается. Просто, если потребуется запустить на другой материнке с другим BIOS'ом, то будет fail. Хост-контроллеры по крайней мере стандартизованы.
                    Цитата Noiser7 @
                    но и клавиатуры

                    Поддержка клавиатуры, ровно как и мыши, реализуется очень просто и в минимальное время.
                    Цитата Noiser7 @
                    др. устройств

                    Каких?
                    Сообщение отредактировано: shm -
                      Цитата shm @
                      Каких?

                      Ну, например, USB Floppy. Но это так, лирика...

                      Вообще мне бы не очень хотелось вступать в полемику о преимуществах того или иного способа доступа к USB. Понятно,что у каждого есть определенные достоинства и недостатки.
                      Интересен обмен опытом с теми,кто пробовал описанный мной способ или хотел бы попробовать.
                        Доброго времени суток.

                        Не совсем под dos, но близко.
                        Требуется подключить к некоторой плате (имеющей USB 2.0 host контроллер) USB Mass Storage.
                        На Full-speed всё работает, а вот на High-speed начинаются проблемы.
                        1. Обнаружилось, что после инициализации хоста для прохождения энумерации требуется некоторая задержка. Так и должно быть?
                        2. (Самое важное) На одной из имеющихся флешек не проходит энумерация даже с этой задержкой. Запрос GET_DESCRIPTOR проходит, а SET_ADDRESS завершается NAK'ом на SETUP (!) фазе.
                        Такого быть не должно в принципе, но если происходит, то что это может означать?
                        Может я слишком быстро шлю запросы, т. к. миллисекундные задержки между запросами как-бы решают проблему.

                        Спасибо.
                        0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                        0 пользователей:
                        Страницы: (51) « Первая ... 49 50 [51] 


                        Рейтинг@Mail.ru
                        [ Script execution time: 0,0736 ]   [ 15 queries used ]   [ Generated: 28.03.24, 10:50 GMT ]