OSDev

К слову о префиксах - может быть пригодится инфа. Он указывается при генерации вторичного имиджа grub-а вот таким параметром. Если его так не указать, то с винчестера ничего не загрузится.

grub-mkimage -O i386-pc -o core-fat.img '--prefix=(,msdos1)/boot/grub' biosdisk fat part_msdos
grub-mkimage -O i386-pc -o core-ext2.img '--prefix=(,msdos1)/boot/grub' biosdisk fshelp ext2 part_msdos
grub-mkimage -O i386-pc -o core-ntfs.img '--prefix=(,msdos1)/boot/grub' biosdisk fshelp ntfs part_msdos

А генерировал три разных имиджа под разные ФС, потому что с несколькими ФС размер имижда получается велик и не умещается в стандартные 63 сектора.

Про параметр --prefix (-p) я в курсе. Я обычно использую дефолтное значение "/boot/grub" (которое можно не указывать в командной строке) вместе с дефолтным "root'ом". Мы не используем инсталляцию в "нулевую дорожку", так что нам размер ядра загрузчика не очень важен. Грузим ядро в виде файла своими первичными загрузчиками и динамически его настраиваем.

Yoda, я кажется нашел ответ на один из моих последних вопросов. Это по-прежнему в силе?

В этому случае всё будет просто ограничено 32 битами (2ТБ). Т.е. всё останется работоспособно, но с ограниченным функционалом.


Полноценная 64-битная нумерация возможна только с использованием комплектного MBR.


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


Не обязательно для меня. Это можно делать и для себя. Например, кто-то создаёт свою ФС, и с использованием протокола MBR/VBR может написать свой первичный загрузчик. Я люблю, когда проект хорошо структурирован и всё делится на отдельно используемые модули с хорошо описанным интерфейсом.


Шаблон будет сложно сделать. У меня создана мощная библиотека-конструктор, на основе которой из готовых модулей строятся все загрузчики. Вычленить из неё кусок, - значит заморозить его вне рамок библиотеки.


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


База легко изменяется на уровне исходников. В файле библиотеки меняется одна константа. Но при этом пересобирается весь комплект и на уровне бинарников сделать аналогичные изменения уже непросто. И потом, уникальная база - это значит с каждым выпуском делать отдельные загрузчики для тебя. Может, всё же добьёшь своё ядро нулями?


Нет ещё. Этот вопрос надо сначала исследовать и поставить серию экспериментов.


Посмотри diskboot.S в оригинальных исходниках. Там стоит последовательность push dx, за ним push si. А у тебя между ними воткнут вызов какой-то функции. Это явно не случайность. Причём я смотрел бинарники из Debian и компилировал GRUB сам, ничего такого нет ни там, ни там.


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



Ну да, естественно. Идентификатор раздела в EBX и номер первого сектора раздела ещё можно передать. Но каким образом можно узнать геометрический номер раздела без поддержки со стороны MBR, я совершенно не представляю себе.

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

До этого я уже дошел путем экспериментов.

Почему не хочешь расширить HiddenSectors до 64 бит?

В принципе вполне достойный вариант. Мне не нравится использование 32-битных регистров (для моих применений). Еще хочу все-таки посмотреть, использует ли хоть кто-нибудь интерфейс, описанный в EDD Spec. Если нет, то дружно забьем на него. Буду изобретать собственный велосипед.

Я имел в виду простейший исходник с демонстрацией обработки параметров, полученных от MBR-загрузчика, и передачей их по цепочке вторичному загрузчику/ядру.

