А это потому что компьютерная техника тоже всё усложняется и усложняется. Отсюда и усложнение прошивок.

Почему тогда u-boot не усложнился настолько? Где-то ты звиздишь...

Концепция UEFI вполне себе оправдана, в том числе и пресловутый SecureBoot. Вот только, необходим минимализм, жесткая стандартизация, и открытость. Со всем этим текущие реализации подкачали, увы.

Нет. Не оправдана. Концепция UEFI - это операционная система, которая работает до пользовательской ОС. Минимализм против концепции UEFI. Жёсткая стандартизция итак есть. Открытость также против концепции UEFI.

Никто _не_ собирается запрещать отключать Secure Boot

Ты сумасшедший?

Что это запрещено в UEFI 3+ — а в UEFI 3 ещё можно.

Откуда тебе известно, что не UEFI3+ будут ставить повсеместно?

Как минимум материнки серверного сегмента сохранят по крайней мере возможность самостоятельных подписей — а вот с ноутами Linux уже работать не будет.

В случае, если нет - должен работать загрузчик SHIM из любого современного дистрибутива: он подписан ключами от M$. А он уже сам управляет ключам независимо от того разрешено это или нет у вендора: пользовательские ключи он хранит в области переменных у UEFI.

Почему тогда u-boot не усложнился настолько?

Ну вы сравнили... Он как-бы не для x86 применяется совсем, а для встраиваемых устройств, там железо как раз таки куда проще в целом (намного причём).

И гибкости в нём, по сравнению с UEFI, совсем никакой нет. Это архитектурно обусловлено - u-boot рассчитан исключительно на то чтобы загрузить ведро в заранее подготовленном формате из раздела MTP или из памяти устройства, и не более - никакого графического стека, драйверов фс и сервисов в нём нет (ну, по крайней мере, если не считать tftpboot сервисом, которого производитель платки тоже может не положить)

И насчёт стандартизации - с ней у u-boot в разы хуже чем у самых дерьмовых UEFI, уж поверьте человеку с 7 летним опытом разработки встраиваемых систем: разработчики одноплатников иногда такие «кастомизированные» загрузчики u-boot ставят на свои платки, что хочется плакать.

Кроме того новые QorIQ LS1046A появились из этой серии, но уже на ARM Cortex-A72,

Насколько я знаю 64-бит ARM ТОЛЬКО UEFI.

/0

uefi - понятие специфичное для ibm pc

Ну вы сравнили... Он как-бы не для x86 применяется совсем, а для встраиваемых устройств

У тебя каша в голове. x86 - это архитектура для встраиваемых устройств в том числе.

там железо как раз таки куда проще в целом (намного причём).

Нет.

Как минимум материнки серверного сегмента сохранят по крайней мере возможность самостоятельных подписей — а вот с ноутами Linux уже работать не будет.

Серверные материнки будут идти с ключами, которыми подписаны специально сертифицированные дистрибутивы.

а вот с ноутами Linux уже работать не будет.

О чём и речь.

В случае, если нет - должен работать загрузчик SHIM из любого современного дистрибутива: он подписан ключами от M$.

Круто. Мелкософт теперь указывает, можно ставить линукс или нельзя. Такого допускать нельзя в принципе.

И гибкости в нём, по сравнению с UEFI, совсем никакой нет. Это архитектурно обусловлено - u-boot рассчитан исключительно на то чтобы загрузить ведро в заранее подготовленном формате из раздела MTP или из памяти устройства, и не более - никакого графического стека, драйверов фс и сервисов в нём нет (ну, по крайней мере, если не считать tftpboot сервисом, которого производитель платки тоже может не положить)

А вот на этом остановлюсь поподробнее.

Задача прошивки материнской платы - начальная инициализация компьютера и передача управления операционной системе. Всё. UEFI тут нафиг не нужен. Простого u-boot достаточно - пусть хоть загрузчик вроде GRUB грузит. Более того: схема загрузки с первого сектора диска себя показала исключительно хорошо, так как именно это обеспечило колоссальную гибкость в выборе загрузчика и способов загрузки.

И насчёт стандартизации - с ней у u-boot в разы хуже чем у самых дерьмовых UEFI, уж поверьте человеку с 7 летним опытом разработки встраиваемых систем: разработчики одноплатников иногда такие «кастомизированные» загрузчики u-boot ставят на свои платки, что хочется плакать.

Вводим правило загрузки по подобию MBR и всё. Никакой UEFI не нужен.

Как минимум материнки серверного сегмента сохранят по крайней мере возможность самостоятельных подписей — а вот с ноутами Linux уже работать не будет.

Просто у тебя будет выбор:

Купить ноут с десяточкой в оффлайновом магазине.

Или заказать ноунейм мейд ин чина ноут с разлоченным загрузчиком по цене в 4 раза выше.

Капитализм, однако.

Или заказать ноунейм мейд ин чина ноут с разлоченным загрузчиком по цене в 4 раза выше.

Ты забыл упомянуть, что ноут будет на каком-нибудь Allwinner A10.

Ты забыл упомянуть, что ноут будет на каком-нибудь Allwinner A10.

Да нет, почему обязательно на нём. Если на нём, то еще на два надо умножить цену. А так — оплата встроенным в x86 трояном интеля. :D

Погугли.

Задача прошивки материнской платы - начальная инициализация компьютера и передача управления операционной системе. Всё. UEFI тут нафиг не нужен.

