amd-ucode.img amd_ucode.img ...

akorop	# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)
Темы: 111 Сообщения: 1755 Участник с: 29 февраля 2012	Ковыряясь с построением загрузочных iso, я наткнулся на непонятную (для меня) штуку. По порядку. В репозитарии имеются пакеты amd-ucode и intel-ucode, которые помещают в /boot файлы amd-ucode.img и intel-ucode.img (именно с такими именами, с минусом). grub-mkconfig "подхватывает" такие файлы, и наличие в комстроке загруки их обоих, вроде, ничему не вредит. В "живых" Arch-based iso в комстроке загрузки фигурируют файлы amd_ucode.img и intel_ucode.img, притом оба. И во многих не-Arch живых iso, судя по конфигам autoiso, используются тоже такие имена (с подчёркиванием), то есть это типа стандарт de facto. После загрузки с живых iso и после установки с них на винт зачастую в /boot нет ни одного из этих файлов, хотя пакеты amd-ucode и intel-ucode числятся установленными. (Например, так обстоит дело в ArchBang, и, кажется, в IceArch). В чём глубокий смысл этих перименований, и что это за интересный стиль - втихую удалять файлы, принадлежащие установленным пакетам? И что за дикое сочетание - на DVD/USB в безусловно пытаться грузить эти файлы, а в установленной системе - безусловно обходиться без них? Так нужны они или нет? Похоже,что всё это - шедевр костылестроения. Чей и какой баг всё это призвано обходить, и в наличии ли этот баг сейчас? (Часто бывает, что бага давно нет, а костыли обросли мясом и остались навечно).

# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)

Сообщения: 1755

Участник с: 29 февраля 2012

Ковыряясь с построением загрузочных iso, я наткнулся на непонятную (для меня) штуку. По порядку.

В репозитарии имеются пакеты amd-ucode и intel-ucode, которые помещают в /boot файлы amd-ucode.img и intel-ucode.img (именно с такими именами, с минусом).
grub-mkconfig "подхватывает" такие файлы, и наличие в комстроке загруки их обоих, вроде, ничему не вредит.
В "живых" Arch-based iso в комстроке загрузки фигурируют файлы amd_ucode.img и intel_ucode.img, притом оба. И во многих не-Arch живых iso, судя по конфигам autoiso, используются тоже такие имена (с подчёркиванием), то есть это типа стандарт de facto.
После загрузки с живых iso и после установки с них на винт зачастую в /boot нет ни одного из этих файлов, хотя пакеты amd-ucode и intel-ucode числятся установленными. (Например, так обстоит дело в ArchBang, и, кажется, в IceArch).

В чём глубокий смысл этих перименований, и что это за интересный стиль - втихую удалять файлы, принадлежащие установленным пакетам?
И что за дикое сочетание - на DVD/USB в безусловно пытаться грузить эти файлы, а в установленной системе - безусловно обходиться без них? Так нужны они или нет?
Похоже,что всё это - шедевр костылестроения. Чей и какой баг всё это призвано обходить, и в наличии ли этот баг сейчас? (Часто бывает, что бага давно нет, а костыли обросли мясом и остались навечно).

vs220	# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)
Темы: 22 Сообщения: 8070 Участник с: 16 августа 2009	Эти файлы если прописаны в загрузке обновляют микрокод процессора. Если не прописать то просто старый используется. А название все равно какое стандарта жесткого по видимому нет

vs220	# 2 года, 6 месяцев назад
Темы: 22 Сообщения: 8070 Участник с: 16 августа 2009	https://wiki.archlinux.org/index.php/Microcode

nafanja	# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	по поводу минуса вместо подчеркивания, а ты много видел подчеркиваний в именах файлов в Арче? это я к тому что скорей всего для однородности где это возможно... Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

по поводу минуса вместо подчеркивания, а ты много видел подчеркиваний в именах файлов в Арче? это я к тому что скорей всего для однородности где это возможно...

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

