OSDev

Аааа, видишь, всё же нужен интерфейс MBR/VBR с поддержкой номера!


С точки зрения MBR, EBR не отличается от VBR. А с точки зрения VBR, EBR не отличается от MBR .
Проверка всегда однонаправленная, т.е. проверяются на валидность значения, полученные от предыдущего загрузчика.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Я все-таки немного различаю интерфейсы MBR-VBR и MBR-EBR. В VBR мне номер не нужен, т.к. есть HiddenSectors, а в EBR нужен, т.к. вовремя не хватило сообразительности завести подобное поле непосредственно в EBR хотя бы как вариант, тоже использовал EBR только в связке с "родным" MBR-загрузчиком. В первичных загрузчиках я не использую дескриптор раздела, передаваемый через ds:si, а в EBR-загрузчике использую.

Понятно. Мне кажется, мы это уже обсуждали, только не помню, с тобой или с кем-то другим. У меня MBR-загрузчики обычно различают расширенные разделы DOS двух основных типов и препятствуют загрузке с них, как с обычных первичных разделов. Конечно за исключением того случая, когда целенаправленно выполняется поиск расширенного раздела для загрузки с него. У меня есть линейка MBR-загрузчиков Jumbo (это мои самые первые собственные MBR-загрузчики). Так вот в них поиск расширенного раздела выполняется специально, когда при обычной загрузке нет активного первичного раздела или когда при альтернативной загрузке указан в качестве загрузочного дополнительный раздел (5-255). Также там используется доп. проверка на валидность EBR-кода (чтобы как минимум не передавать управление на обнуленный EBR-код, который весьма часто встречается; у тебя в этом плане есть оправдание, т.к. обычно расширенный раздел не помечается флагом активности, но мне выполнять доп. проверку по-любому надо, т.к. я использую расширенный раздел в традиционной конфигурации, когда у него этого флага практически никогда не бывает). В третьем Alter'е проверки типа раздела на какое-либо отличное от нуля значение сейчас нет - или места не хватило, или специально убрал, чтобы загружать EBR-код, уже не помню. Спец. проверки на валидность EBR-кода тоже нет. Т.е. он работает по твоим принципам. Может так и оставлю, а может и нет. Точно не могу сказать. Пока это лишь забавный эксперимент.

Подскажите про BIOS UEFI. Вот например такая плата
http://ru.asus.com/Motherboards/AMD_AM3 ... OTH_990FX/
Если на ней запустить программу, использующую не UEFI, а прерывания обычного BIOS, то будет работать? Довелась возможность разок запустить свою ОС на такой системе с процом AMD FX8120 - получилась перезагрузка на этапе инициализации ядра (это уже после выбора из меню GRUB). Возможности отладить нет - комп не мой. Может кому-то известны другие "подводные камни" на таких новых материнках?

С Новым годом,

в BIOS бывает переключатель BIOS/EFI. В режиме BIOS, естественно, все должно работать (у меня работает), хотя встречаются и некоторые недоработки, но это связано не с EFI, а с плохой реализацией собственно интерфейса BIOS. Например, у меня AMI Aptio (AMIBIOS8 на основе UEFI) возвращает не вполне корректную информацию о USB-носителях через функцию EDD 48h, однако обычные BIOS тоже далеко не всегда сообщают корректную информацию об оптическом приводе в режиме AHCI. Там, где поддержки обычной BIOS нет вообще, думаю, не стоит даже пытаться использовать сервис BIOS.

Я загрузку за пределами 2ТБ через функции обычного BIOS как раз отлаживал на материнской плате UEFI. Всё работает. По крайней мере, мне пока не попадались материнские платы, не поддерживающие традиционную (legacy BIOS) загрузку. UEFI BIOS обычно делает так: сканирует установленные носители на предмет наличия UEFI раздела или загрузчика, если такового нет, то грузится в legacy BIOS режиме. Если предусмотрено BIOS Boot Menu (обычно по клавише F8), то, соответственно, спрашивает, в каком именно режиме грузиться с указанного носителя.


Почти наверняка это не из-за UEFI.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

GRUB4DOS.
Вот тут phantom-84 сомневался, куда ему стек приткнуть... В проекте GRUB4DOS неоднократно встречаются такие фрагменты кода:



