загрузчик

Тест нового загрузчика постов

Котэ это всегда хорошо. А котэ познавший дзен - хорош вдвойне

Помогите найти торрент

Нужен образ ОС для планшета.

Сап реактор! Есть ли среди вас пользователи "замечательного" планшета - acer one 10 (acer d16h1).

ЗЫ: На 4pda линки почти все битые.

Уроки ОСдева №2: схемы адресации и твоя первая программа на ассемблере

Если кто-то решил следовать этим туторам, самое время обзавестись необходимыми инструментами. Скачайте turbo assembler (TASM) или любой другой привычный вам. Установите виртуальную машину с Windows XP. Работать с большинством используемых программ проще в ней. Я бы посоветовал Oracle VirtualBox.

CHS

В прошлый раз мы выяснили несколько важных вещей:

- для того, чтобы загрузить ОС с дискеты, нам нужна программа-загрузчик.

- программа-загрузчик должна занимать ровно 512 байт, причём последние два байта должны содержать метку загрузчика (AA55h).

- программа-загрузчик должна располагаться в первом физическом секторе носителя.

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

На картине выше - структура дискового носителя. Это может быть жёсткий диск, дискета или CD, суть не поменяется. Головка, она же лицо, - это одна сторона поверхности носителя (пластины). У жёсткого диска на рисунке 4 двусторонних пластины, то есть 8 головок. Головка в свою очередь разбита на концентрические дорожки (они же цилиндры), а те - на одинакового размера (как правило 512 байт) секторы. Независимо от радиуса цилиндра в каждом из них одинаковое число секторов, что позволяет для доступа к любому конкретному сектору использовать трёхкомпонентную координату Цилиндр-Головка-Сектор (Cylinder-Head-Sector, CHS). Важно помнить, что в системе CHS цилиндры и головки нумеруются с 0, а секторы - с 1. То есть для доступа к первому физическому сектору носителя наши координаты будут иметь значения: 0(цилиндр), 0(головка), 1(сектор).

Проблема в том, что привычные нам файловые системы скрывают физическую геометрию носителей за набором абстракций вроде файлов и папок. К счастью, есть альтернативы. Например, в Windows есть команда debug. Выглядит так:

debug boot.bin(имя файла, загружается в память по адресу 100h)

-w(запись) 100(адрес загруженного файла) 0(номер привода) 0(номер первого сектора) 1(число секторов для загрузки)

-q(выход)

Я выше писал, что секторы нумеруются с 1, но debug закон не писан. Всё остальное время правило в силе.

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

LBA

Информацию из этого раздела мы пока использовать не будем, но позже она пригодится. Формат CHS на сегодняшний день устарел. Практически все устройства нативно поддерживают схему адресации под названием LBA (Linear Block Addressing), в которой к секторам обращаются просто по их порядковому номеру, без учёта геометрии носителя. Тем не менее, CHS поддерживается на уровне эмуляции и для работы с дискетами пользоваться мы будем именно ей.

boot.asm

Итак, мы разобрались, как поместить нашу программу в нужное место на дискете. Самое время приступать к написанию кода! Мы, конечно, не будем в этот раз писать полный загрузчик. Это будет просто небольшая вводная в турбо ассемблер. Она предназначена для людей без опыта в ассемблере и подразумевает, что вы будете пользоваться TASM. Если вы уже знаете x86 ассемблер и намерены пользоваться каким-то другим - смело пропускайте конец статьи.

Скачали TASM? Отлично, инсталлируйте его в какое-нибудь легкодоступное место на диске и в папке BIN/ создайте папки OS/boot/stage1/.

Теперь в stage1/ создайте пустой текстовый файл, переименуйте его в boot.asm и откройте текстовым редактором. В файле создайте следующий текст:

.386p

CSEG segment use16

ASSUME cs:CSEG, ds:CSEG, es:CSEG, fs:CSEG, gs:CSEG, ss:CSEG

begin:

CSEG ends

end begin

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

.386p - указание компилятору сверять инструкции с набором для 386 процессора в защищённом (protected, отсюда p) режиме. Соответственно, если компилятор встретит инструкцию, которую данный процессор не поддерживает, он выдаст ошибку.

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

Следующую строчку будет сложно объяснить, т.к. мы пока не касались устройства процессора, так что просто примите как есть: это указание компилятору считать, что все сегментные регистры процессора указывают на сегмент CSEG.

begin - метка начала программы. Отсюда будет начинаться собственно код.

CSEG ends - конец сегмента CSEG.

end begin - метка конца программы.

Скомпилировать программу в таком виде не выйдет, так как в ней нет ни одной инструкции. Давайте добавим парочку.

.386p

CSEG segment use16