vasek	# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	akorop После загрузки с живых iso и после установки с них на винт зачастую в /boot нет ни одного из этих файлов, хотя пакеты amd-ucode и intel-ucode числятся установленными. Опишу, как это понимаю я ... разумеется на точность не претендую - могу в чем то и ошибаться. При загрузке с Live CD в /boot ничего и не будет. Микрокод имеет три способа загрузки - непосредсвенно из BIOS - отдельный патч микрокода отсутствует (точнее патч имеется, но прописан в BIOS). - загрузчиком, на стадии загрузки системы - имеется отдельный патч, не прописанный в BIOS, но загружаемый в соответствии со способом, регламентируемым данной системой, так называемое раннее обновление микрокода - ~~ручное обновление - патч микрокода загружается (подготавливается) в загруженной системе,~~ можно и в ручную размесить файлы в нужном месте, и загрузка микрокода при наличии нужных файлов в этих директорииях (/usr/lib/firmware/amd-ucode/ и /usr/lib/firmware/intel-ucode/) идет по дефолту - так называемое позднее обновление микрокода ... этот способ использую и я, по мере необходимости. Микрокод загружается при каждой загрузке, при этом создается файл устройство /dev/cpu/microcode, но эта инфа не доступна. Информация об обновлении микрокода лежит в /sys/devices/system/cpu/cpu/microcode. Как узнать/считать текущую версию патча микрокода? - привожу свои значения микрокода, расположенного в BIOS (без использования intel-ucode): 1. прочитать из регистра sudo rdmsr 0x8B -f 63:32 14 2. cat /proc/cpuinfo \| grep -m 1 microcode microcode : 0x14 3. cat /proc/cpuinfo \| grep microcode microcode : 0x14 4. cat /sys/devices/system/cpu/cpu/microcode/version 0x14 5. dmesg \| grep microcode А сейчас в ручную загрузил обновление микрокода и смотрим те же значения, приведенные выше 1. прочитать из регистра sudo rdmsr 0x8B -f 63:32 2f cat /proc/cpuinfo \| grep -m 1 microcode microcode : 0x2f 3. cat /proc/cpuinfo \| grep microcode microcode : 0x2f 4. cat /sys/devices/system/cpu/cpu/microcode/version 0x2f Основное отличие загрузки микрокода intel от amd - микрокод amd включен в linux-firmware, а значит директория /usr/lib/firmware/amd-ucode в Arch всегда имеется, чего нет для Intel, для которого intel-ucode нужно загружать отдельно. ..., и если эта директория и нужные патчи в ней имеются, то загрузка микрокода идет по дефолту. PS - в части - и _ - посмотри вывод любого модуля, имеющего эти знаки - modinfo mmc_core и modinfo mmc-core - безразницы ... EDIT 1* - у меня вообще в /boot нет intel-ucode.img, но обновление идет - я размещаю нужные патчи в /usr/lib/firmware/intel-ucode/ и обновление идет автоматом при каждой загрузке. `фев 19 17:38:04 arch kernel: microcode: sig=0x206a7, pf=0x10, revision=0x14 фев 19 17:38:04 arch kernel: microcode: Microcode Update Driver: v2.2. фев 19 17:38:09 arch kernel: microcode: updated to revision 0x2f, date = 2019-02-17` первоначально загрузилась из BIOS revision=0x14, а затем обновилось из /usr/lib/firmware/intel-ucode/ до revision 0x2f EDIT 2 - Для Intel, на мой взгляд, проще не создавать ни какого intel-ucode.img, не прописывать в загрузчик, а просто положить в /usr/lib/firmware/intel-ucode бинарный патч для своего cpu (как для amd), например, в моем случае Family 6, Model 42, Stepping 7 это будет ls /usr/lib/firmware/intel-ucode 06-2a-07 При следующей загрузке обновление будет проходит уже автоматом, из этой директории. Можно обновить и без перегрузки в действующей загрузке echo 1 > /sys/devices/system/cpu/microcode/reload но со следующей загрузки это уже будет идти автоматом - цитата из DOC `The loading mechanism looks for microcode blobs in /lib/firmware/{intel-ucode,amd-ucode}. The default distro installation packages already put them there.` Повторюсь, для amd этого ничего делать не нужно, уже все имеется - берется из linux-firmware ls /usr/lib/firmware/amd-ucode microcode_amd.bin microcode_amd_fam15h.bin microcode_amd_fam16h.bin microcode_amd_fam17h.bin Ошибки не исчезают с опытом - они просто умнеют

