От UEFI к загрузке один шаг

п.3 - это ASUS, как я понимаю. Или есть сведения, что еще где-то так есть? Впрочем, п.2 на ASUS тоже работает.

И я бы с удовольствием почитал сравнение реализации UEFI на разных производителях.
Возможно, каким-нибудь тестом UEFI-совместимости версий/реализации фич, что ли...

Т.е. не только (и не столько) запуск шелла, а... пока даже не знаю что...
Это я так тонко намекаю на тему предыдущей статьи про UEFIMark

Видимо, текущий "стандарт разработчика" - это Интел + ASUS. Как я понимаю - в зависимости от бабла. Интел (рекомендованные киты) - для богатых, самопал на Интел или ASUS - для бедных.)
Но UEFI есть у GA, что-то видел у ASRock, у MSI должно что-то быть, по идее. Не говорим уж о серверах, да и десктопах/ноутах/моноблоках от брендов типа IBM/HP/Lenovo/Dell/FSC. Как бы объять все эту необъятность в плане: а вот тут такая особенность, а вот тут - такая))

Ведь по опыту BIOS - "но мы-то с вами знаем".

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

> если биос порченный, позволительно ли бут-блоку запустить шелл или другую эфи-утилиту с загрузочной области?

Нет. UEFI - это типа ОС. По аналогии с Linux (более похоже): "если стартанул ТОЛЬКО grub - можно ли запустить приложение"?

> "если шелл встроен в биос, можно ли запустить сторонний?"

Да.

> нельзя ли это все использовать для контроля прохождения пост-процедур или состояния регистров комплектующих платы?

UEFI - это в общем-то и есть "прохождение пост-процедур".) Т.е. вопрос аналогичен "а нельзя ли код "Legacy BIOS" (типа Award 6.0) использовать для контроля прохождения пост-процедур или состояния регистров комплектующих платы?"

У этой версии UEFI BIOS с BootBlock большие проблемы. Его нет )) Почти сразу CAR...

Савелий уже сказал, что конечно да. Вызываем на UEFI-устройстве файл, который лежит по зарезервированному пути. Дальше ловим, как обыкновенную лошадь.

В связи с тем, что UEFI BIOS принципиально отказывается размежевываться с операционной системой (нет передачи управления; вместо этого используются вызовы) UEFI Shell, как и любое UEFI-приложение, является клиентом, а не провайдером этих программных сервисов. Это значит, что "резидентом" всегда является UEFI firmware или, как в последнее время принято (и я это одобрямс) UEFI BIOS.

Для контроля были и остаются контрольные точки. А вот UEFI-среда становится тем самым питательным бульоном, в котором можно приготовить блюдо, диагностирующее компоненты платформы. Ибо, как часто бывает, полнометражная ОС свое кино может и не показать.
P.S. Много метафор. Так получилось.

Если я правильно помню, то как раз-таки Micro-Star.
Слишком мала библиотека плат для такого рода работ. Это одна из причин, по которой хотелось бы получить помощь клуба ROM.by

P.S. Когда велись работы по созданию PCI-диагностики, библиотека мат.плат состояла из 50 наименований. Такие вот лабораторные затраты.

Рабочие будни на серверной плате Tyan S7052GM3NR:

простой вопрос:
имеется загрузочная флешка с HBCD. На компах с UEFI в меню присутствуют 2 пункта - загрузка с флешки (Legacy), и загрузка с флешки (UEFI) (имеется в виду, в меню загрузки). Когда выбираю загрузку легаси, все грузится как обычно. Когда с UEFI - ничего не происходит (модуля нет на флешке). Однако, на некоторых платах (не запоминал, на каких именно) просто нет возможности легаси загрузки с флешки - и тут получаем облом.
Сам вопрос в чем - можно ли поместить модуль для загрузки на флешку, и как его создать из уже имеющегося загрузчика (grub for dos используется, и его модифицированное меню), и желательно чтобы работало и на x86 и на x64 системах?
Есть ли какие-нибудь инструменты? самому писать нет возможности, да и переписывать под новые версии HBCD каждый раз не хочется.

Вопрос на засыпку - будет ли работать модуль UEFI, загруженный с флешки, если флешка защищена от записи? (аппаратная защелка)

P.S. судя по всему, от легаси загрузки производители избавятся совсем, дело времени, и нужно готовиться к такому варианту развития событий.

upd.:
нашел на просторах буржуйского инета:

а так как HBCD использует именно grub4dos, то получается, полностью uefi копии загрузчика сделать не получится. Надо будет либо переделывать под другой загрузчик (не очень хочется, много менюшек перерабатывать), либо искать другие варианты.

А зря не запоминал. Скажу, что на данный момент я не видел матерей, на которых нельзя загрузиться с Legacy (в т.ч. и флешки). Включая сервера HP и IBM последних поколений (G8 и M4, соотв.). Но иногда для этого надо пощелкать параметрами в BIOS Setup.

