Комментарии 81
Вы наверное не пользовались линуксом в начале двухтысячных, слишком остро реагируете на такую мелкую проблему
Пользовался. Разница тут в том, я не припомню такого, чтобы устройство самостоятельно превращало себя в кирпич просто при попытке обновить ОС. Именно не то, чтобы ОС разрушалась — это фигня, недостойная упоминания. Максимум тут грозит переустановка. Тут же само устройство далее неработоспособно, совершенно и полностью. Обычный пользователь с этой проблемой не разберется никак, при этом проблема скрыта и никак себя не проявляет. После возникновения проблемы ОС установить на устройство невозможно физически, кстати как Win, так и Linux свежий на него уже не установятся до устранения проблемы с nvram. Более всего напоминает бомбу замедленного действия. Вообще говоря, это безобразие.
Ага, у вас хоть интернет сейчас есть))) мне приходилось самому дописывать драйвера для сетевой карты чтобы поиграть по сетке с другом на самописном бомбермене и тогда не было даже диалапа( только ты, твой комп, пару книг по С и ядру линукс. Я размышлял по целому дню что я делаю не так, потом записывал нужные мне вопросы в тетрадку и ходил к мамке на работу где доступно было только 30 минут диалапа чтобы погуглить
Я это к тому что после всего такого не особо вообще реагирую на такие проблемы. Я по-моему даже по жизни стал спокойный как слон
Ого, суровое детство, игрушки прибитые к полу :) После такого-то конечно уже практически любые проблемы — не проблемы. Собственно вопрос возникает — а почему тогда был Linux исходно? С ним без доступа к коммунити тогда ну очень несладко было. Любопытство или необходимость?
С ним и сейчас тоже проблемы. Debian на Fake-RAID смог поставить, только прочитав багрепорт от 2013 года с начала и до конца (проблема присутствует до сих пор, кстати).
Просто книгу по ядру линукса подарил один красноглазый друг, он тогда в школе всем мозги промывал со своим линуксом, я пошел, взял у него же ред хат, не помню пятый или четвертый, помню только то что я все данные затер нафиг случайно на своем 60 гиговом харде. Ну играть на моем компе уже невозможно было из за бума новомодных игр и невероятным требованиям к железу, поэтому игрался с операционной системой, в итоге с 2002 года линуксом и пользуюсь. Развлекал меня тогда вместо интернета журнал хакер, на который я копил каждый месяц, откладывая по 50 тг в день(я в казахстане живу) те что мне мама на еду давала, и в конце месяца покупал. Журналу кстати огромное спасибо, у меня до сих пор лежит эта огромная стопка журналов, от которой у меня кстати полка в шкафу не выдержала
Любая программная проблема с любой ОС может быть решена полной переустановкой. Если человек смог поставить Linux, то и переустановить его он сможет. Починить существующую — может быть и нет, но переустановить точно, потому что эти действия он уже когда-то успешно делал. А в случае краха UEFI переустановить его проблематично — требуется специальное оборудование, которого для каких-то брендов может не быть в продаже в принципе.
Все проблемы от сборщиков мусора
Вам еще повезло, что система осталась частично работоспособна. На моем ноутбуке (ASUS) при определенном стечении обстоятельств портится NVRAM так, что ноутубук вообще не включается. Я не единственный с такой проблемой, это глюк UEFI, лечится (точнее восстанавливается работоспособность, проблема не исчезает) либо заменой материнской платы по гарантии, либо пересадкой прошивки программатором с донора (как я и сделал). Прошивка не обновляется производителем совсем, а версия на оффсайте не пригодна для заливки в чип. И никого это не волнует, слишком маленький процент пострадавших…
Было бы хорошо иметь на чипе незатираемый сектор восстановления, тогда проблема легко решается штатными средствами. Но тогда придется устанавливать более емкие, а следовательно более дорогие чипы…
Было бы хорошо иметь на чипе незатираемый сектор восстановления, тогда проблема легко решается штатными средствами. Но тогда придется устанавливать более емкие, а следовательно более дорогие чипы…
Емкости, зачастую, хватило бы и так, тут не хватает мотивации одним и умения другим.
Дело в том, что PC firmware (BIOS или UEFI — не важно) разрабатывался и разрабатывается по следующей схеме:
CPU Vendor -> BIOS Vendor -> System Vendor. Разработчик процессора (в нашем UEFI'шном случае это Intel, AMD или ARM) пишет код низкоуровневой инициализации поставляемых им компонентов — процессора, чипсета, контролера памяти, контролера PCI(e), контролера USB и т.п. и предоставляет этот «скелет» разработчику платформы (обычно таких разработчиков называют IBV aka Independent BIOS Vendor, самые известные — AMI, Phoenix, Insyde). Затем IBV наращивает на «скелете» разного рода «мясо» (т.е. фичи вроде CSM, BIOS Setup, загрузчик, ACPI, и т.д.) и предоставляет так называемый full-featured reference platform BIOS, работающий на референсной же плате от разработчика процессора, называемой CRB aka Customer Reference Board. Затем производители железа вроде ASUS и Gigabyte покупают вот эту самую CRB у производителя CPU и вот этот самый BIOS у IBV и адаптируют и то, и другое под свои условия, добавляя драйверы для собственных устройств, свой AML-код и свои картинки на фон в BIOS Setup.
В результате получается, что производитель CPU отвечает только за свои собственные низкоуровневые компоненты и ему вообще не важно, как устроен NVRAM, если ли баги в работе с ним или нет и где он физически находится. Код инициализации либо не использует NVRAM вообще, либо использует только для чтения/записи временных (non-volatile) или мелких, доступных только коду UEFI, BS-переменных, и если БИОС дошел до загрузки ОС вообще, то эта часть кода работы с NVRAM отлажена и функционирует нормально.
IVB тоже не слишком важно, что там устроено и как, их задача — выкатить работающий референсный BIOS. Никто его толком не тестирует, и многого от него тоже никто не ждет, т.к. CRB сама по себе работает нестабильно и нагрузочного тестирования на ней никто не проводит — это задача конечного вендора. Часть кода берется из TianoCore, часть дописыватся тут же, часть наскивается из других похожих проектов, в итоге получается лоскутное одеяло, которое криво-косо, но работает на CRB, а больше от него ничего и не надо — вендоры сами разбируться, это их работа.
Конечный же вендор стремится минимизировать издержки и ускорить выход продукта на рынок, а потому вообще не лезет в код, написаный на предыдущих этапах, если этот код хоть как-то работает, у него хватает проблем с адаптацией тех кусков кода, которые работать упрямо отказываются, а должны еще вчера. В результате такого подхода куча решений из серии «это костыль, уберем в следующем коммите» и «работает и хай так» не только оказываются в продакшене, но и живут там до самой смерти платы. Архитектуру менять некому и некогда, т.к. никто в дополнительной работе без каких-либо дивидендов не заинтересован.
Дело в том, что PC firmware (BIOS или UEFI — не важно) разрабатывался и разрабатывается по следующей схеме:
CPU Vendor -> BIOS Vendor -> System Vendor. Разработчик процессора (в нашем UEFI'шном случае это Intel, AMD или ARM) пишет код низкоуровневой инициализации поставляемых им компонентов — процессора, чипсета, контролера памяти, контролера PCI(e), контролера USB и т.п. и предоставляет этот «скелет» разработчику платформы (обычно таких разработчиков называют IBV aka Independent BIOS Vendor, самые известные — AMI, Phoenix, Insyde). Затем IBV наращивает на «скелете» разного рода «мясо» (т.е. фичи вроде CSM, BIOS Setup, загрузчик, ACPI, и т.д.) и предоставляет так называемый full-featured reference platform BIOS, работающий на референсной же плате от разработчика процессора, называемой CRB aka Customer Reference Board. Затем производители железа вроде ASUS и Gigabyte покупают вот эту самую CRB у производителя CPU и вот этот самый BIOS у IBV и адаптируют и то, и другое под свои условия, добавляя драйверы для собственных устройств, свой AML-код и свои картинки на фон в BIOS Setup.
В результате получается, что производитель CPU отвечает только за свои собственные низкоуровневые компоненты и ему вообще не важно, как устроен NVRAM, если ли баги в работе с ним или нет и где он физически находится. Код инициализации либо не использует NVRAM вообще, либо использует только для чтения/записи временных (non-volatile) или мелких, доступных только коду UEFI, BS-переменных, и если БИОС дошел до загрузки ОС вообще, то эта часть кода работы с NVRAM отлажена и функционирует нормально.
IVB тоже не слишком важно, что там устроено и как, их задача — выкатить работающий референсный BIOS. Никто его толком не тестирует, и многого от него тоже никто не ждет, т.к. CRB сама по себе работает нестабильно и нагрузочного тестирования на ней никто не проводит — это задача конечного вендора. Часть кода берется из TianoCore, часть дописыватся тут же, часть наскивается из других похожих проектов, в итоге получается лоскутное одеяло, которое криво-косо, но работает на CRB, а больше от него ничего и не надо — вендоры сами разбируться, это их работа.
Конечный же вендор стремится минимизировать издержки и ускорить выход продукта на рынок, а потому вообще не лезет в код, написаный на предыдущих этапах, если этот код хоть как-то работает, у него хватает проблем с адаптацией тех кусков кода, которые работать упрямо отказываются, а должны еще вчера. В результате такого подхода куча решений из серии «это костыль, уберем в следующем коммите» и «работает и хай так» не только оказываются в продакшене, но и живут там до самой смерти платы. Архитектуру менять некому и некогда, т.к. никто в дополнительной работе без каких-либо дивидендов не заинтересован.
А вот от этого совсем поплохело. Что-то я чувствую, что скоро буду с ностальгией вспоминать старые добрые кондовые BIOSы без UEFI как такового. И да, спасибо за информацию, теперь понятно откуда такая свистопляска вообще.
Честно говоря, мысль о том, что хочется старый добрый BIOS появилась с первым же опытом общения с UEFI. ПРи том что UEFI прекрасно работает на моих платах(тьфу-тьфу-тьфу) и он нагляднее и удобнее BIOS'a… Но вот это чувство, что в нем ради свистелк и перделок забивают на качество было… После прочтения стать и комментариев это чувство стало обоснованным.
Стоит сказать, что спеки по ACPI никто не просто не придерживается, а похоже просто не читали.
Стоит добавить, что спеку писали законченые наркоманы, а людей, которые могут правильно писать на AML без ошибок, можно по пальцам пересчитать. Более того, примерно 80% AML-кода пишется производителем CPU (которому плевать на warning'и), еще по 10% — IVB и конечным вендором (и будь они хоть кем, их код — капля в море). Да и если большая часть современных ОС на недоработки ACPI все равно плевать хотела (а серьезно пользуется им только OSX), то и отношение к технологии — соответствующее. Пока оно работает хоть как-то — никто ничего трогать не будет, работы хватает и без этого.
ACPI это наихудший стандарт, который я читал. Понять ЭТО чЮдо по моему нереально.
Можно, если очень стараться и все остальное уже и так работает. Многие пользователи Хакинтоша отлаживают свои DSDT и SSDT самостоятельно до состояния Errors 0, Warnings 0, Remarks 0, Info 0, не имея при этом документации, но это все отнимает кучу времени и будет сломано следующим апдейтом БИОСа, а потому разработчикам просто некогда разбираться с ошибками ACPI. Работает — и ладно.
Пишут, скорее, все-таки на ASL (ACPI Source Language), AML (ACPI Machine Language) — это уже байткод.
Ого, ничего себе. Вот уроды, а. На такое вообще никаких цензурных эпитетов не остается. А какая конкретная модель ноута, если не секрет? Можно в личку, чтобы если такой принесут, знать прикуп заранее.
Правда затем решил обновить firmware у ноутбука [...] в новом firmware нет возможности загрузки с флешки.То есть они (производитель) прям вот честно в changelog'е написали, что, мол, мы считаем, что с флешки грузиться — от лукавого, и убрали эту возможность? Это ведь уже даже не просто мелкое вредительство, это имхо вообще за гранью добра и зла.
Вообще, конечно, новое железо ужасно расстраивает. Казалось бы, есть холодные, быстрые процы на рынке, приличные матрицы, ёмкие винты, кучу памяти можно воткнуть, но вот найти хороший, годный готовый ноутбук при этом становится с каждым годом все сложнее. А «на коленке» изготовить плату, чтобы засунуть ее в какой-нибудь старый корпус, не получится. :-(
Все проблемы от того, что опять смешали код и данные.
NVRAM не место в той же микросхеме, в которой находится исполняемый код, и важнейшим системным приложениям вроде BIOS Setup и BIOS Update не место среди переменных BootXXXX. Неработоспособность их вызвана тем, что в реализациях Phoenix SCT и Insyde H2O все функции, вызываемые с POST-экрана горячими клавишами — всего лишь очередные «загрузочные устройства», прописанные в NVRAM, и потому при нарушении работы NVRAM они тоже перестают работать. Этому багу почти 5 лет и на некоторых новых ноутбуках он по прежнему присуствует. И повезло еще, что хоть что-то загрузочное осталось, иногда бывает так, что какой-нибудь efibootmgr сносит вообще все переменные BootXXXX, и система после перезагрузки показывает только черный экран.
Самая правильная реализация работы с NVRAM в данный момент у AMI. У них отдельно хранится слепок настроек по умолчанию, которые будут скопированны поверх NVRAM в случае, если с ним случилось что-то непоправимое, а системные функции вроде BIOS Setup вызываются из приложения, которое стартует всегда и запуск которого не зависит от состояния NVRAM вообще.
Тем не менее, сама идея NVRAM на той же микросхеме, что и исполняемый код — порочна по сути. Постараюсь в одном из проектов вместо установки одного чипа на 16 мб поставить два по 8 и на первый перенести все регионы, запись в которые нужна при работе системы (GbE, ME, NVRAM), а на вторую записать прошивку и защитить весь чип от записи переключателем SPI_WP. Нужно обновлять прошивку — выключил защиту, обновил из BIOS Setup, включил назад. И никаких танцев с криптографией и защитой пользователя от самого себя. Да, это больше работы по адаптации, но овчинка стоит выделки, на мой взгляд.
NVRAM не место в той же микросхеме, в которой находится исполняемый код, и важнейшим системным приложениям вроде BIOS Setup и BIOS Update не место среди переменных BootXXXX. Неработоспособность их вызвана тем, что в реализациях Phoenix SCT и Insyde H2O все функции, вызываемые с POST-экрана горячими клавишами — всего лишь очередные «загрузочные устройства», прописанные в NVRAM, и потому при нарушении работы NVRAM они тоже перестают работать. Этому багу почти 5 лет и на некоторых новых ноутбуках он по прежнему присуствует. И повезло еще, что хоть что-то загрузочное осталось, иногда бывает так, что какой-нибудь efibootmgr сносит вообще все переменные BootXXXX, и система после перезагрузки показывает только черный экран.
Самая правильная реализация работы с NVRAM в данный момент у AMI. У них отдельно хранится слепок настроек по умолчанию, которые будут скопированны поверх NVRAM в случае, если с ним случилось что-то непоправимое, а системные функции вроде BIOS Setup вызываются из приложения, которое стартует всегда и запуск которого не зависит от состояния NVRAM вообще.
Тем не менее, сама идея NVRAM на той же микросхеме, что и исполняемый код — порочна по сути. Постараюсь в одном из проектов вместо установки одного чипа на 16 мб поставить два по 8 и на первый перенести все регионы, запись в которые нужна при работе системы (GbE, ME, NVRAM), а на вторую записать прошивку и защитить весь чип от записи переключателем SPI_WP. Нужно обновлять прошивку — выключил защиту, обновил из BIOS Setup, включил назад. И никаких танцев с криптографией и защитой пользователя от самого себя. Да, это больше работы по адаптации, но овчинка стоит выделки, на мой взгляд.
Ей-богу стоит, хотя бы с точки зрения бесперебойности работы и легкого восстановления после сбоев. Эти вот танцы с бубном с технологией, которая должна была по идее заменить удобно «старый, немасштабируемый и небезопасный» BIOS вызывают у меня легкую оторопь, я честно говоря никогда себе не представлял устройство, которое само себе способно запороть микропрограмму, просто так вот, в процессе вполне штатной, обычной работы. Чем дальше, тем больше создается впечатление, что вся концепция UEFI — flawed by design.
Концепция там нормальная, как раз, но как всегда, «гладко было на бумаге».
BIOS изнутри устроен еще хуже, и под занавес его разработка стала настолько сложной и дорогой, а требования настолько противоречивыми, что без UEFI (а другого стандарта такого уровня просто не было) все равно было не обойтись.
Проблема там в основном в том, что внедрение UEFI и PI (Platform Interface, стандарт нижнего уровня прошивки) упростило разработку компонентов прошивки примерно на порядок засчет перехода с ассемблера на С и использования стандартных компиляторов/сборщиков/отладчиков/утилит вместо специализированных. А это, в свою очередь, резко упростило и удешевило добавление в прошивку компонентов, которые раньше пихать туда было дорого и велик был риск не вылезти из отладки. В результате имеем половину OpenSSL в составе CryptoPkg, половину сетевого стека из FreeBSD в составе NetworkPkg, поддержку PNG и OpenGL в BIOS Setup и прочий цирк с конями. А т.к. цирк и кони хорошо продаются простому пользователю, то все силы IBV и конечные вендоры бросили именно на них, в итоге фичи уже не влезают в 16 Мб флеша, а баги висят незакрытыми годами. Хуже всего еще и то, что про безопасность задумались более или менее серьезно только в этом году, и до сих пор 95% процентов прошивок — решето такое, что можно вермишель просеивать, но про это я не имею права рассказывать, читайте сами вот тут.
BIOS изнутри устроен еще хуже, и под занавес его разработка стала настолько сложной и дорогой, а требования настолько противоречивыми, что без UEFI (а другого стандарта такого уровня просто не было) все равно было не обойтись.
Проблема там в основном в том, что внедрение UEFI и PI (Platform Interface, стандарт нижнего уровня прошивки) упростило разработку компонентов прошивки примерно на порядок засчет перехода с ассемблера на С и использования стандартных компиляторов/сборщиков/отладчиков/утилит вместо специализированных. А это, в свою очередь, резко упростило и удешевило добавление в прошивку компонентов, которые раньше пихать туда было дорого и велик был риск не вылезти из отладки. В результате имеем половину OpenSSL в составе CryptoPkg, половину сетевого стека из FreeBSD в составе NetworkPkg, поддержку PNG и OpenGL в BIOS Setup и прочий цирк с конями. А т.к. цирк и кони хорошо продаются простому пользователю, то все силы IBV и конечные вендоры бросили именно на них, в итоге фичи уже не влезают в 16 Мб флеша, а баги висят незакрытыми годами. Хуже всего еще и то, что про безопасность задумались более или менее серьезно только в этом году, и до сих пор 95% процентов прошивок — решето такое, что можно вермишель просеивать, но про это я не имею права рассказывать, читайте сами вот тут.
mother_of_god.jpg
Мда, это ж можно ваять такие вири, что Win.CIH печально известный покажется безобидным порнобаннером. А хуже всего то, что все эти дыры принципиально не закрываются на старом оборудовании, производители же концентрируются на выпуске нового. Плохо. Всё очень плохо.
Мда, это ж можно ваять такие вири, что Win.CIH печально известный покажется безобидным порнобаннером. А хуже всего то, что все эти дыры принципиально не закрываются на старом оборудовании, производители же концентрируются на выпуске нового. Плохо. Всё очень плохо.
Можно, и уже ваяют. Я пока не слышал об успешных атаках, устроенных вредоносным кодом, но это вовсе не означает, что их не было или не будет. Обязательно будут. В данный момент безопасность прошивок большинства находящихся на рынке машин — околонулевая, а некоторые вендоры до сих пор позволяют прошивать любые образы БИОСа без валидации прямо из ОС (привет Asrock и EVGA), а это даже не дыра в безопасности — это просто открытая дверь для кода, который хочет добавить себя в БИОС. По моей скромной оценке, примерно на 98% ПК с UEFI на данный момент существует минимум одна незакрытая уязвимость, позволяющая добавить свой код в БИОС и получить управление до загрузки ОС. Остальные два — системы с включенным BootGuard, на которых вместо этого получится DoS, т.е. после прошивки система просто перестанет рабоать.
«Please, please, please, go apply patches!» Xeno Kovah @ CanSecWest2015
«Please, please, please, go apply patches!» Xeno Kovah @ CanSecWest2015
А вот теперь мне холодно и страшно (с). Это ведь в итоге мне всё это потащат в ремонт. Чувствую пора обзаводиться программатором. Нет, я конечно люто признателен производителям за то, что я точно без работы не останусь с таким подходом, и будет мне и хлеб, и масло с икрой на него, но вся моя натура инженера-системотехника искренне протестует против такого безобразного подхода к созданию оборудования. Кстати, а вот эта проблема с nvram — я ведь, насколько понимаю прошивкой не устранил проблему совсем, а просто в процессе прошивки nvram зачистился, верно? Соответственно у юзера все так же сохранилась возможность вновь наступить на грабли при обновлении системы. А значит уже очень скоро, сразу после выхода Win 10, которая будет лицензионно-бесплатная для всех лицензионных пользователей Win 7/8/8.1, мне валом понесут ноутбуки (а может даже и стационарные системники) с той же самой сабжевой проблемой. Ибо шанса обновиться нахаляву на 10-ку мало кто из пользователей упустит.
Именно так, проблема никуда не делась, и скорее всего никуда уже не денется. Жизненный цикл продуктов для массовго рынка — полгода, потом к ним перестают выпускать обновления, ведь нужно разработывать новое поколение продуктов, у которых еще больше фич и еще короче время выхода на рынок. Большая часть ИТ (как и всей остальной индустрии) — пример широко известной в узких кругах экономики говна, исключений там два с половиной и все они работают на индустрию, а не на конечного пользователя.
Системники не понесут, там AMI Aptio, который от разваливания NVRAM намертво не ломается (ну подумаешь настройки перестают сохранятся, но в них все равно ведь никто не лезет...), а вот ноутбуки — еще как, так что без хорошего программатора (рекомендую Dediprog SF-600, но можно взять и MiniPro TL866A, он подешевле) восстаналивать эту гору ноутбуков будет весьма непросто.
Системники не понесут, там AMI Aptio, который от разваливания NVRAM намертво не ломается (ну подумаешь настройки перестают сохранятся, но в них все равно ведь никто не лезет...), а вот ноутбуки — еще как, так что без хорошего программатора (рекомендую Dediprog SF-600, но можно взять и MiniPro TL866A, он подешевле) восстаналивать эту гору ноутбуков будет весьма непросто.
За совет по программатору отдельное спасибо. MiniPro TL866A как минимум надо точно взять будет.
Хехе =) а я совсем обленился что-то. Последнее время паять стало совсем лень, по этому заказал у китайцев клипсу на so8 корпуса. А шить как и раньше буду своим любимым beeprog+
А что за клипса? Я так понимаю, позволяет подцепиться к чипу прямо на плате? Дайте ссылочку поглядеть на продукт.
Так называемая SOIC Test Clip, хорошие делают Pomona и 3M, китайские, к сожалению, быстро выходят из строя.
Что-то типа такого. www.aliexpress.com/item/Free-Shipping-Hot-BIOS-24-25-93-Programmer-SOIC8-SOP8-Flash-Chip-IC-Test-Clips-Socket/32291521087.html
Но для её использования программатор должен адекватно отрабатывать наличие хостового питания.
Сейчас я подчепляюсь мелкими крокодильчиками к ногам, в прогамматоре выбираю режим работы ISP (типа внутрисхемный отладчик\прошивальщик), и шью прошивку на ноутах прямо на «горячую», отправив их в сон, либо просто включив и дождавшись устойчивого чёрного экрана.
Теперь вот хочу попробовать клипсу, а то делать ктулху их крокодилов или паять чипы на каких-нибудь макбуках совсем не хочется.
Но для её использования программатор должен адекватно отрабатывать наличие хостового питания.
Сейчас я подчепляюсь мелкими крокодильчиками к ногам, в прогамматоре выбираю режим работы ISP (типа внутрисхемный отладчик\прошивальщик), и шью прошивку на ноутах прямо на «горячую», отправив их в сон, либо просто включив и дождавшись устойчивого чёрного экрана.
Теперь вот хочу попробовать клипсу, а то делать ктулху их крокодилов или паять чипы на каких-нибудь макбуках совсем не хочется.
Ещё хорошая рабочая лошадка sofitech sp8 и прочие.
Кстати, к вам, как к разработчику отдельная просьба — если вам удастся реализовать вашу схему, с двумя чипами, на одном из которых защищенная от записи основная часть прошивки, а на втором — служебные области, доступные для записи, постарайтесь ещё вот что сделать — если это возможно, добавьте ещё один служебный микропереключатель на плату, при нажатии которого содержимое микросхемы со служебными данными будет полностью перезаписываться чистой эталонной прошивкой. На всякий случай, для удобного аппаратного решения любых потенциальных сабжевых проблем.
Хорошая идея, нажал кнопку — через 30 секунд получил работающую прошивку. Попробую реализовать в одном из следующих проектов, разводка которого еще не закончена.
Именно так. Вкупе с защищенной от записи основной частью прошивки система получится просто неубиваемая. Сервисные инженеры будут бешено признательны за такое аппаратное решение.
Не, тут не знаю как кто, а я обычно придерживаюсь профессиональной корректности. В случае описанном в посте подобная процедура обойдется клиенту в пару тысяч рублей, а в случае, если бы было все так просто, с нажатием одной кнопочки — взял бы максимум 200-300, при этом клиент бы через 10 минут после обращения уже бы забрал живой ноутбук.
А я всегда при настройке компа первым делом обновляю BIOS/UEFi, дабы избежать различных глюков.
Значит, uefi еще слишком молодая технология. Когда-нибудь ее дообкатают и таких глюков больше не будет.
Будем надеяться. Хотя надежды на это особой нет, почитайте что тут в обсуждении CodeRush рассказал.
Несмотря на вот это все — надежда есть и дело понемногу двигается с мертвой точки. Технологию обязательно обкатают, и лет через 5 у нас будут хорошие и защищенные UEFI-совместимые прошивки, а пока мы имеем то, что имеем, и пытаемся если не совсем избежать удара граблями, то хотя бы надеть каску и приготовить бинты.
Может быть, я чего-то не понимаю, но я вообще не вижу смысла внедрения UEFI. Да, BIOS был 16-разрядным. Ну и что? От 64-битности firmware компьютер как-то иначе стал включаться? Или разве в обычном BIOS нельзя реализовать поддержку GPT? Сделано значительное усложнение системы, которое практически не принесло полезного функционала, зато добавило массу новых точек отказа.
Ну любой программист вам скажет, что если «оно работает», это еще не значит, что под капотом все чисто.
С биос груз прошлого тормозит развитие. Решения, которые там применены, себя изжили. Много лет инженеры пытались тянуть лямку обратной совместимости, но со временем груз становится все тяжелее. В какой-то момент это становится слишком дорого.
И плюс наседает маркетинг. Как это ни странно, появление uefi и смерть биос должно увеличить продажи.
С биос груз прошлого тормозит развитие. Решения, которые там применены, себя изжили. Много лет инженеры пытались тянуть лямку обратной совместимости, но со временем груз становится все тяжелее. В какой-то момент это становится слишком дорого.
И плюс наседает маркетинг. Как это ни странно, появление uefi и смерть биос должно увеличить продажи.
Как это ни странно, появление uefi и смерть биос должно увеличить продажи.
Интересно, каким образом? Конечному пользователю вообщем то наплевать как оно там инициируется и грузится.
Потому, что когда выпускают новый uefi, то старый bios перестают производить, и он становится фактически как лампочка с нестандартным цоколем. Какое-то время ее эксплуотировать конечно можно, если уже есть цоколь, который она включена. Но потом меняют и цоколь и лампочку.
Примерно то же самое будет с uefi. Например. Там по спецификации дрова к железу могут идти сразу uefi-ные, вшитые в устройство. И их не надо устанавливать, они «устанавливаются» вместе с втыкнутым устройством, а винда или линукс просто их использует. Пойдут такие устройства, люди с биосом, которые захотят эти устройства использовать, будут вынуждены купить материнку с uefi
Примерно то же самое будет с uefi. Например. Там по спецификации дрова к железу могут идти сразу uefi-ные, вшитые в устройство. И их не надо устанавливать, они «устанавливаются» вместе с втыкнутым устройством, а винда или линукс просто их использует. Пойдут такие устройства, люди с биосом, которые захотят эти устройства использовать, будут вынуждены купить материнку с uefi
Такие устройства уже пошли, это любые современные видеокарты, SSD с интерфейсом NVMe, разного рода ускорители на FPGA и т.д. На данный момент производители предоставляют и OptionROM для совместимости с legacy BIOS, и DXE driver для UEFI, но втечение пары лет от поставки OROM'ов откажутся окончательно, вместе с отказом от CSM на большинстве десктопов. А на ноутбуках от CSM некоторые производители отказались уже сейчас.
В том-то и проблема. Я часто слышу слова «устаревшее решение», «тормозит развитие» и т.д. Но это как раз обычно слова маркетологов, а не инженеров. Само по себе понятие «устаревшее решение» ни о чем плохом не говорит, колесо еще куда более устаревшее решение. В отношении BIOS vs UEFI я вижу достаточно простой, отлаженный десятилетиями код, и напротив него громоздкую спецификацию, обвешанную кучей дополнительных фич, многие из которых вообще никогда не будут востребованы на массовом рынке, вроде возможности создания драйверов на уровне firmware… и вот весь этот программный монстр делает абсолютно то же самое, что и BIOS. И честно, я не верю в то, что разработчикам BIOS дешевле развивать старую систему, чем создавать с нуля новую, и потом еще ее годами отлаживать.
Вот маркетинг — это да. На всех виденных мной коробках от новых материнок гордо красуется надпись вида «Graphical UEFI». Кстати, у меня в шкафу лежит материнка под 486DX, начала 1990-х. Там BIOS Setup стилизован под Windows 3.x. Окошки, пиктограммы, управляется мышкой… Вот тогда это действительно была новинка :)
Вот маркетинг — это да. На всех виденных мной коробках от новых материнок гордо красуется надпись вида «Graphical UEFI». Кстати, у меня в шкафу лежит материнка под 486DX, начала 1990-х. Там BIOS Setup стилизован под Windows 3.x. Окошки, пиктограммы, управляется мышкой… Вот тогда это действительно была новинка :)
А теперь пара слов об «устаревшем решении» от инженера. Оно не устарело, оно обкостылело (всех несогласных прошу в обработчик int13h от award образца начала 2000ых годов, впрочем там можно и весь код посмотреть, костылей хватает) и уже тупо начинало разваливаться от переодических новых костылей, в вашем колесе костылей не так уж и много. Далее, где-то на заре мироздания, тьфу, в эпоху появления DDR2 фирма интел сказала «а ну вас нафиг с вашим устаревшим решением» и начала давать MRC (Memory Refrence Code — код, который вам настраивает память, и без него мы имеем кирпич) в виде 32-битного модуля, который к тому-же и собирался в подобие DLL. Да, недовольные этим могли подписать с интелом ещё один пакет бумажек и получить этот самый MRC в исходниках, коие были тихим ужасом. AMD тоже не отстала, выкатив AGESA/PI примерно в том-же формате. Снова выросли костыли на костылях. Почитайте исходники старого аварда, вам этого хватит, чтобы понять, что новые фичи туды прикрутить было тем ещё гемороем.
Как программист, я сейчас вообще сильно разочаровался в индустрии. Всё делается в минимальные сроки, ошибки не исправляются, если с ними продукт худо-бедно работает и такое поведение не помечено заказчиком как недопустимое в ТЗ. Главный приоритет в современных IT — бабло, но никак не качество.
Не просто 16-разрядным, а написанным на ассемблере по большей части. И он больше 20 лет нес с собой груз тогдашних «временных решений» вроде API через прерывания, управления адрессной линией A20, ресетов через порт клавиатуры и работы с таймером 8256. И производители CPU не могли выбросить никому уже не нужный полоработающий 16-разрядный режим потому, что загрузиться станет невозможно.
Да, за эти годы компьютер стал включаться несколько иначе, а с повсеместным внедрением Management Engine — принципиально иначе, только конечному пользователю это не видно и не интересно. И систему, на самом деле, удалось упростить, а не усложнить, вы просто не видели, что творилось внутри какого-нибудь AMIBIOS8 во времена чипсета P55.
По поводу незовможности загрузки альтернативных ОС из коментария ниже — управление ключами доступно, добавляй свои ключи, удаляй стандартные и будь уверен, что на твоей системе не запустится ничего, кроме того, что ты подписал своими руками. А у тех, кто управление ключами пользователю не дает, просто ничего покупать не нужно.
Да, за эти годы компьютер стал включаться несколько иначе, а с повсеместным внедрением Management Engine — принципиально иначе, только конечному пользователю это не видно и не интересно. И систему, на самом деле, удалось упростить, а не усложнить, вы просто не видели, что творилось внутри какого-нибудь AMIBIOS8 во времена чипсета P55.
По поводу незовможности загрузки альтернативных ОС из коментария ниже — управление ключами доступно, добавляй свои ключи, удаляй стандартные и будь уверен, что на твоей системе не запустится ничего, кроме того, что ты подписал своими руками. А у тех, кто управление ключами пользователю не дает, просто ничего покупать не нужно.
AMIBIOS8 времени g33 чипсета был очень даже читаемым, понятным и вылизанным. Если будет возможность — взгляните на Award времен 965 чипсета, страшные сны вам гарантированы.
Да мне и AMIBIOS8 хватило, доктор сказал «в морг» — значит в морг.
Люди, которые выше в коментариях пишут про «теплый ламповый простой и отлаженный BIOS» просто не видели, в какую вавилонскую башню из костылей и велосипедов он превратился в конце двухтысячных. Из UEFI я сейчас могу практически безболезненно выкинуть все, к чему у меня не лежит душа. Bosch не устраивает наличие SMM (он мешает работе hard-RTOS) — отключаем. Нам не нравится миллион способов прошивки, а нужно оставить один, но провереный — просто отключаем остальные. Понадобилось заменить чип SuperIO на другой — сменили пару DXE-драйверов и готово.
UEFI — это конструктор LEGO в мире прошивок, и каждый собирает из него то, что считает нужным.
Люди, которые выше в коментариях пишут про «теплый ламповый простой и отлаженный BIOS» просто не видели, в какую вавилонскую башню из костылей и велосипедов он превратился в конце двухтысячных. Из UEFI я сейчас могу практически безболезненно выкинуть все, к чему у меня не лежит душа. Bosch не устраивает наличие SMM (он мешает работе hard-RTOS) — отключаем. Нам не нравится миллион способов прошивки, а нужно оставить один, но провереный — просто отключаем остальные. Понадобилось заменить чип SuperIO на другой — сменили пару DXE-драйверов и готово.
UEFI — это конструктор LEGO в мире прошивок, и каждый собирает из него то, что считает нужным.
Не увидел в статье и комментариях: а с внешней клавиатурой грузиться пробовали? На встроенных и прочих «шибко вумных» возможна неработоспособность части клавиш до загрузки драйвера.
Славил похожую петлю на Sony Vaio с месяц назад. Спасло то, что по умолчанию всегда ставлю первой загрузку с Blu-Ray. Поставил Win10, с ней такой проблемы нет. Однако UEFI пока не обновлял, а надо бы.
Выше в комментариях пишут, что далеко не все обновления UEFI одинаково полезны.
Это да. Была у меня интересная ситуация во времена еще BIOS. Купил я как-то себе новую видеокарту. Загрузился в Windows, тогда еще, Me и снес видео драйвер. Радостный вынул из AGP слота старенький Radion и воткнул новую NVidia. Все нормально загрузилось, я поставил видео драйвер и решил проверить что еще можно обновить. Еще обновить можно было BIOS! Завершив обновление, система ушла в перезагрузи и… все! Черный экран! Даже в BIOS не войти. Не помню издавала ли материнская плата какие-нибудь звуки, но все выглядело так, что все, покупай новую. Не знаю почему, но я решил воткнуть старую видео карту и… о чудо! Все нормально загрузилось! Подумав, что возможно просто материнку надо было обесточить после прошивки (что и произошло перед тем, как сменить карту), я опять поменял карты и снова получил только черный экран. Загрузившись со старой картой, я откатил BIOS и больше на этой материнке его не обновлял.
Я посылаю лучи в сторону ASUS. Замечательно работали CPU i5-2500k и ASUS p8z68-v lx. Исчез у меня разгон по множителю — перестал выставляться выше 33.
В ASUS TurboV EVO пропал пункт CPU ratio. Когда пропал не знаю. Возможно когда-то обновлял БИОС, но разгон мне понадобился только сейчас. Но теперь процессор не множителем разгоняется. Нашел тему — похоже у меня такой случай. forum.ixbt.com/post.cgi?id=print:4:122531
Хочется с одной стороны вернуть 4,5 ГГц, а с другой стороны можно окирпичить. 3,7 ГГц по шине лучше, чем кирпич.
В ASUS TurboV EVO пропал пункт CPU ratio. Когда пропал не знаю. Возможно когда-то обновлял БИОС, но разгон мне понадобился только сейчас. Но теперь процессор не множителем разгоняется. Нашел тему — похоже у меня такой случай. forum.ixbt.com/post.cgi?id=print:4:122531
Хочется с одной стороны вернуть 4,5 ГГц, а с другой стороны можно окирпичить. 3,7 ГГц по шине лучше, чем кирпич.
Это МЕ чудит, а ASUS проблему так и не признала. Перешейте регион ME и все будет хорошо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Веселые кольца загрузки, или как с помощью недоработанной прошивки UEFI превратить ваш ноутбук в кирпич