LINUX.ORG.RU
ФорумTalks

[мечты][CoreBoot][LinuxBIOS][EFI] Идеальный загрузчик для x86-машин — альтернатива UEFI и Old BIOS

 , ,


0

1

Начну с требований. Загрузчик должен:
1) быть простым
2) выполнять минимум функций
3) работать быстро
4) позволять осуществлять управление ресурсами компьютера с максимальной гибкостью
5) совместимым с DOS-style BIOS

Думаю, всё. Кажется, что свойства 1-3 и 4 противоречат друг другу, но далее я покажу, что это не так.

Предлагаемая схема загрузчика:
Двууровневая система загрузки, ROM с минимумом функций, SSD с остальным.
Порядко загрузки:
0) Переключение блока питания (или там нажатие кнопки на корпусе) заставляет процессор прыгать на какой-нибудь фиксированный адрес, замапленный на ROM, так что бы команды читались прямо с него. Размер ROM-чипа меньше кэша процессора, следовательно предварительная его загрузка в RAM не нужна.
1) ROM содержит коды инициализации клавиатуры, внутреннего носителя материнской платы, одного или нескольких внешних носителей и отображения на дисплее.
ROM инициализирует минимум необходимого для работы железа, базово — клавиатуру, CMOS и мини-SSD. Загружает настройки CMOS, в зависимости от них устанавливает своё поведение. На этом этапе процессор переключается в защищённый режим, что бы всё остальное работало быстрее. По умолчанию:
1.1) Загружается драйвер клавиатуры и обработчик прерываний
1.2) Драйвер SSD
1.1a) На нажатие клавиш даётся сколько то времени, но не менее секунды.
1.1b) Если поступило прерывание от клавиатуры — то есть нажата ключевая комбинация, например клавиша DEL или F2 (предлагаю реагировать на любую из тех какие когда-нибудь встречались в загрузчиках что бы юзер не гадал что нажимать, то есть Del, F2, F10, F11 и может ещё shift), догружается драйвер дисплея и код отображения меню настройки. В меню настройки должны быть пункты: 1) загрузка системы с SSD, 2) загрузка системы с другого носителя (или нескольких) — как минимум одно устройство, которое можно подключить не разбирая комп, но увлекаться не стоит, флешки, CD, HDD вполне хватит 3) настройки. Настройки должны включать в себя как минимум переключение защиты от записи встроенного SSD. С другой стороны, как вариант можно просто сделать отдельным пунктами «загрузка с SSD без защиты его от записи», «загрузка с флешки без защиты SSD от записи»... Ещё туда можно включить установку часов и пароля. Ну и может быть дефолтного места загрузки (например загружаться сразу с жесткого диска, игнорируя встроенный SSD).
1.3) Происходит чтение встроенного в материнку SSD в фоне, пока ожидается прервывание от клавиатуры. реализовано оно должно быть максимально простым способом, например просто читается в память первые несколько мегабайт и происходит прыжок на самое начало (расчитываем сколько можно прочитать за 1 секунду по скорости SSD-шки).

2.1) часть SSD (носитель впаянный в материнку, ёмкостью не менее 128 MB и максимально быстрый) считана в оперативку. Она не формализуется в спецификациях и там может быть что угодно, например модифицированный GRUB2, эмулятор BIOS, эмулятор (U)EFI или даже сразу ядро Linux (или любое другое на выбор)
2.2) Так как носитель SSD имеет ёмкость порядка гигабайта, то можно туда запихать например SysRescCD и прочей фигни типа антивируса
2.3) загружается что-то вроде гипервизора, инициализирует уже всё железо... В него можно воткнуть все необходимые функции.

Теперь о требованиях:
1-3 — это фичи первоначального загрузчика, он умееть даже меньше чем обычный BIOS. Можно взять даже часть кода U-boot
5 — если загрузка происходит с внешнего носителя, то должна быть возможность делать носитель, который будет грузиться и на старых BIOS. Для этого я предлагаю загружать в RAM первый мегабайт носителя (или его область от 512 кб до 1 мб), а JMP делать на фиксированный в спеках адрес, который будет сразу с начала второго полумегабайта. Думаю что запаса в 512 кб хватит для всех GRUB2, lilo и прочих бут-менеджеров. А вторые 512 кб — это уже код защищённого режима, который загружает что-то вроде GRUB2
4 — очевидно что в мини-SSD на материнке можно установить любой лёгкий дистрибутив GNU/Linux, в том числе с гипервизором и какой-нибудь md5sum в rc-скрипте.

