OSDev

Да это не патч в памяти. Суть такова, что на начало загрузочного кода настраивается BP, а затем все переменные адресуются относительно BP, - код получается короче. А здесь вроде как заранее инициализированная переменная с наперёд известным значением. Её можно использовать, например, как булеву переменную. Экономия места.

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

Да, только какой софт должен эту переменную менять? А если предположить, что должно выполняться пропатчивание проверочного кода, то этот софт должен быть специфичным для конкретного загрузчика, например, быть программой форматирования. Сама программа форматирования сможет сделать вывод о том, нужно ли пропатчивать код (nop'ом), только по местоположению BR на диске, однако ничего подобного не произошло (раздел находился в конце харда). Программных ключей для подобных указаний я вроде бы тоже никогда не встречал. Короче, загадка.

Переношу из другой темы...


Не выкладываю по двум причинам. Во-первых без поддержки загрузки с NTFS в нём не очень много смысла. Windows 7 форматирует GPT разделы только в NTFS, А *nixы живут в своём пространстве файловых систем. Во-вторых, должно быть какое-то логическое разделение. Первая версия - набор, что называтся, must have. Без FAT-ов разработка ОС с нуля весьма затруднительна. Во второй версии хочу предложить джентельменский набор - поддержка CDFS/GPT/NTFS - наиболее распространённые и перспективные ФС. В третьей версии может быть поддержу *никсовое направление.


Вопрос не понял.


Загрузочный раздел определяется в соответствии со спецификациями UEFI, - в таблице разделов GUID предусмотрен флаг загрузочного раздела, аналогичный по смыслу флагу 80h в MBR.


В смысле резервная? Имеешь ввиду копию таблицы в конце диска или т.н. protective MBR? Да в принципе, не важно, - не используется ни та, ни другая. Используется основная GUID таблица разделов.


Основные сложности возникнут не с загрузочным сектором, а с обработкой таблицы разделов GUID. Я намучился с boot.exe.

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

Можно дать ссылку прям на форуме для тестирования. GPT-загрузчик можно потестить, вообще не имея какой-либо ФС в разделе.

Я про интерфейс между GPT-загрузчиком и загрузчиком раздела, описанный в EDD Spec. Интерфейс во многом корявый, но уж так сложилось, что не мы пишем стандарты для всей планеты. Я планирую поддержать этот интерфейс, не отказываять от собственного.

Первое.

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

Да ладно, уже не долго ждать осталось. Тестировать загрузчик без ФС - неблагодарное занятие. :)


Ааа, это EAX="!GPT" со всеми вытекающими последствиями?.. чёрт, я как-то упустил из виду. Да, посмотрю обязательно.


Внутри они конечно разделены. Однако с двух точек зрения они безнадёжно связаны.
1. Пользователю плевать на внутреннюю структуру и кто там что делает. Ему нужно только одно - задал, с какого раздела грузиться, и чтобы автоматом всё было сделано.
2. От интерфейса между MBR/GPT-загрузчиком и VBR отвертется не удастся. Они должны взаимодействовать. А значит, лучше, если предоставленный инструмент гарантированно обеспечивает обе взаимодействующих части, чтобы потом не валить - "а вот у вас кривой VBR или MBR".

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

Yoda, кстати, если опираться на пропатчивание поля HiddenSectors на диске, то можно существенно упростить загрузку из дополнительного раздела (внутри расширенного), отказавшись от использования EBR (при желании можно и не затрагивать загрузку через "активный расширенный" раздел, оставив ее как альтернативный вариант), и при этом даже повысить функциональность MBR-загрузчика в целом. Суть в том, чтобы номер начального сектора этого раздела (фактически просто номер загружаемого сектора) при установке записывать не только в бутсектор раздела, но и в специальное поле (назовем его StartLBA) в MBR. Тогда при отсутствии активных (я активным могу назвать только первичный раздел) разделов можно делать следующее: если StartLBA!=0, то загружать этот сектор, иначе int 18h. Я стал реализовывать загрузку произвольного сектора в Alter 3 (пока только при альтернативной загрузке, т.е. при нажатом Alt'е) и пришел к выводу, что теперь мне не очень-то и нужна загрузка через EBR - установщику не сложно по номеру дополнительного раздела определить его местоположение (заодно при поиске раздела и проверку корректности номера в плане его соответствия реально присутствующему разделу можно выполнять, чего раньше не было) и записать в MBR вместе с номером (тебе с номером вообще возиться не нужно). Пропатчивания поля HiddenSectors на диске у меня пока нет, но в установщике его реализовать тоже не трудно. В дескрипторе раздела, передаваемом коду произвольного сектора от MBR-загрузчика через ds:si (не знаю, практикуешь ли ты передачу этого параметра или нет), я записываю нули за исключением поля PTREC.(start)lba, куда помещаю значение StartLBA.

Да, я патчу HiddenSectors. На всякий случай, вдруг MBR/EBR будут кем-то переписаны.


Да, но только это будет никому не известным отступлением от спецификаций. Активные расширенные разделы и код в EBR, хоть и не популярный, но всё же легальный способ. А так конечно можно сделать загрузку произвольного сектора с любой дисковой структуры.


Это опять EDD specs?

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

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

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

Не совсем. В EDD Spec. эта структура во многом вырожденная (представляет интерес лишь ее расширение по смещению 16+). А вот традиционные MBR-загрузчики обычно предоставляют этот параметр, причем с вполне актуальными значениями полей структуры. Для произвольного загружаемого сектора я предлагаю использовать достаточно вырожденный вариант, но при этом все-таки инициализировать самое "нужное" поле структуры. Конечно вместо StartLBA в MBR можно хранить полноценный дескриптор соответствующего формата с вполне актуальными данными, но мне кажется, что это будет чересчур. Тем более что первичные загрузчики практически никогда не используют данный параметр.

Я закончил работу над NTFS-загрузчиком. И тут мне очень кстати и как раз вовремя подвернулась уникальная возможность. Нашему эникейщику поручили сборку крутой системы, там будет 3ТБ винчестер и мамка с поддержкой EFI. Я на пару дней возьму винт поиграться и проверю загрузку с GUID разделов за пределами отметки 2ТБ. Заодно можно будет пощупать EFI. А пока всё лишний раз проверяю, подчищаю и делаю описание.

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

Спасибо за данную информацию. Искал но не находил. Уже думаю пользоваться.

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