.\" hey, Emacs: -*- nroff -*- .\" Copyright (c) 2010-2018 Henrique de Moraes Holschuh .\" .\" iucode_tool is free software; you can redistribute it and/or modify .\" it under the terms of the GNU General Public License as published by .\" the Free Software Foundation; either version 2 of the License, or .\" (at your option) any later version. .\" .\" This program is distributed in the hope that it will be useful, .\" but WITHOUT ANY WARRANTY; without even the implied warranty of .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the .\" GNU General Public License for more details. .\" .\" You should have received a copy of the GNU General Public License .\" along with this program; see the file COPYING. If not, write to .\" the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. .\" .TH IUCODE_TOOL 8 "2018-01-28" "IUCODE_TOOL 2.3.1" "iucode_tool manual" .\" Please update the above date whenever this man page is modified. .\" .\" Some roff macros, for reference: .\" .nh disable hyphenation .\" .hy enable hyphenation .\" .ad l left justify .\" .ad b justify to both left and right margins (default) .\" .nf disable filling .\" .fi enable filling .\" .br insert line break .\" .sp insert n+1 empty lines .\" for manpage-specific macros, see man(7) .\" .\" disable a Debian-specific workaround for the misuse of - to mean \- .char - \(hy .\" .SH "نام (NAME)" iucode_tool \- ابزار مدیریت و بارگذاری ریزکد پردازنده‌های اینتل .SH "خلاصه دستور (SYNOPSIS)" .B iucode_tool .RI [ options ] .RI "[[\-t" type "] " filename | dirname "] ..." .SH "توضیحات (DESCRIPTION)" \fBiucode_tool\fP ابزاری است که می‌تواند داده‌های ریزکد پردازنده‌های Intel\*R را از فایل‌هایی با قالب‌های متنی و باینری بسته‌های ریزکد بارگذاری کند. .PP این ابزار می‌تواند فهرستی از ریزکدهای موجود در این فایل‌ها را در خروجی نمایش دهد، آن‌ها را ادغام کند، برای ارتقای ریزکد در هسته‌های پردازنده سیستم در هسته بارگذاری نماید، یا برخی از آن‌ها را برای استفاده‌های بعدی در قالب باینری درون یک فایل بنویسد. .PP \fBiucode_tool\fP تمام ریزکدهای موجود در فایل‌ها و دایرکتوری‌های مشخص‌شده را جهت پردازش در حافظه بارگذاری می‌کند. ریزکدهای تکراری و قدیمی نادیده گرفته خواهند شد. این ابزار همچنین می‌تواند با مشخص کردن نام فایل به‌صورت \(lq\-\(rq (علامت منفی)، داده‌های ریزکد را از ورودی استاندارد (\fIstdin\fP) بخواند. .PP فایل‌های داده ریزکد چنانچه پسوند dat. داشته باشند، در قالب متنی dat. فرض می‌شوند و در غیر این صورت باینری در نظر گرفته خواهند شد. ورودی استاندارد (\fIstdin\fP) به‌صورت پیش‌فرض در قالب متنی dat. فرض می‌شود. با استفاده از گزینه .I \-t می‌توان نوع فایل‌های مشخص‌شده پس از آن (از جمله برای \fIstdin\fP) را تغییر داد. .PP اگر یک دایرکتوری مشخص شود، تمام فایل‌هایی که نام آن‌ها با نقطه آغاز نمی‌شود، بدون ترتیب مشخصی بارگذاری خواهند شد. از دایرکتوری‌های تو در تو صرف‌نظر می‌شود. .PP فایل‌ها و دایرکتوری‌های خالی نادیده گرفته شده و از آن‌ها رد خواهد شد. .PP می‌توانید با استفاده از گزینه‌های .IR "\-S" "، " "\-s" "، " "\-\-date\-before" " و " "\-\-date\-after" مشخص کنید که کدام ریزکدها باید در خروجی نوشته، فهرست یا در هسته بارگذاری شوند. چنانچه هیچ‌یک از این گزینه‌ها مشخص نشوند، تمامی ریزکدها انتخاب خواهند شد. .PP می‌توانید ریزکدهای انتخاب‌شده را در هسته بارگذاری کنید، آن‌ها را در یک فایل (با قالب باینری)، در یک بایگانی early initramfs لینوکس، در فایل‌های مجزا برای هر امضای پردازنده در یک دایرکتوری، یا در فایل‌های مجزا برای هر ریزکد در یک دایرکتوری بنویسید؛ این کار با استفاده از گزینه‌های .IR "\-w" "، " .IR "\-\-write\-earlyfw" "، " .IR "\-k" "، " .IR "\-K" " و " .IR "\-W" انجام می‌شود. .PP \fBiucode_tool\fP ریزکدها را در پیام‌های خروجی و خطای خود با نماد \(lq\fIn/k\fP\(rq مشخص می‌کند، که در آن \(lq\fIn\fP\(rq شماره بسته و \(lq\fIk\fP\(rq شماره ریزکد درون آن بسته است. خروجی گزینه .I \-\-list\-all هنگام پردازش چندین فایل ورودی، بهترین نمونه از نحوه کارکرد این نماد است. .PP برای اطلاعات بیشتر درباره ریزکدهای پردازنده‌های اینتل، لطفاً مستندات ارائه‌شده و راهنماهای اینتل ذکرشده در بخش \fIهمچنین ببینید (SEE ALSO)\fP را مطالعه فرمایید. .SH "گزینه‌ها (OPTIONS)" \fBiucode_tool\fP گزینه‌های زیر را می‌پذیرد: .TP .BR \-q ", " \-\-quiet جلوگیری از خروجی‌های معمول برنامه (حالت بی‌صدا). .TP .BR \-v ", " \-\-verbose چاپ اطلاعات بیشتر. برای افزایش سطح جزئیات، می‌توان بیش از یک بار از آن استفاده کرد. .TP .BR \-h ", " \-? ", " \-\-help نمایش تمام گزینه‌های موجود و معانی آن‌ها. .TP .B \-\-usage نمایش خلاصه‌ای از گزینه‌ها و نحوه استفاده. .TP .BR \-V ", " \-\-version نمایش نسخه برنامه. .TP .BI "\-t " type .RI "تعیین نوع فایل برای فایل‌های بعدی. مقدار " type " می‌تواند یکی از موارد زیر باشد:" .RS .IP \fBb\fP قالب باینری. این همان قالبی است که توسط درایور هسته و BIOS/EFI استفاده می‌شود و در بخش 9.11 از راهنمای .IR "Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A" به‌تفصیل توضیح داده شده است. .IP \fBd\fP قالب متنی dat. ریزکد اینتل. این قالبی است که معمولاً توسط شرکت اینتل برای توزیع فایل‌های داده ریزکد به کار می‌رود. .IP \fBr\fP بازیابی ریزکد در قالب باینری. فایل‌های باینری فشرده‌نشده عمومی را برای یافتن و بازیابی ریزکدهایی در قالب باینری اینتل جستجو می‌کند. توجه: ممکن است ریزکدهایی پیدا شوند که بررسی‌های سخت‌گیرانه را پاس نکنند و در نتیجه اگر گزینه‌های \fI\-\-no\-strict\-checks\fP یا \fI\-\-ignore\-broken\fP فعال نباشند، باعث خروج \fBiucode_tool\fP شوند. .IP \fBa\fP (پیش‌فرض) \fBiucode_tool\fP از پسوند نام فایل برای تعیین نوع فایل استفاده می‌کند: قالب متنی dat. برای فایل‌هایی که پسوند .I .dat دارند و نوع باینری برای سایر فایل‌ها. توجه داشته باشید که برای \fIstdin\fP، قالب متنی dat. فرض می‌شود. .RE .TP .B "\-\-downgrade" هنگامی که چندین نسخه از ریزکد یک پردازنده خاص از فایل‌های مختلف در دسترس باشد، نسخه‌ای از فایلی که در آخر بارگذاری شده نگه‌داری می‌شود، صرف‌نظر از سطح ویرایش (revision). فایل‌ها همیشه به همان ترتیبی که در خط فرمان مشخص شده‌اند بارگذاری می‌شوند. این گزینه زمانی که فقط یک فایل بارگذاری شده باشد هیچ تاثیری ندارد. .TP .B "\-\-no\-downgrade" هنگامی که چندین نسخه از ریزکد یک پردازنده خاص از فایل‌های مختلف در دسترس باشد، نسخه‌ای با بالاترین سطح ویرایش (revision) نگه‌داری می‌شود. این حالت، شیوه عملکرد پیش‌فرض است. .TP .B "\-\-strict\-checks" انجام بررسی‌های سخت‌گیرانه روی داده‌های ریزکد. از بارگذاری ریزکدها و فایل‌های داده ریزکد با اندازه و متادیتای غیرمنتظره خودداری می‌کند. همچنین از بارگذاری ورودی‌های ریزکدی که متادیتای یکسان ولی محتوای (payload) متفاوتی دارند جلوگیری خواهد کرد. این حالت، شیوه عملکرد پیش‌فرض است. .TP .B "\-\-no\-strict\-checks" انجام بررسی‌های با سخت‌گیری کمتر روی داده‌های ریزکد. فقط در صورتی استفاده شود که با یک فایل داده ریزکد مواجه شده‌اید که حاوی ریزکدهایی با اندازه‌های نامتعارف یا متادیتای نادرستِ غیربحرانی (مانند تاریخ‌های نامعتبر) است و می‌خواهید آن‌ها را حفظ کنید. اگر تنها می‌خواهید از این موارد رد شوید، از گزینه \fI\-\-ignore\-broken\fP استفاده کنید. .TP .B "\-\-ignore\-broken" صرف‌نظر کردن از ورودی‌های معیوب ریزکد هنگام بارگذاری یک فایل داده ریزکد، به جای توقف اجرای برنامه. اگر ورودی ریزکد قالبی پشتیبانی‌نشده داشته باشد یا هدر آن به‌شدت آسیب دیده باشد، باید از تمام داده‌های باقی‌مانده در فایل صرف‌نظر شود. در این حالت، استفاده از نوع فایلِ \fIبازیابی ریزکد در قالب باینری\fP (گزینه \fI\-tr\fP) توصیه می‌شود، زیرا می‌تواند از روی داده‌های ریزکد به‌شدت آسیب‌دیده رد شود. .TP .B "\-\-no\-ignore\-broken" در صورت مشاهده ریزکد معیوب هنگام بارگذاری فایل داده ریزکد، اجرای برنامه را متوقف می‌کند. این حالت، شیوه عملکرد پیش‌فرض است. .TP .BI "\-s ! | [!]" signature "[,[" pf_mask "][,[" lt: "|" eq: "|" gt: "]" revision "]]" ریزکدها را بر اساس \fIsignature\fP (امضا)، \fIpf_mask\fP (ماسک فلگ‌های پردازنده) و \fIrevision\fP (نسخه ویرایش) مشخص‌شده انتخاب می‌کند. .PP اگر \fIpf_mask\fP مشخص شده باشد، تنها ریزکدهایی انتخاب می‌شوند که دست‌کم با یکی از ترکیب‌های فلگ پردازنده موجود در ماسک سازگار باشند. .PP اگر \fIrevision\fP مشخص شده باشد، و اختیاری با یکی از عملگرهای \(lq\fIeq:\fP\(rq، \(lq\fIlt:\fP\(rq یا \(lq\fIgt:\fP\(rq پیشوند شده باشد، فقط ریزکدهایی را انتخاب می‌کند که ویرایش یکسانی داشته باشند (در صورت عدم استفاده از عملگر، یا در صورت استفاده از عملگر \(lq\fIeq:\fP\(rq)، یا ریزکدهایی که ویرایش آن‌ها کمتر از (عملگر \(lq\fIlt:\fP\(rq) یا بیشتر از (عملگر \(lq\fIgt:\fP\(rq) مقدار مشخص‌شده باشد. .PP برای انتخاب ریزکدهای بیشتر، این گزینه را می‌توان چندین بار مشخص کرد. این گزینه را می‌توان با گزینه \fI\-\-scan\-system\fP ترکیب کرد تا ریزکدهای بیشتری انتخاب شوند. اگر به ابتدای \fIsignature\fP یک علامت \(lq\fI!\fP\(rq (علامت تعجب) اضافه شود، به جای انتخاب، ریزکدها را از انتخاب خارج می‌کند. ترتیب گزینه‌ها مهم است؛ گزینه‌های \fI\-s\fP بعدی، موارد قبلی از جمله \fI\-\-scan\-system\fP را لغو و بازنویسی می‌کنند. .PP هنگام مشخص کردن \fIsignature\fP و \fIpf_mask\fP، اعداد هگزادسیمال باید با پیشوند \(lq\fI0x\fP\(rq و اعداد هشت‌هشتی (octal) با \(lq\fI0\fP\(rq مشخص شوند. اعداد ده‌دهی (decimal) نباید صفر ابتدایی داشته باشند، در غیر این صورت به عنوان عدد هشت‌هشتی تفسیر خواهند شد. .PP نماد ویژه \fI\-s!\fP (بدون پارامتر \fIsignature\fP) به \fBiucode_tool\fP دستور می‌دهد که نیاز به گنجاندن صریح امضاهای ریزکد داشته باشد (با استفاده از شکل بدون نفی \fI\-s\fP یا با استفاده از \fI\-\-scan\-system\fP). .TP .BR "\-S" ", " "\-\-scan\-system" "[=\fImode\fP]" انتخاب ریزکدها از طریق پویش پردازنده‌های فعال (online) این سیستم برای یافتن امضای آن‌ها. .PP از این گزینه تنها یک بار می‌توان استفاده کرد، و می‌توان آن را با گزینه \fI\-s\fP ترکیب کرد تا ریزکدهای بیشتری انتخاب شوند. ریزکدهای انتخاب‌شده با \fI\-\-scan\-system\fP را می‌توان با گزینه بعدی \fI\-s\ !signature\fP از حالت انتخاب خارج کرد. .PP آرگومان اختیاری \fImode\fP (که تنها در نگارش طولانی گزینه پذیرفته می‌شود) روش پویش پردازنده‌ها را تعیین می‌کند: .RS .IP "\fB0\fP یا \fBauto\fP" در حال حاضر معادل \fBfast\fP است، اما در نسخه‌های آینده در صورتی که اینتل سیستم‌هایی با چند امضا فراتر از mixed-stepping به کار گیرد، ممکن است تغییر کند. این حالت برای حفظ سازگاری با نسخه‌های پیشین \fBiucode_tool\fP، حالت پیش‌فرض عملکرد است. .IP "\fB1\fP یا \fBfast\fP" از دستور cpuid برای تشخیص امضای پردازنده‌ای که \fBiucode_tool\fP روی آن در حال اجراست استفاده می‌کند و تمامی steppingهای نوع، خانواده و مدل آن پردازنده را انتخاب می‌نماید. از سیستم‌های mixed-stepping پشتیبانی می‌کند. .IP "\fB2\fP یا \fBexact\fP" از درایورهای هسته برای پویش مستقیم امضای هر یک از پردازنده‌های فعال سیستم استفاده می‌کند. این حالت از سیستم‌های چندامضایی پشتیبانی می‌کند. این روش پویش در سیستم‌های بزرگ با تعداد پردازنده‌های زیاد کند خواهد بود و احتمالاً به مجوزهای ویژه (مانند اجرا با دسترسی کاربر ریشه / root) نیاز دارد. در صورتی که پویش به هر دلیلی با شکست مواجه شود، به عنوان یک اقدام ایمنی (fail-safe)، یک هشدار صادر می‌کند و تمام steppingهای ممکن را برای هر امضایی که با موفقیت پویش کرده در نظر می‌گیرد. .RE .TP \fB\-\-date\-before\fR=\fIYYYY\-MM\-DD\fR و \fB\-\-date\-after\fR=\fIYYYY\-MM\-DD\fR محدود کردن ریزکدهای انتخاب‌شده بر اساس یک بازه تاریخی. تاریخ باید در قالب استاندارد ISO با چهار رقم برای سال، دو رقم برای ماه و دو رقم برای روز داده شود و از \(lq\fI\-\fP\(rq (علامت منفی) به عنوان جداکننده استفاده شود. محدوده تاریخ‌ها اعتبارسنجی نمی‌شود، بنابراین می‌توانید از \fI\-\-date\-after=2000\-00\-00\fP برای انتخاب تمام ریزکدهای پس از ۱ ژانویه ۲۰۰۰ استفاده کنید. .TP .B \-\-loose\-date\-filtering هنگامی که یک بازه زمانی مشخص می‌شود، در صورتی که هر یک از ویرایش‌های ریزکد درون بازه زمانی باشد، تمام ویرایش‌های آن ریزکد برای انتخاب در نظر گرفته می‌شوند (تنها بازه تاریخی نادیده گرفته می‌شود و تمام فیلترهای دیگر همچنان اعمال می‌گردند). .TP .B \-\-strict\-date\-filtering هنگامی که یک بازه زمانی مشخص می‌شود، فقط ریزکدهایی که دقیقاً درون آن بازه زمانی هستند انتخاب می‌شوند. این حالت، شیوه عملکرد پیش‌فرض است. .TP .BR "\-l" ", " "\-\-list" فهرست کردن امضاهای ریزکدهای انتخاب‌شده در خروجی استاندارد (\fIstdout\fP). .TP .BR "\-L" ", " "\-\-list\-all" فهرست کردن تمام امضاهای ریزکدها در هنگام پردازش در خروجی استاندارد (\fIstdout\fP). .TP .BR "\-k" "[\fIdevice\fP], " "\-\-kernel" "[=\fIdevice\fP]" بارگذاری ریزکدهای انتخاب‌شده در هسته. به‌صورت اختیاری، مسیر دستگاه قابل تعیین است (پیش‌فرض: .IR "/dev/cpu/microcode" "). این روش به‌روزرسانی منسوخ شده است: سرانجام از هسته و از iucode_tool حذف خواهد شد." .TP .BR "\-K" "[\fIdirectory\fP], " "\-\-write\-firmware" "[=\fIdirectory\fP]" نوشتن ریزکدهای انتخاب‌شده با نام‌های فایلی که بارگذار میان‌افزار هسته لینوکس انتظار دارد. به‌صورت اختیاری می‌توان دایرکتوری مقصد را مشخص کرد .RI "(پیش‌فرض: " "/lib/firmware/intel-ucode" ")." .TP .BR "\-w\fIfile\fP" ", " "\-\-write\-to" "=\fIfile\fP" نوشتن ریزکدهای انتخاب‌شده در یک فایل با قالب باینری. .TP .BR "\-\-write\-earlyfw" "=\fIfile\fP" نوشتن ریزکدهای انتخاب‌شده در یک بایگانی early initramfs که باید به ابتدای initramfs معمولی ضمیمه شود تا هسته بتواند در مراحل بسیار اولیه بوت سیستم، ریزکد پردازنده را به‌روزرسانی کند. .TP .BR "\-W\fIdirectory\fP" ", " "\-\-write\-named\-to" "=\fIdirectory\fP" نوشتن ریزکدهای انتخاب‌شده در دایرکتوری مشخص‌شده، به ازای هر فایل یک ریزکد، با قالب باینری. نام فایل‌ها نشان‌دهنده امضای ریزکد، ماسک فلگ‌های پردازنده و ویرایش آن خواهد بود. .TP .BR "\-\-write\-all\-named\-to" "=\fIdirectory\fP" نوشتن تمامی ریزکدها در دایرکتوری مشخص‌شده، به ازای هر فایل یک ریزکد، با قالب باینری. نام فایل‌ها نشان‌دهنده امضای ریزکد، ماسک فلگ‌های پردازنده و ویرایش آن خواهد بود. این تنها راه برای نوشتن تمام ویرایش‌های یک ریزکد یکسان در خروجی است. .TP .B "\-\-overwrite" حذف فایل مقصد پیش از نوشتن، در صورتی که از قبل وجود داشته باشد و دایرکتوری نباشد. فایل مقصد درجا بازنویسی نمی‌شود. پیوندهای سخت (Hardlinks) گسسته خواهند شد و هرگونه دسترسی، ACL و سایر صفات گسترده فایل مقصد قبلی از بین خواهد رفت. .TP .B "\-\-no\-overwrite" توقف اجرا در صورتی که فایل مقصد از قبل وجود داشته باشد. این حالت، شیوه عملکرد پیش‌فرض است. توجه داشته باشید که iucode_tool هنگام نوشتن فایل‌ها، از پیوندهای نمادین غیردایرکتوری تبعیت نمی‌کند. .TP .B "\-\-mini\-earlyfw" بهینه‌سازی کانتینر cpio در early initramfs برای رسیدن به کمترین اندازه ممکن. این گزینه اندازه بلوک cpio را به ۱۶ بایت تغییر می‌دهد و ورودی‌های هدر دایرکتوری‌های والد فایل داده ریزکد را حذف می‌کند. در نتیجه، فایل داده ریزکد برای initramfs معمولی در دسترس نخواهد بود و ممکن است ابزارها نسبت به اندازه غیراستاندارد بلوک cpio اخطار دهند. .PP این کار معمولاً حجم early initramfs را ۷۳۶ بایت کاهش می‌دهد. .TP .B "\-\-normal\-earlyfw" بهینه‌سازی اندازه early initramfs برای سازگاری با ابزارها. این حالت، شیوه عملکرد پیش‌فرض است. فایل داده ریزکد درون initramfs معمولی نیز در دسترس خواهد بود. .SH "نکات (NOTES)" \fBiucode_tool\fP تمام داده‌ها را پیش از هرگونه پردازش در حافظه می‌خواند. این ابزار برای بررسی سلامت، حداکثر سقف ۱ گیبی‌بایت (1GiB) داده باینری ریزکد را برای هر فایل داده ریزکد اعمال می‌کند. .PP تمامی پیام‌های اطلاع‌رسانی و خطا به خطای استاندارد (\fIstderr\fP) ارسال می‌شوند، در حالی که خروجی‌های درخواست‌شده توسط کاربر (مانند خروجی تولیدشده توسط گزینه‌های فهرست‌بندی) به خروجی استاندارد (\fIstdout\fP) ارسال می‌گردند. .PP \fBiucode_tool\fP فایل‌ها را با مجوز 0644 (rw\-r\-\-r\-\-) ایجاد می‌کند که بر اساس umask جاری تغییر می‌یابد. .PP فهرست ریزکدهای انتخاب‌شده و فایل‌های خروجی ریزکد در \fBiucode_tool\fP ابتدا بر اساس \fIامضای پردازنده\fP (صعودی) و سپس بر اساس \fIماسک فلگ‌های پردازنده\fP (نزولی) مرتب می‌شوند. .PP هنگامی که چندین ویرایش از یک ریزکد انتخاب شوند، از نسخه‌های قدیمی‌تر صرف‌نظر می‌شود. تنها جدیدترین ویرایش انتخاب‌شده از یک ریزکد (یا در صورت فعال بودن گزینه \fI\-\-downgrade\fP، آخرین ویرایش بر اساس ترتیب بارگذاری) درون فایل نوشته شده یا در هسته بارگذاری می‌شود. .PP فایل‌های داده ریزکد اینتل، چه در قالب باینری و چه در قالب متنی، می‌توانند به یکدیگر متصل شوند (الحاق شوند) تا یک فایل داده ریزکد بزرگ‌تر و همچنان معتبر تولید کنند. .PP \fBiucode_tool\fP هنگام نوشتن فایل‌های داده ریزکد از پیوندهای نمادین تبعیت نمی‌کند. این ابزار یا از نوشتن فایل خودداری کرده و متوقف می‌شود (شیوه عملکرد پیش‌فرض)، یا (در صورت فعال بودن گزینه \fI\-\-overwrite\fP) پیوند نمادین یا فایل مقصد را \fIپیش از\fP نوشتن فایل جدید حذف می‌کند (و در نتیجه پیوندهای سخت را می‌شکند). .PP \fBiucode_tool\fP از پیوندهای نمادین دایرکتوری برای یافتن دایرکتوری جهت نوشتن فایل‌ها تبعیت می‌کند. .SS "نکات لینوکس (Linux Notes)" پیش از نسخه 4.4 لینوکس، درایور به‌روزرسانی ریزکد به دو بخش تقسیم شده بود: درایور به‌روزرسانی زودهنگام ریزکد (early microcode update driver که داده‌های ریزکد را از initramfs دریافت می‌کرد) و درایور به‌روزرسانی دیرهنگام ریزکد (late microcode update driver که می‌توانست یک ماژول باشد و داده‌های ریزکد را از زیرسیستم میان‌افزار دریافت می‌کرد). این دو درایور در نسخه 4.4 لینوکس یکپارچه شدند. .PP درایور به‌روزرسانی ریزکد باید همیشه در سیستم حضور داشته باشد تا اطمینان حاصل شود که به‌روزرسانی‌های ریزکد پس از بازگشت از حالت تعلیق (resume from suspend) و اتصال گرم پردازنده (CPU hotplug) مجدداً اعمال می‌شوند. ماژول ریزکد را تخلیه (unload) نکنید، مگر اینکه واقعاً دلیل فنی موجهی داشته باشید. از لینوکس نسخه 4.4 به بعد، درایور به‌روزرسانی دیرهنگام دیگر نمی‌تواند یک ماژول باشد و در صورت فعال بودن، همواره در سیستم حضور خواهد داشت. .PP به‌روزرسانی زودهنگام ریزکد امن‌تر است. این کار فقط در زمان بوت امکان‌پذیر است و به یک initramfs نیاز دارد، اما به‌شدت توصیه می‌شود: به‌روزرسانی‌های دیرهنگام ریزکد (که داده‌های ریزکد را از مسیر ‎/lib/firmware می‌خوانند) نمی‌توانند ویژگی‌های قابل مشاهده پردازنده را با ایمنی تغییر دهند. .PP به‌روزرسانی‌های زودهنگام ریزکد از نسخه 3.9 لینوکس در دسترس هستند. آن‌ها می‌توانند ویژگی‌های قابل مشاهده پردازنده را با ایمنی تغییر دهند (همانند به‌روزرسانی‌های ریزکدی که دستورالعمل‌های Intel TSX را در هسته‌های Intel Haswell غیرفعال کردند). این به‌روزرسانی‌ها به یک ایمیج initramfs فشرده‌نشده حاوی داده‌های به‌روزرسانی ریزکد در مسیر \fI/kernel/x86/microcode/GenuineIntel.bin\fP نیاز دارند. این ایمیج initramfs فشرده‌نشده باید قبل از هر ایمیج فشرده‌نشده/فشرده‌شده دیگر initramfs قرار گیرد و نام ویژه‌ای دارد: \fIearly initramfs\fP. .PP داده‌های به‌روزرسانی ریزکد درون ایمیج early initramfs به دلیل وجود یک باگ در چندین نسخه از درایور به‌روزرسانی زودهنگام ریزکد هسته لینوکس، باید روی مرز ۱۶ بایتی تراز (aligned) شوند. این امر نیازمند مراحل ویژه‌ای هنگام ساخت آرشیو initramfs حاوی داده‌های ریزکد است و به‌صورت خودکار توسط گزینه \fI\-\-write\-earlyfw\fP در \fBiucode_tool\fP مدیریت می‌شود. .PP از لینوکس نسخه 4.2، امکان ساخت هسته همراه با داده‌های به‌روزرسانی ریزکد به‌صورت میان‌افزار توکار (built-in firmware) با استفاده از قابلیت CONFIG_FIRMWARE_IN_KERNEL نیز فراهم شده است. این قابلیت تا نسخه‌های 4.2.8، 4.4.11، 4.5.5 و 4.6 لینوکس هنوز کاملاً به بلوغ نرسیده بود و ممکن است در تمام موارد کار نکند. .PP رابط به‌روزرسانی \fI/dev/cpu/microcode\fP منسوخ شده و نباید استفاده شود. این رابط یک الزام خاص دارد: هر فراخوانی سیستمی write باید شامل کل ریزکد(ها) باشد. این رابط از طریق \fBiucode_tool\fP با گزینه \fI\-\-kernel\fP قابل دسترسی است. .PP تا نسخه 3.5 لینوکس، به‌روزرسانی دیرهنگام ریزکد باید برای هر هسته به‌صورت جداگانه، با نوشتن عدد ۱ در \fI/sys/devices/system/cpu/*/microcode/reload\fP برای هر پردازنده اعمال می‌شد. بسته به نسخه هسته، باید آن را روی هر هسته اعمال می‌کردید تا از وضعیت خطرناکی که برخی هسته‌ها از ریزکد قدیمی استفاده می‌کنند جلوگیری شود، یا اینکه هسته درخواست را فقط برای پردازنده بوت می‌پذیرفت و از آن برای راه‌اندازی به‌روزرسانی در تمام هسته‌های پردازنده سیستم استفاده می‌کرد. .PP از نسخه 3.6 لینوکس، درایور به‌روزرسانی دیرهنگام ریزکد دارای یک رابط جدید است که با نوشتن عدد ۱ در \fI/sys/devices/system/cpu/microcode/reload\fP به‌طور صریح به‌روزرسانی را برای تمامی هسته‌ها به‌طور هم‌زمان فعال می‌کند. .SH "مثال‌ها (EXAMPLES)" .SS "به‌روزرسانی فایل‌ها در \fI/lib/firmware/intel-ucode\fP:" .HP iucode_tool \-K/lib/firmware/intel-ucode \\ .br /lib/firmware/intel-ucode \\ .br /tmp/file\-with\-new\-microcodes.bin .SS "پردازش هم‌زمان چندین فایل فشرده:" .HP zcat intel\-microcode*.dat.gz | iucode_tool\ \-l\ \- .HP zcat intel\-microcode*.bin.gz | iucode_tool \-l\ \-tb\ \- .SS "انتخاب ریزکدها و ایجاد یک early initramfs:" .HP iucode_tool \-\-scan\-system \\ .br \-\-write\-earlyfw=/tmp/early.cpio \\ .br /lib/firmware/intel\-ucode .HP iucode_tool \-s\ 0x106a5 \-s\ 0x106a4 \-l /lib/firmware/intel\-ucode .SS "استفاده از بارگذار بازیابی برای بارگذاری و به‌روزرسانی ریزکد در early initramfs:" .HP iucode_tool \-L \-tr /boot/intel\-ucode.img .HP iucode_tool \-Ll \-S \-\-write\-earlyfw=/boot/intel\-ucode.img.new \\ .br \-tr /boot/intel\-ucode.img \-tb /lib/firmware/intel\-ucode && \\ .br mv /boot/intel\-ucode.img.new /boot/intel\-ucode.img .SH "اشکالات (BUGS)" برای ریزکدهای با شماره ویرایش منفی حالت خاصی در نظر گرفته نشده است و نسبت به ریزکدهای معمولی ترجیح داده نخواهند شد. .PP حالت تقلیل نسخه (\fIdowngrade mode\fP) فقط باید برای ریزکدهایی با \fIماسک فلگ‌های پردازنده\fP یکسان استفاده شود. این حالت نمی‌تواند موارد نادری را که در آن‌ها تغییر \fIماسک فلگ‌های پردازنده\fP برای اجبار هسته به بارگذاری ویرایش پایین‌تر ریزکد لازم است مدیریت کند، و در چنین شرایطی \fBiucode_tool\fP یک پیام هشدار صادر خواهد کرد. تاکنون، این مورد محدودیت مهمی به شمار نرفته است زیرا تغییرات در \fIماسک فلگ‌های پردازنده\fP در به‌روزرسانی‌های ریزکدِ مرحله تولید و پس از عرضه بسیار نادر است. .PP فیلد متادیتای \fIنسخه بارگذار (loader version)\fP ریزکد توسط \fBiucode_tool\fP نادیده گرفته می‌شود. تا زمانی که یک امضا به بیش از یک نوع بارگذار نیاز نداشته باشد، این موضوع نباید مشکلی ایجاد کند. .PP فایل‌ها به‌صورت اتمیک (atomic) جایگزین نمی‌شوند: اگر اجرای \fBiucode_tool\fP هنگام نوشتن در یک فایل متوقف شود، آن فایل آسیب خواهد دید. .SH "همچنین ببینید (SEE ALSO)" \fBThe Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A: System Programming Guide, Part 1\fP (order number 253668), section 9.11. .\" .BR foo (1), .\" .BR bar (1). .SH "نویسنده (AUTHOR)" Henrique de Moraes Holschuh