Конечно, зачем стесняться? Разместим стек прямо в таблице векторов прерываний!

SYSLINUX.
Дело - швах. Этот кошмар я поддержать не смогу. Точнее, теоретически, может быть это и можно, но только путём глубокого погружения в проект сислинукса.
Сначала думал, раскручу первичную загрузку, откушу. Как же! Этот загрузчик компилируется, как единое целое. В нём первичный загрузчик совершенно неотделим от всего остального кода. То есть, весь проект целиком компилируется с адреса 7C00h и на этот адрес настроен. Первый сектор подгружает второй сектор сразу после себя (при этом по ходу постоянно патча свой собственный код, - вот уж чего я терпеть не могу, так это самомодифицирующийся код). Второй сектор вызывает функции первого сектора, проверяя патчи, используя оттуда переменные и перепатчивая поверх предыдущих патчей, блин. При этом подгружает всё остальное. Кажется, вот тут как раз можно резать... ан нет! Пропатченные и впоследствии перепатченные функции используются в проекте и дальше! Следующая мысль - оставить первые два сектора в покое. Однако, во-первых, на них уже наложены малопредсказуемые патчи. Во-вторых, в этих секторах находятся вшитые в код переменные, которые патчит установщик сислинукса на этапе записи его на диск (отыскивая, например, при этом "мёртвую говядину" и "корми лицо"). Но самое неприятное (в-третьих) - область BPB/BS загрузочного сектора, весьма грязным хаком расширенная с байтов и слов до двойных слов переносится в область данных для последующего использования. В-четвёртых, установщик дописывает в конце файла обширный кусок данных. Это вам не GRUB2, где установщик патчит буквально несколько более-менее понятных параметров и цепочку секторов на диске!
Резюме следующее.
1. Весь проект состоит из постоянно накладывающихся повсюду заплаток на самых разных этапах.
2. Налицо очень сильная привязка загрузчика на этапе его установки.
3. Проект плохо спроектирован и закодирован в плохом стиле.
В-общем, сислинукс я не могу поддержать достаточно простыми средствами, а тратить недели на ковыряние в нём я не готов. Не ожидал я такого от "Peter Anvin и компания". Может быть, вернусь к его раскрутке, но только в отдалённом будущем.

Вообще, меня начинает бесить вот этот "патч"-подход, тотально используемый в линуксе. Хочется чего-то стабильного и целостного. Вот файл. Исполняемый. И он должен быть одним и тем же файлом, который можно просто скопировать, быть уверенным в том, что внутри него ничего не поменялось самым непредсказуемым образом, и что он будет работать одинаково независимо от его расположения. Думал, мои загрузчики как раз помогут в этом, однако я не предполагал, что существуют проекты настолько "изъеденные" изнутри философией "пропатчивания", что их нельзя будет привести в чувство.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Согласен, полное...

Вроде патчил статически, т.е. с использованием исключительно "родного" кода всех уровней (помню, там в бутсекторе номер первого сектора ядра нужно было прописывать вместо 0xDEADBEEF ). Согласен с тем, что syslinux сильно не дотягивает до "вполне достойной альтернативы Grub'а". Я тебе давно говорил, не трать время на эти загрузчики. Лучше напиши свой вторичный загрузчик, если нужен. Думаю, получится вполне достойный конкурент названным экспонатам при грамотном проектировании и при должной раскрутке.

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

Edited.
Точно, причем исходник для формирования пропатченного образа флоппика есть в этой теме, когда к нашей беседе присоединился Ярило.

Edited.
Можно взять слепок бутсектора из памяти в момент старта ядра и прикрутить его к образу ядра. Тем более что твой формат ядра покрывает в том числе и адрес 7C00h (это если не уплотнять образ).

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