Если мне сейчас скажут, что CoreBoot уже есть и всё это умеет, то я скажу — можно взять и его, собрать соответствующим образом и припаять на материнку флешку. Но это должны делать производители материнок, а не юзеры.

UPD: Что бы реализовать защиту от записи SSD, нужно встроить в материнку аппаратный ключ, который позволяет переключать себя программным способом только в одну сторону (запрет записи). Переключение в сторону разрешения записи должно требовать отключение питания.

Таким образом, код загрузчика из SSD (или код ROM) сможет активировать этот ключ сразу после того как убедится, что юзер не нажал на кнопку входа в меню настроек.

UPD2: Можно использовать съёмный SSD, например картридер microsd-карт c картой. Тогда в ROM достаточно только кода инициализации и чтения вот этого самого microsd и всё. Остальное будет делать код, прочитанный оттуда.

Правда появляется минус — если запорешь загрузчик, придётся открывать корпус компа.

★★★★★

Последнее исправление: Xenius (всего исправлений: 10)

А теперь расскажи: нахрена тебе сдался SSD с дорогими контроллерами для малого объема памяти и при отсутствии необходимости контроля кол-ва циклов перезаписи? Очень хочешь переплачивать ~30% стоимости материнки?

А если всё это убрать - что останется? Та же флеш, что и в биосе?

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

> А теперь расскажи: нахрена тебе сдался SSD с дорогими контроллерами для малого объема памяти и при отсутствии необходимости контроля кол-ва циклов перезаписи?

Флешка на два гига стоит меньше 10 баксов. Или у тебя материнка за $30?

А если всё это убрать - что останется? Та же флеш, что и в биосе?


А в BIOS не флеш, там другая технология — с побайтовым, а не блочным доступом. Но контроллер правда не нужен, потому что есть специальные файловые системы для флешек.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от shahid

> Если защищать ценную информацию, то цена в 10000 руб./шт. смешна в сравнении с ценностью защищаемой информации.

А если тебе это надо в субноутбуке, который сам меньше 10000 стоит?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Lighting

Штука в том, что ни один из этих «фактов» об UEFI так и не потверждён.

1) Использует костыльный формат исполнимых файлов от шиндошс (PE) Это я сам видел на диске Ubuntu. http://x86asm.net/articles/uefi-programming-first-steps/ Плюс, открываем это и смотрим пример кода:

format [b]pe64[/b] dll efi
entry main

section '.text' code executable readable

include 'efi.inc'
format pe64 dll efi
entry main

section '.text' code executable readable

include 'efi.inc'

main:
 sub rsp, 4*8              ; reserve space for 4 arguments

 mov [Handle], rcx         ; ImageHandle
 mov [SystemTable], rdx    ; pointer to SystemTable

 lea rdx, [_hello]
 mov rcx, [SystemTable]
 mov rcx, [rcx + EFI_SYSTEM_TABLE.ConOut]
 call [rcx + SIMPLE_TEXT_OUTPUT_INTERFACE.OutputString]

 add rsp, 4*8
 mov eax, EFI_SUCCESS
 retn


section '.data' data readable writeable

Handle      dq ?
SystemTable dq ?
_hello      du 'Hello World',[b]13,10[/b],'(From EFI app written in FASM)',[b]13,10[/b],0

section '.reloc' fixups data discardable

Этого тебе мало?

2) Перегружен всякой фигнёй вроде графического интерфейса или даже антивируса

Открываем http://www.3dnews.ru/offsyanka/618151/ и смотрим на скриншот

3) С GNU/Linux часто работает криво, и вообще сильно завязан на шиндошс

Открываем FSF начала кампанию против «безопасной загрузки» UEFI (комментарий) и видим, что у юзера проблемы с загрузкой Debian в UEFI-режиме, тогда как в режиме нормального BIOS никаких проблем нет.

4) Переизобретает фичи, которые давно уже были в OpenFirmware и core boot, но реализует их более кривым и неизящным способом

