> Да вообще-то проблема не в самом существовании фирмвари, а в закрытости её кода.Мне закрытый код тоже не нравится. Но если честно, догружаемое снаружи фирмваре в сервисный проц - далеко не самое великое зло в природе. Да, у зла еще и степени бывают, мир не черно-белый.
Если уж сравнивать, хак фирмвари накопителя в флешке (будь то винч или юсб флеха) мне как-то видится более вероятным и боле опасным чем то что фирма АМД от своего лица поимеет меня через официальные прошивки вспомогательных сервисных процессоров. Которые делались не для этого, на пути которых в основную систему может стоять IOMMU и вообще, ломать оттуда систему - столь же удобно и логично как вырезать гланды через ж..у автогеном. Какой-нибудь винч с фирмварой в флехе в этом плане намного более интересная мишень.
> спросить, закрыт ли код прошивки в процессорах AMD
Увы, закрыт. И документации на сервисные вспомогательные процы нет. Открыт код драйвера, работающий на основном системном проце. И кодогенератор для "основных" числокрушилок. Мир
> не идеален. и есть ли способ его скачать из процессора, чтобы сличить
> с официальной сборкой (такого, скорее всего, нет пока ни у кого в мире).
Во первых фирмвари бывают разные и их несколько. Например AtomBIOS у амд живет в флешке видеокарты. И рассказывает софту как работать с конкретно вот этой видеокартой. Сам по себе он вообще как таковой не выполняется. Это байткод виртуальной машины. Драйвер интерпретирует его и в результате узнает что надо сделать "чтобы сделать вот эту операцию". На самом деле этот процесс целиком контролирует хост и открытый драйвер и если какое-то действие делать не хочется - можно и не делать. Если это вызовет проблемы - ну, сами виноваты. А есть например кучка сервисных сопроцессоров. Например, управляющий питанием и вентилем. И иными аппаратными блоками. С ними фокус в том что им довольно часто нужны исправления фирмварей для исправления вылезших уже опосля штамповки железок багов. А вон например у новых APU - фирмвара нужна контроллеру памяти. Там мелкий процик, который делает link training и прочее детектирование параметров DDR3 независимо от системы. Система в этот момент трепыхаться может очень ограниченно (основной системной DRAM в этот момент еще нет!) и кодинг BIOS превращается в геморрой. Равно как и любое изменение параметров DRAM: одно неверное движение и ... поток кода шел из DRAM. Если там хоть что-то будет не идеально, выполнение мигом срубится. Играться с параметрами DRAM из кода который из DRAM же и работает - очень своеобразная затея. Ну а вот отдельный микроконтроллер с своей локальной памятью может пережить и какую-нибудь недоступность памяти при (пере)конфигурации, например. А когда начинает хотеться всякие там спячки и прочее, и чтоб быстро и без проблем - так вот постепенно оказывается что проще всего выпихнуть такие операции на отдельный мелкий сервисный процик. То же самое с продвинутым рулением питанием и прочая. Например питание у амд в видяхах и APU рулится как-то так: есть сервисный проц, они называют это SMC (system management controller, чтоли). Этот проц меряет фактическое потребление чипа, 100 раз в секунду. И фактическую загрузку блоков. По итогам принимает решение - куда менять частоты. В результате у GPU нет постоянной рабочей частоты - он порядка 100 раз в секунду адаптивно реклокается под фактическую нагрузку, отключать неиспользуемые блоки (power gating/clock gating). Ну а бонусом еще вентилятором может рулить, etc.Работает круто, быстро и относительно без проблем. И без сервисного проца все это не прокатит - системному софту напряжно 100 раз в секунду все бросать, да и это - достаточно жесткий реалтайм. Там критичны времена реакции и точность времянок. Ну а поскольку железка сложная и все это должно с драйвером взаимодействовать, получается что апдейты иногда может захотеться. И перешивать флеху с риском закирпичивания устройства - удовольствие ниже среднего. Да и флеха для впихивания ВСЕХ фирмварей нужна крупнее и дороже. Вот никто их ВСЕ туда и не пихает.
И если что - амдшники замочили несколько брутальных багов обновлением RAM-based прошивок сервисных процов. И перекачать файлик, предоставив моему ядру при следующей иницилизации девайса вкатить уже более новую фимрвару как-то лучше чем возиться с прошивкой, с риском закирпичить девайс. Ну так, с чисто практической точки зрения.
А еще с чисто практической точки зрения - не так уж плохо если амд отладит управление питанием на своем запасе чипов. А я не амд, если я там баг поймаю - это в хучшем случае покупка нового GPU (да, современное железо можно убить программно, в том числе глупым программированием вольтажей и частот).
