OSDev

Я выполняю детект в соответствии с ACPI Spec.: int 15h 0E820h/0E801h/88h. Базовую память определяю через int 12h.

Судя по тому как я общался со sctuter в скайпе и судя по тому, что он тут спрашивает - это тупо тролинг.
Человек пишет, что знает ACPI, но не знает что такое SourceForge. Человек намекает, что английский язык не нужен словами "Да, ладно. Наверное, помогает засрать мозг работодателю".
По моему это работодатель должен знать английский очень хорошо, если речь идет об IT конторах. Я не думаю, что менеджеру по продажам или сотруднику отдела в банке нечем занятся на работе и он решил программировать ядро операционных систем, до столь редких подробностей. Поэтому объяснение лезет в голову одно - тупо троллинг. То как человек отвечает на вопросы, то как человек нарочно старается спросить запутанней. Странно как-то.

Но вопрос навел на мысль.
Вообщем вопрос все же так будет стоять. Я понимаю, что, чтоб написать программу для работы с памятью, нужно ее выполнять и считывать из этой же памяти. А есть какие-это контролеры, отвечающие за оперативку? Ну там узнать серийный номер, vendor, частоту и другие характеристики. Память слишком скрытна.

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



Я не думаю, что все с образованием программиста работают программистом. Я не работал ни дня программистом.

Так и называется контролёр памяти. По поводу регистров они есть смотри документацию на чипсет.
По поводу вендер и так далее зашита это в память там маленькая микросхема SPD. Доступ к ней через SMBus (I2C).

Да, именно в SPD эти данные и находятся. Большинство биосов переводят их в более удобноваримый вид и отдают ОС в виде таблиц DMI, которые описаны в спецификации SMBIOS. Но эти данные часто неточны.

Реализовал вчера получение списка участков доступной памяти через 0x15, eax=0xe820. В данный момент ядро грузится загрузчиком в реальном режиме по адресу 0x1000:0. После загрузки происходит получение доступной памяти. Немного подробностей http://dev64.wordpress.com/2012/06/08/ibm-pc-at-memory-detection/.



Готовы загрузка с FAT12, FAT32.
Есть билд система для ядра
В ядре есть 16-ти битные и 32 битные сегменты для кода реального и защищённого режимов.
Есть небольшая пока библиотека отладочных функций для вывода шестнадцатиричных чисел и дампов. (Несмотря на то, что агитирую за Cи, функции все слелал на nasm так в реальном режиме оказалось проще).

Теперь нужно решить, куда экспериментировать дальше.

Самое главное это сделать песочницу. В которой будете ловить исключения выводиться сообщение и передача управления в отладочный процесс/функцию.
В отладочном процессе надо сделать обработку клавиатуры вывод текстовой информации с прокруткой. И запуск функции на выполнение. 0 основной код. И отладочные процедуры то как просмотр регистров. Памяти.



Что касается памяти, то надо разбираться со страницами. Проверить и если надо скорректировать диапазоны что бы не попадали на середину страниц.
Экспериментировать с переключением задач.
Сделать загрузку файлов с ФС.

Спасибо. Приоритетность судя по всему такая:
- посимвольный вывод на экран с прокруткой
- отладочные функции отображения регистров и памяти
- обработчики прерываний ( заглушки )
- драйвер клавиатуры...
- отладочная песочница...

Где-то так.

Я бы начал с заглушек на исключения, которые выводят параметры исключения (EIP, CS, FLAGS, ESP, SS, номер исключения, код ошибки) в определенном месте экрана и вешают процессор. С ними отлаживать проще.

Да, вывод отладочной информации. Клавиатура поначалу не обязательна, т.к. ее поддержка может потребовать того, чего еще в принципе нет. Естественно, память. Менеджер физической памяти. Управление виртуальной памятью, сначала в ядре (т.е. то, о чем ты недавно спрашивал), потом и в прикладном пространстве. Эксперименты с многозадачностью (создание/удаление соотв. структур, переключение задач). Т.к. поток - один из основных объектов ядра, создание/удаление структур потоков очень тесно связано с управлением виртуальной памятью в ядре, например, у меня в ядре размер блока распределения и размер блока для потока специально сделаны равными (16 кб, только для блока распределения выделяются все 4 страницы физ. памяти, а для потока только 3), чтобы ими можно было управлять единообразным способом и размещать их вперемешку в едином пространстве (список свободных блоков распределения и список свободных блоков для потоков - это один и тот же список).