Спрашивал у разработчика Core Boot в IRC.

5) Не совместимо со старыми ОС без реальной причины.

http://www.thinkwiki.org/wiki/UEFI_Firmware#Enabling_UEFI_boot_in_Debian

Написано что версии Linux до 3.0-rc1 не загружаются.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

Флешка на два гига стоит меньше 10 баксов. Или у тебя материнка за $30?

И при этом и рядом не валялась по скорости с SSD. Тебе же скорость надо?

Но контроллер правда не нужен, потому что есть специальные файловые системы для флешек.

Которые при редкой полной перезаписи тоже не нужны.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

> Которые при редкой полной перезаписи тоже не нужны.

Всё равно не повредят

И при этом и рядом не валялась по скорости с SSD. Тебе же скорость надо?


Ну и сколько стоит быстрый чип на гиг?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

Я те что, их продаю? Ты говорил про SSD, я про них же и ответил. Давай не сравнивать с ценами простых флешек.

Pavval ★★★★★
()
Ответ на: комментарий от Xenius

>1) Использует костыльный формат исполнимых файлов от шиндошс (PE)

Если отбросить твою фанатичность, чем он плох?

2) Перегружен всякой фигнёй вроде графического интерфейса или даже антивируса

Не вижу ничего лишнего, да, интерфейс дюже пёстрый, но, тем не менее, всё работает значительно быстрее обыкновенного BIOS'а.

Открываем FSF начала кампанию против «безопасной загрузки» UEFI (комментарий) и видим, что у юзера проблемы с загрузкой Debian в UEFI-режиме, тогда как в режиме нормального BIOS никаких проблем нет.

Но пользователь всё равно нахваливает UEFI и возвращаться к BIOS ни за что не собирается. И, по-моему, кто-то либо никогда не сталкивался с глючными BIOS'ами, либо стал забывать, насколько кривые BIOS и ACPI бывают.

4) Переизобретает фичи, которые давно уже были в OpenFirmware и core boot

Ну и где те OpenFirmware и CoreBoot? Правильно, одна - на не-x86 железе, другой - на всяком малораспространённом старье.

Спрашивал у разработчика Core Boot в IRC.

Спросил бы заодно, когда они начнут нормальное оборудование поддерживать.

5) Не совместимо со старыми ОС без реальной причины.

Из-за кривости ядра, может быть?

Написано что версии Linux до 3.0-rc1 не загружаются.

https://lkml.org/lkml/2011/6/8/322

Lighting ★★★★★
()
Ответ на: комментарий от Lighting

> чем он плох?

Однако, ты утверждал что это всё вообще неправда. Теперь вроде признаёшь, что правда, но спрашиваешь чем плох.

Да хотя бы тем что там STUB в виде This program cannot be run in DOS mode, который ну совершенной излишний в современном ПО. Зачем было брать костыли от шиндошс если был нормальный ELF, и это не считая всяких a.out и тд?

Не вижу ничего лишнего, да, интерфейс дюже пёстрый, но, тем не менее, всё работает значительно быстрее обыкновенного BIOS'а.


Нафига в загрузчике вообще нужен интерфейс? Он должен загружать загрузчик ОС как можно быстрее, и предоставлять ОС как можно больше полезных данных о железе. Ну или сразу содержать в себе загрузчик ядра. Всё, больше ничего не нужно.

И, по-моему, кто-то либо никогда не сталкивался с глючными BIOS'ами, либо стал забывать, насколько кривые BIOS и ACPI бывают.


Это вообще-то не оправдание для UEFI, это оправдание для того что бы использовать в качестве BIOS например CoreBoot+SeaBIOS вместо проприетарного говна от всяких Phoenix.

другой - на всяком малораспространённом старье.


Это потому что только на это «старьё» есть опубликованные спецификации. На всякое говно типа интела и нвидии спеков нет, поэтому с их поддержкой проблемы.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Lighting

> https://lkml.org/lkml/2011/6/8/322

Что нам и говорит, что для того что бы ОС поддерживала UEFI её нужно специально модифицировать. То есть, как я и говорил, поддержка старых ОС выкинута без видимой причины.

