[11] - процесс загрузки

Процесс загрузки.

То, что я до сих пор сделал пока рассчитано только на работы с дисками 1,4Мб, то есть с флопами. Это конечно ограничение в некоторой степени, но пока система еще далеко не готова, этого достаточно. Естественно это еще не окончательный вариант. Да и можно ли говорить об окончательности программных продуктов? Нет предела совершенству.

В обязанности бутсектора входит следующее:

1. Загрузить с диска дополнительные части кода и служебную информацию файловой системы.
2. Загрузить с диска файл сценария (конфигурации) загрузки.
3. Загрузить с диска ядро и модули.
4. Перейти в защищенный режим.
5. Передать управление ядру.

Если с первым и двумя последними пунктами все просто и компактно, то второй и третий пункт требуют возможности работы с файловой системой, а третий пункт помимо этого должен знать структуру бинарных форматов. На все это не хватает 512 байт, отводимых для бутсектора. Наш бутсектор занимает больше - один килобайт.
В файловой системе EXT2 с этим не возникает никаких проблем, поскольку первый килобайт файловой системы не используется.
В FAT это немного сложнее. Служебная структура, именуемая Boot Sector Record (BSR), содержит в себе все необходимые поля для выделения для загрузочного сектора места более чем 512 байт. Но как это сделать при форматировании, стандартными средствами, я не нашел. И если формат диска не соответствует каким-то внутренним представлениям Windows, то содержимое такого нестандартного диска может быть испорчено. Выход был найден случайно. Как оказалось утилита format хоть и не имеет таких параметров командной строки, но перед форматированием берет информацию из BSR. И если предварительно заполнить эту структуру (с нужными нам параметрами), а потом уже форматировать, то все получается так, как хочется нам. Таким образом, у меня получилось сделать диск, у которого два сектора зарезервированы (там будет размещаться boot), и одна копия FAT.

Ну теперь давайте по порядку рассмотрим все этапы работы бутсектора.


Загрузка с диска дополнительной части кода и служебной информации файловой системы.

