Board.KolibriOS.org

В Колибри-А кстати первое значение: закомментировано, но все равно непонятно - неужели потребовалось больше места в: Но зачем в trunk ядре было менять?
Я скомпилировал со старыми значениями - система работает, по крайней мере в Qemu.

З.Ы. Кстати проверил ночная сборка стартует при наличии 6 Мб ОЗУ в Qemu. Если таки избавиться от рамдиска и что-нибудь поджать еще, то в 4 Мб чем черт не шутит вписаться.

IRQ_SAVE выкинуть надо. Уже не используется. А с BOOT_VAR думаю просто ошибка.

Тогда может сам поправишь включая область VRR? Я боюсь напортачить.

Хорошо, проверю в ветке acpi.

Mario wrote:Но зачем в trunk ядре было менять?
Я скомпилировал со старыми значениями - система работает, по крайней мере в Qemu.

Тогда была идея попробовать 2.88Мб рамдиск. Я у себя уплотнил системные переменные вверх и вниз относительно области РД, облом.
В области данных BOOT_VAR - одного бага в init.inc я выловил сразу, перенес коррекцию в транк но двойная декларация в const.inc по запарке осталась. Виноват.
Кстати, после этого CleverMouse нашла еще пачку багов с абсолютными адресами BOOT_VAR и на этом все вроде устаканилось.
memory.inc приведу в порядок как разошьюсь с запаркой на работе.

P.S. Системную статическую область имхо надо или расширять за границу 4М (например, увеличивая размер РД), или маппить ее нормальными 4к-страницами.
Нынешний выпендрёж с первой 4М-страницей - это 1)совершенно ненужная шиза, и 2)вечные головняки при инициализации.

Если рамдиск не располагается по фиксированному адресу, то как туда считывать данные из реального режима?

Да он и должен был лежать по тому же адресу, только раскинуться почти на 3Мб.
Для этого я попробовал перекинуть кое-какие статические блоки сверху "вниз", на свободные места, а остальное что не влезло - сдвинуть выше.
Но нифига не вышло, и как позже показала CleverMouse - не могло выйти. Хотя бы потому что в ФАТ12 и в других местах оказалось куча всего завязана на абсолютные адреса из BOOT_VAR.
Кое-что исправлено - в принципе можно разбежаться и головой об еще раз...

Ага, изобретаем опять костыль.

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

Шрифты паковать и встраивать в ядро. А вот большая страница никому не мешает, а экономит TLB.

Драйверы тоже "паковать и встраивать" в ядро?

Если драйвер всегда загружается вполне допустимый вариант.

Как-то опять кривой путь, нужно подгрузить рамдиск до загрузки шрифтов и драйверов, а подгрузить можно только если: 1) прерывания разблокированы (либо PIO режим исключительно, но мне не улыбается драйвер флопика на PIO переписывать), 2) драйвер носителя уже встроен в ядро

Поэтому мне нравится GRUB. Там таких проблем нет. А для Колибри можно рассматривать kernel.mnt как специальный загрузочный образ - то, без чего система работать не будет. Дефолтный курсор встроен в ядро. Почему не встроить туда дефолтные шрифты ?

Ты опять забываешь про дефолтные драйверы, которые на самом деле отдельно.

SVN r. 2261 удалил из синего загрузочного экрана обработку VRR, также почистил файлы с текстом (привел к единообразному виду). Как оказалось ядро с немецким и эстонским языком уже давно не собиралось, а в английском был неправильно задан IF для отображения списка доступных загрузочных устройств.

Еще перевел на немецкий и эстонский сообщения, которые были на английском. Вот только я не уверен в корректности - пользовался Гуглом. Где бы взять живых носителей языков для проверки.