выбор вариантов загрузки

Kernel boot-loaders discussion
  • yogev_ezra, ну да, так и есть.
  • yogev_ezra
    Кроме собственно загрузчика существует проблема еще и с наличием места в карте памяти - участок в который загружен образ не является частью памяти, которую перераспределяет менеджер памяти. И соответственно не может быть выделен по произвольному адресу. Оставлять больше чем 1,44 Мб под эту возможность для универсальной системы - это бесполезная растрата памяти. Вероятно возможно исхитриться и написать адаптивный код, но пока этого никто не сделал - очевидно в виду его достаточной сложности и наличии множества корректировок которые надо произвести при переопределении статических участков памяти. В свое время такая же ситуация была с участком памяти выделяемым под фоновую картинку, но там я при помощи Serge откорректировал код и память стала выделятся уже после начала работы менеджера памяти, но даже тогда это потребовало от Serge большой работы по корректировке расположения множества других участков памяти. Если бы все было так просто как на словах, то много чего мы бы уже исправили, но "увы и ах". :(
  • Тогда имеет смысл выкинуть из загрузчика поддержку всех других размеров, кроме 1.44МБ, раз всё равно ими никто не пользуется. А освободившееся место занять чем-то более полезным, как art_zh предлагает.
  • Только как вариант. И с 2.88М стоит повозиться, рано еще все выкидывать.
    К тому же сдается мне, что почтальон Печкин все правильно доставил.
    Просто те, у кого докУменты были в порядке, не стали по каким-то своим соображениям отдавать посылочку конечным юзерам.
    Ибо 1.44М образ очень хорошо вписывался в концепцию минимальной, аскетичной ассемблерной ОСи, а 2.88М - уже нет.
  • 2.88 Мб не менее хорошо вписывается, просто это не распространенный формат дискет - сам я их в живую не видел, но доходили слухи, что стоимость такой дискеты была в 3-5 раз выше чем у 1,44 Мб. Плюс необходимость наличия также мало распространенного дисковода под этот формат.
  • art_zh wrote:Только как вариант. И с 2.88М стоит повозиться, рано еще все выкидывать. 1.44М образ очень хорошо вписывался в концепцию минимальной, аскетичной ассемблерной ОСи, а 2.88М - уже нет.
    Ещё 1.44 MB вписывается в BIOS от eBox, а 2.88 MB - нет :wink:
    Mario wrote:2.88 Мб не менее хорошо вписывается, просто это не распространенный формат дискет - сам я их в живую не видел, но доходили слухи, что стоимость такой дискеты была в 3-5 раз выше чем у 1,44 Мб. Плюс необходимость наличия также мало распространенного дисковода под этот формат.
    Я и 1.44 MB уже лет 5 в Израиле не видел, да и компьютеры все давно продаются без флоппи-дисководов. 1.44 MB был хорошим размером, когда такие дискеты на самом деле использовались, но сейчас уже неважно, будет это 1.44 или 2.88 - нет ни того, ни другого. Вот если мы вставим Колибри в BIOS, тогда чем меньше - тем лучше.
  • #1940: в первичном загрузчике свободно около 150 байт. Никаких новых функций пока не добавлено.
    _______________________

    какие дискеты? кто-нибудь в наше время еще грузит Колибри с флоповода ?!
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Я создала отдельную ветку для ядра, считывающего настройки загрузочного экрана из внешнего файла config.ini, kernel/branches/kolibri-cfg, r1942. Подробности в http://redmine.kolibrios.org/projects/k ... readme.txt .
    Собранный образ на базе r1937 я выложила в http://ftp.kolibrios.org/users/CleverMouse/kolibri-cfg/ , там есть образ дискеты и образ ISO, последний для разнообразия с kolibri.img в виде отдельного файла для рамдиска, а не загрузочного образа дискеты.
    Сделаем мир лучше!
  • CleverMouse wrote:Я создала отдельную ветку для ядра, считывающего настройки загрузочного экрана из внешнего файла config.ini, kernel/branches/kolibri-cfg, r1942. Подробности в http://redmine.kolibrios.org/projects/k ... readme.txt .
    Собранный образ на базе r1937 я выложила в http://ftp.kolibrios.org/users/CleverMouse/kolibri-cfg/ , там есть образ дискеты и образ ISO, последний для разнообразия с kolibri.img в виде отдельного файла для рамдиска, а не загрузочного образа дискеты.
    CleverMouse: ты ненормальная? :shock: Это ты за выходные всё это написала? :shock: Я в шоке :mrgreen:

    А почему это должно быть несовместимо с транком?
  • "ты ненормальная?" - ну, может быть, и да.
    "Это ты за выходные всё это написала?" - разумеется, не всё, это фактически trunk + sec_loader/boot, а остальное - простой разбор конфига и мелкие правки, которые пишутся за несколько часов с отладкой.
    "А почему это должно быть несовместимо с транком?" - схема загрузки принципиально разная. Транк предполагает, что есть один файл kolibri.img и внутри него находится всё остальное, начиная с ядра kernel.mnt. При этом на момент загрузки ядра из транка образа в случае дискеты образа просто нет, так что конфигурационные файлы догрузить невозможно. sec_loader предполагает, что первичный загрузчик умеет загружать много разных файлов, он, насколько я понимаю, планировался с отказом от одного файла kolibri.img; в частности, вторичный загрузчик и конфигурационный файл должны присутствовать как отдельные файлы. В качестве вторичного загрузчика в kolibri-cfg выступает прямо ядро, и оно подгружает kolibri.img.
    Сделаем мир лучше!
  • Clever Mouse
    Отличная работа, спасибо!

    yogev_ezra
    Все возвращается на круги своя (из старого форума) :
    Mario79 wrote:
    Иван Поддубный wrote:У Вилле в M64 настройки хранятся в config.mnt, который грузится там же, где и kernel.mnt - в bootloader'е. И мне кажется, что такой подход лучше.
    Такой подход лучше и мы, кажется, такие идеи уже обсуждали. Даже хотели сделать, чтобы был счетчик - если никакая кнопка не нажимается, то ядро грузиться с предустановленными параметрами, а если нажимается то предлагается ввести параметры.
    shurf wrote:Отчитываюсь: переделал код загрузки образа дискеты в рамдиск.
    Теперь корректно загружаются дискеты любого формата, а не только 1.44 Мб (файл kernel/trunk/boot/bootcode.inc).
    Но, с дискет, отличных от 1.44 Мб по прежнему не поднимается система, так как привязка к 1.44 Мб присутствует и в коде работы с рамдиском.
    Желающие могут проверить работу КоОС с моим загрузчиком и стандартной дискетой 1.44 Мб
    Проверил на 2.88М-диске, ядро отлично грузится, но потом при загрузке рамдиска затирает часть системных переменных. Попытка расширить область рамдиска (#1941, const.inc) позволила выловить пару старых багов, но все-таки большие диски пока не грузятся.
  • Без динамического выделения памяти под рамдиск игра с размерами не стоит свеч.
  • Mario
    Согласен на все 100.
    Только сложно будет вычесать всех реликтовых багов из ядра - большая часть работы с рамдиском идет через абсолютные адреса.
    У меня сейчас нет ни времени, ни терпения, ни желания чтобы все это перелопачивать - просто было интересно посмотреть в чем проблема с большими img-файлами.
  • CleverMouse wrote:"ты ненормальная?" - ну, может быть, и да.
    Я имел в виду в хорошем смысле, ты как Энштейн (это был комплимент) :wink:
    CleverMouse wrote:"А почему это должно быть несовместимо с транком?" - схема загрузки принципиально разная. Транк предполагает, что есть один файл kolibri.img и внутри него находится всё остальное, начиная с ядра kernel.mnt. При этом на момент загрузки ядра из транка образа в случае дискеты образа просто нет, так что конфигурационные файлы догрузить невозможно. sec_loader предполагает, что первичный загрузчик умеет загружать много разных файлов, он, насколько я понимаю, планировался с отказом от одного файла kolibri.img; в частности, вторичный загрузчик и конфигурационный файл должны присутствовать как отдельные файлы. В качестве вторичного загрузчика в kolibri-cfg выступает прямо ядро, и оно подгружает kolibri.img.
    Объяснение понял, для тестирования пойдёт, но если клиент будет доволен результатом и захочет за это заплатить, то как перенести это в транк? Он же захочет заказать ещё изменения, не только загрузчика. Для каждого изменения делать ветку - слишком накладно, и потом долго собирать это вместе.
    art_zh wrote:yogev_ezra
    Все возвращается на круги своя (из старого форума)
    Я тебя огорчу, но кто-то (Марио?) уже скопировал все сообщения старого форума сюда, так что мог туда не ходить: viewtopic.php?f=34&t=335&start=25
  • Who is online

    Users browsing this forum: No registered users and 2 guests