vasek

# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

akorop
После загрузки с живых iso и после установки с них на винт зачастую в /boot нет ни одного из этих файлов, хотя пакеты amd-ucode и intel-ucode числятся установленными.

Опишу, как это понимаю я ... разумеется на точность не претендую - могу в чем то и ошибаться.
При загрузке с Live CD в /boot ничего и не будет.
Микрокод имеет три способа загрузки
- непосредсвенно из BIOS - отдельный патч микрокода отсутствует (точнее патч имеется, но прописан в BIOS).
- загрузчиком, на стадии загрузки системы - имеется отдельный патч, не прописанный в BIOS, но загружаемый в соответствии со способом, регламентируемым данной системой, так называемое раннее обновление микрокода
- ~~ручное обновление - патч микрокода загружается (подготавливается) в загруженной системе,~~ можно и в ручную размесить файлы в нужном месте, и загрузка микрокода при наличии нужных файлов в этих директорииях (/usr/lib/firmware/amd-ucode/ и /usr/lib/firmware/intel-ucode/) идет по дефолту - так называемое позднее обновление микрокода ... этот способ использую и я, по мере необходимости.

Микрокод загружается при каждой загрузке, при этом создается файл устройство /dev/cpu/microcode, но эта инфа не доступна. Информация об обновлении микрокода лежит в /sys/devices/system/cpu/cpu*/microcode.
Как узнать/считать текущую версию патча микрокода? - привожу свои значения микрокода, расположенного в BIOS (без использования intel-ucode):
1. прочитать из регистра
sudo rdmsr 0x8B -f 63:32
14
2. cat /proc/cpuinfo | grep -m 1 microcode
microcode : 0x14
3. cat /proc/cpuinfo | grep microcode
microcode : 0x14
4. cat /sys/devices/system/cpu/cpu*/microcode/version
0x14
5. dmesg | grep microcode

А сейчас в ручную загрузил обновление микрокода и смотрим те же значения, приведенные выше
1. прочитать из регистра
sudo rdmsr 0x8B -f 63:32
2f
cat /proc/cpuinfo | grep -m 1 microcode
microcode : 0x2f
3. cat /proc/cpuinfo | grep microcode
microcode : 0x2f
4. cat /sys/devices/system/cpu/cpu*/microcode/version
0x2f

Основное отличие загрузки микрокода intel от amd - микрокод amd включен в linux-firmware, а значит директория /usr/lib/firmware/amd-ucode в Arch всегда имеется, чего нет для Intel, для которого intel-ucode нужно загружать отдельно. ..., и если эта директория и нужные патчи в ней имеются, то загрузка микрокода идет по дефолту.

PS - в части - и _ - посмотри вывод любого модуля, имеющего эти знаки - modinfo mmc_core и modinfo mmc-core - безразницы ...

EDIT 1 - у меня вообще в /boot нет intel-ucode.img, но обновление идет - я размещаю нужные патчи в /usr/lib/firmware/intel-ucode/ и обновление идет автоматом при каждой загрузке.

фев 19 17:38:04 arch kernel: microcode: sig=0x206a7, pf=0x10, revision=0x14
фев 19 17:38:04 arch kernel: microcode: Microcode Update Driver: v2.2.
фев 19 17:38:09 arch kernel: microcode: updated to revision 0x2f, date = 2019-02-17

первоначально загрузилась из BIOS revision=0x14, а затем обновилось из /usr/lib/firmware/intel-ucode/ до revision 0x2f