Нормальное решение для замены BIOS не требовало бы модификации самой ОС, а только загрузчика.

И да, ещё есть

6) UEFI использует файловую систему FAT32 запатентованную мелко-мягкими, то есть по идее запрещённую к использованию в других ОС (на самом деле конечно её все поддерживают, но мелко-мягкие в любой момент могут наехать)

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

>Да хотя бы тем что там STUB в виде This program cannot be run in DOS mode, который ну совершенной излишний в современном ПО.

А, значит, совместимость со старым BIOS в современном ПО - нужна?

Нафига в загрузчике вообще нужен интерфейс? Он должен загружать загрузчик ОС как можно быстрее, и предоставлять ОС как можно больше полезных данных о железе. Ну или сразу содержать в себе загрузчик ядра. Всё, больше ничего не нужно.

Что-то в прошлом своём треде ты утверждал ровно обратное.

На всякое говно типа интела и нвидии спеков нет, поэтому с их поддержкой проблемы.

Ну так пользуйся не говном, а... Ах, ну да, я и забыл, что всё - «говно», кроме мочи и, возможно, VIA. А ты ещё и лицемер.

Что нам и говорит, что для того что бы ОС поддерживала UEFI её нужно специально модифицировать. То есть, как я и говорил, поддержка старых ОС выкинута без видимой причины.

Ты упорот? Это баг ядра, который исправили только в третьей ветке, потому её и рекомендуют использовать в гайдах.

Lighting ★★★★★
()
Ответ на: комментарий от Lighting

> всё - «говно», кроме мочи и, возможно, VIA

AMD же есть

Это баг ядра, который исправили только в третьей ветке, потому её и рекомендуют использовать в гайдах.


А в какой ветке он появился?

А вообще, переход на личности тебя не красит.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

>AMD же есть

Ну и чем они лучше Intel и NVidia? Принципиально худшей поддержкой даже с открытыми спеками?

А в какой ветке он появился?

Я тут полистал LKML и LWN, это скорее баг в firmware конкретных производителей, в 3.0 добавили костыль(workaround) для работы с ним. Ну, для BIOS их целая пачка, так что ничего. Но сама поддержка EFI в линапсе ещё с начала нулевых, а UEFI не накладывает никаких ограничений на софт, разве что на железо, так что начальный тезис всё равно ошибочен.

Lighting ★★★★★
()
Ответ на: комментарий от Lighting

> Я тут полистал LKML и LWN, это скорее баг в firmware конкретных производителей, в 3.0 добавили костыль(workaround) для работы с ним.

Однако же баг. А кода для UEFI надо намного больше, как и возложенных на него функций, так что больше и места для багов.

для BIOS их целая пачка, так что ничего


Если не видно разницы, зачем платить больше?

В смысле, зачем менять один костыль на другой? А что BIOS бывает кривым — никто и не спорит.

а UEFI не накладывает никаких ограничений на софт, разве что на железо, так что начальный тезис всё равно ошибочен.


Хорошо, как запустить DOS из-под UEFI?

AMD же есть


Ну и чем они лучше Intel и NVidia? Принципиально худшей поддержкой даже с открытыми спеками?


Ну толсто же. У меня на видеокарте AMD отлично идут 3D игры без всякой проприетарщины, причём даже жручие.
А на NVidia это возможно?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

>Если не видно разницы, зачем платить больше?

