Вторая цитата — не совсем правда. Бесплатно предлагается только обновление существующей системы, при котором на сервере MS сохраняется слепок конфигурации машины, а ключ продукта остается тем, что устанавливается по умолчанию. В результате меняешь себе SSD и видеокарту — ставь сначала свою Windows 7 или 8 заново, потом обновляй ее снова на Windows 10, и тогда все это может быть снова активируется, если повезет.
Нормальный же лицензионный ключ для Windows 10 Pro без танцев с обновлениями и привязки к железу в европейском Windows Store стоит какие-то несчастные 240€, а на сайте MS — $199. Цены не космические, но и не бесплатно совсем.
Замечательная система, все в ней теперь есть: и кейлоггер («адаптивная система проверки орфографии»), и использование вашего подключения к сети для доставки обновлений другим ПК, и сбор личных данных («телеметрия», которую нельзя отключить полностью на всех редакциях, кроме Enterprise и Server), и автоматическая отправка ключа шифрования BitLocker в облако, и отправка данных геолокации по умолчанию, и неотключаемый антивирус («если мы вдруг заметили, что runtime-защита была отключена слишком долго, она будет включена автоматически»), и прочее такое. Мой внутренний параноик бьется в истерике.
Не могу сказать, что это все плохо — просто средний пользователь сам позволил себе такое вручить за свои же деньги, а параноики как сидели на OpenBSD, так и будут сидеть, но тенденция все равно печальная, на мой взгляд.
Большая часть проблем с оборудованием в любой приприетарной ОС решается засылом этого оборудования производителю ОС и дальнейшей совместной отладкой. Так делают все крупные игроки, и Intel, и MS, и WindRiver, и все остальные. Если вам действительно нужно и у вас контракт на тех. поддержку подписан давно и надолго — коммерческие компании вас один на один с проблемой не оставят.
Исходники никто не раздает, т.к. разбираться в них инженеры разработчиков железа не обязаны и не будут — они в нем не понимают ничего, в отличие от тех, кто его писал и поддерживает. Понятно, что сначала заставят прогнать тесты Hardware Certification Kit'а, потом будет пару недель переписки из серии «попробуйте выключить и включить», но по итогу все проблемы, которые были у нас поддержкой оборудования со стороны MS удалось успошно решить.
Хитро придумано: почти 40 часов (неделя) неоплачиваемого рабочего времени разработчика, потраченная на то, чтобы в итоге а) бесплатно наштормить идей для компании, б) бесплатно наделать прототипов для компании, в) выиграть шахматы, которые тот же самый разработчик мог бы купить на свою З/П за час. Извините, но нет.
А что с ними, номера команд отличаются от общепринятых?
Если так, что можно модифицировать код проекта ch341prog и выслать pull request. А еще лучше написать ребятам из проекта flashrom о том, что очень хотелось бы видеть этот чип в списке поддерживаемых, есть шанс, что они услышат.
Из моих статей переехали вот эти две (раз и два), и только потому, что они были в DIY. Каким боком они про гаджеты — я не знаю, если программаторы и JTAG-отладчики считать ими, то тогда сразу записываем в гаджеты FPGA промышленные за мегатонну денег, и ПЛК, и SDN-железки, и все железное вообще, от Arduino до LHC.
Идея переноса технических железных статей хабов с Хабра — дрянь, многие просто перестанут их писать, и я в том числе.
Теперь только UEFI на эмуляторе, и не дай рандом упомянуть, что прошивка выполняется на голом железе — мигом на ГТ переедешь.
В наличии с сайта производителя или отдельно (нужно будет включить kext-dev-mode в 10.10), упомянутые в статье утилиты ch341* должны собираться и работать и в OSX, но я этот момент не проверял.
Можно попробовать TinyBitBang, но в ней I2C реализован через ногодрыг, и потом работает медленнее, чем аппаратные реализации, но зато даже на FT232RL и прочих копеечных FTDI'шках без MPSSE.
Пропустил статью, пока был в отпуске, наверстываю. Есть SMM и на Atom, и на Quark, ибо кое-где он реально нужен. Используется SMM для эмуляции legacy USB, поддержки USB-клавиатур и мышей в DOS, обновления компонентов прошивки (доступ к SPI flash возможен только из SMM при правильной реализации защиты прошивки от переписывания вредоносным кодом), эмуляции отсутствующих и исправления неверно реализованных IO-портов (т.н. IO Trap), иногда используется для независимого от ОС управления сложной периферией вроде EC. Если это все не нужно, зато нужен риалтайм — SMM можно отключить полностью, для этого достаточно посадить линию SMI# процессора на землю, снять все биты регистра SMI_EN (отключив таким образом все источники программных SMI) и поставить бит SMI_LOCK, чтобы злоумышленник не смог включить все обратно. У нас есть разработанные по заказу Bosch варианты наших плат с уменьшенными задержками, отключенным энергосбережением и управлением питанием, полностью отключенным SMM и другими мелкими изменениями, помогающими использовать RTOS на x86.
Потому, что для UEFI закрытый код инициализации памяти и чипсета поставляется в составе платформы AMI Aptio, доступ к которой у нас имеется, а в случае coreboot инициализацию выполняет открытый код, написанный сообществом в результате реверс-инжениринга и потому не всегда работающий правильно. Да и избавиться от проприетарных компонентов не получится даже с coreboot, все равно нужны и ME, и VBIOS, на использование которых все равно придется купить у Intel лицензию.
Не думаю. Если реализаций не появится — ненужные части просто выкинут, как это уже случилось с «хвостатыми» файлами в при переходе с FV Rev1 к FV Rev2. Наличие стандарта (даже если он всеобъемлющий и непонятный) гарантирует интероперабельность при условии, что реализации следуют букве этого самого стандарта. На данный момент в реализациях UEFI 2.4 замечательно работают драйверы, написанные для EFI 1.01, хотя их и рекомендуется переписать под новую Driver Model, чтобы они были меньше и загружались быстрее. EFI-приложения, не использующие вендорские расширения, запускаются и работают на реализациях UEFI любого производителя (проверял лично на реализациях AMI, Phoenix, Insyde и Intel). С пониманием там тоже не должно быть больших проблем, я думаю. Да, стандарт достаточно объемный, но основные идеи (как устроены драйверы, что такое протоколы, как вызвать общий код, как сохранить свои данные и т.п) намного проще, чем интерфейс через прерывания и IO-порты, которым грешил legacy BIOS.
Мне тоже не нравится тот факт, что фичи постоянно добавляют, а баги в реализациях чинят не очень резво, но сделать с этим фактом я могу только одно — не пихать в свои БИОСы бездумно все подряд, до чего появился доступ, ведь чем меньше кода в прошивке, тем там меньше багов. К сожалению, такое мнение среди «обычных пользователей» не слишком популярно, им нужен графический Setup с красивой картинкой на фоне и прочий stuff. И загрузка чтобы без PXE-костылей. И дуалбут в Android. И черта в ступе еще. Пока такой подход позволяет продать больше плат, чем конкуренты — процесс добавления фич не остановить.
UEFI — это пока еще не ОС в привычном понимании термина, это скорее очень продвинутый аналог HAL. На ОС становится похожа его комбинация с UEFI Shell, вот её уже можно назвать однозадачной дисковой ОС с прямым доступом к ресурсам, таким себе новым DOS без костылей времен Очакова.
Добавление загрузки по HTTP объяснимо и ожидаемо, ведь хоть какой-нибудь HTTP-сервер имеется почти в каждой внутренней сети, и просто положить в /boot/bootx64.efi файл с загрузчиком намного проще, чем поднимать TFTP-сервер, настраивать специальным образом DHCP так, чтобы от отвечал на PXE-запросы и собрать загрузчик для 16-битного реального режима, не забыв проследить, чтобы его размер не превысил доступные 0x20000 байт.
Туда он свернул или не туда — посмотрим лет через 10-15, сейчас же в каждом новом стандарте просто добавляют очередную нужную фичу, показавшуюся полезной участникам UEFI Forum. К счастью, большая часть этих фич не является обязательно к реализации, и некоторые «темные углы» стандарта EFI 1.01 так и не реализованы до сих пор. UEFI хорош тем, что если какая-то его часть мне особенно не нравится — я ее просто не собираю и все. К примеру, мне не нравится стандартный механизм Capsule Update, и в моих реализация функциих UpdateCapsule и QueryCapsuleCapabilities просто возвращают EFI_UNSUPPORTED. Кому-то не нравится SMM, кому-то другому — RW и RO-данные в одной микросхеме, но все эти вопросы решаемые и разные части стандарта не приколочены друг к другу намертво. UEFI похож на конструктор, каждый собирает из него то, что считает нужным.
Сложно сравнивать, это проекты разных весовых категорий. С одной стороны у нас UEFI Forum из Intel/AMD/MS/HP/Dell/etc., а с другой — небольшая группа энтузиастов и примкнувший к ним Google, использующий coreboot на Chromebook. Для UEFI есть «раздутый и чрезмерно усложненный», но открытый стандарт, документация, бесплатные инструменты для проверки на соответсвие реализации стандарту, открытый SDK и т.п., для coreboot есть только код, немного документации, немного вики-страниц с coreboot.org и громадный mailing list. Более того, coreboot, по сути, отвечает только за очень раннюю инициализацию системы, это аналог PEI в UEFI, а все остальное предлагается делать через payload, которым может быть либо ядро ОС (как у Google, если нужен single OS PC — самое то), либо «эмулятор» легаси БИОСа SeaBIOS, либо даже реализация UEFI из TianoCore.
Я не работал с coreboot напрямую, но участвовал на правах «мимокрокодила» в проекте проходящего у нас практику студента, который занимался адаптацией coreboot под наши платы. За 8 месяцев работы по 4-5 часов в день у него получилось загрузить Linux в качестве payload на 3 платах из 5, Windows 7 через SeaBIOS на тех же трех, но работала ОС нестабильно, а на двух оставшихся платах coreboot так и не смог инициализировать DRAM правильно, несмотря на все танцы с бубном и помощь двух не самых глупых инженеров. И наблюдений я делаю вывод, что coreboot в данный момент хорошо подходит для какого-то вполне опредленного нишевого железа (как хромобуки или индустриальные ПК), но со всеми проблемами с инициализацией, стартом и работой системы придется разбираться самому, поддержка сообщества быстро сведется к shut up and hack. Пока Google не начнет продавать support plan'ы для coreboot, нам делать на нем что-то — слишком большой риск, есть шанс не вылезти из отладки.
С моей точки зрения пользователю тоже стало чуть проще, хоть и немного непривычно, но это ощущение может быть вызвано банальной профдеформацией.
Если не лезть под капот, то UEFI для пользователя отличается тем, что там GPT/ESP вместо MBR, загрузчик больше не 16-битный, нет 2Тб-ограничения на размер дисков и Setup выглядит более модным. Пользователи чуть продвинутее замечают, что настройки из CMOS memory теперь дополнены громандым куском NVRAM, порядок загрузки устройств теперь задать сложнее и загрузка по типу (т.е. не «вот это загрузчик», а «USB HDD») теперь не доступна по умолчанию (эта фича старых БИОСов оказалась настолько полезна клиентам, что нам пришлось реализовать ее еще в 2011 году, а в 2014 я переписывал реализацию с нуля, т.к. в UEFI 2.4 старый подход перестал работать). Плюс проблема root-of-trust более или менее решилась, а на замену древнего DOS для прямого доступа к системе пришел UEFI Shell. Стало ли все это усложнением для пользователя — возможно, я не знаю. Но усложнив в одном месте, сильно упростили в другом, и теперь не нужно править MBR, чтобы новый загрузчик на диск дописать, или устраивать ресет ОС выводом в порт клавиатуры, которого давно уже на самом деле нет, но БИОС вынужден был его эмулировать.
Да, нетребовательность линукса к ACPI позволяет этот самый код ACPI отлаживать в нем без особого бубна. Я бы не назвал ACPI самым худшим стандартом (IEEE 1149.7 уверенно держит марку, на мой взгляд), но и хорошим его пока нызвать тоже рано. Будем посмотреть, возможно руками UEFI Forum из ACPI получится сделать что-то удобоваримое.
Тем не менее, даже с опцией acpi=off ядро успешно загружается и работает. И то, что Linux не использует «свой» набор данных из метода _OSI — это факт.
Про «на отвяжись» я уже однажды на ГТ писал:
Примерно 80% ASL-кода пишется производителем CPU (которому плевать на warning'и), еще по 10% — IBV и конечным вендором (и будь они хоть кем, их код — капля в море). Да и если большая часть современных ОС на недоработки ACPI все равно плевать хотела (а серьезно пользуется им только OSX), то и отношение к технологии — соответствующее. Пока оно работает хоть как-то — никто ничего трогать не будет, работы хватает и без этого.
Ситуация понемногу улучшается, но медленно. Посмотрим, что будет в новых прошивках.
От использования любых других компиляторов кроме Intel IASL отказались пару лет назад, когда стандарт ACPI был передан UEFI Forum на сопровождение. А после внедрения ASL 2.0 этот компилятор — вообще единственный, который способен собрать из нового кода что-то работающее.
Расскажу вам как разработчик UEFI, что вот этот «убогий сине-белый набор менюшек в текстовом режиме» превосходит по стабильности и отлаженности графический сетап на порядок. И работает даже в text mode, когда с VBIOS или GOP-драйвером что-то стряслось. И serial redirection в нем работает замечательно, а не как попало. И ломаться там почти нечему, ибо 90% кода уже лет 5 входит в состав открытого проекта TianoCore.
UEFI — это не сетап и не менюшки, это в первую очередь интерфейс для драйверов и загрузчиков, свободный груза легаси-костылей времен царя Гороха, способный не загружать неподписанные option ROM'ы и выступать в качестве root-of-trust для ОС.
Нормальный же лицензионный ключ для Windows 10 Pro без танцев с обновлениями и привязки к железу в европейском Windows Store стоит какие-то несчастные 240€, а на сайте MS — $199. Цены не космические, но и не бесплатно совсем.
Не могу сказать, что это все плохо — просто средний пользователь сам позволил себе такое вручить за свои же деньги, а параноики как сидели на OpenBSD, так и будут сидеть, но тенденция все равно печальная, на мой взгляд.
Исходники никто не раздает, т.к. разбираться в них инженеры разработчиков железа не обязаны и не будут — они в нем не понимают ничего, в отличие от тех, кто его писал и поддерживает. Понятно, что сначала заставят прогнать тесты Hardware Certification Kit'а, потом будет пару недель переписки из серии «попробуйте выключить и включить», но по итогу все проблемы, которые были у нас поддержкой оборудования со стороны MS удалось успошно решить.
Если так, что можно модифицировать код проекта ch341prog и выслать pull request. А еще лучше написать ребятам из проекта flashrom о том, что очень хотелось бы видеть этот чип в списке поддерживаемых, есть шанс, что они услышат.
Идея переноса технических железных статей хабов с Хабра — дрянь, многие просто перестанут их писать, и я в том числе.
Теперь только UEFI на эмуляторе, и не дай рандом упомянуть, что прошивка выполняется на голом железе — мигом на ГТ переедешь.
Мне тоже не нравится тот факт, что фичи постоянно добавляют, а баги в реализациях чинят не очень резво, но сделать с этим фактом я могу только одно — не пихать в свои БИОСы бездумно все подряд, до чего появился доступ, ведь чем меньше кода в прошивке, тем там меньше багов. К сожалению, такое мнение среди «обычных пользователей» не слишком популярно, им нужен графический Setup с красивой картинкой на фоне и прочий stuff. И загрузка чтобы без PXE-костылей. И дуалбут в Android. И черта в ступе еще. Пока такой подход позволяет продать больше плат, чем конкуренты — процесс добавления фич не остановить.
Добавление загрузки по HTTP объяснимо и ожидаемо, ведь хоть какой-нибудь HTTP-сервер имеется почти в каждой внутренней сети, и просто положить в /boot/bootx64.efi файл с загрузчиком намного проще, чем поднимать TFTP-сервер, настраивать специальным образом DHCP так, чтобы от отвечал на PXE-запросы и собрать загрузчик для 16-битного реального режима, не забыв проследить, чтобы его размер не превысил доступные 0x20000 байт.
Туда он свернул или не туда — посмотрим лет через 10-15, сейчас же в каждом новом стандарте просто добавляют очередную нужную фичу, показавшуюся полезной участникам UEFI Forum. К счастью, большая часть этих фич не является обязательно к реализации, и некоторые «темные углы» стандарта EFI 1.01 так и не реализованы до сих пор. UEFI хорош тем, что если какая-то его часть мне особенно не нравится — я ее просто не собираю и все. К примеру, мне не нравится стандартный механизм Capsule Update, и в моих реализация функциих UpdateCapsule и QueryCapsuleCapabilities просто возвращают EFI_UNSUPPORTED. Кому-то не нравится SMM, кому-то другому — RW и RO-данные в одной микросхеме, но все эти вопросы решаемые и разные части стандарта не приколочены друг к другу намертво. UEFI похож на конструктор, каждый собирает из него то, что считает нужным.
В русскоязычных интернетах так мало информации, к сожалению, что даже банальный пересказ ченджлога становится статьей.
Я не работал с coreboot напрямую, но участвовал на правах «мимокрокодила» в проекте проходящего у нас практику студента, который занимался адаптацией coreboot под наши платы. За 8 месяцев работы по 4-5 часов в день у него получилось загрузить Linux в качестве payload на 3 платах из 5, Windows 7 через SeaBIOS на тех же трех, но работала ОС нестабильно, а на двух оставшихся платах coreboot так и не смог инициализировать DRAM правильно, несмотря на все танцы с бубном и помощь двух не самых глупых инженеров. И наблюдений я делаю вывод, что coreboot в данный момент хорошо подходит для какого-то вполне опредленного нишевого железа (как хромобуки или индустриальные ПК), но со всеми проблемами с инициализацией, стартом и работой системы придется разбираться самому, поддержка сообщества быстро сведется к shut up and hack. Пока Google не начнет продавать support plan'ы для coreboot, нам делать на нем что-то — слишком большой риск, есть шанс не вылезти из отладки.
Если не лезть под капот, то UEFI для пользователя отличается тем, что там GPT/ESP вместо MBR, загрузчик больше не 16-битный, нет 2Тб-ограничения на размер дисков и Setup выглядит более модным. Пользователи чуть продвинутее замечают, что настройки из CMOS memory теперь дополнены громандым куском NVRAM, порядок загрузки устройств теперь задать сложнее и загрузка по типу (т.е. не «вот это загрузчик», а «USB HDD») теперь не доступна по умолчанию (эта фича старых БИОСов оказалась настолько полезна клиентам, что нам пришлось реализовать ее еще в 2011 году, а в 2014 я переписывал реализацию с нуля, т.к. в UEFI 2.4 старый подход перестал работать). Плюс проблема root-of-trust более или менее решилась, а на замену древнего DOS для прямого доступа к системе пришел UEFI Shell. Стало ли все это усложнением для пользователя — возможно, я не знаю. Но усложнив в одном месте, сильно упростили в другом, и теперь не нужно править MBR, чтобы новый загрузчик на диск дописать, или устраивать ресет ОС выводом в порт клавиатуры, которого давно уже на самом деле нет, но БИОС вынужден был его эмулировать.
Про «на отвяжись» я уже однажды на ГТ писал:
Ситуация понемногу улучшается, но медленно. Посмотрим, что будет в новых прошивках.
От использования любых других компиляторов кроме Intel IASL отказались пару лет назад, когда стандарт ACPI был передан UEFI Forum на сопровождение. А после внедрения ASL 2.0 этот компилятор — вообще единственный, который способен собрать из нового кода что-то работающее.
UEFI — это не сетап и не менюшки, это в первую очередь интерфейс для драйверов и загрузчиков, свободный груза легаси-костылей времен царя Гороха, способный не загружать неподписанные option ROM'ы и выступать в качестве root-of-trust для ОС.