Принимаются предложения по разработке низкоуровневого интерфейса для встраиваемых версий Колибри.
Новый аппаратный интерфейс должен
1) отвязать ядро от рудиментов древней РС-архитектуры;
2) заменить 16-битный сервис BIOS нормальными 32битными вызовами;
3) спрятать проприетарный платформо-зависимый код в ROM;
4) обеспечить быструю загрузку системы (200-300мс от нажатия кнопки до GUI);
5) избавить разработчиков железа от покупки заказной версии BIOS.
Совместимость с PC-BIOS, UEFI, CoreBoot не требуется.
Главное - продумать оптимальный интерфейс с ядром и пользовательскими приложениями.
И еще - какие-нибудь заглушки для эмуляторов.
Kolibri-BIOS
А какие сервисы предоставит биос ?
Точнее что будет из себя представлять плата ?
Для ядра нужна карта памяти, её получаем через е820 но у тебя всё может быть hardcoded. То же самое с PCI. Не надо сканировать шину по bus_dev_fn и вычислять прерывания на APIC. Всё уже в железе. И так далее.
Точнее что будет из себя представлять плата ?
Для ядра нужна карта памяти, её получаем через е820 но у тебя всё может быть hardcoded. То же самое с PCI. Не надо сканировать шину по bus_dev_fn и вычислять прерывания на APIC. Всё уже в железе. И так далее.
art_zh, привет!
Название ветки грандиозно-амбициозное, но все же хотелось бы знать от ТС, будет ли буквальное
уточнение массы нюансов и потенциальное желание ответов на проблемно-правильные вопросы
перспектив реализации темы, при взгляде некого другого человека со стороны?
А изначально вывалить типа ВЕСЬ концепт можно ли? Это дабы не плодить сразу кучу вопросов или не превращать тему в новый открытый труп...
BIOS все же очень привязана в типу железа и даже как там чего напаяно (схемотехника)....
Засветить тему - "луч света в темном царстве" и ни чего не сказануть об железяках некорректно как то.
Главное интерфейс, а остальное фигня, так получается.
Я так не вижу.
Я вижу пока, что будет 87 спецверсий Kolibri-BIOS.
Иначе как?
Название ветки грандиозно-амбициозное, но все же хотелось бы знать от ТС, будет ли буквальное
уточнение массы нюансов и потенциальное желание ответов на проблемно-правильные вопросы
перспектив реализации темы, при взгляде некого другого человека со стороны?
А изначально вывалить типа ВЕСЬ концепт можно ли? Это дабы не плодить сразу кучу вопросов или не превращать тему в новый открытый труп...
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 хватит или нужно больше?
Кора
Не то.
Этот BIOS не будет открытым.
ftp://kolibrios.org/users/art_zh/-B/
детали будут добавляться по ходу дела
В конфигурации железа могут быть сменные варианты: и плата CPU, и периферийная плата допускают апгрейд.
Напр. объем системной памяти заранее не известен, HDA или сеть могут быть не впаяны, и т.п.
Так что какой-то мостик между BIOS и ядром таки-нужен.
Отдельный вопрос про видеоканал: ядру нужно где-то узнать разрешение LCD-экрана, и/или устанавливать разрешение VGA-монитора. Это еще минимум 2 мостика.
ЗЫ: Управление питанием. Контроль температуры/напряжения. APIC-интерфейс. SATA, USB, GBE - всё низкоуровневое желательно по возможности вынести из ядра/драйверов и запереть в ROMe.
VaStaNi
Извини, приходится сильно фильтровать базар, иначе слечу с NDA и вообще всё накроется медным тазом.
Часть кода я должен спрятать, принципиальную схему - тоже.
Но распайка сигналов на разъёмах и интерфейс BIOS - здесь всё открыто, и нужно чтобы всё было удобно и надежно.
Кстати, тебе 32 линии GPIO хватит или нужно больше?
Кора
Не то.
Этот 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 разных вариантов железа. Это не проблема, скомпилировал ядро и вперёд.
Это же не документация.
Для меня идеальный вариант когда вся железная конфигурация записана в *.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 битах.
Образ BIOS может лежать где угодно - только скажи куда.
Все вендоры и bdf-адреса известны, .inf будет.
AMD поставляет VESA-BIOS/AtomBIOS в виде готового бинарного модуля. Тебе нужен текстовый видеорежим? Тогда надо будет его линковать в BIOS и городить к нему стандартный 16-битный интерфейс.
Если не нужен - тогда имеет смысл запустить графику+фреймбуфер сразу в 32 битах.
А что вообще за биос ? АМД предоставляет набор "сделай сам" или полностью самописный ?
И как будет происходить загрузка и передача управления ядру ? Уже в защищённом режиме ?
И как будет происходить загрузка и передача управления ядру ? Уже в защищённом режиме ?
Serge
Стандартные PnP-модули для видео и SATA/RAID. Стоит ли ради них (и еще сетевого BIOS) 16-битный огород городить?
Процессор, контроллер памяти и северный мост надо программировать ручками по-любому.
Процесс заканчивается загрузкой ядра и прыжком в нужный адрес.
Вход в защищенный страничный режим, а может и файловую подсистему имеет смысл перенести в BIOS.
Хотя, может и нет?
Энумерация PCI-устройств: даже если всё железо однозначно известно, все равно каждому устройству надо назначить порты, MMIO, IRQ/MSI, сконфигурировать PM и еще много чего разного.
мы с тобой уже пару раз перепирались по этому поводу, еще раз проимхую свою позицию: лучшая структура для хранения всей этой инфы - это расширенное конфигурационное пространство PCI Express, очень легко отображаемое на память. И видимое когеррентно с двух сторон: из ядра/драйвера, и изнутри железа.
Стандартные PnP-модули для видео и SATA/RAID. Стоит ли ради них (и еще сетевого BIOS) 16-битный огород городить?
Процессор, контроллер памяти и северный мост надо программировать ручками по-любому.
Процесс заканчивается загрузкой ядра и прыжком в нужный адрес.
Вход в защищенный страничный режим, а может и файловую подсистему имеет смысл перенести в BIOS.
Хотя, может и нет?
Энумерация PCI-устройств: даже если всё железо однозначно известно, все равно каждому устройству надо назначить порты, MMIO, IRQ/MSI, сконфигурировать PM и еще много чего разного.
мы с тобой уже пару раз перепирались по этому поводу, еще раз проимхую свою позицию: лучшая структура для хранения всей этой инфы - это расширенное конфигурационное пространство PCI Express, очень легко отображаемое на память. И видимое когеррентно с двух сторон: из ядра/драйвера, и изнутри железа.
1. Если можно обойтись без 16 бит, это надо сделать.
2. вход делать уже в защищёном плоском режиме, как в GRUB. Страничный режим устанавливать в ядре.
3.Не ясен вопрос с распределением физических адресов. Процессор 64 бита поддерживает ?
Надо подумать над вариантами организации адресного пространства. Если ядро находится в БИОС, а саму биос можно разместить по любым физ.адресам, то ядру не нужны смещения OS_BASE и другая подобная фигня. Оптимальный вариант собрать ядро, биос и mmio одним блоком адресов, чтобы замапить большими страницами. Очень хороший выигрыш в быстродействии.
Ещё один геморрой - разные функции задержки типа nanosleep(). Нужны очень, а с реализацией всегда проблемы. Счётчики тактов и инструкций требуют муторной калибрации.
Ещё. Что с софтом для разработчиков ? Первым вопросом будет "как запустить Линукс ?", вторым "где взять gcc ?".
2. вход делать уже в защищёном плоском режиме, как в GRUB. Страничный режим устанавливать в ядре.
3.Не ясен вопрос с распределением физических адресов. Процессор 64 бита поддерживает ?
Надо подумать над вариантами организации адресного пространства. Если ядро находится в БИОС, а саму биос можно разместить по любым физ.адресам, то ядру не нужны смещения OS_BASE и другая подобная фигня. Оптимальный вариант собрать ядро, биос и mmio одним блоком адресов, чтобы замапить большими страницами. Очень хороший выигрыш в быстродействии.
Если конфигурация известна заранее, то можно распределить все ресурсы на бумаге и потом закодить в конфигурационное пространство ? И составить карту регистров mtrr.даже если всё железо однозначно известно, все равно каждому устройству надо назначить порты, MMIO, IRQ/MSI, сконфигурировать PM и еще много чего разного.
Если там только 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. Не знаю, не думал. КореБут же как-то грузит Линукс?
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.
Ещё вопрос с обработкой прерываний. Legacy железа не будет ? Всё сразу на APIC и MSI ?
6.Так Coreboot заменяет IBM PC BIOS. А тут совсем другое всё.
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.
это именно тот случай, когда легче спаять...Несбыточная мечта ядерщика и драйверописателя.
не будет: я поэтому SIO-чип вообще ставить не хочу, а с HDD пока еще не все ясноЕщё вопрос с обработкой прерываний. Legacy железа не будет ? Всё сразу на APIC и MSI ?
да, другое. Но у SoUrcerer'a есть одна совершенно сумасшедшая идея, если пойдет - тогда Линуксу пипец .6.Так Coreboot заменяет IBM PC BIOS. А тут совсем другое всё.
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 ?
Можно и на транке, но сперва бранч. Начнем с лягушек.
Короче надо посчитать всё железо, посчитать все запрашиваемые ресурсы, и прикинуть как это разместить по адресам. Тогда можно будет определить место для ядра. Ещё надо посмотреть на ресурсы GPU. Фреймбуфер должен быть write-combined, а вот GART и командные буферы не помню. Надо запланировать под это дело один mtrr и желательно ещё в биос настроить, чтобы потом не возиться. Видеорежим лучше устанавливать из ATOMBIOS, вплоть до того, что копировать её в нижние адреса, прыгать в realmode а потом назад и стирать на фиг. Но вообще для драйвера ATOMBIOS необходима, сейчас весь модесеттинг через её байткод идёт. Для неё есть какие-то правила по адресам, где можно её разместить, нет привязки к адресам legacy bios ?
Who is online
Users browsing this forum: No registered users and 0 guests