Ты шутишь что ли? Или просто не понимаешь, что EFI позволяет избавиться от ограничений DOS MBR на объём накопителей(2Тб, ага, в BIOS'е это хоть как-нибудь решено?), кривых реализаций ACPI, IDE-режима и ещё горы решений и костылей, которые давно и безвозвратно устарели.

Хорошо, как запустить DOS из-под UEFI?

Что-то сразу после развенчания мифа про необходимость ядра >=3.0 для загрузки, ты сразу вспомнил про DOS. Сначала придумай убедительную причину, зачем его понадобится запускать на реальной машине, а не в виртуалке, а потом поговорим.

А на NVidia это возможно?

А на NVidia это не нужно.

У меня на видеокарте AMD отлично идут 3D игры без всякой проприетарщины, причём даже жручие.

Модель карты назови. А заодно, скажи-ка, можно ли на ней управлять энергосбережением, использовать ускорение видео, остальные функции, доступные через проприетарный драйвер?

Lighting ★★★★★
()
Ответ на: комментарий от Lighting

> А заодно, скажи-ка, можно ли на ней управлять энергосбережением, использовать ускорение видео, остальные функции, доступные через проприетарный драйвер?

Видео даже HD идёт без тормозов, но не знаю, есть ли здесь помощь карты, но какая разница? Аппаратное ускорение видео нужно только на всяких говноселеронах и слабых ARM, на нормальном AMD-шном процессоре оно и так идёт.

Энергосбержением? Хрен знает, никогда этим не заморачивался. Какие остальные функции ты имеешь ввиду не представляю, а значит они мне не нужны.

Разве что OpenCL вроде как не работает, а оно нужно. Но а что, на Nvidia с Nouveau оно заводится?

на NVidia это не нужно.


Если бы было не нужно, nouveau бы не было. Раз он есть, значит нужно.

Что-то сразу после развенчания мифа про необходимость ядра >=3.0 для загрузки, ты сразу вспомнил про DOS. Сначала придумай убедительную причину, зачем его понадобится запускать на реальной машине, а не в виртуалке, а потом поговорим.


Ну вообще оно нужно для прямой работы с железом, обычно через него BIOS перепрошивали например. Ну и SMM, вроде как в реальном режиме процессора не работает (по крайней мере до 386 его не было), а значит у DOS-подобной ОС более полный контроль над железом

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Lighting

> просто не понимаешь, что EFI позволяет избавиться от ограничений DOS MBR на объём накопителей(2Тб, ага, в BIOS'е это хоть как-нибудь решено?)

BIOS и DOS MBR вообще никак не связаны. То есть на диске можно использовать любую разметку, какую вздумается (да хоть самостоятельно придуманную), и BIOS загрузит всё что нужно. А вот как раз UEFI требует GPT разметки, а другую с ним вроде как и нельзя использовать.

кривых реализаций ACPI, IDE-режима и ещё горы решений и костылей, которые давно и безвозвратно устарели.


Ха-ха, надеешься что в EFI будет всё менее кривое? Проблема-то в проприетарщине, так что что бы от этого всего избавиться нужно юзать Core Boot.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

>Видео даже HD идёт без тормозов, но не знаю, есть ли здесь помощь карты, но какая разница? Аппаратное ускорение видео нужно только на всяких говноселеронах и слабых ARM, на нормальном AMD-шном процессоре оно и так идёт.

Энергосбержением? Хрен знает, никогда этим не заморачивался.

Нету в убогом швабодном драйвере - значит и не нужно. Зачем тогда вообще видеокарта, если графику можно обсчитывать на процессоре?

Ну вообще оно нужно для прямой работы с железом, обычно через него BIOS перепрошивали например.

Нет BIOS -> его не нужно перепрошивать -> DOS больше не нужен.

BIOS и DOS MBR вообще никак не связаны.

Ограничение в 2Тб - это ограничение DOS MBR, которого при использовании GPT нету, но что там с поддержкой GPT в BIOS? Он как минимум не сможет загрузиться с такого раздела. Я уже даже не говорю про необходимость хотя бы одного загрузочного раздела на диске и всякие костыли вроде гибридных MBR.

Кстати-кстати, не забывай, не просто DOS MBR, а MS DOS MBR.

Ха-ха, надеешься что в EFI будет всё менее кривое?

UEFI - это хотя бы стандарт, а не несколько отдельных и абсолютно несовместимых проприетарных поделий, так что баги будут править.

Lighting ★★★★★
()
Ответ на: комментарий от Lighting

> Кстати-кстати, не забывай, не просто DOS MBR, а MS DOS MBR.

Ну тогда уж и не UEFI, а Microsoft UEFI

что там с поддержкой GPT в BIOS?


Ты читать не умеешь? BIOS вообще не нужно поддерживать таблицы разделов.

И кстати, это правильный подход — просто загружать в память первый сектор и передавать туда управление — поскольку он не привязан ни к ОС, ни к формату таблицы разделов.

Я уже даже не говорю про необходимость хотя бы одного загрузочного раздела на диске и всякие костыли вроде гибридных MBR.


Эти костыли только шиндошс нужны, а вообще BIOS их не требует.

Зачем тогда вообще видеокарта, если графику можно обсчитывать на процессоре?


Если бы было можно, она была бы не нужна. Но вот увы, таки нельзя. Производительности не хватит.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

>Ну тогда уж и не UEFI, а Microsoft UEFI

Что ж сразу не AMD UEFI или IBM UEFI? А, может, Apple UEFI? EFI, на которой основан нынешний стандарт UEFI, разработана Intel. Может, просветишь, при чём тут Microsoft?

BIOS вообще не нужно поддерживать таблицы разделов.

Скажи, ты хоть чуточку представляешь себе процесс загрузки? Да, BIOS не нужна сама таблица разделов, нужна сама информация о ней(за подробностями читай документацию, буду я тебе ещё её пересказывать). Так вот, чтоб ты знал, большинство систем с BIOS просто не грузятся с дисков с GPT.

Эти костыли только шиндошс нужны, а вообще BIOS их не требует.

Лол, нет, это нужно именно BIOS'у. Далеко не всему зоопарку, но некоторым(на платах Intel).

Lighting ★★★★★
()
Ответ на: комментарий от Lighting

> А, может, Apple UEFI?

То есть ты хочешь сказать, что в маковском EFI применялся PE-формат модулей?

Так вот, чтоб ты знал, большинство систем с BIOS просто не грузятся с дисков с GPT.


Так никто и не спорит, что GPT фигня.

Зато если использовать разметку BSD disklabel, то вполне можно загружаться с диска, используемого в режиме «эксклюзивного использования» ака «Dangerously Dedicated». Вот, почитай это например.

Да, BIOS не нужна сама таблица разделов, нужна сама информация о ней(за подробностями читай документацию, буду я тебе ещё её пересказывать)


Нет уж, перескажи, нафига BIOS это нужно. Единственное что он делает — это загружает первый сектор устройства (будь то дискета, жесткий диск или хз что) по адресу 0:7C00h и передаёт на него управление. А в первом секторе можешь хоть чёрта лысого записать.
Если используется Generic MBR, то да, загрузиться с раздела дальше двух терабайт не получится, потому LBA32 с сектором 512 байт позволяет адресовать только такое количество блоков.

Я и говорю, Generic MBR — это проблемы шиндошс, в нормальных операционках установлен GRUB или LILO, которые распознают дофига разных разметок.

это нужно именно BIOS'у. Далеко не всему зоопарку, но некоторым(на платах Intel).


То есть Intel сам создал проблему, сам её решил. Вместо того что бы открыть документацию и помочь допилить CoreBoot под свои платы.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

>То есть ты хочешь сказать, что в маковском EFI применялся PE-формат модулей?

Я хочу сказать, что Apple и MS настолько причастны к разработке, насколько Lenovo и все остальные. Первоначально EFI был создан Intel.

Так никто и не спорит, что GPT фигня.

А вот теперь, просто уйди. Зачем, зачем тащить в систему какие-то тухлые BSD-аналоги, когда есть отлично работающий GPT?

Нет уж, перескажи, нафига BIOS это нужно.

Не забывай, что перед передачей управления, BIOS ещё и проверяет находящийся там код, так что совсем без представления о MBR обойтись никак нельзя.

Я и говорю, Generic MBR — это проблемы шиндошс, в нормальных операционках установлен GRUB или LILO, которые распознают дофига разных разметок.

Так что, линапс уже научился грузиться с >2Тб разделов на дисках с MS MBR? Нет? Может, с GPT без UEFI? Снова нет? Ну и вот.

То есть Intel сам создал проблему, сам её решил.

А что, Intel уже стал писать BIOS для своих плат?

Вместо того что бы открыть документацию и помочь допилить CoreBoot под свои платы.

Да, что-то никому эта поделка не нужна, кроме терминальных красноглазых фанатиков швабодки. Остальным, если что, плевать, есть сорцы для их биоса или нету, главное - чтобы нормально работал, чего Coreboot, судя по историям «успеха» на ЛОРе, обеспечить пока не может. Да и они в предыдущих версиях оставили поддержку доброй половины плат, не портировав их в четвёртую ветку.

Lighting ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.