+100500

Более того: схема загрузки с первого сектора диска себя показала исключительно хорошо, так как именно это обеспечило колоссальную гибкость в выборе загрузчика и способов загрузки.

Аналогично

Серверные материнки будут идти с ключами, которыми подписаны специально сертифицированные дистрибутивы.

Есть те, кому нужны Debian или Gentoo — значит будут и платы с возможностью подписи.

Ну какой смысл производителям не предоставлять такой возможности? Intel не запрещает, RedHat не столь сильна. И потом: не сделаешь ты — другой сделает.

Погугли.

Уточни про что? UEFI - интеловское изобретение. Может быть ты с чем-то перепутал? Конечно, UEFI можно портировать на любую архитектуру и кто-то этим занимается, но это мало что значит. Больше бутлоадеров всяких и разных. Ну и если уточнять про LS1046A - для него есть и U-Boot и UEFI. Ну и ты можешь свое написать, если ни тот ни другой не устраивают.

Проблема не в UEFI, проблема в документации на микропроцессоры. Если процессор полностью документирован и доступен в розницу, то ты можешь написать какой угодно бутлоадер для своего собственного компьютера. Если же ты можешь купить только готовый залоченый продукт: «ATX»-совместимый компьютер или 96Boards-совместимый компьютер, то ты получишь только UEFI с подписанными интелом/хуявеем/кем там еще блобами.

Ну и сошлюсь на конкретный документ про бутлоадеры, ARM TrustZone, Secure Boot, u-boot, uefi:

https://www.nxp.com/docs/en/supporting-information/QORIQ_LS1046A_BSP_V0-4_REV...

Глава 8. Boot Loaders

https://github.com/qoriq-open-source/u-boot

https://github.com/qoriq-open-source/ls1043a-uefi

https://github.com/qoriq-open-source/ppa-generic/tree/integration/ppa/soc-ls1046 (то что вращается в Arm TrustZone, аналог Intel SMM + там же конфигурятор SEC engine, аналог Intel ME насколько я понимаю)

Я ж не крутой практик, я ж просто интересуюсь. Оный QorIQ я только подумываю прикупить ради интереса, если борда недорогая найдется.

Ok, UEFI для ARM пилила Linaro. Когда три года назад я был в Линаро то коллеги которые пилили UEFI говорили что кто-то убедил ARM что 64-битные процы должны быть только с UEFI. Ну еще говорили что пользователи плохо понимают идею UEFI и что он лучше grub и uboot.

я этого не понимаю. расскажешь подробнее? у меня на руках сейчас платка с ls1012a, в ней u-boot. это не контрпример к твоему утверждению?

я вообще не понимаю выражения «arm64 может быть только с uefi». для меня это /0. возможно, по причине глупости и неграмотности

у меня на руках сейчас платка с ls1012a, в ней u-boot. это не контрпример к твоему утверждению?

Если политика ARM не сменилась то он работает поверх UEFI.

Кстати, еще вспомнил: этиже ребята сильно хотели от ARM таблицы ACPI, и их поддержку реализовывали теже мои бывшие коллеги.

Вообще я немного знаю о 64-бит ARM - только то что слышал или читал. В живую я работал только с 32 bit.

Если политика ARM не сменилась то он работает поверх UEFI.

в доке написано иное, rbl никакого интерфейса совместимого с uefi не предоставляет и в рантайме не работает. я же привел ссылку.

uefi надо компелять отдельно

как вообще arm может обязать использовать uefi? не продавать ядра тем, кто не юзает их блоб?

может qoriq не поддерживает acpi? надо сейчас посмотреть в этом направлении, ok, благо железо есть

" ARM только UEFI"

Расскажи мне все об этом, прямо сейчас!

Я тебя не понимаю. Ты говоришь про SoC (system on chip) с архитектурой ARM? Ты не путаешь ARM Trustzone с UEFI?

И поясни как Linaro могла пилить UEFI для ARM, если ARM не производит SoC?

Насколько я знаю ARM симулирует SOC на плисках, и на симуляции отлаживается свой (и Линаровский) софт.

Кроме того в той тимы был кремний. Я не разбирался откудова. Возможно ARM заказывала на стороне Engineering samples.

Ты уверен что именно в SoC ARM UEFI писали или все-таки в какую нибудь SPI NAND для ARM SoC? Это как бы не одно и то же.

Жду эту плату http://linuxgizmos.com/wandboard-org-launches-i-mx8m-based-sbc-with-rpi-expan...

Ты уверен что именно в SoC ARM UEFI писали или все-таки в какую нибудь SPI NAND для ARM SoC? Это как бы не одно и то же.

чего, чего а spi NAND там точно небыло. Была большая, кажется двухпроцессорная или четырехпроцессорная, dev-борда с кучей PCI-e слотов (кажется 8) и SATA винт был подключен кабелем. Это так выглядел кремний который мне показывали.

А так - да, в детали я не вникал. Я занимался сильно другими задачами.

Еще бенчмарки показывали и сравнивали с Интелом. ARM рулил по потреблению, Интел - по производительности.

А я заказал LS1012A за 50$, только что пришла, самая дешевая из семейства. Посматриваю на более дорогие, но цена больше 2000$ на девборды от самих NXP для платки с целью «посмотреть как оно работает» слишком велика, переписываюсь сейчас с китайцами, может предложат что-то дешевое на этих процессорах.