Я когда-то сравнивал один из твоих загрузчиков с базой 500h и базой 600h - отличались только одним байтом - подумал, что может база "вбита" где-то в одном месте и от нее корректно отсчитываются все другие параметры (размер доступного для загрузки файла буфера и т.п.). Не хочу постоянно конвертировать. Ради эксперимента было интересно это сделать, но теперь попробую сделать над собой усилие и написать собственный загрузчик (ты продемонстрировал, что это вполне реально сделать). Может, после и read-only-драйвер напишу. Уж слишком понравилось использовать NTFS-раздел (не сильно напрягают даже остающиеся пока ограничения). Еще слегка напрягает, что после конвертирования модиф. GRUB'а в твой формат перестает работать MB-точка входа. Можно конечно "выдрать" соответствующий код из самого GRUB'а или написать самому, но что-то не хочется усложнять код в этом направлении, когда в GRUB'е все это уже есть. Хотя можно и в адаптационный код добавить распознавание на предмет загрузки по адресу 600h и в случае успешного распознавания выполнять полный перенос на нужное место, как это сделано у тебя (когда у меня в mksys задано уплотнение, в начало sys-образа помещается лишь конец исходного образа, что эффективнее, но по понятным причинам это не подходит для образа, который может быть загружен и по адресу 600h, и по адресу 8000h). Кстати, если ты не будешь уплотнять образ ядра до верхней границы твоего адаптационного кода (у полученной мной версии это 183+1 байта), а оставишь 512 байт в любом случае, то по идее у тебя это тоже должно работать.

К слову, сегодня узнал о фишке fasm'а, позволяющей вообще не править исходники при обработке различных входных файлов (при желании можно и другие входные параметры брать из специальных файлов). Сейчас у меня в исходниках mksys обычно записано:
Теперь можно написать так:
И брать имена входных файлов из соответствующих переменных окружения.

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

Да, заметил. Крутая функция, однако:
Это тестирование клавиатурных флагов BIOS. Я в MBR-загрузчиках тоже их использую.

Скинь мне mksys (знакомое название, БЛИН ) for Win, плиз, как добавишь.

Я уже показывал, как это можно сделать, причем элементарно.

Для этого надо задействовать дополнительные 4 байта где-то в BPB/BS data или вне этой области. Первое решение может нарушить стандарты, а второе - в целом бесполезный расход места при условии чрезвычайно редкой потребности в загрузке свыше 2ТБ и её работоспособности при использовании совместимого GPT-загрузчика.


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


Хмм. Подумаю. Может и добавлю.


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


"Починить" её работу непросто. Я думаю, что лучше всего следующие варианты:

• Забить на неё. Потому что иначе зачем мы конвертировали ГРУБ в новый формат;
• Перекомпилировать ГРУБ с линковкой по другому адресу загрузки с добавлением вместо diskboot.S небольшого адаптера без релокации кода.

Хорошо.


Тестирование?? По-моему, это принудительный сброс всех флагов, кроме Left shift и Right shift.


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


Хоть убей, не помню. Вписывать в бут-сектор при инсталляции?

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

"Родной" GPT-загрузчик может быть затерт с такой же высокой вероятностью, что и MBR-загрузчик. Расширять формат бутсектора можно вполне безопасно, т.к. все это будет писаться в процессе установки загрузчика на диск или в "ручном" режиме. Даже если установщик запускается ради перезаписи этого поля, он все равно должен переписать код загрузчика или по краней мере убедиться, что на диске находится его точная копия. Загрузка с позиции выше 2 тб - это уже вполне актуальная потребность, и она будет увеличиваться в самое ближайшее время.

Вполне возможно. Но я все-таки поищу, т.к. пока планирую развивать BIOS-GPT-загрузку. Хотя в сторону EFI тоже не мешает поглядывать.

Попробую написать свой NTFS-загрузчик, может даже сделаю open source.

В пред. посте я подошел к вполне нормальному решению. И тебе дал наводку, как без больших усилий можно обойти эту проблему. Ты экономишь несколько сотен байт, оставляя эту проблему нерешенной. Используй адаптационный код размером 512 байт и все будет ОК. Плюс пользователь будет меньше напрягаться, когда размеры исходного и конечного файлов будут совпадать.

