Вторичен Boot Loader, dev64

Програмиране

Вторичен Boot Loader

Съдържание

Отговор. Boot Loader е с размер само 512 байта. В 512 байта можете да поберете прехода към защитен режим. В защитен режим функциите на BIOS за работа с хардуер вече не са налични. Преминаването към Boot Loader-e в защитен режим и зареждането на ядрото от диска няма да успее. Следователно за зареждане на големи ядра се използва допълнителен междинен bootloader, който работи в защитен режим. Boot Loader не зарежда ядрото, а междинен loader. Средният софтуер преминава в защитен режим, зарежда желаното ядро от файловата система и прехвърля контрола върху него. Тъй като междинният товарач не е ограничен по размер до 512 байта, той може да бъде много по-функционален. В този случай ядрото на операционната система може да не е обикновен двоичен файл, а преместваем elf файл. В същото време междинният товарач може да бъде доста сложна програма с много възможности. Включително, той може да поддържа редица видове устройства за зареждане и файлови системи. И дори може да се добави поддръжка на графичен режим за красота. Наред с други неща, междинният товарач може да осигури средство за конфигуриране на ядрото или конфигуриране на режима на зареждане на операционната система.

Подобна схема с междинен буутлоудър е реализирана от GNU GRUB буутлоудъра. GNU GRUB се използва от GNU Linux, FreeBSD, NetBSD. Windows също използва многостепенна система за зареждане. Вижте ntldr.

В същото време има операционни системи с малко ядро, които не изискват двустепенно зареждане. 512-байтов Boot Loader е заобиколен, например QNX4 и Menuet OS. Очевидно това обяснява ограничението на размера на ядрото QNX4.

KolibriOS има много различни опции за зареждане, включително mtldr, което ви позволява да конфигурирате зареждане на KolibriOS в конфигурационните файлове на Windows ntldr.

Къде се съхранява междинният товарач? GRUB използва термина „зона за зареждане“ за това. Търсенето на този термин не даде полезна информация. За да намерите отговора на този въпрос, трябва да изровите GRUB документацията и източниците.

Друга възможност за зареждане на голямо ядро е използването на опаковки. Ядрото е внедрено като саморазархивиращ се код. Не е необходимо да се разопакова изцяло. Частта може да бъде разопакована. Използвах опаковки, за да преодолея проблема с размера на ядрото в QNX4. В QNX4 ядрото съдържа виртуална файлова система, която е коренът на всички останали системи. В тази виртуална система можете да поставите обичайните изпълними програми, които ще бъдат стартирани при зареждане на ядрото. Ядрото съдържа в себе си и най-простата обвивка, която позволява изпълнението на най-простите скриптове. Това позволява да се добавят допълнителни драйвери към ядрото и т.н. В моя случай внедрих QNX4 стартиране от CD за последващо изтегляне на архивни данни от ftp. За целта добавих към ядрото драйвер за CD устройство, мрежови драйвери и други помощни програми. Но тъй като нямах достатъчно място за всички помощни програми, трябваше да опаковам всичко в един голям архив и да го разопаковам със собствения си разархиватор, също записан в ядрото. Разархивателят използва gzip библиотеката, за да разопакова архивните данни, компилирани в него като обикновена константа.

GRUB

Основната идея, популяризирана от GRUB, е да се приложи универсален буутлоудър за множество операционни системи, който поддържа спецификацията MultiBoot:

Спецификация на много зареждане

описва 3 конвенции:

1. Формат на ядрото на операционната система. Това е a.out или още по-добре формат на елфи. Първите 8 килобайта на ядрото трябва да съдържат специална структура, която описва редица флагове. Тази структура просто фигурира в горния пример. За повече информация относно структурата вижте примера.

2. Multiboot Specification описва състоянието на процесора в момента, когато управлението се прехвърля към ядрото. Защитеният режим вече е активиран, регистрите на сегменти се зареждат с селекторите на желаните сегменти. Регистърът BX е указател към структура, която описва параметрите, предадени от GRUB буутлоудъра към ядрото. (Например параметрите на диска, от който се извършва зареждането). Повече за държавата в стандарта.

3. Спецификацията Multiboot описва структурата, която се предава на ядрото, заредено в паметта като параметър. Ядрото не е задължено да обработва тази информация. Но ако разработчиците искат, те могат да го използват. Адресът, на който се съхранява тази структура, не се пресича с кода и данните на ядрото. Нищо друго не е гарантирано. Ядрото трябва да се грижи за защитата на тези данни, ако е необходимо. Подробности в същата спецификация.

