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

Kernel boot-loaders discussion
  • XVilka wrote:svn --reintegrate
    Я не имел в виду физический перенос, который можно осуществить, а способ работы как таковой: если есть 2 варианта работы, но один из них по всем параметрам лучше другого (strictly better), то используется первый вариант, а второй выбрасывается. Если же у обоих есть и преимущества, и недостатки, то тогда решить, что оставить, а что выбросить, гораздо сложнее. Изменения CleverMouse, по вашему мнению, strictly better чем текущий транк? Если да, то может сделать их транком? А если нет, то каковы их недостатки перед текущим транком?
  • рамдиск использует две константы

    Code: Select all

    RAMDISK             equ (OS_BASE+0x0100000)
    RAMDISK_FAT         equ (OS_BASE+0x0280000)
    
    но там жесткая привязка в коде к размеру 1.44
  • Загрузка с дискеты и CD идет на абс. адрес 100000h через int 15h и еще где-то сидит привязка, некогда искать.

    Если стало тесно в kolibri.img - надо официально переходить на HD-загрузку (а для встроенных систем - на BIOS Boot ) и не париться.
  • Надо переходить на загрузку, не стесненную одним размером.
  • art_zh wrote: Если стало тесно в kolibri.img - надо официально переходить на HD-загрузку (а для встроенных систем - на BIOS Boot ) и не париться.
    Мне пока не тесно, и если Flash ROM chip на 2 мегабайта, то хватит и на BIOS, и на Колибри. Но для широкой аудитории, думаю, тесно. А рассчитывать надо на большинство.
  • yogev_ezra
    А зачем вообще хранить образ рамдиска (включая FAT) в ROM, если ядро будет грузиться через BIOS Boot?
    Ведь rdsave работать не будет все равно.
    Подгрузить шрифты, иконки и обои (а также, возможно, и драйверы) можно и с фиксированных ROM-адресов, а с остальным работать или на HD/BD, или сделать поддержку CBFS.
  • art_zh wrote:yogev_ezra
    А зачем вообще хранить образ рамдиска (включая FAT) в ROM, если ядро будет грузиться через BIOS Boot?
    Ведь rdsave работать не будет все равно.
    На eBox EEPROM, там можно и записывать (если использовать функцию "Virtual Floppy" от производителя), правда небольшое число раз, а потом он испортится.
    art_zh wrote:Подгрузить шрифты, иконки и обои (а также, возможно, и драйверы) можно и с фиксированных ROM-адресов, а с остальным работать или на HD/BD, или сделать поддержку CBFS.
    Если будет поддержка CBFS, то можно и так, ты прав. Я просто шёл по минимуму сопротивления. Для eBox "минимум сопротивления" - это узнать, как включить заводскую функцию "Virtual Floppy", и тогда не понадобится ни допиливать CoreBoot, ни менять что-либо в Колибри.
  • Изменения в ветке kolibri-cfg призваны показать, что конкретную задачу настройки экрана загрузки внешним файлом несложно решить на основе существующего кода. У этой ветки следующие недостатки по сравнению с транком:
    - отсутствует сохранение параметров; надо заметить, что на столь ранней стадии загрузки, по-видимому, сохранение параметров прямо конфликтует с текстовым файлом настроек;
    - несогласованность образов дискеты при разных способах загрузки: при загрузке с дискеты все файлы, естественно, читаются с неё; при остальных видах загрузки файл образа дискеты всё ещё нужен, но файлы ядра и настроек должны лежать вне ядра;
    - отсутствует перезапуск ядра из памяти.
    Сделаем мир лучше!
  • CleverMouse wrote:Изменения в ветке kolibri-cfg призваны показать, что конкретную задачу настройки экрана загрузки внешним файлом несложно решить на основе существующего кода. У этой ветки следующие недостатки по сравнению с транком:
    - отсутствует сохранение параметров; надо заметить, что на столь ранней стадии загрузки, по-видимому, сохранение параметров прямо конфликтует с текстовым файлом настроек;
    Ну если все нужные параметры уже читаются из конфиг-файла, то их и сохранять не придётся, верно?
    CleverMouse wrote:- несогласованность образов дискеты при разных способах загрузки: при загрузке с дискеты все файлы, естественно, читаются с неё; при остальных видах загрузки файл образа дискеты всё ещё нужен, но файлы ядра и настроек должны лежать вне ядра;
    То есть, если сейчас я использую утилиту HD_boot от diamond-а для загрузки kolibri.img с SD-карточки, то в ветке kolibri-cfg это работать не будет?
    CleverMouse wrote:- отсутствует перезапуск ядра из памяти.
    Ну это лично мне ещё никогда не нужно было.

    Можешь, пожалуйста, объяснить про параметр vbemode в конфиг-файле (я не понял, что он делает), а также, где задавать цветность (32 бита, 256 цветов и т.д.)?
  • "Ну если все нужные параметры уже читаются из конфиг-файла, то их и сохранять не придётся, верно?" - это спорный вопрос, поэтому я его специально выделила. Если пользователь поменял какие-то настройки в загрузочном экране, он может хотеть, чтобы они сохранились, и тогда сохранение настроек прямо из загрузочного экрана удобно. На всякий случай: у меня нет чёткой позиции по вопросу, что в этом случае лучше.

    "То есть, если сейчас я использую утилиту HD_boot от diamond-а для загрузки kolibri.img с SD-карточки, то в ветке kolibri-cfg это работать не будет?" - нет, не будет, ядро из kolibri-cfg несовместимо по загрузке с ядром из транка. Я не в курсе, что такое HD_boot; если ты имеешь в виду HD_load/USB_Boot/inst.exe из дистрибутива, то ему надо подсунуть скомпилированный kolibri-cfg/bootloader/fat32/bootsect.asm в качестве BOOT_F32.BIN, а скомпилированный kordldr.f32.asm скопировать на целевой FAT32-том - сейчас inst.exe копирует MTLD_F32.

    "Ну это лично мне ещё никогда не нужно было." - ну, лично мне тоже, я упоминаю для полноты.

    "Можешь, пожалуйста, объяснить про параметр vbemode в конфиг-файле (я не понял, что он делает)" - "если вы не знаете что это - оно вам не надо" ©. Я серьёзно.

    "где задавать цветность (32 бита, 256 цветов и т.д.)?" - я ориентировалась на существующий код, а он не сохраняет цветность, записывает только разрешение и указатель на вход в таблице видеорежимов - если по последней части возник вопрос, смотри цитату выше. В любом случае, VESA-режимы на 256 цветов не поддерживаются, только на 32bpp и 24bpp, а между ними особой разницы нет.
    Сделаем мир лучше!
  • "а скомпилированный kordldr.f32.asm скопировать на целевой FAT32-том"... и ещё туда же скопировать kernel.mnt. Файл с аналогичным именем из образа в kolibri-cfg будет игнорироваться и может просто отсутствовать, так что простая замена файла kolibri.img на свежескачанную "ночную сборку" не пройдёт.
    Сделаем мир лучше!
  • Можешь, пожалуйста, объяснить про параметр vbemode в конфиг-файле (я не понял, что он делает), а также, где задавать цветность (32 бита, 256 цветов и т.д.)?
    Центровая фишка в Синем Меню (и, между прочим, шедевр программирования на ассемблере i8086) - это окошко выбора VBE-режимов (VESA BIOS Extension). Загрузчик выцарапывает из VBIOS все доступные режимы и предлагает юзеру самому сделать себе выбор. Такое остроумное решение позволяло избежать лавины претензий типа "а че у меня экран такой кривой?", с которыми чайники атаковали сайты всех ОСей во времена ЭЛТ-мониторов.

    Если по ходу дела юзеру надо было поиграть с разными VESA-режимами, он мог это сделать и в 32-битной среде с помощью vbemode. Именно для этого была нужна соответствующая опция в меню.

    Короче, CleverMouse как всегда права: если ты до сих пор не знал, что это такое -- оно тебе не надо!
  • "Объяснение понял, для тестирования пойдёт, но если клиент будет доволен результатом и захочет за это заплатить, то как перенести это в транк?" - отличия между kolibri-cfg и trunk не слишком большие и в местах, которые изменяются довольно редко. Я могу внедрить kolibri-cfg в trunk условной компиляцией, контролируемой переменной окружения или специальным inc-файлом.
    Сделаем мир лучше!
  • Я наблюдаю какое-то гробовое молчание в ответ на слова "Я могу внедрить kolibri-cfg в trunk". Я, пожалуй, уточню: если возражений не поступит, я ведь внедрю kolibri-cfg в trunk.
    Сделаем мир лучше!
  • Who is online

    Users browsing this forum: No registered users and 1 guest