Отладка начального загрузчика
Теперь небольшое отступление, как работает тот загрузчик:
1. boot-sector: ищет в корневой папке раздела файл "mtldr", грузит его в ОЗУ;
2. mtldr: выводит приветствия, ищет .img - файл ядра, грузит его, переходит в защищенный режим и передает управление дальше.
Когда я сменил имя "mtldr" на "bigboot" во всех исходниках прога работать перестала. Надо узнать, почему. Вопрос - как?
ВМварь и прочие, как я понял, отладку не поддерживают, QEmu только под линуха, а bochs просто пишет, что не может открыть образ "\\.\PhysicalDrive2".
Приду с работы, под убунтой на боксе попробую еще, с каким-нибудь путем вроде "/dev/sdc", но думаю, что врядли что-то изменится. Да и писать на асме с Intel-синтаксисом из-под линукса дело возможное, но вряд ли безгемморойное.
Подскажите, пожалуйста, кто с этим сталкивался - чем с наименьшим геммороем можно отладить boot-сектор, записанный на флешку?
ЗЫ. Имя диска указано правильно, параметры АТА в боксе указывал, параметры загрузки настраивал. В ВмВари этот же путь к реальному диску прокатывает без проблем.
ЗЗЫ. Ось - вин7 (с правами админа) и ХР сп3, и там и там не открывает "\\.\PhysicalDrive2".
Вполне понятно. Чтобы занимала меньше и места и работала быстрее. Но я думаю главноая причина не в этом, а в том, что некоторые люди считают, что почти всё под PC надо писать на асме. Я отношусь к этой категории.
Легко и просто. У FASM (на нём кстати написана KolibriOS) есть версия под Linux. Большинство других ассемблеров с Intel синтаксисом имеют версии под Linux.
А подключать не реальный диск а img образ нельзя разьве?
Вообще если загрузчик грамотно написан, то ему должно быть всё равно откуда он грузится: с флешки, с жёсткого диска или с дискеты.
Использовать грамотно написанный загрузчик (требования смотри выше) и отлаживать с помощью Bochs из образа.
Если в начальном загрузчике, то с помощью функции 8 прерывания 0x13. Именно так делают универсальные загрузчики (а ещё они берут не фиксированный номер диска, а из DL - при загрузке BIOS пишет туда номер загрузочного диска). Если же для Bochs, то эти параметры нужны только для жёстких дисков (получить их можно с помощью bximage). Для флешек (подключить виртуальную флешку он может, но грузиться с неё не умеет) и дискет параметры расчитываются автоматически.
img-образ для Bochs - просто побитовая копия. Дискеты для всех ВМ представляются именно в таком формате. Жёсткие диски и образы CD/DVD могут представляться и в более сложном формате.
Интересно как вы его запустите без операционной системы.
адресация в этих функциях LBA . )
Загрузчики не должны быть универсальными, но для харда и флешки действительно лучше использовать унифицированный загрузчик (и для mbr, и для разделов), при условии что флешка с mbr. В современном загрузчике сначала идет попытка использования EDD, а уже потом при отсутствии поддержки в целом или возможности использовать для конкретного девайса функции EDD используется традиционный дисковый сервис. Функцию 8 можно использовать во-первых для проверки непротиворечивости значений heads и spt, возвращаемых этой функцией и соотв. значений находящихся в mbr, в структурах загрузочных секторов разделов (bpb и т.п.). Во-вторых, ее можно использовать для вычисления емкости старых девайсов с целью дальнейшей проверки попадания линейного или "трехмерного" адреса очередго загружаемого сектора в допустимые пределы. Для современных хардов значения heads и spt, устанавливаемые BIOS, обычно равны 255 и 63 соответственно. Для флешек трехмерные координаты часто четные, чтобы раздел(ы) флешки четко укладывались в весь объем.
Лично я предпочитаю нагружать загрузчики более интеллектуальной работой, а не перегружать часто бесполезной. Например, не грузить первые три сектора загружаемого файла, а загрузить файл целиком и может быть даже не один. Конечно, у меня тоже есть перегибы. Например, в коде FAT12 для флоппика для определения геометрии используются константы, а не поля известной структуры, кроме того сама структура "обрезана" и не содержит полей, появившихся в последних версиях. Кода для FAT12 для харда нет вообще, хотя если бы захотел написать, то написал бы. Есть FAT16, FAT32, разные варианты MBR с расширениями (подходят и для харда, и для флешки). Готовится CDFS с поддержкой Джульет при наличии на диске.
В принципе так, но мои загрузчики при необходимости могут использовать и традиционный сервис с "трехмерной" геометрией (здесь универсальность как раз не помешает, по крайней мере пока). Правда, я получаю "трехмерные" координаты из линейных, а хранящиеся в структурах загрузчиков использую лишь для проверки. Только EDD используется лишь в CD-загрузчике.
Это как раз мой случай, правда, я сейчас занимаюсь внедрением поддержки CD/DVD и CDFS (ISO9660 с расширениями). Хотя некоторые грузят все необходимое на этапе начальной загрузки посдедством BIOS, а потом не работают с флешкой вообще. Было бы хорошо, если бы USB-накопители обладали такими же возможностями по эмуляции, что клавиатура и мышь (USB).
Я тоже. Только вот у меня для вычисления используется количество головок и секторов, возвращёное функцией BIOS, а как у вас? Константы? Под универсальностью я имел ввиду: использование номера диска, переданного BIOS в DL при передаче управления загрузчику и преобразование в "трёхмерную геометрию" на основе данных BIOS.
я использовал готовые константы как Phantom-84 ) так у меня ещё и свободное место осталось . первый сектор вторичного загрузчика гружу в 7е00 и предаю ему управление , а он сам уже дописывает остальные части дальше и может пользоваться функциями (чтение сектора EDD,чтение сектора FDD,разбор FAT12,printf) загрузочного сектора в 7c00 . экономия ;)
Константы используются только в одном загрузчике, для флоппика. Для других загрузчиков значения heads и spt получаются от BIOS и для проверки сравниваются с соотв. значениями из bpb или mbr (это особая проверка - ее редко кто выполняет - осуществляется по координатам конца раздела, с которого продолжается загрузка), но все это только при условии, что для загрузки не удалось использовать EDD.
я использовал готовые константы как Phantom-84 ) так у меня ещё и свободное место осталось . первый сектор вторичного загрузчика гружу в 7е00 и предаю ему управление , а он сам уже дописывает остальные части дальше и может пользоваться функциями (чтение сектора EDD,чтение сектора FDD,разбор FAT12,printf) загрузочного сектора в 7c00
Это как в грабе или в DOS. Мне такое не нравится. У меня система может грузиться вообще без вторичного загрузчика при условии, что она одна в разделе, а ядро естественно универсальное и вообще ничего не знает об ФС, с которой оно загружается, и почти ничего о загрузочном устройстве, хотя получает номер загрузочного диска (в формате BIOS) и раздела от загрузчика (но это используется только для получения сведений о загрузочном устройстве для последующего его поиска в списке устройств, сформированном драйверами). Вторичный загрузчик, если используется, грузится как ядро (при желании можно даже имя не менять), но работает в RM (не использует драйверы), поэтому содержит в себе весь необходимый код для работы с дисками и ФС, хотя можно написать и такой вторичный загрузчик, который эмулировал бы поведение ядра в плане загрузки драйверов и использовал их для загрузки ядра, но опять же мне будет проще написать разные вторичные загрузчики или просто пополнить вторичный загрузчик кодом для поддержки новых устройств/ФС (здесь нет особых ограничений на размер кода и в качестве источника дальнейшей загрузки могут быть выбраны диски разных типов с разными ФС, поэтому универсальность вполне целесообразна).