OSDev

Представляю вашему вниманию инструментарий разработчика – набор для загрузки ОС.
Данный набор позволит тем разработчикам, которые не хотят использовать монстроидальные Linux-овые загрузчики GRUB/SYSLINUX/LILO, а хотят быстро и просто загружать собственный бинарный образ с любых носителей (дискеты, жёсткие диски, флеш-накопители, компакт-диски...) с файловыми системами FAT12/16/32, exFAT, NTFS, Ext2/3/4, Minix1/2/3, ISO9660, с дисков, разбитых на разделы как в традиционной схеме MBR, так и в прогрессивной схеме GUID (GPT) даже с разделов лежащих за пределами отметки 2ТБ. Поддерживается Dual boot. Также в комплект входит утилита Windows/Linux, которая позволяет записывать соответствующие загрузочные секторы на любое устройство или в файл, представляющий собой виртуальный образ носителя. Этот комплект позволяет приступить непосредственно к разработке образа, не разбираясь на ранних стадиях со структурой файловых систем и не впадая в ступор от нехватки места для отладки своего загрузчика. В архиве есть демонстрационное ядро, показывающее корректную инициализацию, сохранение и использование переданных загрузчиком параметров, вы можете его использовать в качестве стартапа для своего ядра.
К достоинствам набора относятся:
– Простота подготовки носителя к загрузке, при этом данные на диске не пострадают;
– Предельная простота использования – после подготовки носителя просто копируете на него свой файл образа ОС любым удобным способом и грузитесь с него;
– Ваш образ может иметь достаточно большой размер – до 620кБ;
– Ваша ОС легко узнает, с какого носителя она загружена;
– Вашу ОС можно будет легко продемонстрировать друзьям (проверить/отладить) – просто передайте файл, другие запишут его на подготовленный таким же образом носитель.
Набор не отменяет существующие загрузчики, такие, как GRUB или SYSLINUX. Он их дополняет! Эти загрузчики имеют убогую первичную загрузку, делающую процесс установки загрузчика на новый диск непростым и рискованым занятием. В комплекте приложены версии загрузчиков, не требующих процедуры установки, они непосредственно могут быть загружены этим набором.
Спецификации, использование и много чего другого можно прочитать на официальной странице проекта.

Заходим, скачиваем, используем...
OS Boot Tools v3.3
...обсуждаем здесь.

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

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

Про идентификатор раздела расскажи поподробнее. Я идентифицирую раздел одним 8-разрядным числом, передаваемым в dh. Первичные загрузчики могут получать это значение в том числе и от MBR-загрузчиков.

Я понимаю, что для ядра маленькой системы 608к вполне достаточно, но просто интересно с чем связано такое ограничение, почему не больше?

PS. Еще хотелось бы видеть поддержку Cdfs (Etfs).

Чего непонятного? Загружаем ядро в базовую память. При правильном подходе этого более чем достаточно.

+1. Я тоже хотел это написать. Именно этого загрузчика недостает до моего полного комплекта.

А, тьфу, что-то я ступил, извиняюсь, я думал управление на ядро передается уже в защищенном режиме, невнимательно описание прочитал.

Yoda, есть проверка базовой памяти и размера файла?
Наличие MBR, не решает проблемы.
Всё равно, надо будет писать функцию чтения с диска и записи на него. И будут тежи вопросы. А простой helloword можно и в MBR записать.
Иметься ли наличие поддержки GPT?

Лично у меня свой такой же набор файлов. И грузит он как COM, так MZ-EXE файлы.
С флопика гружусь в дос пишу и отлаживаю KLOADER.EXE очень удобно закончил отладки скинул в корень.
Гружусь с жесткого тот загружает мой KLOADER.EXE


MZ-EXE, выбран в виду любви к продукции Borland.

Во-первых, здесь видимо имелось в виду "не более 608 кб", а во-вторых, очень плохо, что "максимальный размер загружаемого файла зависит от типа файловой системы и её параметров" - нужно, чтобы он зависел исключительно от размера доступной (базовой) памяти. Из-за того, что вы выбрали такую низкую базу загрузки, вам и кэшировать секторы CD/DVD, FAT и т.п. особо некуда, а большие "последние" кластеры при необходимости можно считывать частично, т.е. читать только те секторы кластера, которые содержат данные файла. У меня база загрузки файла ядра равна 8000h. Сразу за файлом ядра загружается еще один файл - его база загрузки кратна 1 кб, т.к. размер файла ядра должен быть кратен 1 кб. При использовании упрощенных загрузчиков оба файла должны быть упакованы в один.