ASSUME cs:CSEG, ds:CSEG, es:CSEG, fs:CSEG, gs:CSEG, ss:CSEG

begin:                    cli

                             hlt

CSEG ends

end begin

Мы добавили 2 команды: cli и hlt. Первая запрещает прерывания, то есть не даёт устройствам отправить сигнал процессору, а вторая останавливает сам процессор. Таким образом, сейчас наша программа при запуске просто "вешает" компьютер. Тем не менее, её уже можно превратить в исполняемый файл.

Откройте командную строку, перейдите в папку BIN/ и введите: tasm OS/boot/stage1/boot.asm. После нажатия enter в папке BIN/ появится файл BOOT.OBJ. Это ещё не конец. Файл .obj - это инструкция для линкера, так что пишите: tlink boot.obj. Теперь у вас добавились два новых файла, BOOT.MAP и BOOT.EXE, последний из которых - и есть исполняемый файл, который нам нужен! Незадача в том, что мы пишем не приложение под DOS, а операционную систему, которая должна будет работать на голом железе. exe-формат содержит таблицы релокации и всякие прочие данные, которые нам будут мешать. В нашем исполняемом файле должны быть только инструкции программы и больше ничего. К счастью, и тут есть готовое решение. Пишите в командной строке exe2bin boot.exe и жмите enter. Появился файл boot.bin. Проверьте его размер, он должен занимать ровно 2 байта, по одному байту на инструкции cli и hlt. Успех!

В качестве ДЗ предлагаю всем желающим самостоятельно загнать файл в первый сектор дискеты, вся нужная информация в тексте статьи есть.

Уроки ОСдева №1

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

P.S.: если знаете английский, советую зайти сюда. Это довольно старая серия уроков по ОСдеву для новичков. Я в своё время почерпнул там очень много и в своих постах наверняка буду невольно цитировать оттуда.

Часть 1, теоретическая.

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

Я думаю, стоит начать с включения компьютера. Это не шутка: чтобы создать свою операционную систему, надо до определённой степени понимать как работает компьютер. Что происходит, когда вы нажимаете кнопку POWER на системном блоке и как у вас на экране оказывается ваш заваленный ярлыками и "новыми папками" рабочий стол? Для того, чтобы программа (а наша ОС - это, конечно же, программа) начала исполняться, она должна сначала попасть в оперативную память. Содержимое оперативной памяти же на момент включения пусто. Если среди читающих есть инженеры, советую зажмуриться и пропустить до следующего абзаца: сейчас будет упрощённая модель.

1. Нажатая кнопка POWER посылает электрический сигнал на материнскую плату.

2. Сигнал доходит до материнской платы и отправляется к блоку питания.

3. Блок питания просыпается и начинает подавать энергию подключенным устройствам.

4. Блок питания посылает сигнал на материнскую плату, начинает исполняться программа BIOS.

5. BIOS проводит POST (power-on self-test), посылая сигналы разным устройствам и получая (или не получая) от них ответ. Если устройство не отправило ответ, оно помечается как нерабочее или отсутствующее. Тут же BIOS определяет количество оперативной памяти и некоторые другие параметры системы.

6. Если POST окончен и никаких критических поломок не выявлено, BIOS сверяется со списком загрузочных устройств. Наверняка вы хоть раз его видели, если устанавливали Windows: его обычно можно настроить через интерфейс BIOS, выбрав, с чего загружать ОС (floppy, HDD, USB, ...).

Вот тут начинается часть, которая интересует нас. Предположим, мы вставили дискету с нашей ОС в привод и настроили приоритет загрузки следующим образом: CD-ROM, флоппи-привод, жёсткий диск, USB. Как BIOS определит, что на одном из носителей есть операционная система для загрузки? Физическое устройство цифровых носителей и способы доступа к информации на них это тема для отдельного урока или даже нескольких, так что пока удовольствуемся упрощённой схемой: BIOS считывает с 0 по 511 байты носителя и проверяет, чему равны байты 510 и 511. Если они равны 170 и 85 (AAh и 55h в шестнадцатеричной системе), BIOS считает, что нашёл программу-загрузчик. После этого считанный участок носителя размером в 512 байт загружается в оперативную память и запускается центральный процессор компьютера, который начинает выполнять загруженную программу. Программа-загрузчик догружает остальные файлы ОС и располагает их в памяти нужным образом, а потом говорит процессору, откуда нужно начать выполнение ОС.

Какие выводы можно сделать из полученной информации?

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

2. Загрузчик должен быть не больше 510 байт, ведь BIOS считывает 512 и последние два из них заняты меткой загрузчика.

3. Последние два байта программы-загрузчика должны быть равны AA55h.