Позволете ми да обобщя. GRUB ви позволява да изградите ядрото си като обикновен elf файл. Единствената разлика от обикновения изпълним файл е, че ядрото трябва да започне с вложка на асемблер, описваща специална структура с флагове и т.н. Това вмъкване по никакъв начин не нарушава структурата на файла с елфи.

Все още не ми трябват огромни ядра на операционната система, нито предимствата на ядрото във формат elf. Затова за експерименти използвам Boot Loader от OS Menuet.

Boot Loader от OS Menuet

Това е проста алтернатива на GRUB. Това е една стъпка. Зарежда ядрото от файл с посоченото име от дискета, форматирана във формат MSDOS (FAT12). Източниците за този Boot Loader могат да бъдат взети от инсталацията на OS Menuet. Освен това е налична версия, която ви позволява да поискате името на файла на ядрото преди зареждане:
http://www.menuetos.org/M32.htm

Можете да компилирате Boot Loader, като използвате fasm или nasm. След това трябва да го копирате на дискета. За експерименти (най-вероятно от първия път няма да оправя всичко, трябва да си напиша програма, която ще запише 512 байта в първия сектор на дискетата) ...

Boot Loader - програма за копиране

Както казах по-горе, вместо реални дискети, използвам виртуални дискети под формата на обикновени дискови файлове. Помощната програма за копиране на Boot Loader трябва да вземе съдържанието на компилирания 512 файл с Boot Loader и да го запише в първите 512 байта на файла, което е изображение на виртуалната дискета.
Изображението на виртуалната дискета във формат MSDOS получих, като въведох „MSDOS изображение“ в Google. В резултат получих връзка с изображение на диск.
http://www.allbootdisks.com/download/dos.html

Програмата се оказа елементарна. Източниците са по-долу. Реших да използвам "гол C". За практика преди да напишете собственото си ядро. Не съм сигурен дали C ++ е добър за ядрото.

Както описах по-горе, програмата копира 512 байта от файла, посочен в първия параметър, във файла, посочен във втория параметър. Някои хора най-вероятно ще искат да ме критикуват при вида на gotos, приложен в кода. Отговарям на критиката с въпроса: „Как да направя обработката на грешки с дескриптори на затварящи се файлове по-красива? За да няма повторения на кода ".

В допълнение, в този код също реших да се откажа от тежкия printf () в полза на "лекия" write ().

CodeBlocks + MiniGW

Като IDE за писане използвах средата CodeBlocks за Windows.
http://www.codeblocks.org/downloads/

Тази среда включва компилатора MiniGW. Инсталирах точно версията с MiniGW, включена в CodeBlocks. И това, което радва. Моята програма е компилирана както на FreeBSD, така и на Windows. Освен това всичко работи както трябва. Затова препоръчвам CodeBlocks + MiniGW. И още един много интересен факт. CodeBlocks ви позволява много удобно да превключвате към декларации за променливи, включвания и т.н. Това само по себе си не трябва да изненадва потребителите на Visual Studio. Друго интересно нещо.

Тъй като първоначално планирах да компилирам под FreeBSD, копирах директорията на FreeBSD на моя/usr/include машина и я посочих в моя проект CodeBlocks. Бяха свързани допълнителни включвания и при превключване към някой от .h файловете CodeBlocks започна да ми предлага опция къде да превключа - към включване от FreeBSD или включване със същото име от инсталацията на MiniGW, инсталирана с CodeBlocks.

Дразнеше ме наличието на дублиращи се заглавки. Не намерих начин да се отърва от включените в MiniGW файлове, от които не се нуждаех, просто взех и преместих директорията им на друго място. И на тяхно място сложих включването от FreeBSD. Представете си изненадата ми, че MiniGW с включването на FreeBSD успя да компилира без проблеми и да изгради работещ exe-shnik!

Тези. на FreeBSD включват MiniGW и gcc/gpp са съвместими. Разбира се, получените файлове не винаги ще бъдат изпълнени. Да, и не винаги ще бъдат свързани. Компилацията по този начин обаче може да бъде проверена директно под Windows. Фактът сам по себе си е много приятен. А прости програми дори могат да бъдат сглобени и ще работят по същия начин. (По-късно се оказа, че компилираният под Windows exe-shnik работи странно. Вместо 512 байта, чета по-малко от някои файлове. Може би това се дължи на факта, че под Windows файловете се отварят по подразбиране „в текстов режим“. Следователно има флаг O_BINARY за отваряне (Но след това промених включенията ... Не го възстанових обратно. Трябваше да спра да използвам помощната програма под Windows. Имам виртуален FreeBSD).