Снова про MBR: загрузка с USB/CD

Вы уж извините, но просто FAT не существует. Есть FAT12, FAT16, FAT32 и FAT64. Они разные! Нельзя просто вот так сказать что там фат и всё. Это мало о чём говорит.

 

Под FAT в Windows понимается FAT12/FAT16. Флешка объемом 2 гига легко форматируется под FAT(16). Другое дело в том, что у флешек обычно разметка схожа с хардами, а не с флоппиками, т.е. скорее всего linkmaze затер MBR флешки загрузчиком, который в принципе не должен там находиться.

 

Прошу прощения, но мне откровенно фиолетово, что там понимается в Windows. Она и iso9660 перевирает и называет несуществующей cdfs. Да, флэшки могут быть и разделяемые (с MBR и таблицей партишнов) и не разделяемые, но это зависит не от флэшки, а от того кто её разбил. Разделяемую флэху можно переформатить в не разделяемую и наоборот и никто ничего вам не скажет ибо та же windows прекрасно понимает и то и то. Fat12 хоть и полностью аналогична fat16 по концепции по реализации с ней несовместима. Загрузчик от fat12 на разделе с fat16 грузить не будет. Для человека программировавшего загрузочные сектора, fs драйвера и утилиты просто fat звучит как "какая то fs но я не знаю точно какая".

 

Quatre_R_Winner
Я примерно то же написал в #19 =)

 

Ну тогда вы должны знать, что загрузчики от M$ практически всегда являются универсальными по отношению к FAT12/FAT16, а частенько и к FAT32. Хотя лично я придерживаюсь подхода писать отдельные загрузчики для разных FS или даже носителей.

 

Был не прав. Каюсь.
Пореверсил загрузчики FAT12 и FAT32. Оказалось следующее.
Похоже Phantom_84 прав что FAT12/FAT16 загрузчики универсальны тк в МС сидят читеры =)
Вероятность чита я не учёл. В загрузчике они не парсят fat таблицы и поэтому им пофиг 16 она или 12. Они банально грузят только 4 сектора, причём полагают что они располагаются на диске последовательно.
В случае с fat32 таблицы им пришлось всётаки реверсить тк корневая директория находится в области данных, а не отдельно. И загрузочных секторов в случае с 32 битами стало 2 тк в один они это не уместили (я думаю даже не пытались). Но всё равно я не считаю что FAT12 и FAT16 можно скостить до просто FAT. Должна быть ясность.

 