Бутсектор загружается БИОСом по адресу 0:7c00h занимает он 512 байт. Память начиная с адреса 0:7e00h свободна. но в эту память мы загрузим второй сектор бута. Одновременно загружается информация необходимая для обслуживания файловой системы. Для EXT2 дополнительно необходимо загрузить два килобайта (суперблок и дескрипторы групп), для FAT немного больше - 4,5 килобайта (первая копия FAT).
Адрес 0:7e00h идентичен адресу 7e0h:0. Вторым вариантом мы и будем пользоваться, потому что наша процедура загрузки секторов размещает их по сегментному адресу, хранящемуся в es.
В ax номер сектора, с которого начинается чтение (первый сектор является нулевым (каламбур . И далее все зависит от файловой системы.
Для EXT2 загружается 5 секторов - второй сектор бутсектора (1 сектор), суперблок файловой системы (2 сектора) и дескрипторы групп (2 сектора).
Для FAT загружается 10 секторов - второй сектор бутсектора (1 сектор), таблица FAT - 9 секторов (такой размер она имеет на floppy дисках).
Все. первый пункт загрузки выполнен.

Функции обслуживания файловых систем имеют одинаковый интерфейс. Cобственно их всего две fs_init и fs_load_file. Естественно у них различаются реализации, но в процессе компиляции выбирается используемая файловая система. Для совместного использования нам никак не хватит одного килобайта, да и не за чем это.


Загрузка с диска файла сценария (конфигурации) загрузки.

Из-за сложности VFAT (FAT с длинными именами) он не реализован. Все имена на диске FAT должна иметь формат 8.3
В файловой системе FAT я не оперирую принятыми в MS системах именами дисков и при указании пути использую путь относительно корневой директории диска (как это делается в юникс системах).

Файл конфигурации у нас пока называется boot.rc и находится в каталоге /etc. Формат у этого файла достаточно нестрогий. Из-за нехватки места в boot секторе там сделана реакция только на ключевые слова, которыми являются:

* kern[el] - файл ядра;
* modu[le] - файл модуля;
* #end - конец файла конфигурации.

Использование этих слов в другом контексте недопустимо.

Предварительно проинициализировав файловую систему

call fs_init

Мы загружаем этот файл с диска.

mov si, boot_config
call fs_load_file

...

boot_config:
db '/etc/boot.rc', 0

Содержимое файла конфигурации такое:

kernel /boot/kernel
#end

Модулей у нас пока никаких нет, да и ядро еще в зачаточном состоянии. Но речь сейчас не об этом.


Загрузка с диска ядра и модулей.

Про этот момент я не буду особо расписывать, желающие могут посмотреть в исходниках, которые в скором времени появятся на сайте.
Скажу только, что программа анализирует файл конфигурации, в соответствии с ключевыми словами загружает ядро (которое может быть в единственном экземпляре) и любое количество модулей. Общий объем ядра и модулей ограничен свободным размером базовой памяти (около 600к).

Перейдем к предпоследнему пункту.


Переход в защищенный режим.

Бутсектор не особо беспокоится об организации памяти в системе - это забота ядра. Для перехода в защищенный режим он описывает всего два сегмента: сегмент кода и сегмент данных. оба сегмента имеют базовый адрес - 0 и предел в 4 гигабайта (это нам пригодиться для проверки наличия памяти).

Перед переходом в защищенный режим нам необходимо включить адресную линию A20. По моим сведениям этот механизм ввели в пору 286 для предотвращения несанкционированных обращений к памяти свыше одного мегабайта (непонятно зачем?). Но поскольку это имеет место быть - нам это нужно обрабатывать, иначе каждый второй мегабайт будет недоступен. Делается это почему-то через контроллер клавиатуры (еще одна загадка).
После этого можно переходить в защищенный режим.
В регистр gdtr загружается дескриптор GDT.
Очищается регистр флагов.
Включается защищенный режим. Не смотря на то, что процессор уже находится в защищенном режиме, мы пока работаем в старых адресах. Чтобы от них уйти нам нужно сделать дальный переход в адреса защищенного режима.
16 в этом адресе перехода - это не сегмент. Это селектор сегмента кода.
После всего этого мы инициализируем сегментные регистры соответствующими селекторами, в том числе и сегмент стека, но указатель стека у нас не меняется, только теперь он становится 32-х битным.
Это GDT - Глобальная таблица дескрипторов. Здесь всего два дескриптора, но во избежание ошибок в адресации обычно вводится еще один дескриптор - нулевой, который не считается допустимым для использования. Мы не будем резервировать для него место специально, просто начало таблицы сместим на 8 байт выше.
А это содержимое регистра GDTR. Здесь устанавливается предел и базовый адрес дескриптора. обратите внимание на базовый адрес, здесь происходит резервирование нулевого дескриптора.

Теперь процессор находится в защищенном режиме и уже не оперирует сегментами, а оперирует селекторами. Селекторов у нас всего три. Нулевой - недопустим. восьмой является селектором данных и шестнадцатый - селектором кода.

После этого управление можно передать ядру. дальше со всем этим будет разбираться оно.


Передача управления ядру.

Здесь вообще все просто. Когда мы загрузили ядро, в файле ядра мы определили адреса сегмента кода и сегмента данных. Не смотря на то, что ядро имеет вполне конкретные смещения в сегменте (которые задаются при компиляции), код инициализации ядра рассчитан на работу без привязки к адресам. Это нужно для определения количества памяти, после перевода ядра на свои адреса доступ ко всей памяти будет для ядра затруднен в связи с включением механизма страничного преобразования.
Итак, переходим к выполнению кода ядра.
В этом фрагменте в eax записывается адрес начала кодового сегмента ядра.
Так как сегмент кода у нас занимает всю виртуальную память, нам не важно где находится ядро (хотя мы знаем, что оно было загружено в базовую память). Мы просто передаем ему управление.

[12] - определение количества памяти

Определение количества памяти через BIOS.

Ну, начнем с исторических функций.
Давным-давно, когда даже Билл Гейтс говорил что 640 килобайт хватит всем, но не у всех были эти 640 килобайт. в биосах существовала функция определения количества базовой памяти.

int 12h

Выходные параметры:

* ax - размер базовой памяти в килобайтах.

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

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

int 15h fn 88h

Входные параметры:

* ah = 88h

Выходные параметры:

* ax - размер расширенной памяти в килобайтах.

Возможно из за архитектуры 286-х процессоров (которым размер шины адреса не позволяет иметь больше чем 16 мегабайт памяти) эта функция часто имеет аналогичное ограничение и результат в ax не может превышать 3с00h (Что составляет 15Мб).

Но, опять таки, появились новые процессоры. 16 мегабайт стало мало. Вследствие этого появилась еще одна функция BIOS:

int 15h fn e801h

Входные параметры:

* ax = e801h.

Выходные параметры:

* ax - размер расширенной памяти в килобайтах до 16Mb;
* bx - размер расширенной памяти в блоках по 64к свыше 16Мб;
* cx - размер сконфигурированный расширенной памяти в килобайтах до 16Mb;
* dx - размер сконфигурированной расширенной памяти в блоках по 64к свыше 16Мб.

Не знаю, что означает сконфигурированная память. Так написано в описании.

Здесь производители BIOS видимо оказались неединодушны. Некоторые версии в ax и bx возвращают 0, это значит что размер памяти следует определять из cx, dx.

Но видимо и 4 гигабайт оказалось мало. В новых BIOS появилась еще одна функция.

int 15h fn e820h

Входные параметры:

* eax = e820h;
* edx = 534d4150h ('SMAP');
* ebx - смещение от начала карты памяти;
* eсx - Размер буфера;
* es:di - Адрес буфера для размещения карты памяти.

Выходные параметры:

* eax - 534d4150h ('SMAP');
* ebx - следующее смещение от начала карты памяти, если = 0, то вся карта передана;
* ecx - Количество возвращенных байт;
* буфер заполнен информацией;

Эту функцию нужно вызывать в цикле до тех пор, пока не будет прочитана вся карта памяти.

Формат структуры таков:
Поле type может содержать следующие значения:

* 1 - Доступно для использования операционной системой;
* 2 - Зарезервировано (например, ROM);
* 3 - ACPI reclaim memory (Доступно для операционной системы после прочтения таблицы ACPI;
* 4 - ACPI NVS memory (Операционной системе требуется сохранять эту память между NVS сессиями).

Проверить как работает эта функция у меня не получилось, мой BIOS ее не поддерживает.
Но в заключение скажу следующее. Все функции в случае ошибки (если функция не поддерживается) возвращают установленный флаг cf. В случае отсутствия новых функций необходимо обращаться к более старым.

Функции BIOS не работают в защищенном режиме, поэтому все эти операции необходимо производить еще до перехода в защищенный режим.


Определение размера памяти другими способами:

Помимо функций BIOS есть еще много других способов.

Самый простой - помереть память самому. Делается это из защищенного режима, страничное преобразование должно быть выключено, адресная линия A20 должна быть включена.
Можно мереть от нуля, но поскольку в первом мегабайте есть дыры (видеопамять, биосы, просто дыры), удобнее делать это начиная с первого мегабайта.

Вовсе не обязательно проверять каждый байт, достаточно проверять один байт на какое-то определенное количество памяти. Определенным количеством памяти можно посчитать мегабайт, но лучше (хотя и медленнее) за единицу памяти принять одну страницу памяти (4к).

Во избежание неприятностей память лучше не разрушать, а восстанавливать в первоначальном виде. делается это примерно так:
Если после этого в eax содержится то же значение, которое было до того, значит память присутствует по данному адресу. Если возвратилось 0ffffffffh, значит память отсутствует, если же что ни будь другое - то это может быть ROM, хотя после мегабайта вы вряд ли встретите какой либо BIOS. В любом случае если память по текущему адресу не обнаружена, значит, память закончилась и дальше искать чревато... существуют еще различные типы памяти (ACPI например) которую не стоит трогать.

Из защищенного режима можно воспользоваться содержимым CMOS, некоторые ячейки в нем BIOS заполняет определенными при начальном тесте системы значениями. Но здесь все не так однозначно как хотелось бы. Разные версии BIOS могут хранить значения в разных местах.

* 15h - Базовая память в килобайтах (младший байт) (IBM);
* 16h - Базовая память в килобайтах (старший байт) (IBM);
* 17h - Расширенная память в килобайтах (младший байт) (IBM);
* 18h - Расширенная память в килобайтах (старший байт) (IBM);
* 30h - Расширенная память в килобайтах (младший байт) (IBM);
* 31h - Расширенная память в килобайтах (старший байт) (IBM);
* 34h - Расширенная память более 16Мб (блоками по 64к) (младший байт) (AMI);
* 35h - Расширенная память более 16Мб (блоками по 64к) (старший байт) (AMI);
* 35h - Расширенная память (блоками по 64к) (младший байт) (AMI WinBIOS);
* 36h - Расширенная память (блоками по 64к) (старший байт) (AMI WinBIOS);

Байты 30-31 принято считать стандартными, но они определяют только 64Мб памяти. Не очень то подходят для использования.


Динамическое распределение памяти.

Почти любое приложение пользуется динамически выделяемыми блоками памяти (известная, наверное, всем функция malloc в c). Сейчас мы поговорим о том, как это все работает.

Подходить к этому можно по разному, но принцип везде прослеживается один. На каждый блок памяти необходимо иметь структуру, описывающую занятось блока, его размер. В примитивной реализации это может выглядеть так, как это сделано в DOS.

В ДОСе вся память на равных правах принадлежит всем запущенным программам. Но чтобы операционная система могла как-то контролировать использование памяти, в ДОСе применяются MCB (Memory Control Block). Формат этого блока таков:
Размер структуры 16 байт (1 параграф памяти) и эта структура непосредственно предшествует описываемому блоку памяти.
Размер блока указывается в параграфах в поле SizeParas. Такая структура вполне подходит для ограниченной по размерам памяти DOS, но для приложений она не очень то применима. Разница состоит в том, что в случае ДОС, чтобы найти блок свободной памяти (Такие блоки помечаются нулевым OwnerId), необходимо пройти по всем блокам от начала цепочки, до тех пор, пока не встретится свободный блок соответствующего размера. В ДОСе имеется функция, с помощью которой можно получить адрес первого блока (Base MCB) (int 21h, fn 52h).
Столь медленный поиск не страшен для DOS, у которого количество блоков редко превышает несколько десятков, но в приложениях поиск по цепочке блоков может быть достаточно долгой процедурой.
Поэтому в приложениях обычно применяется другой алгоритм, который заключается в следующем. (Я рассмотрю наиболее быстрый алгоритм, вариантов, конечно, может быть множество):

У каждого блока, как я уже говорил, есть два основных параметра: размер и флаг занятости. Оба эти параметра размещаются в одном двойном слове памяти. Поскольку как начало блока, так и его размер обычно выравниваются на четное число байт, младшие биты размера остаются неиспользуемыми (всегда равны нулю) и флаг занятости размещается в одном из них.

Этот параметр блока размещается перед началом и по окончанию блока. Начальный параметр следующего блока соответственно будет размещен непосредственно после конечного параметра предыдущего, что позволит анализировать цепочку блоков с одинаковым успехом в обоих направлениях.

Свободные блоки памяти размещаются в списках в соответствии со своим размером. Размер блоков в списках увеличивается в геометрической прогрессии. К примеру, в первом списке хранятся блоки до 16 байт длиной, во втором до 32-х байт длиной и так далее. Такая система позволяет, зная размер необходимого блока, сразу же выбирать из соответствующего списка подходящий блок и не требует поиска по всем блокам. Для организации списков к блоку добавляются несколько параметров (поскольку блок свободен, и его внутреннее пространство может быть использовано для любых целей, эти параметры размещаются в самом блоке). К этим параметрам относятся ссылка на следующий свободный блок в списке, и номер списка в котором находится блок. (Это позволяет ускорить удаление блока из списка).

Для выделения блока необходимого размера сперва проверяется список соответствующего размера, в котором может потребоваться поиск блока. Если соответствующий список пуст, то проверяется следующий список, в котором уже не требуется проводить поиска, поскольку любой блок заведомо больше нужного размера. Найденный пустой блок делится на две части, вторая - не нужная часть оформляется как свободная и помещается в соответствующий список, а первая часть оформляется как занятая и возвращается программе.

Из-за необходимости введения дополнительных параметров для свободных блоков памяти минимальный размер блока не может быть меньше 8 байт. Даже если пользователь захочет получить блок меньшего размера, выделится блок в 8 байт длиной.

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

Для того, чтобы предотвратить попытку объединения первого блока памяти (при его освобождении) с предшествующим ему, перед первым блоком ставится параметр с флагом занятости. То же самое делается и для последнего блока памяти, но только после него.

disk2.zip (9 kb) - KernelNG PreAlpha-1. Новая организация ресурсов.

imgtools.rar (32 kb) - Image tools - fdread.exe, fdwrite.exe (dos/win32) - утилиты для работы с имиджами дисков от Дрона

i586-elf-gnu.rar (2.2 Mb) - i586-elf GNU (bin) - i586 elf binutils и gcc

nd_gnutools.rar (449 kb) - ND GNU-Tools (bin) - гнутые тулзы, выдранные из cygwin для корректной работы компайлеров

Tech Help 6.0 - Замечательный справочник по прерываниям BIOS и DOS. Имеет массу другой информации. Схож с HelpPC (если Вы знаете, что это такое).

bootprog.zip (50 kb) - Пару примеров работы с бут сектором на паскале и ассемблере

os.zip (377 kb) - Исходник операционной системы, написанной Алексеем Фрунзей

SolarOS (3145 kb) - Исходник операционной системы, написанной моим земляком, Богданом Онтану.

Kolibri OS 0.6.0.0 (2117 kb) - Kolibri OS - операционная система, развившаяся из Menuet 32. Отличается ориентированностью на ассемблере - большая часть приложений для неё также написаны на ассемблере.

bin86-0.16.17.tar.gz (700 kb) - This is a simple assember and linker for 8086 - 80386 machine code.

MS-DOS 6.0 (19 mb) - Исходник известной нам ОС, MS-DOS 6.0 . Сегодня только осилил залить. Пароль на архив: antichat.ru~!@#


PS Пост будет обновляться. "Горячие" файлы, буду выделять красным, остальные - оливковым.

(C) Dron, 2001 г.

Статью я нашел на просторах народа и побоялся, как-бы она не потерялась. Решил выложить ее здесь. Над оформлением буду еще работать.
Статья не моя, но всетаки предлагаю супер-модератору, закрепить ее как важное.

В общем нарыл еще один интересный исходник ядра, для винды 9х, который работает в защищенном режиме.
[DOWNLOAD]

На инаттаке по-свежее статейка лежит:


Написание собственной Операционной Системы №1
Написание собственной Операционной Системы №2
Написание собственной Операционной Системы №3


PS А может собраться и AntichatOS накодить?

__________________
Bedankt euch dafür bei euch selbst.

H_2(S^3/((z1, z2)~(exp(2pi*i/p)z1, exp(2pi*q*i/p)z2)))=Z/pZ

Запосчу-ка я сюда же примерчик =)

The Real "Hello World"

1. Идея (hello.c)

Изучение нового языка программирования начинается, как правило, с написания простенькой программы, выводящей на экран краткое приветствие типа "Hello World!". Например, для C это будет выглядить приблизительно так.

Показательно, но совершенно не интересно. Программа, конечно работает, режим защищенный, но ведь для ее функционирования требуется ЦЕЛАЯ операционная система. А что если написать такой "Hello World", для которого ничего не надо. Вставляем дискетку в компьютер, загружаемся с нее и ..."Hello World". Можно даже прокричать это приветствие из защищенного режима.

Сказано - сделано. С чего бы начать?.. Набраться знаний, конечно. Для этого очень хорошо полазить в исходниках Linux и Thix. Первая система всем хорошо знакома, вторая менее известна, но не менее полезна.

Подучились? ... Понятно, что сперва надо написать загрузочный сектор для нашей мини-опрерационки (а ведь это именно мини-операционка). Поскольку процессор грузится в 16-разрядном режиме, то для созджания загрузочного сектора используется ассемблер и линковщик из пакета bin86. Можно, конечно, поискать еще что-нибудь, но оба наших примера используют именно его и мы тоже пойдет по стопам учителей. Синтаксис этого ассемблера немколько странноватый, совмещающий черты, характерные и для Intel и для AT&T (за подробностями направляйтесь в Linux-Assembly-HOWTO), но после пары недель мучений можно привыкнуть.

2. Загрузочный сектор (boot.S)

Сознательно не буду приводить листингов программ. Так станут понятней основные идеи, да и вам будет намного приятней, если все напишите своими руками.

Для начала определимся с основными константами.

START_HEAD = 0 - Головка привода, которою будем использовать.

START_TRACK = 0 - Дорожка, откуда начнем чтение.

START_SECTOR = 2 - Сектор, начиная с которого будем считывать наше ядрышко.

SYSSIZE = 10 - Размер ядра в секторах (каждый сектор содержит 512 байт)

FLOPPY_ID = 0 - Идентификатор привода. 0 - для первого, 1 - для второго

HEADS = 2 - Количество головок привода.

SECTORS = 18 - Количество дорожек на дискете. Для формата 1.44 Mb это количество равно 18.

В процессе загрузки будет происходить следующее. Загрузчик BIOS считает первый сектор дискеты, положит его по адресу 0000:0x7c00 и передаст туда управление. Мы его получим и для начала переместим себя пониже по адресу 0000:0x600, перейдем туда и спокойно продолжим работу. Собственно вся наша работа будет состоять из загрузки ядра (сектора 2 - 12 первой дорожки дискеты) по адресу 0x100:0000, переходу в защищенный режим и скачку на первые строки ядра. В связи с этим еще несколько констант:

BOOTSEG = 0x7c00 - Сюда поместит загрузочный сектор BIOS.

INITSEG = 0x600 - Сюда его переместим мы.

SYSSEG = 0x100 - А здесь приятно расположится наше ядро.

DATA_ARB = 0x92 - Определитель сегмента данных для дескриптора

CODE_ARB = 0x9A - Определитель сегмента кода для дескриптора.

Первым делом произведем перемещение самих себя в более приемлемое место.

Теперь необходимо настроить как следует сегменты для данных (es, ds) и для стека. Это конечно неприятно, что все приходится делать вручную, но что делать. Ведь нет никого в памяти компьютера, кроме нас и BIOS.

Наконец можно вывести победное приветствие. Пусть мир узнает, что мы смогли загрузиться. Поскольку у нас есть все-таки еще BIOS, воспользуемся готовой функцией 0x13 прерывания 0x10. Можно конечно презреть его и написать напрямую в видеопамять, но у нас каждый байт команды на счету, а байт таких всего 512. Потратим их лучше на что-нибудь более полезное.

Функция write_message выгдядит следующим образом

А сообщение так

К этому времени на дисплее компьютера появится скромное "Booting data ..." . Это в принципе уже "Hello World", но давайте добьемся чуточку большего. Перейдем в защищенный режим и выведем этот "Hello" уже из программы написаной на C.

Ядро 32-разрядное. Оно будет у нас размещаться отдельно от загрузочного сектора и собираться уже gcc и gas. Синтаксис ассемблера gas соответсвует требованиям AT&T, так что тут уже все проще. Но для начала нам нужно прочитать ядро. Опять воспользуемся готовой функцией 0x2 прерывания 0x13.

Сама функция чтения предельно простая: долго и нудно заполняем параметры, а затем одним махом считываем ядро. Усложнения начнуться, когда ядро перестанет помещаться в 17 секторах ( то есть 8.5 kb), но это пока только в будущем, а пока вполне достаточно такого молниеносного чтения.

Вот и все. Ядро успешно прочитано и можно вывести еще одно радостное сообщение на экран.

Вот содержимое сообщения

А вот функция остановки двигателя привода.

На данный момент на экране выведено "Booting data ...done" и лампочка привода флоппи-дисков погашена. Все затихли и готовы к смертельному номеру - прыжку в защищенный режим.

Для начала надо включить адресную линию A20. Это в точности означает, что мы будем использовать 32-разрядную адресацию к данным.

Выведем предупреждающее сообщение, о том, что переходим в защищенный режим. Пусть все знают, какие мы важные.

Пока еще у нас жив BIOS, запомним позицию курсора и сохраним ее в известном месте ( 0000:0x8000 ). Ядро позже заберет все данные и будет их использовать для вывода на экран победного сообщения.

Теперь внимание, запрещаем прерывания (нечего отвлекаться во время такой работы) и загружаем таблицу дескрипторов

У нас таблица дескрипторов состоит из трех описателей: Нулевой (всегда должен присутствовать), сегмента кода и сегмента данных

Переход в защищенный режим может происходить минимум двумя способами, но обе ОС , выбранные нами для примера (Linux и Thix) используют для совместимости с 286 процессором команду lmsw. Мы будем действовать тем же способом

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

В конце ассемблерного файла полезно добавить следующую инструкцию.

В результате скомпилированный код будет занимать ровно 512 байт, что очень удобно для подготовки образа загрузочного диска.

3. Первые вздохи ядра (head.S)

Ядро к сожалению опять начнется с ассемблерного кода. Но теперь его будет совсем немного.

Мы собственно зададим правильные значения сегментов для данных (ES, DS, FS, GS). Записав туда значение соответствующего дескриптора данных.

Проверим, нормально ли включилась адресная линия A20 простым тестом записи. Обнулим для чистоты эксперимента регистр флагов.

Вызовем долгожданную функцию, уже написанную на С.

И больше нам тут делать нечего.

4. Поговорим на языке высокого уровня (start.c)

Вот теперь мы вернулись к тому с чего начинали рассказ. Почти вернулись, потому что printf() теперь надо делать вручную. поскольку готовых прерываний уже нет, то будем использовать прямую запись в видеопамять. Для любопытных - почти весь код этой части , с незначительными изменениями, повзаимствован из части ядра Linux, осуществляющей распаковку (/arch/i386/boot/compressed/*). Для сборки вам потребуется дополнительно определить такие макросы как inb(), outb(), inb_p(), outb_p(). Готовые определения проще всего одолжить из любой версии Linux.

Теперь, дабы не путаться со встроенными в glibc функциями, отменим их определение

Зададим несколько своих

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

Вот и вывели мы этот "Hello World" на экран. Сколько проделано работы, а на экране только две строчки

Booting data ...done
Go to proteсted mode ...done

Немного, но и немало. Закричала новая операционная система. Мир с радостью воспринял ее. Кто знает, может быть это новый Linux ...

5. Подготовка загрузочного образа (floppy.img)

Итак, подготовим загрузочный образ нашей системки.

Для начала соберем загрузочный сектор.

as86 -0 -a -o boot.o boot.S
ld86 -0 -s -o boot.img boot.o

Обрежем 32 битный заголовок и получим таким образом чистый двоичный код.

dd if=boot.img of=boot.bin bs=32 skip=1

Соберем ядро

gcc -traditional -c head.S -o head.o
gcc -O2 -DSTDC_HEADERS -c start.c

При компоновке НЕ ЗАБУДБЬТЕ параметр "-T" он указывает относительно которого смещения вести расчеты, в нашем случае поскольку ядро грузится по адресy 0x1000, то и смещение соотетствующее

ld -m elf_i386 -Ttext 0x1000 -e startup_32 head.o start.o -o head.img

Очистим зерна от плевел, то есть чистый двоичный код от всеческих служебных заголовков и комментариев

objcopy -O binary -R .note -R .comment -S head.img head.bin

И соединяем воедино загрузочный сектор и ядро

cat boot.bin head.bin >floppy.img

Образ готов. Записываем на дискетку (заготовьте несколько для экспериментов, я прикончил три штуки) перезагружаем компьютер и наслаждаемся.

cat floppy.img >/dev/fd0

6. Е-мое, что ж я сделал (...)

Здорово, правда? Приятно почувствовать себя будущим Торвальдсом или кем-то еще. Красная линия намечена, можно смело идти вперед, дописывать и переписывать систему. Описанная процедура пока что едина для множества операционных систем, будь то UNIX или Windows. Что напишете Вы? ... не знает не кто. Ведь это будет Ваша система.

Для новичков, да и не только будет полезно....