3. Загрузчик должен занимать строго определённое место на носителе: с 0 по 511 байты. Думаю, вы замечали, что когда копируете файлы на носитель обычными методами, никто не спрашивает вас, в какой именно участок памяти вы хотите их поместить. Значит, копировать загрузчик нужно каким-то особенным способом.

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

Урок ОСдева №8: основной загрузчик, вводная.

Дисклеймер: эта серия постов не про UEFI. Это не значит, что я не знаю о существовании UEFI.

Про UEFI будет отдельная серия постов. Почему я не пишу про UEFI прямо сейчас? Потому что

UEFI - это уровень абстракции над железом, а мне интересно именно железо и работа с ним.

Итак, мы закончили писать первичный загрузчик. Что дальше? Дальше - немного пугающая

свобода. Если в случае ПЗ ограничения на объём памяти ставят разработчика в жёсткие рамки

и ограничивают полёт фантазии, то теперь вы можете строить архитектуру программы

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

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

что сможете сделать лучше - пробуйте. В любом случае стоит держать в голове минимальный

набор задач, который должен будет выполнять ваш загрузчик:

- Переключать процессор из 16-битного в 32-битный или 64-битный режим.

- Включать доступ к расширенной памяти.

- Составлять карту RAM и передавать её ОС.

- Минимально взаимодействовать с устройствами ввода-вывода, чтобы показать сообщение об ошибке

или принять ввод пользователя.

- Находить, считывать и обрабатывать файл конфигурации (опционально, делает загрузчик более гибким).

- Находить на диске и загружать в указанную область памяти ядро ОС.

- Находить на диске и загружать в указанные области памяти дополнительные файлы (опционально).

- Предоставлять ОС базовую GDT (об этом позже).

Важный момент: рано или поздно перед вами встанет вопрос совмещения в одной программе

16-битного и 32-битного (или 64-битного) кода. Лично я предпочёл с этим не заморачиваться и

разбил загрузчик на отдельные файлы. Тем более, что это соответствует любимой мной аккуратной

модульной структуре. Если вы всё-таки хотите запихать весь код в один файл, стоит заранее

выбрать ассемблер, который это поддерживает.

Ещё один важный момент: достоверное определение аппаратных ресурсов может быть (было до

появления UEFI - вставят тут апологеты) сложной задачей. Там, где это можно сделать

простым способом - я буду использовать его. Там, где для этого нужно будет полагаться

на технологии, рассказ о которых выйдет слишком объёмным для одного-двух постов (ACPI, UEFI) -

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

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

На этом вступление закончено и можно начинать писать. 16-битный модуль загрузчика будет

в некоторых местах повторять первичный. Такие участки кода я буду давать без объяснений.

Ну и - этот пост можно назвать вводным в новый этап программы, так что кода будет

немного. Поехали.Если вы вместе со мной писали ПЗ, то сейчас, запустив машину, получите вот такое

сообщение:

Создайте в папке boot папку stage2, а в ней - текстовый файл loader.asm. Заголовок и конец

модуля выглядят почти идентично ПЗ:

.386p

CSEG segment use16

ASSUME cs:CSEG, ds:CSEG, es:CSEG, fs:CSEG, gs:CSEG, ss:CSEG

LOCALS @@

begin:

CSEG ends

end begin

Добавилась только директива LOCALS @@. В TASM эта команда разрешает использование локальных

меток. Начинающаяся с символов @@ метка или переменная будет работать только в границах

процедуры или модуля, в котором прописана. Это позволит нам создавать в разных местах

переменные и указатели с одинаковыми именами. Вы оцените полезность фичи, когда начнёте писать

большие программы. Идём дальше. Первое, что нам нужно сделать - это установить значения

сегментных регистров. Совсем как в ПЗ, изменилось только значение. Если помните, loader.bin

у нас был загружен в 0050h:0000h. Выглядит так:

begin:

     ;DS, ES, FS, GS.

          mov ax,0050h     ;Сегмент загрузчика.

          mov ds,ax     ;Поместить это значение во все сегментные регистры.

          mov es,ax

          mov fs,ax

          mov gs,ax

     ;СЕГМЕНТ СТЕКА.

          cli     ;Запретить прерывания перед переносом стека.

          mov ss,ax     ;Поместить в SS адрес сегмента загрузчика.

          mov sp,0FFFFh     ;Указатель стека - на конец сегмента.

          sti     ;Разрешить прерывания.

          cli

          hlt

Регистр CS мы не трогаем, так как его значение было корректно установлено ПЗ. Для комфортной

работы нам понадобится информация из блока параметров BIOS. Мы знаем, что он был загружен в

память вместе с ПЗ, поэтому обращаться к диску нужды нет. Собственно, я мог бы просто

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

Будет лучше считать структуру из RAM. Для этого нам понадобится неинициализированный