Да. Но я ставил целью сделать код, пригодный для ЛЮБОЙ валидной файловой системы. В принципе, ничто не мешает FAT32 выкинуть резервную копию бут-сектора и оставить только два зарезервированных сектора - один загрузочный и один FSInfo. В таком случае килобайтный бут уже не поместится.


DL, а не DH. Да, там номер загрузочного диска BIOS. Мой MBR передаёт полученное от BIOS значение дальше по цепочке.
Идентификатор раздела - это 4 байта, уникальный ID (Volume Serial Number), прописываемый при форматировании в бут-сектор по адресам 43h-46h для FAT32 и 27h-2Ah для FAT12/16. В принципе, имея номер загрузочного диска можно оттрассировать цепочку загрузки и самостоятельно определить раздел, с которого загружена ОС. Однако, если используются какие-то бут-менеджеры, то решение задачи может оказаться нереальным. Определение раздела по переданному VolumeID намного надёжней.


Будет обязательно. Сейчас как раз работаю над ней.


Проверки базовой памяти нет. Сначала ввёл, затем отказался от неё.
Проверки размера файла тоже нет. За ненадобностью.


Я написал, какие именно проблемы решает загрузчик. И проблемы вполне реальные. Вспомни, что ранние версии MS-DOS требовали, чтобы IO.SYS/MSDOS.SYS были первыми именами в корневой директории и IO.SYS располагался непрерывно в начале диска. Более поздние версии сняли ЧАСТЬ ограничений. Это всё от острой нехватки места. Любой, кто пишет загрузчик нулевого уровня так или иначе столкнётся с серьёзными сложностями подобного рода. А ведь гораздо приятней сразу иметь нулевой загрузчик, не имеющий НИКАКИХ ограничений на размещение файла, его имя и положение в корневой директории и не парясь процессом начальной загрузки.


С данным загрузчиком дальнейшую работу с дисками через BIOS по INT13 уже можно и не писать. 608к вполне достаточно, чтобы в них вписать перевод в защищённый режим, часть ядра, драйверы дисков и файловых систем без промежуточных стадий. А в случае мини-систем и вообще целиком грузить всё ядро ОС.


Ну да, конечно. Посмотри на мучения Станислава, нещадно терзающего свою флешку нестандартными форматами :)


Сейчас нет, но стоит в ближайших планах.


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


Полностью зависимость убрать малореально. Во-первых, BIOS сам отъедает немалую часть базовой памяти. Во-вторых, сектор устройства документированно может быть до 4к (уже в этом есть неизбежная вариативность!). В третьих ещё минус 1.5к векторов прерываний и переменных BIOS. Ещё нужно место для самого кода, промежуточных данных и т.д. На всё я отвожу максимум 32к. Остальное (640-32) и есть те самые гарантированные 608к, что на самом деле немало. Реальный максимум - 627к для FAT12/16 и 625к для FAT32, но лишние 20к - слабое утешение. Если файл не вписался в 608к уже сейчас, то надёжней будет всё же ввести промежуточный загрузчик или распаковку в ОЗУ, чем закладываться на негарантированный бонус в 20к.


Не вижу связи. Это лишь вопрос выбора адреса, КУДА что кэшировать/писать. База 600h позволяет мини-ОС полней и удобней использовать имеющуюся в распоряжении память.


Вот видите, у вас уже начались какие-то искусственные ограничения :)

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

Да. Но в отличии от FAT1x в FAT32 обычно с этим нет проблем. В любой винде загрузчик имеет размер минимум 1 кб, а резерв часто делается еще больше. Есть и другие вменяемые способы увеличения размера пространства, доступного загрузчику. Например, у меня для FAT1x используется единый (для обоих типов ФС) расширитель загрузчика, размещаемый в файле bootex.bin размером 512 байт. Можно даже сделать вариативное размещение расширителя либо в файле, либо в резервной области.

Я говорил про свой идентификатор раздела. Он передается в dh и является просто "географическим" (сейчас) или каким-либо иным (в перспективе) номером раздела. Выдержки из моей спецификации на эту тему можно найти здесь.