EDIT 2 - Для Intel, на мой взгляд, проще не создавать ни какого intel-ucode.img, не прописывать в загрузчик, а просто положить в /usr/lib/firmware/intel-ucode бинарный патч для своего cpu (как для amd), например, в моем случае Family 6, Model 42, Stepping 7 это будет
ls /usr/lib/firmware/intel-ucode
06-2a-07
При следующей загрузке обновление будет проходит уже автоматом, из этой директории. Можно обновить и без перегрузки в действующей загрузке
echo 1 > /sys/devices/system/cpu/microcode/reload
но со следующей загрузки это уже будет идти автоматом - цитата из DOC

The loading mechanism looks for microcode blobs in /lib/firmware/{intel-ucode,amd-ucode}. The default distro installation packages already put them there.

Повторюсь, для amd этого ничего делать не нужно, уже все имеется - берется из linux-firmware
ls /usr/lib/firmware/amd-ucode
microcode_amd.bin microcode_amd_fam15h.bin microcode_amd_fam16h.bin microcode_amd_fam17h.bin

Ошибки не исчезают с опытом - они просто умнеют

beisic	# 2 года, 6 месяцев назад
Темы: 5 Сообщения: 184 Участник с: 22 августа 2018	vasek EDIT 1 - у меня вообще в /boot нет intel-ucode.img, Для использующих загрузчик system-boot intel-ucode.img проще пописать в файле /boot/loader/entries/arch.conf : `title arch linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux.img options root=/dev/nvme0n1p2 rw`

beisic

# 2 года, 6 месяцев назад

Темы: 5

Сообщения: 184

Участник с: 22 августа 2018

vasek
EDIT 1 - у меня вообще в /boot нет intel-ucode.img,

Для использующих загрузчик system-boot intel-ucode.img проще пописать в файле /boot/loader/entries/arch.conf :

title   arch
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options root=/dev/nvme0n1p2  rw

vasek	# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Я практически microcode не использую, ну очень редко, а поэтому, если возникла такая необходимость, мне проще скопировать один файлик в нужное место и загрузить. Обновляется microcode Intel редко (сейчас действует microcode-20180425.tgz), нужную версию обновления скачиваю с их сайта. intel-ucode.img по существу создан на основе этого же интеловского файла microcode-20180425.tgz EDIT 1 - конечно, нужно помнить, что иногда, как пишут (хотя такие факты мне не известны), обновление микрокода уже нужно на стадии ранней загрузки и в этом случае необходимо использовать intel-ucode.img, загружаемый загрузчиком. Если это не суть важно, то проще использовать позднюю загрузку - разместил всего один файлик в нужном месте ... и все. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Я практически microcode не использую, ну очень редко, а поэтому, если возникла такая необходимость, мне проще скопировать один файлик в нужное место и загрузить. Обновляется microcode Intel редко (сейчас действует microcode-20180425.tgz), нужную версию обновления скачиваю с их сайта.
intel-ucode.img по существу создан на основе этого же интеловского файла microcode-20180425.tgz

EDIT 1 - конечно, нужно помнить, что иногда, как пишут (хотя такие факты мне не известны), обновление микрокода уже нужно на стадии ранней загрузки и в этом случае необходимо использовать intel-ucode.img, загружаемый загрузчиком. Если это не суть важно, то проще использовать позднюю загрузку - разместил всего один файлик в нужном месте ... и все.

Ошибки не исчезают с опытом - они просто умнеют

RusWolf	# 2 года, 6 месяцев назад
Темы: 11 Сообщения: 2394 Участник с: 16 июля 2016	vasek intel-ucode.img по существу создан на основе этого же интеловского файла microcode-20180425.tgz `[ruswolf@arch-wolf ~]$ pacman -Ss intel-ucode extra/intel-ucode 20191115-3 Microcode update files for Intel CPUs` Почему тогда дата посвежее в репе?

RusWolf

# 2 года, 6 месяцев назад

Темы: 11

Сообщения: 2394

Участник с: 16 июля 2016

vasek
intel-ucode.img по существу создан на основе этого же интеловского файла microcode-20180425.tgz

[ruswolf@arch-wolf ~]$ pacman -Ss intel-ucode
extra/intel-ucode 20191115-3
    Microcode update files for Intel CPUs

Почему тогда дата посвежее в репе?

