Kolibri-BIOS
-
HDD желательно, но тогда биос должна будет весь физический слой настроить по обмену данными.
Настройка физического слоя - она ведь не только для SATA; больше всего возни с контроллером памяти, приемопередатчиками системной шины (севмост - южмост) и PCIe.
С настройкой DRAM у меня опыт есть, там все очень тупо, но понятно.
Для быстрых последовательных шин надо проводить специфический "тренинг" и согласовывать импеданс линий, он для каждой системы особенный.
Вот видеорегистры - там темна вода в облацех, даже с НДА никакой понятной инфы нигде не расписано.
Все-таки придется AtomBIOS цеплять. Формат бинарного модуля где-то попадался, посмотрю.
С настройкой DRAM у меня опыт есть, там все очень тупо, но понятно.
Для быстрых последовательных шин надо проводить специфический "тренинг" и согласовывать импеданс линий, он для каждой системы особенный.
Вот видеорегистры - там темна вода в облацех, даже с НДА никакой понятной инфы нигде не расписано.
Все-таки придется AtomBIOS цеплять. Формат бинарного модуля где-то попадался, посмотрю.
art_zh
По HD лет 15 назад договорились, что биос всю настройку обмена делает. И все контроллеры спроектированы так, что программный сброс не затрагивает эту настройку. Специально, чтобы проще было дрова делать.
По HD лет 15 назад договорились, что биос всю настройку обмена делает. И все контроллеры спроектированы так, что программный сброс не затрагивает эту настройку. Специально, чтобы проще было дрова делать.
маловато! Потом каковы они? Каждый пин можно дергать, как в контроллере? Или переписью побайтно? DWordом? или...?art_zh wrote:Кстати, тебе 32 линии GPIO хватит или нужно больше?
Ты же ничего не кажеш!? Битовые операции нужны периферии, ты же понимаешь. Строб, допустим нужно выдать с чатотой 16 кГц пусть просто типа меандр...
вот, вот, вот! А что там по поводу таймеров и их IRQ!? Сколько, какие, какие тайминги возможны будут, что будет питать SMI, не покорёжит ли из временную стабильность SMI со своими замороками по откладыванию обработчика?Serge wrote:Ещё один геморрой - разные функции задержки типа nanosleep(). Нужны очень, а с реализацией всегда проблемы. Счётчики тактов и инструкций требуют муторной калибрации.
Что вообще с SMI будешь делать (планы)?
У BIOS на него ставка - у меня на его большой зуб негодования! Это уродское исчадие ада по отношению к периферии требующей жестких временных норм, невозможность строить на РС то, что как "два пальца..." реализуется на вшивом МК за полдоллара!
Я тебе писал годик назад, пречитай, давай навесь МК с архитектурой ARM на борт и пусть он реал тайм рулит вшивотиной типа Legacy..........
Часть ядра имее сервис типа микро сеть (SPI напр.) двуголовый CPU - подчиненные бортовой(ые) МК.
Головной 64 битный CPU сбрасывает ему в мозг запросы, макрокоманды, уставки, прогу, вплоть перешивает его, конфигурит... внешняя диаграмма обеспечивается самим МК к мостам не привязана...
Узость МК компенсирует CPU PC, а недостатки периферич. плана у CPU PC компенсируются МК.
Все то, что будет уметь МК (ARM) включая микроконтроллерное масштабирование далее вниз, будет уметь ТВОЙ БОРТ, и а ля Kolibri-BIOS!
Реально запузырить?
А бы на нем супервизор и скоростную КПСВВ реализовал, тогда ядро может обеспечить RTOS с "внешними латентностями"..... ну-уууу, наверное, в микросекундных (а то и круче), а не миллисекундных единицах!
А ещё есть вариант поставить FPGA от Xilinx or Altera и например как ещё и довесок USB контроллер типа CY7C68013A (может считать с внешней последовательной памяти произвольные PID VID, на основе которых система распознаёт своё USB устройство и загружает программу выполнения в ОЗУ контроллера - есть решения на этой микросхеме, например, LPT-порта, логических анализаторов на одной данной икросхеме и буферных элементах.VaStaNi wrote: Узость МК компенсирует CPU PC, а недостатки периферич. плана у CPU PC компенсируются МК.
Все то, что будет уметь МК (ARM) включая микроконтроллерное масштабирование далее вниз, будет уметь ТВОЙ БОРТ, и а ля Kolibri-BIOS!
Реально запузырить?
!
P.S. Сами интерфейсные платы можно сделать в съёмном исполнении для использования в автономноммобильном приборе, при необходимости.
art_zh
Atombios нужен обязательно, там не только видеорежимы, Но и начальная настройка вся. У гпу свой контроллер памяти и его тоже надо настроить, выставить частоты памяти и ядра, и режимы энергосбережения. Это мы привыкли, что видеобиос всё за нас делает, а там на самом деле до чёртиков работы.
Atombios нужен обязательно, там не только видеорежимы, Но и начальная настройка вся. У гпу свой контроллер памяти и его тоже надо настроить, выставить частоты памяти и ядра, и режимы энергосбережения. Это мы привыкли, что видеобиос всё за нас делает, а там на самом деле до чёртиков работы.
Last edited by Serge on Thu Feb 14, 2013 9:07 pm, edited 1 time in total.
VaStaNi, Kopa
очень дельные замечания, но слегка не в тему
большая просьба -- все предложения по железу постить сюда, а эту тему оставить только для BIOS.
а то мы уже через месяц запутаемся кто и про что говорил.
очень дельные замечания, но слегка не в тему
большая просьба -- все предложения по железу постить сюда, а эту тему оставить только для BIOS.
а то мы уже через месяц запутаемся кто и про что говорил.
Для справки - coreboot НЕ ЗАМЕНЯЕТ PC BIOS - он как раз ТОЛЬКО инициализирует железо. Сверху можно запустить BIOS (SeaBIOS) или UEFI (TianoCore).
XVilka
1) CoreBoot очень медленный. Версия для Е-350 (ближайший аналог по железу) грузится 5 секунд - дольше чем родной UEFI.
2) CoreBoot 100% открытый. Мне (как разработчику железа) нет никакого резона полностью открывать код загрузчика.
По крайней мере пока я не отобью свои издержки.
3) Надеюсь, что разработка полноценной Колибри-машины сможет хорошенько пихнуть НАШ проект вперед.
Но имхо CoreBoot этой основой цели только помешает: он автоматически превратит мое железо в еще одну встраиваемую Линукс-платформу.
Заурядную и никому не интересную.
В которой КолибриОС останется второстепенной и экспериментальной опцией.
1) CoreBoot очень медленный. Версия для Е-350 (ближайший аналог по железу) грузится 5 секунд - дольше чем родной UEFI.
2) CoreBoot 100% открытый. Мне (как разработчику железа) нет никакого резона полностью открывать код загрузчика.
По крайней мере пока я не отобью свои издержки.
3) Надеюсь, что разработка полноценной Колибри-машины сможет хорошенько пихнуть НАШ проект вперед.
Но имхо CoreBoot этой основой цели только помешает: он автоматически превратит мое железо в еще одну встраиваемую Линукс-платформу.
Заурядную и никому не интересную.
В которой КолибриОС останется второстепенной и экспериментальной опцией.
art_zh
Линукс всё равно запилят и он будет работать быстрее и лучше чем на ПК версии с таким же железом. Это неизбежно, как победа коммунизма.
Ещё вопрос про SMM. Есть ли датчики, контроллеры и прочая фигня типа управления питанием и вентиляторами, доступные только из SMM ?
Линукс всё равно запилят и он будет работать быстрее и лучше чем на ПК версии с таким же железом. Это неизбежно, как победа коммунизма.
Ещё вопрос про SMM. Есть ли датчики, контроллеры и прочая фигня типа управления питанием и вентиляторами, доступные только из SMM ?
art_zh: я не говорю что надо его использовать, но напраслину на него наводить тоже не надо. И про скорость - он медленный на каком-то железе не из-за своей архитектуры, а из-за каких-то неправильных драйверов. Тот же USB, например, можно не инициализировать, что сэкономит минимум 2-3 секунды, и т.д.
Между прочим современный UEFI имеет режим "fastboot", когда пропускает инициализацию половины железа.
Между прочим современный UEFI имеет режим "fastboot", когда пропускает инициализацию половины железа.
Who is online
Users browsing this forum: No registered users and 1 guest