Кнопки, которые есть, но не используются лично вами, значительно лучше, чем те, которые вам нужны, а их нет. Вы пользуетесь Pause, Print Screen /SysRq или Scroll Lock? А я пользуюсь каждый день, и если их на клавиатуре нет — это повод достать нормальную клавиатуру.
Добавлю, что там еще и прошивка — полный хлам, застрявший на уровне 2007 года. BootGuard'а нет, SMM нет, SecureBoot'а нет, защиты от вредоносных OROM'ов нет, TPM не поддерживается. Да, у них теперь есть пара очень хороших специалистов по безопасности прошивки, но там, как в старом анекдоте, «всю систему надо менять».
Если получится запустить из OROM, будет совсем хорошо, спасибо за попытку заранее.
По руссификации — не сталкивался с этой задачей, но думаю, что пары протоколов будет достаточно (знать бы только каких именно...). В крайнем случае, интерфейс можно весь в графической консоли битмапами рисовать, как в старые добрые времена.
В данном случае, это все же больше для скриншотов, чем для примера.
Интересущихся «вирусами» советую посмотреть код SMM Backdoor уважаемого d_olex, и его запись в блоге о разработке этого бэкдора.
И тогда этих EbcDxe тоже надо с собой носить по количеству архитектур. Если основной драйвер огромный (UGA/GOP-драйвер для Radeon for MAC, к примеру), то есть смысл собрать его в EBC и носить с собой пригоршню интерпретаторов на каждый случай, а вот для таких поделок в 3 экрана EBC — только лишний оверхед.
Просто потому, что в игры играют миллионы, а настройками BIOS Setup делятся десятки. Денег на этой фиче не заработать, только из за нее плату у тебя, а не у конкурента, никто не купит — т.е. для производителя смысла в этой фиче почти нет. Мне она понадобилась — вот я ее и написал.
Что мешает — да ничего, собственно. ASUS, к примеру, давно уже позволяет сохранить по F12 скриншот BIOS Setup в формате BMP. Почему это до сих пор не внедрено в массы — черт его знает, разработчики не видят необходимости (у них перенаправление текстовой консоли есть, его хватает в 95% случаев), менеджеры никогда не работали с BIOS Setup и не знаю про него ничего, а пользователи не могу достучаться до людей, принимающих решения, через три линии «технической поддержки».
Придется держать отдельные версии в любом случае — исполнитель EBC стартует в начале фазы DXE, а там еще до этого две фазы на полмегабайта кода суммарно, которые делают всю черную работу по инициализации процессора, кэша L2, оперативной памяти и других жезненно необходимых устройств. Это все на EBC не напишешь, как не крутись.
Драйверы те написаны на тулките GNU-EFI и тоже собираются по экземпляру для каждой архитектуры, на данный момент только для x86 и amd64.
Большое пожалуйста.
Драйвер собирается для целевой архитектуры и для разных архитектур нужны разные драйверы. По идее, есть возможность собрать DXE-драйвер в байткод EBC, но, во-первых, далеко не во всех прошивках есть драйвер для исполнения этого байткода (зовут его EbcDxe, можете открыть свою прошивку в UEFITool и поискать такой), во-вторых, сам этот исполнитель пока собирается только для IA32, AMD64 и IA-64, т.е. ARM, MIPS и PPC все равно в пролете, в-третьих, компилятор в EBC стоит денег, а бесплатно можно только писать непосредственно на байткоде, как это делает icbook.
В общем, намного проще собрать несколько платформо-зависимых драйверов и рядом их положить, места сейчас для OptionROM хватает, а для обычной прошивки кроссплатформенность вообще не нужна, если процессор вдруг не поменятся с x86 на ARM (у AMD были планы сделать попиново совместимые процессоры с различными ядрами, но от них отказались, и правильно, на мой взгляд).
Я подпишусь не только на UEFI, но на нее — в первую очередь. И я хочу, чтобы статья целиком про UEFI была хотя-бы в хабе firmware, а не просто в «системном программировании», которое слишком общее, и к которому можно подвести разработку собственной ОС, и написание драйверов для FUSE, и обзор новых WinAPI.
Замените в своем комментарии UEFI на Derby.js и получится то же самое по смыслу — а хаб отдельный для нее есть.
Пиши сюда в «системное программирование», как и предлагается, и пусть вылезает все, что нужно. И аудитория найдется, если в пятницу вечером не публиковать.
А теги у вас перестали работать потому, что кто-то поставил вам в карму минус, а контр-плюс туда поставить невозможно, т.к. у вас нет публикаций. Скажите, вас это сильно мотивирует взять и написать отличную статью прямо сегодня? А ведь задумка была именно такая, ЕМНИП.
Добавлю еще, что невозможность поставить плюс в карму пользователю без статей на корню убило такое явление как «комментарий полезнее поста». Примеров тьма, вот JerleShannara — человек пишет о своем опыте работы с прошивками, с BIOS, с coreboot, оставляет полезные комментарии, а поставить ему плюс в карму я не могу, у него, видите ли, нет публикаций. Т.к. минус поставить можно, то такие пользователи рано или поздно оказываются в режиме «один комментарий в час» и уходят с Хабра. Эта политика не мотивирует к написанию новых постов, уважаемое НЛО. Сделайте с ней что-нибудь, прошу.
Хабр снова торт! Спасибо большое за статью.
Сталкивался с SystemC во время учебы, и тогда он показался достаточно интересным, но проблемы с открытыми (или хотя бы дешевыми) утилитами для синтеза останавливали. Видно, что с тех пор прогресс ушел далеко вперед, но утилит таких по прежнему нет — печально.
Обычный юзер-анонимус никому не интересен — денег с него взять не получится, т.к. свобода продается очень плохо, а пока ты занимаешься открытием свой платформы, согласованием открытия документации с производителями процессоров, памяти и контролера клавиатуры, конкуренты успевают выпустить две-три линейки продуктов и оставить тебя наедине с устаревшим уже на старте продаж железом и двумя с половиной потенциальными покупателями из числа фанатов свободы и всего такого. Обычный же пользователь и сам добровольно идет в walled garden, и друзей туда тащит, постоянные рекорды продаж Apple — тому ярчайший пример.
О втором. Для вендоров из Embedded и Industrial AMD гарантирует десятилетний срок поддержки и выпуска чипов, пусть и не очень крупными партиями. eKabini вышел в 2014, соответственно EOL он получит в 2024, и еще пару лет можно жить на старых запасах.
Этот процессор — последний x86, у которого нет «ядра обеспечения безопасности» с подписанным БЛОБом в качестве прошивки и полным отсутсвием документации на него в открытом доступе.
И не такое переписывали, и если сильно захотеть — можно в космос полететь, так что за SMU я сильно не переживаю, особенно после вот этой презентации (она же на видео).
С PSP я воюю прямо сейчас на Merlin Falcon, и он меня уже достал. Не могу ничего рассказать толком, NDA, но по сравнению с eKabini, где никаких танцев вокруг PSP не было — жизнь простого инженера стала с ним значительно сложнее, особенно если в его firmware виден баг, а ты даже сделать с этим ничего не можешь, кроме как репортить в AMD и ждать неизвестно сколько, пока в очередном обновлении AGASE/PI это баг не починят.
По руссификации — не сталкивался с этой задачей, но думаю, что пары протоколов будет достаточно (знать бы только каких именно...). В крайнем случае, интерфейс можно весь в графической консоли битмапами рисовать, как в старые добрые времена.
Интересущихся «вирусами» советую посмотреть код SMM Backdoor уважаемого d_olex, и его запись в блоге о разработке этого бэкдора.
Драйверы те написаны на тулките GNU-EFI и тоже собираются по экземпляру для каждой архитектуры, на данный момент только для x86 и amd64.
Драйвер собирается для целевой архитектуры и для разных архитектур нужны разные драйверы. По идее, есть возможность собрать DXE-драйвер в байткод EBC, но, во-первых, далеко не во всех прошивках есть драйвер для исполнения этого байткода (зовут его EbcDxe, можете открыть свою прошивку в UEFITool и поискать такой), во-вторых, сам этот исполнитель пока собирается только для IA32, AMD64 и IA-64, т.е. ARM, MIPS и PPC все равно в пролете, в-третьих, компилятор в EBC стоит денег, а бесплатно можно только писать непосредственно на байткоде, как это делает icbook.
В общем, намного проще собрать несколько платформо-зависимых драйверов и рядом их положить, места сейчас для OptionROM хватает, а для обычной прошивки кроссплатформенность вообще не нужна, если процессор вдруг не поменятся с x86 на ARM (у AMD были планы сделать попиново совместимые процессоры с различными ядрами, но от них отказались, и правильно, на мой взгляд).
Замените в своем комментарии UEFI на Derby.js и получится то же самое по смыслу — а хаб отдельный для нее есть.
Сталкивался с SystemC во время учебы, и тогда он показался достаточно интересным, но проблемы с открытыми (или хотя бы дешевыми) утилитами для синтеза останавливали. Видно, что с тех пор прогресс ушел далеко вперед, но утилит таких по прежнему нет — печально.
Этот процессор — последний x86, у которого нет «ядра обеспечения безопасности» с подписанным БЛОБом в качестве прошивки и полным отсутсвием документации на него в открытом доступе.
С PSP я воюю прямо сейчас на Merlin Falcon, и он меня уже достал. Не могу ничего рассказать толком, NDA, но по сравнению с eKabini, где никаких танцев вокруг PSP не было — жизнь простого инженера стала с ним значительно сложнее, особенно если в его firmware виден баг, а ты даже сделать с этим ничего не можешь, кроме как репортить в AMD и ждать неизвестно сколько, пока в очередном обновлении AGASE/PI это баг не починят.