beisic	# 2 года, 6 месяцев назад
Темы: 5 Сообщения: 184 Участник с: 22 августа 2018	vasek EDIT 1 - конечно, нужно помнить, что иногда, как пишут В ArchWiki пишут как про конфигурацию загрузчиков grub, systemd-boot, EFISTAB , rEFInd, Syslinux для ранней загрузки микрокода, так и для поздней.

vasek	# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	RusWolf extra/intel-ucode 20191115-3 Почему тогда дата посвежее в репе? Периодически выходит пакет обновлений микрокода, в котором приведены все cpu, но это не значит, что обновления коснулись всех cpu - но в пакете должны быть приведены все cpu, иначе быть не может. Смотрим конкретно мой cpu, анализируя заголовок микрокода 1. Смотрим дату (занимает 4 байта, смещение 8 байт) hexdump -C -s 8 -n 4 /usr/lib/firmware/intel-ucode/06-2a-07 00000008 19 20 17 02 02/17/2019 - 17 февраля 2019г., то есть обновление у Intel было 17 февраля, .... а в наш пакет вошло намного позже. 2. Смотрим ревизию (занимает 4 байта, смещение 4 байт) hexdump -C -s 4 -n 4 /usr/lib/firmware/intel-ucode/06-2a-07 00000004 2f 00 00 00 2f - и видим, что ревизия для моего cpu не изменилась, так и осталась 2f, то есть обновления то микокода были … но они мой cpu не затронули. EDIT 1 - молодежь тоже не поверила моим выкладкам - пришлось скачать и потрошить пакет intel-ucode-20191115-3-any.pkg.tar.xz - извлек от туда intel-ucode.img, из которго извлек GenuineIntel.bin, который содержит бинарники для все cpu, и из которого извлек название бинарника для своего cpu: sig=206a7, pf_mask=0x12, rev= 0x2f `Intel x86 or x64 microcode, sig 0x000206a7, pf_mask 0x12, 2019-02-17, rev 0x002f, size 12288` и видим ту же дату 2019-02-17, которую приводил выше, вытащенную непосредственно из микрокода, и тот же номер ревизии 2f … то есть как такового обновления для моего cpu не было. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 2 года, 6 месяцев назад (отредактировано 2 года, 6 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

RusWolf
extra/intel-ucode 20191115-3
Почему тогда дата посвежее в репе?

Периодически выходит пакет обновлений микрокода, в котором приведены все cpu, но это не значит, что обновления коснулись всех cpu - но в пакете должны быть приведены все cpu, иначе быть не может.

Смотрим конкретно мой cpu, анализируя заголовок микрокода
1. Смотрим дату (занимает 4 байта, смещение 8 байт)
hexdump -C -s 8 -n 4 /usr/lib/firmware/intel-ucode/06-2a-07
00000008 19 20 17 02
02/17/2019 - 17 февраля 2019г., то есть обновление у Intel было 17 февраля, .... а в наш пакет вошло намного позже.
2. Смотрим ревизию (занимает 4 байта, смещение 4 байт)
hexdump -C -s 4 -n 4 /usr/lib/firmware/intel-ucode/06-2a-07
00000004 2f 00 00 00
2f - и видим, что ревизия для моего cpu не изменилась, так и осталась 2f, то есть обновления то микокода были … но они мой cpu не затронули.

EDIT 1 - молодежь тоже не поверила моим выкладкам - пришлось скачать и потрошить пакет intel-ucode-20191115-3-any.pkg.tar.xz - извлек от туда intel-ucode.img, из которго извлек GenuineIntel.bin, который содержит бинарники для все cpu, и из которого извлек название бинарника для своего cpu: sig=206a7, pf_mask=0x12, rev= 0x2f

Intel x86 or x64 microcode, sig 0x000206a7, pf_mask 0x12, 2019-02-17, rev 0x002f, size 12288

и видим ту же дату 2019-02-17, которую приводил выше, вытащенную непосредственно из микрокода, и тот же номер ревизии 2f … то есть как такового обновления для моего cpu не было.

Ошибки не исчезают с опытом - они просто умнеют