Драйвер перехода в реальный режим

Всем привет!
Существуют ли драйвера, осуществляющие переход в реальный режим (разумеется, с закрытием ядра запущенной системы)?
Если нет, то почему, а если да - можно ли их где-нибудь найти?

 

AFAIK из protected mode уже нельзя переключится в real. Но, даже если чип это позволяет, ни в какой OS такого драйвера не будет т.к. слетит сразу всё ядро, драйвера, управление памятью и т.д.

 

s0larian

Можно.

Не сразу. Но глюки будут.

Вообщем зачем нужен реальный режим? Естьже виртуальный, он лучше. А так винда в часности 3.11 и 9x использовали функции боса. Даже функция есть для вызова прерываний биоса есть.

 

Начиная с 386 проца нет документированого прямого способа переключиться в real mode. Только reset.

 

Странно, а вот В.Юров в книге "ASSEMBLER" пишет, что для перехода из "защищённого" в "реальный" режим нужно всего-то сбросить нулевой бит cr0. Примерно так:

Код (Text):

1. mov eax,cr0
2. and al,0feh
3. mov cr0,eax

 

Partner

Во-первых способ есть во-вторых документированный.

INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986
Page 210 of 421
14.5 Switching Back to Real-Address Mode

http://microsym.com/editor/assets/386intel.pdf

Грубо говоря установка PE=0. Несчитая подготовки регистров.
В-третьих ресет тоже спопоб и тоже документированный.

 

Сорри, был неправ. Действительно можно.

 

Pavia, так а в современном проце это работает? И в доке описано?

 

s0larian
Конечно работает. Возьму свежий мануэл на процессор там тоже самое написанно.
Но еси ты соберешься писать это самому. То нужно будет учесть как на такое отриагирует система. Что будет с прерываниями. Возможно еще что-то.

 

Partner Ты наверное хотел сказать что начиная с 386 он есть, а вот на 286 - да, только ресет

 

Спасибо за мысли
Вообще логично, что такой драйвер не нужен самой системе, так как после его использования она слетит гарантированно...
Собственно, такой вопрос родился из следующей задачи: я пытаюсь загрузить "на горячую" WinXP из Linux без ребута системы
В принципе для этого есть стандартная связка kexec => grub4dos => WinXP.. однако она почему-то крашится на новом железе (причём предположительно проблема именно в работе grub4dos, т.к. на том же железе kexec спокойно подгружает новое ядрo Linux поверх старого).
Потому стал искать пути переключиться из защищённого режима в реальный - тогда AFAIK можно без проблем стартовать ядро новой системы (той же WinXP) без всяких заморочек с grub4dos..

 

Не совсем так

 

Medstrax
А как? До сих пор был уверен, что так и есть.

 

А я думаю (теоритически), что не слетит. Ведь она не слетает по аппаратному ресету или сбою питания. Вероятность, конечно, есть. Ну а так... Запрет прерываний, корректировка лимитов в скрытых частях сегментных регистров и сброс PE - реальный режим. Потом реинит PIC, только не ясно что там с таблицей векторов RM будет после виндовса. А сама винда, по идее, должна потом это расценить как некорректное завершение работы.

add:
а переход в RM через сброс процессора описан у Фроловых. Там они, имея ввиду 286-й, повествуют и утверждают, что нет иного способа, кроме посылки нужной команды контроллеру клавиатуры.

 

А восстановить назад получится?)

 

Существовала такая практика - либо ч/з контроллер клавы либо ч/з triple fault вызывался
INIT#, вернее triple fault напрямую к INIT#-у не приводит, его чипсет генерит после того как проц выставляет на шину сигнал, что он в дауне, но не суть важно... Перед этим в CMOS записывалось одно из "магических" чисел, к сожалению ни адреса ячйки CMOS, ни самих чисел моя память не сохранила . Биос при инициализации проверяет эту ячейку, и если там то что надо - осуществляет передачу управления по адресу, записанному где-то области данных биоса, точнее опять же не помню. Подробности найти не составит труда
Добавлю - с RESET# такая мулька не проходит

 

Medstrax
Ну так это и есть перезагрузка. =)
Судя по манам проц одинаково реагирует на INIT# и RESET#. Переходит в RM и начинает выполнять код биоса. А он уже решает что дальше делать.

Писать надо в CMOS регистр 0Fh - Shutdow Code - код используется BIOS'ом для определения причины предыдущего завершения работы. И выполнения соответствующих действий. Табличка от Гука но лучше проверять на конкретном БИОСе. 00, 05 и 0Ah есть везде.

00- аппаратный или программный сброс
01-размер памяти определен
02-тест памяти пройден
03-тест памяти выявил ошибки
04- POST завершен идет загрузка системы
05*- Переход JMP [40h:67h] с инициализацией контроллера прерываний
06-тест защищенного режима пройден
07 -тест защищенного режима выявил ошибки
08- ошибка при определении размера памяти.

0A*- Переход JMP [40h:67h] без инициализацией контроллера прерываний. Используется для одного из видов инициализации мультипроцессорной системы.

Barbos

У Фроловых есть разные главы. В одной из них рассказывается про 286 и для него кроме как через ресет нет способа.
А в другой рассказывается про 386 и 486. В качестве перехода RM приведен пример сброса бита PE.

Виндоусе настраивает систему на APIC. Плюс все устройства под него настроены. Переводить на PIC немного сложно, но возможно. А вот таблицу прерываний он мог сбить, но я уверен что не сбивает.

 

Ну если быть точным, то различий между инициализацией проца по INIT# и RESET# дофига,
в тех же манах немало написано по этому поводу. Что касается предмета обсуждения (не сабжа, нет, заколустали русский язык коверкать ), то повторюсь - с помощью INIT# есть возможность передать управление своему коду в реальном режиме, с помощью RESET# - нет. А как это назвать - перезагрузка или как-то иначе - сути дела не меняет.

 

Dzutte

По-моему проще все-таки ребутнуться Тебе все равно придется делать действия, которые при ребуте автоматически выполняются.

 

Medstrax
Вот тебе строчка из манов.

Переведу. Запрос процессора по контакту INIT# вызывает аналогичные отклик от него, как харварный ресет.
Как видим одно и тоже.

Как видим передача будет в любом случии биосу, а он уже в зависимости от настроек будет выполнять соответствующий код.
Так что все работать будет.