Kolibri-BIOS

Using Kolibri in embedded systems
  • А какие сервисы предоставит биос ?
    Точнее что будет из себя представлять плата ?

    Для ядра нужна карта памяти, её получаем через е820 но у тебя всё может быть hardcoded. То же самое с PCI. Не надо сканировать шину по bus_dev_fn и вычислять прерывания на APIC. Всё уже в железе. И так далее.
  • art_zh, привет!
    Название ветки грандиозно-амбициозное, но все же хотелось бы знать от ТС, будет ли буквальное
    уточнение массы нюансов и потенциальное желание ответов на проблемно-правильные вопросы
    перспектив реализации темы, при взгляде некого другого человека со стороны?
    А изначально вывалить типа ВЕСЬ концепт можно ли? Это дабы не плодить сразу кучу вопросов или не превращать тему в новый открытый труп...

    BIOS все же очень привязана в типу железа и даже как там чего напаяно (схемотехника)....
    Засветить тему - "луч света в темном царстве" и ни чего не сказануть об железяках некорректно как то.
    Главное интерфейс, а остальное фигня, так получается.
    Я так не вижу.
    Я вижу пока, что будет 87 спецверсий Kolibri-BIOS.
    Иначе как?
  • art_zh wrote:Принимаются предложения по разработке низкоуровневого интерфейса для встраиваемых версий Колибри.
    "Всё" в основном уже придумано за нас.:)
    И один из вариантов называется OpenBios Применяется, в частности, и в OLPC компьютерах
    Хотя эта информация, вроде, уже предлагалась на форуме к обсуждению.

    P.S. По возможностям могу помочь в применении данного варианта BIOS.
    Картинки по запросу Openbios c google
  • Serge
    ftp://kolibrios.org/users/art_zh/-B/
    детали будут добавляться по ходу дела
    В конфигурации железа могут быть сменные варианты: и плата CPU, и периферийная плата допускают апгрейд.
    Напр. объем системной памяти заранее не известен, HDA или сеть могут быть не впаяны, и т.п.
    Так что какой-то мостик между BIOS и ядром таки-нужен.

    Отдельный вопрос про видеоканал: ядру нужно где-то узнать разрешение LCD-экрана, и/или устанавливать разрешение VGA-монитора. Это еще минимум 2 мостика.

    ЗЫ: Управление питанием. Контроль температуры/напряжения. APIC-интерфейс. SATA, USB, GBE - всё низкоуровневое желательно по возможности вынести из ядра/драйверов и запереть в ROMe.

    VaStaNi
    Извини, приходится сильно фильтровать базар, иначе слечу с NDA и вообще всё накроется медным тазом.
    Часть кода я должен спрятать, принципиальную схему - тоже.
    Но распайка сигналов на разъёмах и интерфейс BIOS - здесь всё открыто, и нужно чтобы всё было удобно и надежно.
    Кстати, тебе 32 линии GPIO хватит или нужно больше? :D

    Кора
    Не то.
    Этот BIOS не будет открытым.
  • art_zh
    Это же не документация. :(

    Для меня идеальный вариант когда вся железная конфигурация записана в *.inc или *.h. Такой-то контроллер - bus_dev_f, irq pic, irq apic, mmio_0, mmio_1
    APIC_ADDR xxx
    HPET0_ADDR yyy
    HPET1_ADDR zzz
    и т.д.

    Не надо сканировать шину, не надо парсить ACPI, которого и нет.
    Дальше, неизвестно распределение памяти. Это будет похоже на IBM PC с биос в верхушке первого мегабайта ? Будет текстовая видеопамять по 0хb8000 ?
    Пусть будет 10 файлов с конфигурацией на 10 разных вариантов железа. Это не проблема, скомпилировал ядро и вперёд.
  • Эта тема как раз и создана для согласования и уточнения документации.
    Образ BIOS может лежать где угодно - только скажи куда.
    Все вендоры и bdf-адреса известны, .inf будет.
    AMD поставляет VESA-BIOS/AtomBIOS в виде готового бинарного модуля. Тебе нужен текстовый видеорежим? Тогда надо будет его линковать в BIOS и городить к нему стандартный 16-битный интерфейс.
    Если не нужен - тогда имеет смысл запустить графику+фреймбуфер сразу в 32 битах.
  • А что вообще за биос ? АМД предоставляет набор "сделай сам" или полностью самописный ?
    И как будет происходить загрузка и передача управления ядру ? Уже в защищённом режиме ?
  • Serge
    Стандартные PnP-модули для видео и SATA/RAID. Стоит ли ради них (и еще сетевого BIOS) 16-битный огород городить?
    Процессор, контроллер памяти и северный мост надо программировать ручками по-любому.
    Процесс заканчивается загрузкой ядра и прыжком в нужный адрес.
    Вход в защищенный страничный режим, а может и файловую подсистему имеет смысл перенести в BIOS.
    Хотя, может и нет?

    Энумерация PCI-устройств: даже если всё железо однозначно известно, все равно каждому устройству надо назначить порты, MMIO, IRQ/MSI, сконфигурировать PM и еще много чего разного.
    мы с тобой уже пару раз перепирались по этому поводу, еще раз проимхую свою позицию: лучшая структура для хранения всей этой инфы - это расширенное конфигурационное пространство PCI Express, очень легко отображаемое на память. И видимое когеррентно с двух сторон: из ядра/драйвера, и изнутри железа.
  • 1. Если можно обойтись без 16 бит, это надо сделать.
    2. вход делать уже в защищёном плоском режиме, как в GRUB. Страничный режим устанавливать в ядре.
    3.Не ясен вопрос с распределением физических адресов. Процессор 64 бита поддерживает ?
    Надо подумать над вариантами организации адресного пространства. Если ядро находится в БИОС, а саму биос можно разместить по любым физ.адресам, то ядру не нужны смещения OS_BASE и другая подобная фигня. Оптимальный вариант собрать ядро, биос и mmio одним блоком адресов, чтобы замапить большими страницами. Очень хороший выигрыш в быстродействии.
    даже если всё железо однозначно известно, все равно каждому устройству надо назначить порты, MMIO, IRQ/MSI, сконфигурировать PM и еще много чего разного.
    Если конфигурация известна заранее, то можно распределить все ресурсы на бумаге и потом закодить в конфигурационное пространство ? И составить карту регистров mtrr.
    ...конфигурационное пространство PCI Express, очень легко отображаемое на память
    Если там только PCI Express, то да. Если нет, то функции чтения-записи лучше упрятать в биос.

    Ещё один геморрой - разные функции задержки типа nanosleep(). Нужны очень, а с реализацией всегда проблемы. Счётчики тактов и инструкций требуют муторной калибрации.

    Ещё. Что с софтом для разработчиков ? Первым вопросом будет "как запустить Линукс ?", вторым "где взять gcc ?".
  • 1. ОК, я тоже так считаю. Только придется напрямую GPU-регистры программировать, в том числе PLL-синхронизацию частоты развертки.
    2. ОК.
    3. Проц 64-битный, 2-головый.
    гм, ядро с биосом в одном пространстве - это хорошо, но почему без OS_BASE?
    нижние же адреса у юзерспейса, а ядро еще и все юзерспейсы должно держать в ядерной половине памяти, нет?

    4. фиксированные ресурсы PCI, говоришь? Кхе!
    и все константы - в .ini-файл!

    5. Там только PCIexpress. Некоторые шины/девайсы можно скрывать от чтения/записи или записывать однократно (Write-Once).
    Кроме того, некоторые функции имеют дополнительное конфигурационное "подпространство", не в стандарте PCIe. Документация на APU- уже открытая, на южмост - пока нет.

    6. Не знаю, не думал. КореБут же как-то грузит Линукс?
    Last edited by art_zh on Wed Feb 13, 2013 10:31 pm, edited 1 time in total.
  • 1.Напрямую программировать PLL очень муторно. Там куча расчетов ведётся по GTF, чтобы режим установить. И надо EDID читать чтобы поддерживаемые режимы получить. На асме без драйвера будет сделать очень сложно.

    3.Не совсем без OS_BASE, а без ремапа, потому что ядро физически по 0x10000, а виртуально 0x80010000. А если ядро физически по 0xFEC00000 то зачем ему ремап ? У нас сейчас адресное пр-во разделено пополам и обе растут вверх. А в данном случае ядерная часть переворачивается вверх тормашками. Ядро и все остальные статические области, таблицы страниц и mmio поднимаются на самый вверх. Ниже куча ядра и потом user-space. В этом случае парой констант можно регулировать размер user-space. Хочешь - 2Гб, хочешь 3.
    и все константы - в .ini-файл!
    Несбыточная мечта ядерщика и драйверописателя.
    Ещё вопрос с обработкой прерываний. Legacy железа не будет ? Всё сразу на APIC и MSI ?

    6.Так Coreboot заменяет IBM PC BIOS. А тут совсем другое всё.
  • Serge wrote:1.Напрямую программировать PLL очень муторно.
    Знаю, и не понаслышке. Еще одна стенка для пролома.
    3.Не совсем без OS_BASE, а без ремапа, потому что ядро физически по 0x10000, а виртуально 0x80010000. А если ядро физически по 0xFEC00000 то зачем ему ремап ? У нас сейчас адресное пр-во разделено пополам и обе растут вверх. А в данном случае ядерная часть переворачивается вверх тормашками. Ядро и все остальные статические области, таблицы страниц и mmio поднимаются на самый вверх. Ниже куча ядра и потом user-space. В этом случае парой констант можно регулировать размер user-space. Хочешь - 2Гб, хочешь 3.
    Красиво, только надо сначала на транке опробовать?
    Несбыточная мечта ядерщика и драйверописателя.
    это именно тот случай, когда легче спаять...
    Ещё вопрос с обработкой прерываний. Legacy железа не будет ? Всё сразу на APIC и MSI ?
    не будет: я поэтому SIO-чип вообще ставить не хочу, а с HDD пока еще не все ясно
    6.Так Coreboot заменяет IBM PC BIOS. А тут совсем другое всё.
    да, другое. Но у SoUrcerer'a есть одна совершенно сумасшедшая идея, если пойдет - тогда Линуксу пипец :twisted: .
    Last edited by art_zh on Wed Feb 13, 2013 11:51 pm, edited 1 time in total.
  • Идея совершенно не дикая, но я все еще жду твоих подсказок в ЛС. Однако, я в low level не силён.
  • art_zh
    Можно и на транке, но сперва бранч. Начнем с лягушек.

    Короче надо посчитать всё железо, посчитать все запрашиваемые ресурсы, и прикинуть как это разместить по адресам. Тогда можно будет определить место для ядра. Ещё надо посмотреть на ресурсы GPU. Фреймбуфер должен быть write-combined, а вот GART и командные буферы не помню. Надо запланировать под это дело один mtrr и желательно ещё в биос настроить, чтобы потом не возиться. Видеорежим лучше устанавливать из ATOMBIOS, вплоть до того, что копировать её в нижние адреса, прыгать в realmode а потом назад и стирать на фиг. Но вообще для драйвера ATOMBIOS необходима, сейчас весь модесеттинг через её байткод идёт. Для неё есть какие-то правила по адресам, где можно её разместить, нет привязки к адресам legacy bios ?
  • Who is online

    Users browsing this forum: No registered users and 7 guests