У такого подхода (я его называю "лэйбльным") есть как преимущества, так и недостатки. Чтобы идентифицировать раздел, нужно прочитать его бутсектор, а заодно и бутсекторы других разделов. У меня перечисление разделов может выполняться вообще без обращения к их содержимому. Существует вероятность появления двух одинаковых идентификаторов.

Что так? Ты же заполняешь базовую память под завязку. А как это сделать, точно не зная границу доступной (базовой) памяти сверху?

Не понял. А если у тебя в корне лежит стометровый файл ядра? Как загрузчик его будет грузить?

+1

+1. В моей схеме драйвер загрузочного устройства и ФС находится в отдельном файле, который грузится вместе с файлом ядра, поэтому никакие промежуточные стадии не нужны. Этот драйвер является обычным драйвером защищенного режима. Единственное, что следует учитывать, так это то, чтобы в нем обязательно содержался и драйвер загрузочного диска, и драйвер соответствующей ФС, и менеджер разделов (в случае использования разбитого на разделы диска).

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

То что "отъедает" BIOS, никак нельзя считать доступной базовой памятью. В случае больших секторов (больше 1 кб; к примеру 2 кб в CD/DVD) ты мог бы кэшировать последний сектор файла в специальном буфере, если он полностью не умещается в оставшемся участке памяти, а находящиеся в нем файловые данные умещаются. Арифметика 640-32 (в идеале) больше похожа на мою. Я не понял, откуда при адресе загрузке 600h у тебя взялись 32 кб? Ты что ли используешь участок в конце базовой памяти? А как же EBDA?

Сомнительное утверждение. Если почти всю базовую память занимает загруженный образ, то о каком удобстве вообще идет речь. А с загрузчиком дела обстоят еще хуже, ведь у тебя адрес загрузки ядра (600h) лежит ниже адреса загрузки загрузчика (7C00h). Получается, чтобы загрузить ядро размером больше 7C00h-600h, тебе сначала нужно переместить загрузчик.

Это искусственное ограничение исключительно положительное. Кратность размера файла ядра 1 кб является одним из первичных признаков его корректности (есть еще и сигнатура в конце), который может быть проверен уже на этапе работы первичного загрузчика (я бы и проверку контрольной суммы вынес в первичный загрузчик, но наличие у файла ядра контрольной суммы не описано в загрузочной спецификации).

Вопрос: а зачем всё это, если удалось всё нормально разместить в 512 байтах?


Интересные спецификации. Однако, в свете VolID я рассматриваю это только как потенциальный бонус. Тем более, что после перехода в защищённый режим Int13 перестаёт быть доступным (или же надо делать отдельный Virtual 86 модуль специально для функций BIOS) и что такое Drive 80h - уже остаётся только гадать. VolID в целом более надёжный метод, т.к. предоставляет информацию, не зависящую от BIOS.


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


Существует. Однако 1) она мала и 2) ничто не мешает принудительно разнести совпадающие идентификаторы.


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


:))) а с чего бы в корне лежал 100-метровый файл ядра, если чётко сказано - 608к? Только если 1) файловая система попорчена или 2) пользователь вышел за рамки спецификаций. И то, и другое - однозначно Achtung!


ОК, принято. Сформулирую более внятно в ближайшем же обновлении.


32к сверху. Я релокирую бут-код вверх. А что EBDA? EBDA мне не мешает. Я эту область не трогаю :)


Если всю, то переходи в защищённый режим и используй остальную память. Если не всю, то и базовую память можно нормально использовать. В любом случае, зачем терять кусок памяти, ниже базы загрузки? Его надо впоследствии криво мапировать, либо накладывать на него какие-то переменные (тоже криво). 600h - это первый реально свободный байт, и то, что туда помещается начало пользовательской ОС, выглядит вполне естественным.


Нормально перемещается. Нет проблем.


1. Посмотрел на файл NTLDR на одном из дисков. Размер - 297072. Ничему не кратен.
2. Не вижу серьёзной причины для введения кратности. Но если уж так хочется, не пойму, чем база 600h помешала? Да хоть и 123h :)
3. Если кратность размера файла по каким-то необъяснимым причинам завязана с кратностью памяти, то в чём принципиальное отличие кратности 1024 от 512? Магия чисел? А по мне, так лучше 512. В размер сектора.
4. Не дело это первичного загрузчика, проверять кратность и сигнатуры. Его задача - загрузить файл и передать на него управление. В конце концов, ИМХО, лучше будет, если стартап-код в начале образа сам проверить свою контрольную сумму и полноту загрузки.

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