Почему нет? Если модулю не нужна запись на эту флешку. Шелл (как пример приложения) с read-only-устройства грузится и работает, это 100%.

Вопрос интересный. В плане - как через UEFI-загрузчик на флешке стартовать некую Legacy-систему (и возможно ли это в принципе). В любом случае понадобится UEFI-версия GRUB, как я понимаю.

поизучал форум greenflash - оказывается, можно только grub2 использовать, и его меню. grub4dos никак не будет работать, ибо использует функции биос, которого нет при загрузке с uefi. А суть именно в том, чтобы загрузчик позволял по цепочке загрузить выбранный вариант любых других образов, утилит, и т.п. Например, memtest, образ установки какого-нибудь линукса, винды, и прочее. Вот тут проблема №2 - ВСЕ эти утилиты и образы должны быть uefi совместимыми. Т.е. использовать gpt, не использовать mbr, и не использовать функций биос (все утилиты, основанные на дос и загрузке из дос-подобных загрузчиков отпадают, а это огромный парк ПО, практически 80%).

Есть мысль, что можно выдернуть модуль эмуляции биос из какого-нибудь uefi платы, поддерживающей legacy boot, и в качестве загрузчика использовать его (видимо, переделать придется), тогда даже на тех платах, где нет legacy boot, можно загрузиться с сертифицированного виндового загрузчика uefi, или grub2 uefi и эмулировать биос, а дальше передавать управление на обычный grub4dos или что там раньше использовали (на вкус и цвет).

P.S. понятно, что этот механизм сломают, рано или поздно, и можно будет прикрутить что угодно, а пока придется пользоваться костылями. К тому времени M$ отработает деньги, вложенные в "разработку" win8 (и даже, возможно, следующей ОС), а дальше еще что-нибудь придумают, чтобы осложнить жизнь альтернативным ОС и загрузчикам.

Нет никаких эмуляций BIOS в UEFI-среде. Есть CSM-режим и этим все сказано.

Какие проблемы в UEFI Shell запустить memtest? Я скажу какие: memtest должен работать в 64-х битном режиме. Поэтому вопрос не к загрузчикам софта, а к разработчикам софта. Они должны выдать 64-битный код. Потрудитесь глянуть в исходники, чтобы понять в чем разница. Эмуляция здесь вообще ни к чему.

Статья о режиме совместимости UEFI.

Неужто memtest не должен быть EFI-приложением? Даи насчет 64-бит я все думаю. Есть и для 32-бит...

>Неужто memtest не должен быть EFI-приложением?
В данном контексте это даже не обсуждается )) Обязательно!
> Даи насчет 64-бит я все думаю. Есть и для 32-бит...
Не жилец.

Про CSM и эмуляцию.

Эмуляции Legacy BIOS для приложений под UEFI нет. Кто будет клиентом такого сервиса?
Программы, скомпилированные под DOS под UEFI работать не могут, так как расчитаны
на режим 16-bit Real Mode. UEFI-приложения не используют Legacy BIOS а используют UEFI-протоколы.

Зато есть CSM (Compatibility Support Module) и EFI_LEGACY_BIOS_PROTOCOL, которые являются
шлюзом из 64-bit Protected Mode в 16-bit Real Mode.

Представим, что есть видео адаптер или SCSI контроллер, BIOS которого не поддерживает UEFI,
написан как Legacy Option ROM и предназначен для выполнения в 16-bit Real Mode. Для того, чтобы
работать с этим устройством, 64-битный UEFI BIOS материнской платы должен вызывать сервисные
функции из 16-битного Legacy Option ROM адаптера. А эти сервисные функции написаны для
16-bit Real Mode. Поэтому, вызывать их нужно внутри "капсулы", обеспечивающей контекст 16-bit Real Mode.

Пример: Если видеокарта не поддерживает UEFI GOP (Graphics Output Protocol), то когда UEFI-приложение
вызывает функцию GOP.SetMode, firmware должно создать "капсулу" и вызвать старый-добрый
Legacy BIOS INT 10h function 0 (set video mode). В этом и смысл CSM.

"...на данный момент я не видел матерей, на которых нельзя загрузиться с Legacy (в т.ч. и флешки). ..."
Например, ноутбук ASUS T100TA. Таковой возможности вообще нет. Максимум, можно отключить Secure Boot, про CSM вообще нет упоминаний. Загрузиться можно ТОЛЬКО с UEFI.

Ну, это все же не "мать широкого профиля", а полуноут/полупланшет, вещь в себе.
У нас уж довольно давно для кое-каких исследований есть Dell-овские планшеты с такими же симптомами, модель не скажу, видимо кто-то из тех, что осенью официально вышли.

Этот девайс обещан нам ASUS'ом для исследований. Как только схлынут массы интересующихся маркетологов, он поступит в лабораторию. Счет идет на дни, хотя нам уже удалось познакомится с ним на презентации (~месяц назад).