Quatre_R_Winner
я если честно флешек поделенных на разделы не видел ((

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

 

Прошу прощения у специалистов по программированию загрузочных секторов и драйверов файловых систем. Флэшка форматируется стандартными средствами Windows в FAT16 (просто FAT—как ее обозвали в Microsoft). А дискета – FAT12. (по показаниям WIN HEX). Далее копирую первые три байта с дискеты на флэшку, затем на флэшке оставляю все данные без изменений с 4 байта по 3Dh (на моей флэшке первые три байта eb 3c 90), далее копирую с флоппи байты от 3E до 200h на флэшку по соответствующему смещению. А теперь вопрос к специалистам по программированию загрузочных секторов и файловых систем. Так как же всё-таки это всё работает на FAT16 с загрузчиком от FAT12.

 

Это всё надо для написания драйвера.
Для загрузчика можно через INT13h читать.
При загрузке с флэшки BIOS эмулирует либо FDD либо HDD на основе флэшки.

 

можно - читайте
только имхо посмотреть полезно как биос все это делает - полноценный драйвер хоста и шины в биос пихать смысла нет - там только самое важное и нужное - рамки в которых работаете знать не лишне

 

я под дос пишу прогу для доступа к флешке через контроллер UHC
продвигаюсь - в год по чайной ложке
спецификация обрушивает на тебя вагон информации вот и думаю потом с чего начать следующий шаг

 

Я уже поправился и написал что дело тут в читерстве ребят из МС. Они вообще не юзают фат таблицы, а именно в них то и отличие в 12 и 16 битных вариантах. Как результат:
- они не грузят загрузочный файл целиком.
- если файл в начале фрагментирован, то он не заработает.
Посему если партишн подготовлен корректно (файл не фрагментирован) то это дело загрузится.
За свою ошибку я уже извинился.

 

Там именно и есть полноценный драйвер.
Ничего там очень сложного нету.

И чего там в спецификации такого сложного?
У меня на написание драйвера UHCI+OHCI под DOS ушло примерно два месяца, при том что писал я в свободное время.
Дальше всё быстро продвигается - написание поддержки флэшек, PTP устройств (фотоаппаратов), принтеров и всего, на что есть спецификации много времени не забирает.
Если интересно - на sources.ru есть тема по программированию USB в DOS.
Она здоровая, но если всю прочитать - проблем возникать не должно, там все нюансы триста раз описаны.
Но до этого спецификацию конечно надо прочитать.
А вообще начинать можно с Кулакова, у него есть описание UHCI и примеры кода.
По сути у него там куча ошибок, но для того чтобы разобраться - подходит.

 

Зашел сюда
http://www.boot-land.net/forums/index.php?showtopic=8353
Dos Usb Driver

там нашел ссыль
http://bretjohnson.us/
а там всякого...
да и на boot-land.net погулять можно для интересу

 

cppasm

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

 

свобоное время у меня почти 0 - все ребенок забирает

 

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

P.S. Извините, небольшой оффтоп, но тоже в тему загрузчика. Что-то писал-писал, и вдруг задумался, как в той притче о сороконожке, которая начала думать о том с какой ноги ходит:
Вот прошел ПОСТ, биосовские инициализации. Пишем, допустим, на уровне лодера. Как для нас мапирована память? Уточню, я имею в виду следующее - у нас есть несколько банков памяти, на материнке, куда воткнуты планки разного размера. Чипсет автоматом сгоняет всю свободную память в блок, начинающийся с нуля и простирающийся до свободного объема? То есть я не должен задумываться о том, сколько и куда памяти воткнуты и есть ли "дыры" в мемори-мэпе?
Вопрос возник не на пустом месте - работал с отладочной платой на самсунговском процессоре с ядром арм9, так вот там этот процесс полностью подконтролен и лежит на совести программиста, то есть после включения питания, если память висит на банке 8, то и доступна она будет с адреса 0х30000...0 (не помню точно). А если хочется видеть ее по адресам 0х0000 - ...., то надо включать страничный режим, вирт. память, и задавать мэппинг.

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

И второй вопрос. Допустим, я читаю через инт13 с диска/флешки. Чтение по секторам, количество секторов для прочтения - ворд. То бишь прочесть максимум я могу 65535*512 байт, что равно примерно трем метрам. Адресовать я могу максимум 1 мегабайт (в реал-моде). Есть ли возможность прочитать большой файл в оперативную память, не выходя из риал-мода? ну допустим, захотелось мне загрузить свою ОС, ядро, что там еще - лодером, в риал. Чтобы в протектед вообще к дискам не обращаться. А данных накопилось на 10/15/20 мегабайт (просто к примеру). Можно ли это организовать?

 

P.P.S.
По поводу второго вопроса, кажется, нагуглил - INT 15h, AH=87h, позволяет, вроде бы, перемещать блок байт в верхние адреса - загрузчики наподобие LiLo используют его, или есть более традиционные методы?

 

См. wiki.osdev.ru. Короче говоря, дыры есть, но это никак не связано с банками памяти.

Про загрузку выше первого мега... Да, в BIOS могут присутствовать функции, копирующие данные из базовой памяти в "расширенную", а могут и не присутствовать. Они обычно работают по одному и тому же приципу: выполняют быстрое переключение в защищенный режим, копируют указанный фрагмент, а потом переключаются обратно в рельный режим. Т.е. все это можно сделать самостоятельно. Про 65535*512 ты немного погорячился... Здесь нужно учитывать различные ограничения, накладываемые аппаратурой, в том числе макс. размер базовой памяти.

 

2SunGod
По 1 вопросу - int 15h, ax=0E820h. Вообще память считается непрерывной с адреса 0 до MAX-1, причем на количество и тип планок можно смело ложить - это проблемы контроллера памяти. Но не следует ложить на все прочие девайсы, имеющие io space в памяти (т.е. отображенные туда), например видео с ее LFB и CGA..VGA памятью в пределах первого метра, ACPI, BIOS и пр., плюс старые приколы вроде дыры в диапазоне 15-16М. Причем Е820 рассказывает далеко не обо всем.
По 2 вопросу - если очень не хочется в PM, можно попробовать unreal. Но, лично я не заморачиваюсь - когда я накодю нечто, не влезающее в 640к, которых достаточно всем (с), как его из РМ загрузить, я придумаю. =)

Встречный вопрос. Кто обеспечивает shadow-bios под границей 1M? В смысле - это дыра в RAM с отображением туда ROM, т.е. биос замаплен дважды, или же это все-таки RAM с копией ROM? Если копия - то кто ее там строит?