Посмотри, там после вызова этой подпрограммы вроде бы идет условный переход: 74h, 08h. Типичное однократное тестирование нужных бит с обнулением ненужных.

Я уже говорил, что даже это необязательно. Главное, чтобы возможность такая сохранялась. Хотя в инсталляторе это тоже сделать нетрудно. Поясню мотивы, побудившие меня зацепиться за эту "тему". Казалось бы наконец-то появилась возможность получать "мой" идентификатор от первичного загрузчика - живи и радуйся. Но нет, оказывается, чтобы радость была полной, нужно еще установить твой MBR-загрузчик. А меня это не устраивает, т.к. мне в MBR необходимо наличие моего MBR-загрузчика, обеспечивающего dual booting. Вот и получается, что пока нет возможности пропатчивать первичный загрузчик, я вынужден по-прежнему пропатчивать вторичный, т.е. счастье, вызванное поддержкой с твоей стороны нового, столь актуального для меня, параметра, оказалось совсем недолгим! Как патчил вторичный загрузчик/упакованное ядро в твоем формате, так и продолжаю это делать сейчас.

Этим обычно занимается (U)EFI. Я бы сказал, что Legacy BIOS загрузка свыше 2ТБ - уникальная фича этого комплекта, поэтому вряд ли можно говорить о её неминуемой массовости.


Я так понимаю, отсутствие dual boot - единственное, что мешает использовать мои нулевые загрузчики. Хорошо, я добавлю функцию dual boot.

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

Как уже сказал, я пока буду заниматься BIOS-GPT-загрузкой. Насчет "уникальной фичи" я бы не торопился это утверждать. Нужно посмотреть другие GPT-загрузчики, ну и код того, что они загружают. У меня кстати тоже периодически появлялось желание перейти на 64-разрядную нумерацию секторов в первичных загрузчиках. Из-за невысокой степени актуальности я прежде этого не делал, но в свете внедрения поддержки GPT и NTFS об этом опять нужно всерьез задуматься.

В основном это, но для меня не только. Мне нужен мой "родной" MBR-загрузчик, т.к. твой пакет я использую только для загрузки с NTFS-разделов (может, еще с ExtFS потом поэкспериментирую), но ведь у меня часто присутствует и раздел с моей ОС, размещенной обычным способом. Твой MBR-загрузчик далеко не всегда сможет обеспечить мне такую загрузку. Но в общем я уже нашел решение - использовать мой MBR-загрузчик, поддерживающий в том числе и твой интерфейс (см. в пред. постах). Если есть интерес, я могу всерьез заняться этой "темой" и разместить здесь вполне отлаженные версии.

Так чего ещё кроме дуал-бута не хватает в моих нулевых загрузчиках? Скажи, рассмотрим. Разумные пожелания приветствуются.


А какая связь между MBR-загрузчиком и твоей ОС в каком-то разделе?


Как вариант, - вполне. Как я уже сказал, открою и документирую спецификации MBR/VBR (но ты их и так уже знаешь). В принципе, интерфейс вполне устоявшийся и обеспечивает всё необходимое.

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

В этом каком-то разделе стоит мой первичный загрузчик, который в штатном режиме ожидает определенных параметров от моего MBR-загрузчика, когда раздел не активный. В первичном разделе я еще могу пропатчить непосредственно первичный загрузчик, но в расширенном разделе (это мой позиционно независимый миниобраз) мне неоткуда взять номер начального сектора раздела, кроме как получить его от "родного" MBR-загрузчика (в EBR поддерживается только ячейка для номера дополнительного раздела, содержимое которой используется, когда MBR-загрузчик передает 0 - это директива к самостоятельному определению "активного" дополнительного раздела).

Только я забыл, у тебя используется в MBR-загрузчике идентификация "родного" EBR-загрузчика/просто хоть какого-то кода, отличного от нулей? Или ты не делаешь разницы в MBR-загрузчике между первичным и расширенным разделами?