Board.KolibriOS.org

Alex2003 wrote:Почему нельзя разобрать дрова которые пишет производитель и на их основе драйвера под КолибриОС? Мешает авторское право, да?

По крайней мере под AMD есть очень много свободных дров в Linux, выложенных под свободными лицензиями GPL, да и для другого хорошего железа тоже. Думаю, мешает сложность портирования с C на ассемблер, недостаток свободного времени и людей в проекте Kolibri.

floppy121 wrote:...отчасти ещё и из-за сложностей с аппаратным бэкдором AMD PSP - AMD-шным аналогом аппаратного бэкдора Intel ME и его прошивкой. Среди поддерживаемых coreboot-ом плат есть много Intel-овских с зондом Intel ME, но это потому что научились с ним работать и при возможности хотя бы немного урезать его прошивку так чтобы плата ещё продолжала грузиться. Среди поддерживаемых AMD-шных, с зондом PSP пожалуй только PC Engines APU2. Зато и советовать AMD-шные коребутовские платы намного проще, если практически все они без зонда и могут работать на 100% опенсорсе без блобов: одни платы уже на практике, и их даже выделили в проект libreboot, а другие хотя бы в теории.

А зачем нам эта дырка?

Alex2003 wrote:А зачем нам эта дырка?

Дыру попытались обосновать удобством для админов и прочей фигнёй, хотя я ни разу не видел чтобы хоть какие-нибудь админы кроме NSA-шных её использовали К тому же, из-за зондов ME/PSP в зависимости от платформы могут быть большие сложности с самой возможностью запуска "неподписанных" (т.е. не одобренных Большим Братом) прошивок вроде coreboot.

Иногда производитель железа вроде Purism может договориться с зондоделом по этому поводу и обеспечить запуск коребута на своём свежем железе, пусть и с зондом. Но пока такие договора были только с Intel-ом который по своей природе дыряв: имеет много аппаратных уязвимостей которым AMD не подвержена и для исправления которых в ОС должны быть программные патчи, значительно снижающие производительность. Да и железо такое идёт с солидной наценкой "за свободу" и нам по цене не очень доступно.

Как видишь, не по своей воле коребутчикам приходится сидеть на пусть и не устаревшем, но не на самом свежем железе: приходится искать материнки на всяких авито в хорошем состоянии (новым уже не купить, если только на складе каком завалялось) а процессор заказывать из Китая например. И есть несколько магазинов - правда не в России - которые делают то же самое за пользователей: ищут б/у железо в хорошем состоянии и поддерживаемое коребутом, тщательно чистят его до состояния почти как новый, может быть с небольшим ремонтом по мелочи, прошивают coreboot и продают с определённой наценкой за работу.
В России пока так никто не делает, поэтому Kolibri Shop - продающий коребутное железо с встроенным в БИОС Колибри - вполне рабочая идея! И хотя бы понятно в чём уникальная особенность такого компа, ведь в "Эльдорадо" подобный комп не купишь

Kopa wrote:Возможно ли собрать с кодом из OpenBios (представленным и в проекте Qemu на Github)

Вики подсказывает что

Most of the implementations provided by OpenBIOS rely on additional lower-level firmware for hardware initialization, such as coreboot or Das U-Boot

То есть OpenBIOS, как и SeaBIOS, неспособен самостоятельно полностью инициализировать железо, и полагается на coreboot который проинициализирует железо за него и передаст ему управление.

Насколько мне известно, QEMU использует coreboot для инициализации своего виртуального железа и передаёт управление SeaBIOS - стандартному основному дополнению "Payload" у coreboot. Возможно SeaBIOS может быть заменён OpenBIOS, но необходимость в coreboot для инициализации железа сохраняется. А на прошлой странице подробно рассказано, почему именно coreboot а не что-то другое.

floppy121 wrote:

Alex2003 wrote:art_zh когда- то предлагал идею подобного рода: на одной голове крутится Колибри и 32 битные приложения, а другая голова пока спит, и включается только для обработки 64 кода. Если так сделать на этой сборке, то получится на каждую разрядность по два ядра и два потока. По моему нормально, но для этого нужно переделать ядро? Или нет?

Загрузить 64-битный код на 2-ю (3-ю, и т.д) голову конечно можно, и здесь большой ядерной переделки не требуется.
Но этот код должен как-то общаться с внешним миром, так?
тут возможны 2 варианта:

1) создать для него дополнительный ядерный API-сервис, вызываемый через межпроцессорное аппаратное прерывание. Т.е. фактически не просто создать новую 64-битную операционную среду, но еще и как-то склеить её со старой 32-битной.

2) ничего вообще кроме загрузчика не создавать; дать 64-битному приложению полный доступ ко всему пространству в монопольном режиме - и пусть само там делает что хочет. Рай для программистов и ад для пользователей.

Лично я уже староват и для первого пути, и для второго.

Читал, что какая-та версия MacOS была с гибридным ядром (32+64 bit), и ничего, шустро работала!

Alex2003 wrote:Читал, что какая-та версия MacOS была с гибридным ядром (32+64 bit), и ничего, шустро работала

а есть ли у Колибри реальная необходимость в 64 битах?

floppy121 wrote:

Alex2003 wrote:Читал, что какая-та версия MacOS была с гибридным ядром (32+64 bit), и ничего, шустро работала

а есть ли у Колибри реальная необходимость в 64 битах?

Это смотря с какого бока-рака:
Если смотреть с положительной стороны:
первое - это задел под будущее: если кто-то напишет открывашку для exe (на что я сильно надеюсь), программам, которые были изначально сделаны под Windows, понадобится гораздо больше системных ресурсов (в том числе и процессора), чем приложениям, которые были изначально написаны для KolibriOS; ведь как известно приложения под винду не оптимизируются, а если и оптимизируются, то через пень-колоду;
второе - более широкое адресное пространство: сравните 64 строки/ячейки/блока/потока/бита/адреса и 32 строки/ячейки/блока/потока/бита/адреса соответственно;
Есть и недостаток: могут (а может и появятся) говнокодеры (тьфу-тьфу-тьфу через левое плечо), а также замедление выполнения кода в два-пять раза.
Конечно, если KolibriOS будет работать как-то вот так

...AMD Ryzen 3 1200 OEM...Количество ядер: 4
Максимальное число потоков: 4
...art_zh когда- то предлагал идею подобного рода: на одной голове крутится Колибри и 32 битные приложения, а другая голова пока спит, и включается только для обработки 64 кода...

это уже будет что-то вроде читерства: два ядра занимаются только 32 битными приложениями, а два оставшихся - только 64 битными. Зато процессор не будет мучиться угрызениями совести, одновременно выполняя 32 и 64 битные инструкции, при этом переводя данные то в один регистр, то в другой.
И производительность будет выше, чем у кого-либо.
P.S. Иногда я не умею выразить свои мысли так, чтобы их все поняли.

Только сейчас до меня дошло, что нужно делать сборку на AMD Fusion. Вот только не совсем понятно: какой тогда процессор и чипсет использовать? Пойду в Гугле покопаюсь что-ли...
Да, кстати, я разжился 3d-принтером, правда только качество не очень. Короче, я неоднократно возвращался к теме "Создание макробука", и переосмыслил концепт:
- Процессор AMD Fusion. Почему? В нем есть и ЦПУ, и ГПУ, которых с головой хватит для КолибриОС и комфортной работы в пределах ОС. Кто сказал, что чем больше мегагерц и чем современней оборудование, тем быстрее компьютер работает?
Если взглянуть на приставки (PlayStation) и компьютеры Apple (как бы их не хаяли), то можно заметить, что они работают быстрее, чем обычный ПК, хотя и имеют меньше ресурсов. А всё дело в оптимизации.
Короче, AMD Fusion и 1-2 ГБ ОЗУ, намертво распаянного на плате, думаю, хватит.
- Ноутбучный формат. Во-первых, это компактно. Во-вторых, исключает возможность тотального апгрейда (нам ведь нужна жёсткая платформа), за исключением планок ОЗУ, microSD, и, возможно, СИМ-карт.
Продолжение следует...

Продолжим.
После перечитывания Википедии, посещений множества сайтов и сравнения нескольких процессоров я окончательно убедился, что art_zh был прав в выборе платформы для Колибри-А. Сама AMD считает (а может и считала) Fusion наиболее перспективным проектом, ниша которого пускай и не популярна (компьютеры между нетбуками и ноутбуками), но очень перспективна. Как мы видим, она была права.
Итак, в прошлом посте я сказал, что идеальным вариантом формата платформы для КолибриОС является ноутбук, поскольку некоторые его части попросту не позволяют свою замену на свои аналоги без специального оборудования и ТЯМа, что и обеспечивает консервативность и жесткость платформы. Более того, такое решение компактней, чем настольный ПК.
Фух, воды много...
Короче, конфиг будущей платформы:
- AMD Fusion E-240 1.5 GHz 1 core + Radeon HD 6250 500 MHz
- 2 ГБ ОЗУ DDR3 1333 MHz, два слота
- вместо жёсткого диска - 32 мб чип BIOS, с записаными в него Coreboot+SeaBoot+KolibriOS+ ещё что-нибудь
- остальное на обсуждение

Шеф, у нас неприятности!
Где бы я не искал, но процессоров AMD Zacato нигде не нашёл! Только одни материнские платы...
Блин. Жалко, это был бы идеальный вариант для платформы под Колибри ОС

Этот вариант казался идеальным 7-8 лет назад.
Широко разрекламированная AMD платформа APU (CPU+GPU+Северный Мост) под кодовым названием Fusion слишком долго доводилась до ума,
а когда наконец появилась в продаже - очень сильно всех разочаровала.

Какое-то время AMD ещё позиционировала свои APU для встраиваемых приложений с несложной графикой,
но их бысто вытолкали с рынка - сначала Intel Atom, а теперь вот и ARMы.

А жаль, этот моторчик очень хорошо тарахтел под Колибри (после небольшой её заточки напильником)

Для КолибриОС не требуется большая мощность. Проблема только в отсутствии плат и дров

Просто я хочу напечатать корпус на своём трехмерном принтере, запихать начинку - и платформа готова!

Размер корпуса 185 на 260 с 17 дюймовым экраном, который вращается на все 360 градусов устроит?
Плюс 32 МБ ПЗУ?