Насколько я понимаю, загрузка системы проходит по следующему пути (если я не прав, прошу меня исправить): 1) биос считывает дисковый загрузчик с нулевого сектора, размещает его по адресу 7С00 и передаёт туда управление 2) дисковый загрузчик сканирует таблицу разделов на наличие сигнатуры 80h. отображает все эти сигнатуры и ждёт пока юзер выбирет с какой грузиться 3) загружает первый сектор выбранной таблицы разделов (системный загрузчик) по адресу 7С000h и передаёт туда управление. 4) Системный загрузчик должен по идее создать таблицы дескрипторов, проинициализировать gdtr, idtr, ldtr, перевести процессор в 32х защищённый режим, установить страничную адресацию памяти. 5) Затем по идее он должен проинициализировать драйвер ФС (как иначе он сможет загружать системные файлы?) 6) ...
7С000H - нолик забыл. 2) Активным разделом может быть только один раздел. Его загрузчик и выбирает. А вообще загрузчик по нулевому сектору загружает себя из соседних секторов. После чего выводит меню с возможностью дальнейшей загрузки. Хотя и не обязан, но на то он и мульти загрузчик. Дальше из любого раздела или файла загружается системный загрузчик. Системный загрузчик загружает ядро и передает ему управление. Скорее всего загружается лоадер, который загружает ядро. Так вот лоадер какраз и занимается переводом в защищенный режим. Хотя груб и лило сами переводят проц в защищенный режим. Помимо прочего в ядро от загрузчика/лоадера передается системная информация как то о наличии памити и загрузочный диск. А вообще он загрузчик ничего не обязан делать.
Не забыл нолик. Начальный загрузчик, считываемый БИОСом, размещается по физическому адресу 7C00h, а не 7C000h. Что дальше делает загрузчик, определяет автор загрузчика В принципе, он не обязан искать активный раздел и т.д. Загрузочный сектор того же GRUB фактически загружает сам GRUB, а не какую-то ось. По какому адресу начальный загрузчик грузит что-то ещё, определяется опять-таки автором загрузчика. Что же касается создания таблиц дескрипторов и т.д., то это уже зависит от оси и к начальной загрузке прямого отношения не имеет.
Ну хорошо. а где дисковый загрузчик будет хранить свои внутренности? в 1 сектор он явно не влезет. КК предлагал хранить его в свободных секеторах на харде, но этот метод мне не очень нравится... А что, разве системные загрузчики должны иметь базонезависимый код? полюбому должно быть какое-то соглашение - иначе каждая ось должна была бы иметь свой собственный дисковый загрузчик... но ведь существует много универсальных продуктов.
Quark Начальный загрузчик (тот, что в загрузочном секторе) грузит либо своё продолжение, хранящееся в свободных секторах (или специальном разделе) диска, либо загружает заранее известную ему программу из активного или ещё какого заранее определённого раздела диска, а она уже занимается всем остальным. Универсальных продуктов нет ни одного и быть не может. Типа "универсальный" продукт может просто знать о требованиях нескольких конкретных систем и имитировать их родные загрузчики -- но не более того.
или реализовывать свой процесс загрузки, которому должны следовать ОС, использующие этот загрузчик (скажем GRUB)
Спасибо всем за ответы по поводу дискогого загрузчика. У меня есть такая мысль. Юзер запускает инсталятор загрузчика. Тот свою началюную часть пишет на нулевой сектор, а оставшуюся - создаёт файл на харде, получает адрес файла (тут первая проблмма: нужно запоминать либо LBA либо CHS адрес- смотря какой поддерживает хард, причём если CHS, то появляется проблемма номер 2, т.к. в этом режиме адресуются только первые 8Гб адресного пространства) и прописывает этот адрес в начальный загрузчик. При запуске компьютера загрузчик знает где расположена оставшаяся часть - считывает её с харда и грузит. Здесь вообще-то есть ещё одна проблемма - никто не гарантирует что файл который создал загрузчик система не вздумает куда-нибудь переместить (скажем при дефрагментации диска).
rei3er Это не всегда удобно и/или эффективно. В любом случае, за универсальность приходится платить. Quark Нормальный загрузчик сам ищет нужный файл на диске. Есно, загрузчик должен быть рассчитан на используемую файловую систему.
Quark Есть два пути. Загрузка с фиксированного адресса или искать файл разбирая ФС. Зачем же драйвер?Просто функцию чтения файлов. Для фат в один сектор умещается. А вообще использовать еще пары секторов рядом с нуливым есть ряд свободных секторов. МС их использует. Что касается. Проблемы с размером и адресацией. Она решается путем определения поддерживаемой функции и записи соответствующего загрузчика. Функции начиная c номера 40h Int 13h преднозначены для больших дисков. Для маленьких функции с меньшими намоерами. Что касется проблемы если делать загрузку по фиксированным адрессам, то там тогда надо помечать их как файл. Есть системные/защищенные файлы они считаются не перемещаемыми какраз по такой причине.
Спасибо. С загрузчиками вобщем-то всё ясно... если что - сорцы граба посмотрю. Всё-же меня больше интересует сам процесс загрузки системы. ну, на примере виндовс. загрузчик перевёл проц в защищённый 32х режим со страничной адресацией. Дальше по идее нужно загружать основные модули: hal, ntoskrnl, драйвера и т.п. Так?
Есть два факта: 1. Каждая ось имеет своё представление о том, как её должны бутить. 2. Загрузчик, для того, чтобы удовлетворить требования ОС, может действовать так, как ему больше нравится. Скажем grub. Я в коде не ковырялся, но изучение документации и здравый смысл подсказывают следующую схему. У grub есть stage1 -- содержимое бутсектора, -- который содержит код, и данные указывающие где лежит файлик stage2. То есть, у него есть просто список секторов диска, где этот файлик располагается. stage1 грузит stage2 в память. stage2 же, как я понимаю содержит помимо собственно grub'а указание на то, где можно найти драйвер fs, на которой лежат все остальные файлики grub'а: драйвера всяких разных фс, конфиг и тп. Эти файлики grub уже достаёт через драйвер fs по имени, равно как и файлы vmlinuz, initrd.gz указанные в конфиге. Если речь идёт о загрузке vmlinuz, то grub его умеет бутить и грузит самостоятельно. Если речь идёт о загрузке другой ОС, то grub про это ничего не знает, и просто использует chainloading, то есть грузит в память загрузчик целевой ОС и отдаёт управление ему. Загрузчик вражеской оси он берёт, в обычной ситуации, из загрузочного сектора раздела, куда эта ос установлена. Если этот загрузчик вендовый, то чтобы он не запутался, неплохо бы в конфиге grub'а добавить команду, которая сделает вендораздел активным разделом. Но это уже проблемы не grub'а, а того, кто пишет конфиг grub'у. lilo при этом, не имеет драйверов fs в принципе, он работает по сохранённому спискам секторов файлов ядра и initrd.gz, и каждый раз при перезаписывании какого-нибудь из этих файлов, надо обновлять списки секторов. Вендовый загрузчик, предполагаю, работает примерно как grub, только вместо stage2 он использует файл ntldr -- это вроде как аналог stage2 + статически влинкованные в него stage1_5. ps. Если я где-то наврал про схемы работы разных загрузчиков -- не надо ругаться: я специально вопросом не занимался. Я эпизодически узнавал какие-то новые особенности их работы, а всё рассказанное -- это мои домыслы.
lilo страдал таким маразмом. Всегда лучше грузить файлы, чем какие-то участки диска. Grub в этом плане значительно лучше продуман. Тебе уже не раз говорили, что разные оси грузятся по-разному. Но в общем естественно загрузчик загружает ядро, ядро выполняет инициализацию, в процессе которой загружает драйверы и оболочку. Лично я вторичный загрузчик не использую, хотя мою схему можно адаптировать под использование вторичного загрузчика вообще без каких-либо особых усилий. Первичный загрузчик грузит сразу два файла. Первый - это обычно ядро, а второй может быть чем угодно - я его использовал и как драйвер загрузочного диска и ФС, и как миниобраз для построения ram-диска, и как пакет, содержащий драйверы, необходимые для загрузки (драйвер загрузочного диска и драйвер в двух разных файлах, а не в одном).
r90 stage1 загружает stage1.5 или stage2 stage1 состоит из двух секторов, первый сектор является boot-сектором, он загружает второй сектор второй сектор хранит не список секторов, в которых лежит stage1.5 или stage2, а номер первого сектора stage1.5 или stage2 (все сектора располагаются последовательно) если используется stage1.5, то в нем реализуется драйвер требуемой ФС для возможности считывания stage2 начальный номер сектора stage1.5 записывается в бинарный образ второго сектора stage1 после его формирования на основе информации о начальном номере сектора раздела
