Пароль для UEFI чаще всего хранится в NVRAM, в переменной без флага RT, т.е. прочитать его через gRT->GetVariable не получится, но можно опробовать сделать полный дамп через системный SPI-интерфейс (необходимы права рута) и попытаться распарсить NVRAM и восстановить пароль, если он хранится не очень безопасным образом. Некоторые производители плат не доверяют «стандартному» механизму, и реализовывают хранение пароля средствами EC или крипточипа, другие закрывают область хранения пароля через Protected Range Registers от чтения/записи после окончания фазы DXE, в общем, если производитель платы хоть немного подумал в этом направлении — без физического доступа пароль так просто не сбросить.
Очень советую всем заинтересовавшимся темой замечательную книгу «Goedel, Escher, Bach: An Eternal Golden Braid», она же в русском переводе «Гёдель, Эшер, Бах — эта бесконечная гирлянда». Книга — просто ураган, особенно если читать ее вдумчиво. Фанатам музыки и математики к прочтению обязательна.
Нанять меня сейчас нельзя, а вот посоветовать пару хороших ISP-программаторов с поддержкой Linux/OSX я могу:
1. MiniPro TL866A, если не пугает его китайское происхождение. А еще для него есть качественный открытый софт.
2. Dediprog SF-100, если не пугает его цена. В Linux/OSX он поддерживается утилитой flashrom.
Я тестировал оба, и ни разу ни один из них не отказался шить чип, находящийся на плате, что нередко бывает на более дешевых программаторах.
Все отлично, кроме стоимости платформы — уж очень она кусается.
Планирую выпросить у Arrow вот такой кит для экспериментов, на первое время должно хватить.
Ребята из института, в котором я учился, реализовали похожий проект в 2007 году, там конечно не Arduino, а ПЛК, но суть такая же. Многие пробовали выиграть у этого автомата, но получалось, на моей памяти, всего у пары человек.
Очень хочется какую-нибудь System Studio Community Edition с поддержкой JTAG и EFI Debug хотя бы только для Galileo и Minnowboard, а то получается, что железо стоит 100 долларов, а ПО к нему — 2400.
Интересный материал, но тексты, написанные таким способом практическки невозможно читать, т.к. глаз "спотыкается" на каждом третьем слове. В ЛС не пишу потому, что хочу, чтобы и другие авторы статей Хабра задумались над иными приемами выделения ключевых слов в тексте. Заранее спасибо.
Пожалуйста, хорошо, что сейчас можно вот так просто взять и написать непосредственно разработчикам. Будете в офисе Congatec Deggendorf — заходите в отдел R&D, буду рад познакомиться лично.
Баг с локом не страшный, но неприятный, и проблема именно в его внезапности. Можно обновить glibc на непатченый и пару суток с ним работать без сбоев, а потом очередной вызов чего-нибудь из pthreads внезапно упадет и приехали. Я пробовал запустить Debian i386 через debootstrap, работает, но необходимость постоянно проверять, не пришел ли новый glibc с каждым обновлением — она напрягает, так что Yocto наше все в данный момент.
Еще одна хотелка, если можно: выложите Quark_EDK2 куда-нибудь на GitHub, чтобы можно было прозрачно его форкнуть, поправить и выслать пулл-реквест. А то, к примеру, все танцы вокруг spi-flash-tools и sysimage можно было бы пропустить, достаточно лишь правильно написать файл QuarkPlatformPkg/QuarkPlatformPkg.fdf. Я уже начал это делать для 4 части моей статьи, потому что разработка DXE-драйверов подразумевает постоянную пересборку образа UEFI, а проходить каждый раз через не самый простой процесс его сборки для Galileo, даже при наличии скрипта — то еще удовольствие.
Принимаю предложение немного похоливарить, тем более от разработчика.
1. Почему Yocto, а не что-то другое — это понятно. Во-первых, над Yocto у Intel больше контроля, согласовывать добавление/изменение/удаление каких-то пакетов ни с кем не нужно. А еще потому, что в Quark X1000 имеется баг обработки префикса lock, из-за которого практически все современные дистрибутивы Linux не могут нормально работать на нем из-за постоянных сегфолтов.
2. К сожалению, создается впечатление, что Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО. Или не хочет, тут уж я не могу сказать. Понятно, что основные деньги зарабатываются продажей железа, но разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная. Куда не ткнись по поводу поддержки ПО для Atom/Quark — везде затык. За один только EMGD иногда хочется убивать, а оно там все такое. Простой пример из недавнего: интерфейс MIPI CSI2 на Atom E38xx, которые так старательно рекламируют в Embedded-среде: «наш SoC его поддерживает, все работает, можете подключать свои камеры и сразу видеть результат.» Не указано только, что драйвер atomisp2 есть только для Yocto и Timesys Fedora 20, работает только с 32-битным ядром Linux 3.10 и поддерживает работу с ровно двумя камерами на 5 МП, которые, по невероятному стечению обстоятельств, и установлены на тестовой плате для CSI, а ее, в свою очередь, можно подключить только к CRB для Baytrail. В итоге я потратил неделю на то, чтобы заставить камеру работать через этот интерфейс хоть как-то, при том, что на iMX6 этот же интерфейс работает на любом современном Linux'е из коробки.
3. Почему Quark SoC имеет всего 16 линий GPIO на данный момент? Именно вследсвие этого пришлось ставить I2C port expander и делать всю совместимость с Arduino через него. Было бы достаточно GPIO — обошлись бы level shifter'ами.
4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
5. Зачем понадобилось вообще выпускать Quark в качестве отдельного SoC, какова его ниша в данный момент? Производительность меньше чем у RaspberryPi за 30$, x86 «не настоящий», интерфейсов для IoT любой Atom предоставляет больше, рекорды энергопотребления он тоже не бьет. Я понимаю, когда такое урезанное ядро используется как synthesable IP core внутри какого-нибудь Atom для поддержки TXE, но зачем его в таком виде на рынок выводить, кособокого и без GPU, да еще и рекламировать его как дверь в мир IoT, при том, что I2C (в виде SMBus) и SPI есть на любом CPU и SoC производства Intel последних 5 лет? А еще можно поставить на плату копеечный МК на Cortex-M и получить все то же самое, только дешевле и с лучшей поддержкой со стороны ПО.
Получилось немного сумбурно, прошу меня извинить, тоже редко пишу по-русски.
Хочу сказать огромное спасибо за открытый код UEFI для Galileo (как раз пишу цикл статей про него в данный момент: раз, два, три, четвертая часть на подходе), очень жду открытия UEFI для Minnowboard MAX, обещали в сентябре, но вмешались "unforseen changes". Спасибо также за первый на моей памяти JTAG TAP для x86 без NDA и за $20 вместо $5000, теперь можно писать и отлаживать baremetal OS, не заключая контрактов.
Удачи вам, всей IOTG и другим ребятам из ED. Ровно одно пожелание для всех вас от простого инженера: обратите внимание на поддержку своих продуктов со стороны ПО, желательно еще до их выхода. А то ведь Galileo уже почти год как выпущен, а репозиторий для opkg появился только сейчас, аппаратные интерфейсы на SoC есть — драйверов для них нет, и так далее. А то получается продуктивнее просто сказать, что на наших платах нет поддержки CSI2, CAN и HSUART, чем приводить их Proof-of-Concept-драйверы от Intel в пригодное для клиентов состояние. За любой сдвиг в этом направлении — охапку лучей добра вам заранее.
Собираю я тут небольшие утилиты на Qt, из которой используется только Core, GUI и Widgets. А еще я собираю UEFI-прошивки, UEFI-приложения и прочие вещи на основе UDK2014. Без студии все это вместе занимает примерно 2 Gb, поэтому 5-6Gb оверхеда — совершенно неприемлемо. Если у вас огромные диски — я за вас рад.
Очень важно. Представьте себе, скажем, ультрабук с 32GB SSD (да хоть Surface Pro), на котором хотелось бы иметь сборочную платформу, но не получается ровно потому, что полноценная VS2013 Pro туда просто не влезает.
Самое интересное, что эта возможность была в VS2010, даже отдельная редакция Visual C++ Express была, занимавшая что-то около гигабайта, но затем менеджмент решил, что пришла пора больших SSD и что каждому разработчику на C/C++ нужно дать в нагрузку еще и C#, и VB.NET, и SQL Server CE, и кучу всего остального, спасибо огромное, господа.
Замечательно. Вот только галочка Visual Studio core скачивает устанавливает ровно 221 пакет, которые занимают чуть меньше 9 гигабайт. Хорошая попытка, MS, но нет.
Один вопрос по поводу новой студии: опять нет выбора того, что устанавливать, а что не надо, и ради сборки проектов на C++ нужно ставить 10 гигабайт всяких эмуляторов Windows Phone и средств разработки для Web, которые не будут использоваться никогда?
В данный момент использую VS2013 Express for Windows Desktop ровно потому, что с ней ставится не так много хлама, как с полноценными версиями.
Если Вы можете себе представить грамотного толкового разработчика, способного сделать схему и отладить ее либо написать/портировать программу, но при этом не способного внятно и толково объяснить суть своей работы, основные принципы, положенные в основу и методы их реализации, причем обяснить как в виде выступления, так и в виде печатного выступления, то Ваша фантазия явно превосходит мою.
Мало что бывает фантастичнее, чем реальная жизнь. Если в вашем примере предположить, что толковый разработчик говорит и думает на испанском, а объяснить ему нужно немецким заказчикам за 60, которые плохо понимают по английски, причем желательно еще вчера и по телефону — получится ситуация, которую я иногда наблюдаю у себя в отделе. И ничего, справляемся.
Он может привести документацию в соответствие к некоторым требованиям по оформлению, но если Вы, как разработчик, невнятно описали логику работу узла устройства, он ничего не сможет сделать.
Логика работы узла описывается не словами, а чертежами и кодом, которые не нуждаются в переводе. Вся остальная документация, application notes, datasheets и прочее такое готовится инженерами совместно с отделом тестирования и отделом QA, и твое конкретно умение писать полезно, но решающим фактором не является. Не умеешь — поясни тому, кто умеет, вместе у вас все получится.
Моя основная мысль — не отрицая важности умения писать и взаимодействовать с людьми, нельзя требовать эти умения от инженера, иначе вам нужен уже не просто инженер, а мастер на все руки, за совсем другие деньги.
В серьезной дискуссии принято обсуждать сами идеи, а не носителей этих идей, будь они авторитетными или нет, так что будь он хоть новым Буддой — если он говорит очевидные вещи, он говорит именно их.
Новоиспеченные инженеры не умеют читать и писать потому, что на них есть спрос даже в таком виде. Не будет спроса — быстро научатся. Другой вопрос, что очень много инженерной работы требует в первую очередь хорошего знания предметной области, а затем уже социальных навыков и умения хорошо писать. На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума.
Я не пытаюсь умалить важность умения грамотно сделать презентацию или хорошо выступить перед аудиторией, но это все — скорее вишенка на торте, чем основные навыки инженера. В первую очередь, нужно уметь задачи решать в своей области, и у многих новоиспеченных инженеров проблемы как раз с этим.
На мой взгляд, инженерному образованию в России не хватает в первую очередь практики, обязательной для всех. Немецкие технические ВУЗы отправляются всех своих студентов на целый семестр практики, которую студенты проходят в реальных фирмах, занимаясь реальными задачами. Прямо сейчас в нашем отделе R&D работают 5 студентов: один портирует coreboot и SeaBIOS на наши платы, другой пишет библиотеку для взаимодействия с board features на C# и демо-программу для нее, третий занимается подбором подходящего чипа SuperIO для новых моделей процессоров без поддержки шины LPC, четвертый и пятый разрабатывают пост-кодер для USB Debug Port. Работают они наравне со всеми (за исключением количества часов в неделю), выступают на совещаниях, делают презентации, но в первую очередь — работают над своими проектами. И успех их, как инженеров, зависит именно от качества работы, а не от умения писать или делать презентации.
И оригинал — муть без капли нового смысла, «чтобы быть хорошим инженером, нужно уметь читать, писать и общаться с другими», но перевод — просто запредельный, и сверху еще сдобрен примечаниями переводчика. Ализар ушел на GT, но дело его живет.
BaS:Ep2 даже в 1998 mode слишком простой, ровно потому, что плазмид Peeping Tom с обоими улучшениями — OP. Активировать невидимость, дождаться противника, дать по голове ключом, смыть, повторить. Так проходится буквально вся игра, поэтому мне приходилось самому себе создавать challenge, чтобы играть было интереснее.
Добавлю как разработчик UEFI — аппаратной поддержки PIC для x86 очень не хватает. Для x64 такой код может быть сгенерирован компилятором, а для x86 его приходится либо писать на ассемблере, когда нельзя сделать его исполняемым на месте, либо вычислять реальный базовый адрес и патчить relocation table.
Мне наоборот кажется, что CD-эмулятор более универсален: грузит какие-угодно образы как при legacy-, так и при EFI-загрузке (описанная в после флешка — только legacy, для EFI придется ставить grub-efi и переделывать конфиг), внутрь можно поставить диск или SSD хоть на терабайт, и самое главное — в ODD-mode устройство получается read-only и никакие злобные вирусы ваше загрузочное устройство внезапно не отформатируют. Про удобство обновления образов выше уже написали. Недостаток эмулятора в том, что флешек разных много, а контролеры для эмуляторов делает, ЕМНИП, только iODD (Zalman продает их продукты под своим брендом на европейском рынке), поэтому если у вас неудачные BIOS/USB-контролер/карма — с эмулятора вы не загрузите ничего, а флешки можно перебирать, пока рабочая не найдется. Это не большая проблема для людей, не работающих с CRB, ES и прочими полуготовыми продуктами, но я с ней сталкиваюсь довольно часто, поэтому 100% заменой флешек эмулятор для меня пока не стал.
1. MiniPro TL866A, если не пугает его китайское происхождение. А еще для него есть качественный открытый софт.
2. Dediprog SF-100, если не пугает его цена. В Linux/OSX он поддерживается утилитой flashrom.
Я тестировал оба, и ни разу ни один из них не отказался шить чип, находящийся на плате, что нередко бывает на более дешевых программаторах.
Планирую выпросить у Arrow вот такой кит для экспериментов, на первое время должно хватить.
Баг с локом не страшный, но неприятный, и проблема именно в его внезапности. Можно обновить glibc на непатченый и пару суток с ним работать без сбоев, а потом очередной вызов чего-нибудь из pthreads внезапно упадет и приехали. Я пробовал запустить Debian i386 через debootstrap, работает, но необходимость постоянно проверять, не пришел ли новый glibc с каждым обновлением — она напрягает, так что Yocto наше все в данный момент.
Еще одна хотелка, если можно: выложите Quark_EDK2 куда-нибудь на GitHub, чтобы можно было прозрачно его форкнуть, поправить и выслать пулл-реквест. А то, к примеру, все танцы вокруг spi-flash-tools и sysimage можно было бы пропустить, достаточно лишь правильно написать файл QuarkPlatformPkg/QuarkPlatformPkg.fdf. Я уже начал это делать для 4 части моей статьи, потому что разработка DXE-драйверов подразумевает постоянную пересборку образа UEFI, а проходить каждый раз через не самый простой процесс его сборки для Galileo, даже при наличии скрипта — то еще удовольствие.
1. Почему Yocto, а не что-то другое — это понятно. Во-первых, над Yocto у Intel больше контроля, согласовывать добавление/изменение/удаление каких-то пакетов ни с кем не нужно. А еще потому, что в Quark X1000 имеется баг обработки префикса lock, из-за которого практически все современные дистрибутивы Linux не могут нормально работать на нем из-за постоянных сегфолтов.
2. К сожалению, создается впечатление, что Intel очень хорошо умеет делать железо, но не очень хорошо умеет делать ПО. Или не хочет, тут уж я не могу сказать. Понятно, что основные деньги зарабатываются продажей железа, но разница между Intel и другими специалистами рынка Embedded вроде TI или ST — огромная. Куда не ткнись по поводу поддержки ПО для Atom/Quark — везде затык. За один только EMGD иногда хочется убивать, а оно там все такое. Простой пример из недавнего: интерфейс MIPI CSI2 на Atom E38xx, которые так старательно рекламируют в Embedded-среде: «наш SoC его поддерживает, все работает, можете подключать свои камеры и сразу видеть результат.» Не указано только, что драйвер atomisp2 есть только для Yocto и Timesys Fedora 20, работает только с 32-битным ядром Linux 3.10 и поддерживает работу с ровно двумя камерами на 5 МП, которые, по невероятному стечению обстоятельств, и установлены на тестовой плате для CSI, а ее, в свою очередь, можно подключить только к CRB для Baytrail. В итоге я потратил неделю на то, чтобы заставить камеру работать через этот интерфейс хоть как-то, при том, что на iMX6 этот же интерфейс работает на любом современном Linux'е из коробки.
3. Почему Quark SoC имеет всего 16 линий GPIO на данный момент? Именно вследсвие этого пришлось ставить I2C port expander и делать всю совместимость с Arduino через него. Было бы достаточно GPIO — обошлись бы level shifter'ами.
4. Почему в Quark используется архитектура i586+, при всем том, что примерно 95% софта сейчас собираются для i686? В итоге потерялось едиственное преимущество x86 (кроме отлаженных драйверов для Linux) — обратная совместимость с уже собранным ПО. А если все равно нужно все пересобирать, то можно пересобрать и для ARM или MIPS.
5. Зачем понадобилось вообще выпускать Quark в качестве отдельного SoC, какова его ниша в данный момент? Производительность меньше чем у RaspberryPi за 30$, x86 «не настоящий», интерфейсов для IoT любой Atom предоставляет больше, рекорды энергопотребления он тоже не бьет. Я понимаю, когда такое урезанное ядро используется как synthesable IP core внутри какого-нибудь Atom для поддержки TXE, но зачем его в таком виде на рынок выводить, кособокого и без GPU, да еще и рекламировать его как дверь в мир IoT, при том, что I2C (в виде SMBus) и SPI есть на любом CPU и SoC производства Intel последних 5 лет? А еще можно поставить на плату копеечный МК на Cortex-M и получить все то же самое, только дешевле и с лучшей поддержкой со стороны ПО.
Получилось немного сумбурно, прошу меня извинить, тоже редко пишу по-русски.
Хочу сказать огромное спасибо за открытый код UEFI для Galileo (как раз пишу цикл статей про него в данный момент: раз, два, три, четвертая часть на подходе), очень жду открытия UEFI для Minnowboard MAX, обещали в сентябре, но вмешались "unforseen changes". Спасибо также за первый на моей памяти JTAG TAP для x86 без NDA и за $20 вместо $5000, теперь можно писать и отлаживать baremetal OS, не заключая контрактов.
Удачи вам, всей IOTG и другим ребятам из ED. Ровно одно пожелание для всех вас от простого инженера: обратите внимание на поддержку своих продуктов со стороны ПО, желательно еще до их выхода. А то ведь Galileo уже почти год как выпущен, а репозиторий для opkg появился только сейчас, аппаратные интерфейсы на SoC есть — драйверов для них нет, и так далее. А то получается продуктивнее просто сказать, что на наших платах нет поддержки CSI2, CAN и HSUART, чем приводить их Proof-of-Concept-драйверы от Intel в пригодное для клиентов состояние. За любой сдвиг в этом направлении — охапку лучей добра вам заранее.
Самое интересное, что эта возможность была в VS2010, даже отдельная редакция Visual C++ Express была, занимавшая что-то около гигабайта, но затем менеджмент решил, что пришла пора больших SSD и что каждому разработчику на C/C++ нужно дать в нагрузку еще и C#, и VB.NET, и SQL Server CE, и кучу всего остального, спасибо огромное, господа.
В данный момент использую VS2013 Express for Windows Desktop ровно потому, что с ней ставится не так много хлама, как с полноценными версиями.
Мало что бывает фантастичнее, чем реальная жизнь. Если в вашем примере предположить, что толковый разработчик говорит и думает на испанском, а объяснить ему нужно немецким заказчикам за 60, которые плохо понимают по английски, причем желательно еще вчера и по телефону — получится ситуация, которую я иногда наблюдаю у себя в отделе. И ничего, справляемся.
Логика работы узла описывается не словами, а чертежами и кодом, которые не нуждаются в переводе. Вся остальная документация, application notes, datasheets и прочее такое готовится инженерами совместно с отделом тестирования и отделом QA, и твое конкретно умение писать полезно, но решающим фактором не является. Не умеешь — поясни тому, кто умеет, вместе у вас все получится.
Моя основная мысль — не отрицая важности умения писать и взаимодействовать с людьми, нельзя требовать эти умения от инженера, иначе вам нужен уже не просто инженер, а мастер на все руки, за совсем другие деньги.
Новоиспеченные инженеры не умеют читать и писать потому, что на них есть спрос даже в таком виде. Не будет спроса — быстро научатся. Другой вопрос, что очень много инженерной работы требует в первую очередь хорошего знания предметной области, а затем уже социальных навыков и умения хорошо писать. На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума.
Я не пытаюсь умалить важность умения грамотно сделать презентацию или хорошо выступить перед аудиторией, но это все — скорее вишенка на торте, чем основные навыки инженера. В первую очередь, нужно уметь задачи решать в своей области, и у многих новоиспеченных инженеров проблемы как раз с этим.
На мой взгляд, инженерному образованию в России не хватает в первую очередь практики, обязательной для всех. Немецкие технические ВУЗы отправляются всех своих студентов на целый семестр практики, которую студенты проходят в реальных фирмах, занимаясь реальными задачами. Прямо сейчас в нашем отделе R&D работают 5 студентов: один портирует coreboot и SeaBIOS на наши платы, другой пишет библиотеку для взаимодействия с board features на C# и демо-программу для нее, третий занимается подбором подходящего чипа SuperIO для новых моделей процессоров без поддержки шины LPC, четвертый и пятый разрабатывают пост-кодер для USB Debug Port. Работают они наравне со всеми (за исключением количества часов в неделю), выступают на совещаниях, делают презентации, но в первую очередь — работают над своими проектами. И успех их, как инженеров, зависит именно от качества работы, а не от умения писать или делать презентации.