BSOD при перезагрузке GDT

Да это всё конечно звучит здорово...но ты сам это пробовал делать? Как насчет того, что грабу передаются входные параметры (ну смысл загрузчика, как я понимаю, - это считать первый сектор загрузочной записи винта)...
Я просто в линухе сильно не копался по этому поводу...но думаю, что загрузчик и делает все подготовительные операции и не висит же он в памяти, а размечает эту память заново с передачей управления на 0x7C00....
Хотя похоже всё гораздо сложнее!
К тому же после перехода в реальный режим у нас память свыше метра не будет доступна! И у меня после перехода таким образом в реальный режим - подвисает винда.

 

KonstantinBart

1. Считываешь первый сектор раздела, где установлен загрузчик (lilo или grub)
2. Записываешь его по физическому адресу 0x7C00
3. Переходишь в реальный режим
4. Передаешь управление на 0x7C00
кроме того, никакие параметры grub'у не передаются
все нужные параметры уже "зашиты" в образе grub'а на диске
да, еще
про INIT# для перехода в реальный режим забудь, я только сейчас об этом подумал
INIT# приводит в частности к полной реинициализации всех целочисленных регистров, т. е они получают POWER-ON значения (а значит EIP = 0x0000FFF0, база CS = 0xFFFF0000)...этот факт не даст нам возможность перехватить управление после INIT#

 

KonstantinBart
какие новости! бутсектору параметры передаются?
тебе стоит узнать о процессе загрузки ОС.

При включении процессор работает в реальном режиме, в регистрах лежат заранее заготовленные значения. После Power-On-Self-Test BIOS ищет загрузочный диск. Как только он найден, его первый (по счету) сектор (если это HDD, то там MBR, если дискета - бутсектор) считывается в физическую память по физадресу 07c00 (в сегментной нотации, например, так: 0000:7C00).
Далее делается джамп на него и он грузит систему. А именно, конкретно у граба есть два куска загрузчика - один из них лежит в первом секторе, в другом лежит все остальное, кажется они зовутся stage 1 и stage 2. Так вот первая часть грузит вторую и передает ей управление. Появляется симпотная картинка и предложение выбрать ОС. Считыватся параметры, аргументы ядра и грузится ядро. Ему передается управление.

Тебе нужно проделать ровно то же, что делает биос - записать бутсектор по адресу 7с00 и передать на него управление. В реальном режиме, естественно.

Я не помню точно, #INIT и #RESET одно ли это и то же, но в старых процах точно через #RESET возвращались в реальный режим, когда нельзя было обнулять CR0.PE

Код (Text):

1. в реальном режиме сначала
2.  
3.     ; Готовим CMOS и область данных BIOS для дальнейшего прыжка обратно в реальный режим
4.     push es
5.       ; Запись адреса реалмодного кода в 0040:0067
6.       mov  ax, 40h
7.       mov  es, ax
8.       mov  word [es:67h], REAL_ENTRY
9.       mov  word [es:69h], cs
10.  
11.       ; Запись 0Ah в ячейку 0Fh CMOS памяти
12.       mov  al, 0fh
13.       out  70h, al
14.       nop           ; небольшая задержка
15.       mov  al, 0ah
16.       out  71h, al
17.     pop  es
18.  
19. потом в защищенном режиме:
20.     ; #RESET
21.     mov  al, 0feh
22.     out  64h, al
23.     __hlt: hlt
24.     jmp __hlt
25.  
26. REAL_ENTRY:
27. ....

 

естественно не одно и то же
INIT# не ведет к сбросу кэша (1-го и 2-го уровней), реинициализации MSR регистров, FPU/MMX/SSE регистров, MTRR регистров
остается нетронутым APIC ID регистр

 

в любом случае проще имхо сбросить CR0.PE и вернуть юзермодную IDT )

 

реалмодную :P

 

кстати, обязательно ли нужно, чтобы в RM IDTR.BASE был равен 0?

 

