Комментарии 13
CodeRush, спасибо дружище, Отличная статья!
Продолжай писать в том же духе
Продолжай писать в том же духе
Спасибо.
Не могу отделаться от ощущения, что головную боль одних (создателей ОС/загрузчиков/БИОСов) вывалили на других (пользователей). По сумме вроде бы, как боли стало меньше, но пользователь озадачено чешет болезненное место. Раньше не болело, теперь стало — а умные дяди говорят, что так и должно быть.
Не могу отделаться от ощущения, что головную боль одних (создателей ОС/загрузчиков/БИОСов) вывалили на других (пользователей). По сумме вроде бы, как боли стало меньше, но пользователь озадачено чешет болезненное место. Раньше не болело, теперь стало — а умные дяди говорят, что так и должно быть.
С моей точки зрения пользователю тоже стало чуть проще, хоть и немного непривычно, но это ощущение может быть вызвано банальной профдеформацией.
Если не лезть под капот, то UEFI для пользователя отличается тем, что там GPT/ESP вместо MBR, загрузчик больше не 16-битный, нет 2Тб-ограничения на размер дисков и Setup выглядит более модным. Пользователи чуть продвинутее замечают, что настройки из CMOS memory теперь дополнены громандым куском NVRAM, порядок загрузки устройств теперь задать сложнее и загрузка по типу (т.е. не «вот это загрузчик», а «USB HDD») теперь не доступна по умолчанию (эта фича старых БИОСов оказалась настолько полезна клиентам, что нам пришлось реализовать ее еще в 2011 году, а в 2014 я переписывал реализацию с нуля, т.к. в UEFI 2.4 старый подход перестал работать). Плюс проблема root-of-trust более или менее решилась, а на замену древнего DOS для прямого доступа к системе пришел UEFI Shell. Стало ли все это усложнением для пользователя — возможно, я не знаю. Но усложнив в одном месте, сильно упростили в другом, и теперь не нужно править MBR, чтобы новый загрузчик на диск дописать, или устраивать ресет ОС выводом в порт клавиатуры, которого давно уже на самом деле нет, но БИОС вынужден был его эмулировать.
Если не лезть под капот, то UEFI для пользователя отличается тем, что там GPT/ESP вместо MBR, загрузчик больше не 16-битный, нет 2Тб-ограничения на размер дисков и Setup выглядит более модным. Пользователи чуть продвинутее замечают, что настройки из CMOS memory теперь дополнены громандым куском NVRAM, порядок загрузки устройств теперь задать сложнее и загрузка по типу (т.е. не «вот это загрузчик», а «USB HDD») теперь не доступна по умолчанию (эта фича старых БИОСов оказалась настолько полезна клиентам, что нам пришлось реализовать ее еще в 2011 году, а в 2014 я переписывал реализацию с нуля, т.к. в UEFI 2.4 старый подход перестал работать). Плюс проблема root-of-trust более или менее решилась, а на замену древнего DOS для прямого доступа к системе пришел UEFI Shell. Стало ли все это усложнением для пользователя — возможно, я не знаю. Но усложнив в одном месте, сильно упростили в другом, и теперь не нужно править MBR, чтобы новый загрузчик на диск дописать, или устраивать ресет ОС выводом в порт клавиатуры, которого давно уже на самом деле нет, но БИОС вынужден был его эмулировать.
Может кто-либо объяснить чем этот раздутый и чрезмерно усложненный стандарт разработки firmware лучше чем тот же Coreboot?
Сложно сравнивать, это проекты разных весовых категорий. С одной стороны у нас UEFI Forum из Intel/AMD/MS/HP/Dell/etc., а с другой — небольшая группа энтузиастов и примкнувший к ним Google, использующий coreboot на Chromebook. Для UEFI есть «раздутый и чрезмерно усложненный», но открытый стандарт, документация, бесплатные инструменты для проверки на соответсвие реализации стандарту, открытый SDK и т.п., для coreboot есть только код, немного документации, немного вики-страниц с coreboot.org и громадный mailing list. Более того, coreboot, по сути, отвечает только за очень раннюю инициализацию системы, это аналог PEI в UEFI, а все остальное предлагается делать через payload, которым может быть либо ядро ОС (как у Google, если нужен single OS PC — самое то), либо «эмулятор» легаси БИОСа SeaBIOS, либо даже реализация UEFI из TianoCore.
Я не работал с coreboot напрямую, но участвовал на правах «мимокрокодила» в проекте проходящего у нас практику студента, который занимался адаптацией coreboot под наши платы. За 8 месяцев работы по 4-5 часов в день у него получилось загрузить Linux в качестве payload на 3 платах из 5, Windows 7 через SeaBIOS на тех же трех, но работала ОС нестабильно, а на двух оставшихся платах coreboot так и не смог инициализировать DRAM правильно, несмотря на все танцы с бубном и помощь двух не самых глупых инженеров. И наблюдений я делаю вывод, что coreboot в данный момент хорошо подходит для какого-то вполне опредленного нишевого железа (как хромобуки или индустриальные ПК), но со всеми проблемами с инициализацией, стартом и работой системы придется разбираться самому, поддержка сообщества быстро сведется к shut up and hack. Пока Google не начнет продавать support plan'ы для coreboot, нам делать на нем что-то — слишком большой риск, есть шанс не вылезти из отладки.
Я не работал с coreboot напрямую, но участвовал на правах «мимокрокодила» в проекте проходящего у нас практику студента, который занимался адаптацией coreboot под наши платы. За 8 месяцев работы по 4-5 часов в день у него получилось загрузить Linux в качестве payload на 3 платах из 5, Windows 7 через SeaBIOS на тех же трех, но работала ОС нестабильно, а на двух оставшихся платах coreboot так и не смог инициализировать DRAM правильно, несмотря на все танцы с бубном и помощь двух не самых глупых инженеров. И наблюдений я делаю вывод, что coreboot в данный момент хорошо подходит для какого-то вполне опредленного нишевого железа (как хромобуки или индустриальные ПК), но со всеми проблемами с инициализацией, стартом и работой системы придется разбираться самому, поддержка сообщества быстро сведется к shut up and hack. Пока Google не начнет продавать support plan'ы для coreboot, нам делать на нем что-то — слишком большой риск, есть шанс не вылезти из отладки.
> а на двух оставшихся платах coreboot так и не смог инициализировать DRAM правильно, несмотря на все танцы с бубном
А если не секрет почему эти проблемы возникли только на Coreboot, но с UEFI все работало нормально? Ведь согласно вашему утверждению PEI и Coreboot выполняют одну и ту же функцию а значит инициализация должна быть одинакова и приводить к одним и тем же результатам.
А если не секрет почему эти проблемы возникли только на Coreboot, но с UEFI все работало нормально? Ведь согласно вашему утверждению PEI и Coreboot выполняют одну и ту же функцию а значит инициализация должна быть одинакова и приводить к одним и тем же результатам.
Потому, что для UEFI закрытый код инициализации памяти и чипсета поставляется в составе платформы AMI Aptio, доступ к которой у нас имеется, а в случае coreboot инициализацию выполняет открытый код, написанный сообществом в результате реверс-инжениринга и потому не всегда работающий правильно. Да и избавиться от проприетарных компонентов не получится даже с coreboot, все равно нужны и ME, и VBIOS, на использование которых все равно придется купить у Intel лицензию.
Мне одному кажется, что этот UEFI постепенно превращается в мини-ОС? С очень многими сомнительными «фичами» (сужу со стороны дилетанта). Например, мне решительно непонятно, что делает текстовый протокол HTTP в том месте, где передаваться будут в основном двоичные данные? Определённо, где-то UEFI свернул не туда…
UEFI — это пока еще не ОС в привычном понимании термина, это скорее очень продвинутый аналог HAL. На ОС становится похожа его комбинация с UEFI Shell, вот её уже можно назвать однозадачной дисковой ОС с прямым доступом к ресурсам, таким себе новым DOS без костылей времен Очакова.
Добавление загрузки по HTTP объяснимо и ожидаемо, ведь хоть какой-нибудь HTTP-сервер имеется почти в каждой внутренней сети, и просто положить в /boot/bootx64.efi файл с загрузчиком намного проще, чем поднимать TFTP-сервер, настраивать специальным образом DHCP так, чтобы от отвечал на PXE-запросы и собрать загрузчик для 16-битного реального режима, не забыв проследить, чтобы его размер не превысил доступные 0x20000 байт.
Туда он свернул или не туда — посмотрим лет через 10-15, сейчас же в каждом новом стандарте просто добавляют очередную нужную фичу, показавшуюся полезной участникам UEFI Forum. К счастью, большая часть этих фич не является обязательно к реализации, и некоторые «темные углы» стандарта EFI 1.01 так и не реализованы до сих пор. UEFI хорош тем, что если какая-то его часть мне особенно не нравится — я ее просто не собираю и все. К примеру, мне не нравится стандартный механизм Capsule Update, и в моих реализация функциих UpdateCapsule и QueryCapsuleCapabilities просто возвращают EFI_UNSUPPORTED. Кому-то не нравится SMM, кому-то другому — RW и RO-данные в одной микросхеме, но все эти вопросы решаемые и разные части стандарта не приколочены друг к другу намертво. UEFI похож на конструктор, каждый собирает из него то, что считает нужным.
Добавление загрузки по HTTP объяснимо и ожидаемо, ведь хоть какой-нибудь HTTP-сервер имеется почти в каждой внутренней сети, и просто положить в /boot/bootx64.efi файл с загрузчиком намного проще, чем поднимать TFTP-сервер, настраивать специальным образом DHCP так, чтобы от отвечал на PXE-запросы и собрать загрузчик для 16-битного реального режима, не забыв проследить, чтобы его размер не превысил доступные 0x20000 байт.
Туда он свернул или не туда — посмотрим лет через 10-15, сейчас же в каждом новом стандарте просто добавляют очередную нужную фичу, показавшуюся полезной участникам UEFI Forum. К счастью, большая часть этих фич не является обязательно к реализации, и некоторые «темные углы» стандарта EFI 1.01 так и не реализованы до сих пор. UEFI хорош тем, что если какая-то его часть мне особенно не нравится — я ее просто не собираю и все. К примеру, мне не нравится стандартный механизм Capsule Update, и в моих реализация функциих UpdateCapsule и QueryCapsuleCapabilities просто возвращают EFI_UNSUPPORTED. Кому-то не нравится SMM, кому-то другому — RW и RO-данные в одной микросхеме, но все эти вопросы решаемые и разные части стандарта не приколочены друг к другу намертво. UEFI похож на конструктор, каждый собирает из него то, что считает нужным.
К счастью, большая часть этих фич не является обязательно к реализации
В том-то и беда этого стандарта — слишком много вот этих всех «необязательных фич». Через 10-15 лет он будет «стандартизировать» вообще всё, что угодно, только вот реализаций 95% этого хлама вообще никогда не появится, а количество понимающих его человек сведётся к нулю, говоря утрированно.
Не думаю. Если реализаций не появится — ненужные части просто выкинут, как это уже случилось с «хвостатыми» файлами в при переходе с FV Rev1 к FV Rev2. Наличие стандарта (даже если он всеобъемлющий и непонятный) гарантирует интероперабельность при условии, что реализации следуют букве этого самого стандарта. На данный момент в реализациях UEFI 2.4 замечательно работают драйверы, написанные для EFI 1.01, хотя их и рекомендуется переписать под новую Driver Model, чтобы они были меньше и загружались быстрее. EFI-приложения, не использующие вендорские расширения, запускаются и работают на реализациях UEFI любого производителя (проверял лично на реализациях AMI, Phoenix, Insyde и Intel). С пониманием там тоже не должно быть больших проблем, я думаю. Да, стандарт достаточно объемный, но основные идеи (как устроены драйверы, что такое протоколы, как вызвать общий код, как сохранить свои данные и т.п) намного проще, чем интерфейс через прерывания и IO-порты, которым грешил legacy BIOS.
Мне тоже не нравится тот факт, что фичи постоянно добавляют, а баги в реализациях чинят не очень резво, но сделать с этим фактом я могу только одно — не пихать в свои БИОСы бездумно все подряд, до чего появился доступ, ведь чем меньше кода в прошивке, тем там меньше багов. К сожалению, такое мнение среди «обычных пользователей» не слишком популярно, им нужен графический Setup с красивой картинкой на фоне и прочий stuff. И загрузка чтобы без PXE-костылей. И дуалбут в Android. И черта в ступе еще. Пока такой подход позволяет продать больше плат, чем конкуренты — процесс добавления фич не остановить.
Мне тоже не нравится тот факт, что фичи постоянно добавляют, а баги в реализациях чинят не очень резво, но сделать с этим фактом я могу только одно — не пихать в свои БИОСы бездумно все подряд, до чего появился доступ, ведь чем меньше кода в прошивке, тем там меньше багов. К сожалению, такое мнение среди «обычных пользователей» не слишком популярно, им нужен графический Setup с красивой картинкой на фоне и прочий stuff. И загрузка чтобы без PXE-костылей. И дуалбут в Android. И черта в ступе еще. Пока такой подход позволяет продать больше плат, чем конкуренты — процесс добавления фич не остановить.
Не туда, а вот сюда
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что новые версии UEFI-стандартов нам готовят, часть третья, UEFI 2.5