дубликат BPB и процедура, которая его заполнит. Добавьте эти переменные в конец модуля:

;=======================================;

;Блок параметров BIOS, 33 байта.;

;Здесь хранятся характеристики;

;носителя.;

;=======================================;

BPB:BPB_OEMnamedb ?,?,?,?,?,?,?,?     ;0-7. Имя производителя. Может быть любым.

BPB_bytespersecdw ?     ;8-9. Размер сектора в байтаx.

BPB_secperclustdb ?     ;10. Количество секторов в кластере.

BPB_reserveddw ?     ;11-12. Число зарезервированныx секторов (1, загрузочный).

BPB_numFATsdb ?     ;13. Число FAT.

BPB_RDentriesdw ?     ;14-15. Число записей Корневой Директории.

BPB_sectotaldw ?     ;16-17. Всего секторов на носителе.

BPB_mediatypedb ?     ;18. Тип носителя. 0F0 - 3,5-дюймовая дискета с 18 секторами в дорожке.

BPB_FATsizedw ?     ;19-20. Размер FAT в сектораx.

BPB_secpertrackdw ?     ;21-22. Число секторов в дорожке.

BPB_numheadsdw ?     ;23-24. Число головок (поверxностей).

BPB_hiddensecdd ?     ;25-28. Число скрытыx секторов перед загрузочным.

BPB_sectotal32dd ?     ;29-32. Число секторов, если иx больше 65535.

;===============================================;

;Расширенный блок параметров BIOS, 26 байт.;

;Этот раздел используется в DOS 4.0.;

;===============================================;

EBPB_drivenumdb ?     ;0. Номер привода.

EBPB_NTflagsdb ?     ;1. Флаги в Windows NT. Бит 0 - флаг необxодимости проверки диска. Бит 1 - флаг необходимости диагностики ;поверхности.

EBPB_extsigndb ?     ;2. Признак расшренного BPB по версии DOS 4.0.

EBPB_volIDdd ?     ;3-6. "Серийный номер". Любое случайное число или ноль, без разницы.

EBPB_vollabeldb ?,?,?,?,?,?,?,?,?,?,?     ;7-17. Название диска. Устарело.

EBPB_filesysdb ?,?,?,?,?,?,?,?     ;18-25. Имя файловой системы.

db ?     ;Еще один байт для того, чтобы структура занимала 15 32-битных слов.

Как видите, в этом варианте переменным не присвоены значения. Кроме того, в конце

зарезервирован ещё один байт. Он нужен для того, чтобы размер таблицы делился на 4

и её можно было загрузить как последовательность 32-битных слов, не перетерев

ничего лишнего. Теперь нужна процедура.

read_BPB proc

     push cx     ;Сохранить регистры.

     push di

     push si

     push ds

     push 07C0h

     pop ds     ;DS=07C0h, сегмент первичного загрузчика.

     mov si,3     ;SI=смещение BPB в ПЗ.

     mov di,offset BPB     ;DI=смещение BPB в loader.bin

     mov cx,15     ;CX=счётчик для копирования.

     rep movsd     ;Скопировать 15 32-битных слов, размер BPB+1 байт.

     pop ds     ;Восстановить регистры.

     pop si

     pop di

     pop cx

     ret     ;Завершить процедуру.

read_BPB endp

Тут в общем всё просто. Устанавливаем пару регистров DS:SI на начало BPB в первичном загрузчике,

а ES:DI - на нашу неинициализированную структуру. Потом командой rep movsd копируем всю

конструкцию + 1 байт. Вызовите процедуру инструкцией call после установки сегмента стека -

и готово. Кстати, вопрос знатокам: что быстрее выполнит 32-битный процессор в 16-битном

режиме - копирование 15 32-битных слов или 30 16-битных?

На этом пока всё. Сделайте новый батч файл с примерно таким текстом, чтобы не возиться

с инструкциями вручную:

tasm project\boot\stage2\loader.asm

tlink loader.obj

exe2bin loader.exe

Слинкуйте файл, закиньте на дискету - и готово. Сообщение о том, что loader.bin

не найден, должно пропасть. В следующий раз - установка видеорежима и методы вывода

текста.

Ссылка на полный полный текст модуля: https://drive.google.com/file/d/1rFc3OcEDmf7Rs_hEJ6iX98-1SimN_dx_/view?usp=sharing

Суть проблемы, не загружается винда с SSD

Почему то при отключённых остальных дисках, не загружается с SSD, выдаёт An operating system wasn't found. Ttry disconnecting any drives that don't contain an operating system. Press Ctrl+ Alt+Del to restart. хотя ssd в биосе есть и винда на нём стоит,тут ещё статусы "система, активен" почему то не на ссд в общем я уже и не знаю, что делать.