извиняюсь, конечно, реалмодную )

 

Спасибо за объяснение...как в общим чертах это всё выглядит (для винды по крайней мере) - я и так знал...а вот stage1 и stage2 - очевидно понятия из загрузчика Линуха....
Опять же ... что значит "передать на него управление"? тут подразумевается, что ядро и прочее находится на HDD...а у меня по заданию всё должно находится в оперативке....ну нет харда - и всё тут
Всё придется делать ручками самому и не изменяя GPL-ных файлов Линуха!

А вот насчет переключения в реальный режим.... Сейчас буду пробовать корректно перейти в него...без подвисаний винды.

 

Еще SMBASE не меняется

 

Фигня это. Выставляем проц как AP и используем связку - INIT, потом SIPI, если вектор SIPI равен XX, то управление передастся на XX000h, где мы можем подготовить свой код.

З.Ы. INIT# лучше посылать ч/з контроллер клавы (out 64h), т.к он достаточно медленный - у нас есть время послать своему процу SIPI через APIC. Если посылать INIT# сразу ч/з APIC - то реакция моментальная - проц сразу перегружается, мы не успеваем отправить SIPI вдогонку. Тут надо извращаться - делать так, чтобы в рез-те выполения одной команды
посылались последовательно INIT и SIPI - выполнимо, но извратно, мне не понравилось

 

В пределах первого метра записываешь код (код_1) (для реалмода)-аналог загрузчика ядра линукса. Задача этого куска-передать как надо управление ядру Линукса.
Так же в пределах первого метра код (код_2) по переходу из защищенного режима в реальный и передаче управления на код_1.
Из ядра винды делаешь прыжок на код_2. И если ты все правильно написал то все будет тип топ.
Сразу после выхода в реал сделай дальний прижок на след. команду и проинициализируй регистры стека.

 

Этот код вызывает не RESET#, а INIT#

 

извини меня, а как это все в ОЗУ попадает? )
или это какое-то гипотетическое задание?
Medstrax

слишком много условностей
нельзя однозначно сказать, будет в итоге нужная последовательность действий или нет

а не RESET# ли это будет?
INIT# можно сгенерировать на шине
через порты 92h, CF9h (по крайней мере на современных интеловских чипсетах)

сложно
если все через CR0 делать, линейный адрес инструкции, которая идет после инструкции сброса PG и PE, должен совпадать с физическим адресом инструкции

 

у меня нужная последовательность получалась всегда

Предлагаю проверить. Выставь в APIC_BASE_MSR проц как AP и выполни пресловутые
out 64h... У меня в рез-те был зависон, т.к проц ждет SIPI.
Если бы посылался RESET# - APIC_BASE_MSR принимал бы дефолтовое значение,
т.е. проц бы стал BP.
Оч возможно, что реакция контроллера клавы на out... специфичная для каждого чипсета

 

я за тебя рад конечно, но это все равно не решение
решение - это когда работает без "если"
имхо, конечно

ОК
можно проверить
потом отпишусь

 

сейчас проверил еще на одной машинке
чипсет 945, мать Gigabyte GA-8I945P-G-RH
рез-т тот же:
если проц AP - после out... зависон
если BP - перзагрузка
получается все-таки INIT#

 

а ты уверен что ядро линуха само не считывает данных с харда?

то есть без подвисаний винды? ты уповаешь на то что винда после всего этого будет еще и нормально работать?

 

Если честно - то я его не копал...но дпустим boot-дискам с Линухом хард не нужен.....идет работа с CD-диском и оперативкой...это же как то разрулили?

да нет конечно - я же говорю, что она виснет ... но похоже тут главная траблая в том, что все новые дескрипторы я установил, а селекторы для них для сегментов кода, данных и стека - нет (остались системные)!

 

ясное дело, что линух грузит драйвера/конфиги с того носителя с которого загрузили. но явно не с RAM'a, хотя может есть такие дистрибутивы.

а какой результат ты ожидаешь? bsod?