Не, вторичный загрузчик я пока писать не буду. Во-первых, они уже есть. Во-вторых, это гораздо более трудоёмкая работа. В-третьих, в нём пока нет необходимости. Хотя Shikhin и Griwes развели бурную дискуссию по созданию загрузчика под названием Gandalf и даже завели проект в GitHub, я так и не смог понять, чем их не устраивает протокол Мультибут, весь проект сейчас на стадии одной страницы описания, чего бы они хотели видеть (пока даже без конкретики), а критика GRUB2 свелась к ссылке на тему, где товарищ создавал загрузочный компакт-диск и таки сделал его с твоей помощью, используя твой grub.sys и мой iso9660.bin . Другими словами, в основе каждого проекта должна быть разумная необходимость, а я пока не вижу её в случае вторичного загрузчика.
Что касается раскрутки, то хотелось бы сначала довести до кондиции и раскрутить уже имеющееся, а не хвататься за новое. За двумя зайцами погонишься...


О, нет, туда бесполезно смотреть с моей перспективы. Между первичной загрузкой и линуксом обязательно должна быть вторичная. Причём достаточно сложная, с поддержкой initrd. Ну его в баню. В данном случае вполне достаточно поддержки линукс-специфичных вторичных загрузчиков. Как я уже говорил, у меня сейчас линукс именно так и грузится, и я этому вполне рад.


Я всегда говорил, что проекты всегда надо делить на самодостаточные модули с чётко очерченными минимально необходимыми интерфейсами и между модулями не должно быть никаких "левых" неотслеживаемых связей.


Можно попробовать сделать так: заглушка считывает первый сектор раздела, переносит оттуда BPB/BS в загруженный образ, пропатчивает первый сектор сходным с оригиналом образом и передаёт управление на второй сектор, в точку после считывания остатка файла и подсчёта контрольной суммы, сразу перед хаком с BPB/BS.
Да, так, пожалуй можно. Тогда надо будет ещё разобраться, что за мусор дописывает инсталлятор в конец файла.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Есть еще вариант не мучатся с телом самого syslinux а загружать его MBR.bin а он пусть грузит само тело. Тут двух зайцев мне кажется можно убить, 1 легче поддержать такую загрузку, 2 более универсально, т.е. можно надеется что такой способ по мере выхода новых версий syslinux останется рабочим, а если грузить напрямую тело возможно что с выходом новых версий что то поменяется в загрузке, в MBR у них гораздо реже что либо меняется, вроде )). Хотя теряется свобода расположения самого syslinux на томе он уже должен будет стоять там где его MBR найдет. А вот если использовать такой же подход к grub4dos то он сам разбирает файловую и находит свое тело у него 8 кило первичный загрузчик, я еще 2 версией загрузчика boot грузил так grub4dos указывая в загрузке boot grub-овский MBR фаил.

По идее все должно быть нормально. Единственная проблема - это необходимость подстраиваться под каждую конкретную версию или даже сборку. Кстати я не замечал, что инсталлятор что-то дописывает в конец ядра. Т.е. я брал оригинальный бинарник из пакета, пропатчивал его, после чего он работал. Может, довесок каким-либо образом расширяет возможности ядра?

Ну, понятно. Я просто в очередной раз напомнил, в каком направлении можно развивать эту тему. Они есть, но, сам понимаешь, какие. Везде используется пропатчивание и часто присутствует расширенный функционал, не нужный для обычной загрузки с предопределенного загрузочного диска/раздела. Конечно пропатчивание можно оправдать использованием универсального первичного загрузчика, а расширенный функционал - это все-таки лучше, чем отсутствие какой-либо нужной функции, которая может понадобиться в самый неподходящий момент. Но все-таки в моем представлении вторичный загрузчик должен работать немного по-другому.

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

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

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

Ну, да, сымитировать загрузку ядра родным первичным загрузчиком и helper'ом, разместив их модифицированные версии по своим местам в памяти. Кстати, я хочу сделать эмуляцию загрузки первичного загрузчика NTFS через доп. точку входа (по смещению 256h), чтобы его можно было тестировать в реальных условиях без записи на жесткий диск. Тоже нужно буде совмещать в памяти данные из бутсектора тома и код тестируемого загрузчика. Подобным образом работает мой mbremu.

Основная проблема в том, что тогда syslinux все равно придется устанавливать в раздел оригинальным установщиком или пропатчивать прямо на диске. Мы же стремимся к тому, чтобы после установки на диск/в раздел наших загрузчиков все остальное можно было записывать простым копированием файлов.