SG_SES_MICROCODE(8) SG3_UTILS SG_SES_MICROCODE(8)

sg_ses_microcode - ارسال ریزکد به یک محفظه SCSI

sg_ses_microcode [--bpw=CS] [--dry-run] [--ealsd] [--help] [--id=ID] [--in=FILE] [--length=LEN] [--mode=MO] [--non] [--offset=OFF] [--skip=SKIP] [--subenc=MS] [--tlength=TLEN] [--verbose] [--version] DEVICE

این ابزار تلاش می‌کند ریزکد (میکروکد) را در یک محفظه (یا یکی از زیرمحفظه‌های آن) مرتبط با DEVICE بارگیری (دانلود) کند. فرآیند انجام این کار در استانداردها و پیش‌نویس‌های خدمات محفظه SCSI (کوتاه‌نوشت SES) که توسط کمیته T10 نگهداری می‌شود، تعریف شده است.

فرآیند کار به این صورت است که یک یا چند توالی شامل دستور SCSI با نام SEND DIAGNOSTIC ارسال می‌شود که به‌صورت اختیاری پس از آن دستور RECEIVE DIAGNOSTIC RESULTS قرار می‌گیرد. دستور نخست یک صفحه عیب‌یابی کنترلی بارگیری ریزکد (کوتاه‌نوشت dpage) را ارسال می‌کند و دستور دوم یک صفحه وضعیت بارگیری ریزکد را دریافت می‌نماید که می‌توان آن را به‌عنوان گزارشی از دستور نخست در نظر گرفت.

رفتار پیش‌فرض (یعنی زمانی که گزینه --mode=MO مشخص نشده باشد) واکشی صفحه عیب‌یابی وضعیت بارگیری ریزکد و رمزگشایی آن است. این کار نیازی به خود فایل ریزکد (سفت‌افزار) ندارد، بنابراین گزینه --in=FILE لازم نیست.

تازه‌ترین مرجع برای این ابزار پیش‌نویس سند خدمات محفظه ۳ SCSI (کوتاه‌نوشت SES-3) نسخه T10/2149-D بازنگری ۷ در نشانی http://www.t10.org است. استانداردهای موجود برای SES و SES-2 به‌ترتیب ANSI INCITS 305-1998 و ANSI INCITS 448-2008 هستند.

بیشتر پشتیبانی‌های دیگر از SES در این بسته (به‌جز بارگیری ریزکد) را می‌توان در ابزار sg_ses یافت. راه دیگر برای بارگیری سفت‌افزار در یک دستگاه SCSI استفاده از دستور WRITE BUFFER تعریف‌شده در SPC-4 است؛ به ابزار sg_write_buffer مراجعه کنید.

آرگومان‌های گزینه‌های بلند برای گزینه‌های کوتاه نیز الزامی هستند.

که در آن CS اندازه هر تکه بر حسب بایت است و باید مضربی از ۴ باشد. این مقدار حداکثر تعداد بایت‌های ارسالی در هر دستور SEND DIAGNOSTIC خواهد بود. بنابراین اگر CS کمتر از طول واقعی ریزکد باشد، چندین دستور SEND DIAGNOSTIC ارسال می‌شود که هر کدام تکه بعدی داده‌های خوانده‌شده را برداشته و فیلد آفست بافر را در صفحه کنترلی بارگیری ریزکد به مقدار مناسب افزایش می‌دهند. پیش‌فرض اندازه تکه ۰ است که به‌صورت عددی بسیار بزرگ تفسیر می‌شود و بنابراین تنها یک دستور SEND DIAGNOSTIC ارسال خواهد شد.
عدد مشخص‌شده در CS اختیاری می‌تواند با «,act» یا «,activate» همراه شود. در این حالت پس از ارسال موفقیت‌آمیز ریزکد به DEVICE، یک صفحه کنترلی اضافی بارگیری ریزکد ارسال می‌شود که حالت آن روی «Activate deferred microcode» [0xf] تنظیم شده است.
با تعیین این گزینه، فراخوانی‌های واقعی برای اجرای دستورات SEND DIAGNOSTIC و RECEIVE DIAGNOSTIC RESULTS نادیده گرفته می‌شوند. هیچ دستور SCSI به DEVICE ارسال نمی‌شود اما دستگاه همچنان باز می‌شود و تعیین آن الزامی است. می‌توان از یک دستگاه ساختگی مانند ‎/dev/null‎ (در یونیکس) استفاده کرد.
این ابزار انتظار پاسخی منطقی به دستور RECEIVE DIAGNOSTIC RESULTS ارسالی خود دارد (و اگر چنین پاسخی دریافت نکند متوقف می‌شود). از این رو این گزینه پاسخ‌های ساختگی با یک محفظه اصلی و سه زیرمحفظه ارائه می‌دهد. این پاسخ‌های ساختگی شامل وضعیت‌های سالم و مناسب هستند.
خروج پس از آخرین دستور SEND DIAGNOSTIC. یک دستگاه SES نباید به‌روزرسانی سفت‌افزار خود را بلافاصله پس از دریافت آخرین «تکه» از سفت‌افزار آغاز کند؛ بلکه باید منتظر بماند تا دست‌کم یک دستور RECEIVE DIAGNOSTIC RESULTS ارسال شود تا فرصت گزارش خطا به دستگاه داده شود. با این حال، برخی از دستگاه‌ها به‌روزرسانی سفت‌افزار را بلافاصله آغاز می‌کنند که این امر باعث مسدود ماندن دستور پایانی RECEIVE DIAGNOSTIC RESULTS شده و اغلب با خطای «target reset» متوقف می‌شود.
این گزینه موجب می‌شود از ارسال دستور پایانی RECEIVE DIAGNOSTIC RESULTS صرف‌نظر شود. این گزینه معمولاً همراه با گزینه --bpw=CS استفاده می‌شود.
پیش از نگارش 1.10 این ابزار [20180112]، این رفتار (یعنی نادیده گرفتن آخرین دستور RECEIVE DIAGNOSTIC RESULTS) رفتار پیش‌فرض بود.
نمایش پیام راهنمای نحوه استفاده و سپس خروج. اگر چند بار استفاده شود، نام حالت‌ها و اختصارات آن‌ها را نیز چاپ می‌کند.
این گزینه فیلد BUFFER ID را در صفحه کنترلی بارگیری ریزکد تنظیم می‌کند. ID مقداری بین ۰ (پیش‌فرض) تا ۲۵۵ است.
خواندن داده‌ها از فایل FILE که همراه با دستور SEND DIAGNOSTIC ارسال خواهد شد. اگر FILE برابر با «-» باشد، ورودی استاندارد (stdin) تا رسیدن به انتهای فایل (EOF) خوانده می‌شود (مشابه رفتار گزینه --raw). داده‌ها از ابتدای FILE خوانده می‌شوند، مگر در حالتی که فایل معمولی بوده و گزینه --skip=SKIP مشخص شده باشد.
که در آن LEN طول داده‌های قابل نوشتن روی دستگاه بر حسب بایت است. اگر مشخص نشود (و طول از طریق --in=FILE یا --raw قابل استنتاج نباشد)، پیش‌فرض صفر در نظر گرفته می‌شود. اگر گزینه مشخص شده باشد و طول استنتاج‌شده از --in=FILE یا --raw کمتر باشد (یا هیچ داده‌ای ارائه نشده باشد)، بایت‌های 0xff به‌عنوان بایت‌های پُرکننده استفاده می‌شوند.
این گزینه حالت (MODE) را تنظیم می‌کند. MO مقداری بین ۰ (که dmc_status و پیش‌فرض است) تا ۲۵۵ است. همچنین می‌توان از نام اختصاری استفاده کرد. بخش «حالت‌ها (MODES)» را در ادامه ببینید. برای فهرست کردن اختصارات حالت موجود در زمان اجرا، یک مقدار نامعتبر وارد کنید (مانند «--mode=xxx») یا از گزینه «-h» استفاده نمایید.
سازگاری با پیاده‌سازی‌های غیراستانداردی که موتور بارگیری ریزکد خود را پس از ارسال دستور RECEIVE DIAGNOSTIC RESULTS همراه با صفحه وضعیت بارگیری ریزکد بازنشانی می‌کنند. با تعیین این گزینه، از ارسال ترکیب این دستور و صفحه وضعیت جلوگیری می‌شود، مگر اینکه پیش‌تر خطایی رخ داده باشد.
این گزینه فیلد BUFFER OFFSET را در صفحه کنترلی بارگیری ریزکد تنظیم می‌کند. OFF مقداری بین ۰ (پیش‌فرض) تا 2**32-1 و یک آفست بایتی است. اگر گزینه --bpw=CS نیز داده شده باشد، این گزینه نادیده گرفته می‌شود (و هشداری به خطای استاندارد stderr ارسال می‌گردد).
این گزینه تنها زمانی فعال است که --in=FILE داده شده باشد و FILE یک فایل معمولی باشد، نه stdin. داده‌ها از آفست بایتی SKIP تا انتهای فایل (یا به میزانی که با --length=LEN مشخص شده) خوانده می‌شوند. در صورت عدم تعیین، آفست بایتی پیش‌فرض صفر خواهد بود (یعنی از ابتدای فایل).
SEID شناسه زیرمحفظه است. مقدار پیش‌فرض آن ۰ است که نشان‌دهنده شناسه محفظه اصلی می‌باشد.
TLEN طول کل ریزکد بارگیری‌شده (یا در حال بارگیری) بر حسب بایت است. پیش‌فرض آن صفر است که در بیشتر موارد مشکلی ایجاد نمی‌کند. این گزینه تنها زمانی به کار می‌آید که TLEN بزرگتر از LEN باشد. در این حالت TLEN به دستگاه SES با عنوان DEVICE ارسال می‌شود تا دستگاه بداند اگر در این فراخوانی تنها LEN بایت دریافت کرده، باید انتظار دریافت بقیه آن را در آینده نزدیک داشته باشد (مثلاً توسط فراخوانی دیگر). این گزینه فقط زمانی لازم است که بخش‌هایی از ریزکد در فراخوانی‌های جداگانه این ابزار ارسال می‌شوند (برای نمونه زمانی که ریزکد در دو فایل مجزا پخش شده باشد).
افزایش سطح جزئیات خروجی (یعنی خروجی اشکال‌زدایی).
چاپ رشته نسخه و سپس خروج.

در ادامه فهرستی از مقادیر پذیرفته‌شده توسط آرگومان MO این ابزار آمده است. ابتدا نام اختصاری و سپس در داخل کروشه مقادیر ده‌دهی و شانزده‌شانزدهی متناظری که می‌توانند برای MO تعیین شوند نشان داده شده‌اند.

استفاده از RECEIVE DIAGNOSTIC RESULTS برای واکشی صفحه عیب‌یابی وضعیت بارگیری ریزکد و چاپ آن.
بارگیری ریزکد با آفست‌ها و فعال‌سازی آن.
بارگیری ریزکد با آفست‌ها، ذخیره و فعال‌سازی.
بارگیری ریزکد با آفست‌ها، ذخیره و تعویق فعال‌سازی.
فعال‌سازی ریزکد معوق. هیچ دستور پیگیری RECEIVE DIAGNOSTIC RESULTS برای واکشی صفحه وضعیت بارگیری ریزکد ارسال نمی‌شود زیرا ممکن است DEVICE در حال بازنشانی باشد.

به‌جز dmc_status، این مقادیر در فیلد حالت بارگیری ریزکد در صفحه کنترلی بارگیری ریزکد قرار می‌گیرند. در مورد dmc_status، صفحه وضعیت بارگیری ریزکد با دستور RECEIVE DIAGNOSTIC RESULTS واکشی و رمزگشایی می‌شود.

نخست اینکه اگر عملیات موفقیت‌آمیز باشد، این ابزار باید بدون هیچ خروجی به کار خود پایان دهد. معمولاً سازندگان هر زمان که سفت‌افزار جدیدی منتشر می‌کنند، رشته «revision» (که ۴ نویسه طول دارد) را تغییر می‌دهند. این تغییر را می‌توان در پاسخ به دستور SCSI INQUIRY، برای نمونه با استفاده از ابزار sg_inq مشاهده کرد. ممکن است لازم باشد دستگاه را خاموش و روشن (power cycle) کنید تا ریزکد جدید فعال شود. همچنین اگر برای بارگیری ریزکد از حالت dmc_offs_defer [0xe] استفاده شده باشد، ممکن است به یک فراخوانی دیگر با activate_mc نیاز باشد.

اگر مشکلی رخ دهد، معمولاً پیام‌هایی توسط این ابزار چاپ می‌شود. نخستین چیزی که باید بررسی شود خود فایل ریزکد (سفت‌افزار) است: آیا برای مدل این دستگاه طراحی شده است؟ آیا فایل آسیب دیده است؟ و در صورت تلاش برای تنزل نسخه (یعنی بازگرداندن سفت‌افزار قدیمی‌تر)، آیا سازنده چنین کاری را مجاز می‌داند؟

بارگذاری سفت‌افزار جدید روی دستگاه یک عملیات حساس است که همیشه در استانداردها و پیش‌نویس‌های T10 به روشنی تعریف نشده است. شاید بتوان حدس زد که این استانداردها عمداً مبهم تدوین شده‌اند. در آزمایش‌های این ابزار، تفسیر یک سازنده از استاندارد تا حدی شگفت‌آور بود. گزینه --non برای مدیریت همین تفسیر خاص افزوده شد. بنابراین اگر پیشنهادهای بالا کمکی نکرد، گزینه --non را اضافه کنید.

این ابزار می‌تواند حداکثر ۲۵۶ مگابایت ریزکد را پردازش کند که برای بیشتر کاربردها کافی است. در سیستمی که محدودیت حافظه دارد، چنین تخصیص‌های بزرگ حافظه ممکن است با شکست روبرو شوند.

کاربر باید بداند که بیشتر سیستم‌عامل‌ها برای میزان داده‌ای که می‌توان با یک دستور SCSI ارسال کرد محدودیت‌هایی دارند. در لینوکس این مقدار به سازوکار گذر مستقیم استفاده‌شده (مانند SG_IO بلوکی یا راه‌انداز sg) و تنظیمات گوناگون sysfs در سری هسته‌های لینوکس 2.6 و 3 (مانند ‎/sys/block/sda/queue/max_sectors_kb‎) بستگی دارد. دستگاه‌ها (یعنی واحدهای منطقی) نیز معمولاً محدودیت‌هایی در مورد حداکثر داده‌ای که می‌توانند در یک دستور پردازش کنند دارند. این دو محدودیت نشان می‌دهند که با بزرگ‌تر شدن فایل‌های سفت‌افزار، استفاده از حالت‌های حاوی کلمه «offset» به همراه گزینه --bpw=CS الزامی خواهد بود؛ و CS می‌تواند بسیار کوچک باشد، برای نمونه ۴۰۹۶ بایت، که منجر به ارسال چندین دستور SEND DIAGNOSTIC می‌شود.

خطای دقیق ناشی از پیاده‌سازی غیر استاندارد، کلید حس (sense key) از نوع ILLEGAL REQUEST و کد asc/ascq برابر با 0x26,0x0 بود که نشان‌دهنده «Invalid field in parameter list» (فیلد نامعتبر در فهرست پارامتر) است. در صورت مشاهده چنین خطایی، دوباره با گزینه --non امتحان کنید.

بارگیری ریزکد نادرست روی یک دستگاه می‌تواند موجب از کار افتادن کامل آن دستگاه شود. امید است که سازنده دستگاه داده‌ها را پیش از فعال‌سازی اعتبارسنجی کند.

یک زمان مهلت طولانی (سیستم‌عامل) معادل ۷۲۰۰ ثانیه برای هر دستور SEND DIAGNOSTIC تنظیم شده است.

تمام اعداد ارائه‌شده با گزینه‌ها ده‌دهی فرض می‌شوند. همچنین می‌توان مقادیر عددی را به‌صورت شانزده‌شانزدهی همراه با پیشوند «0x» یا «0X» (یا پسوند «h» یا «H») وارد کرد.

اگر هیچ فایل ریزکد/سفت‌افزاری تعیین نشود، این ابزار صفحه عیب‌یابی وضعیت بارگیری ریزکد را واکشی و رمزگشایی می‌کند که می‌تواند احیاناً آغازگر دیگری را نشان دهد که در حال به‌روزرسانی ریزکد است. حتی اگر چنین باشد، واکشی صفحه وضعیت نباید مشکلی ایجاد کند:

$ sg_ses_microcode /dev/sg3
Download microcode status diagnostic page:
  number of secondary sub-enclosures: 0
  generation code: 0x0
  sub-enclosure identifier: 0 [primary]
   download microcode status: No download microcode operation in progress [0x0]
   download microcode additional status: 0x0
   download microcode maximum size: 1048576 bytes
   download microcode expected buffer id: 0x0
   download microcode expected buffer id offset: 0

دستور زیر ریزکد/سفت‌افزار جدید را به یک محفظه ارسال می‌کند. ارسال یک فایل ۱.۵ مگابایتی در یک دستور موجب قفل شدن موقت محفظه شد و سفت‌افزار را به‌روزرسانی نکرد. شکستن فایل سفت‌افزار به تکه‌های ۴ کیلوبایتی (یک حدس تجربی) موفقیت‌آمیزتر بود:

sg_ses_microcode -b 4k -m dmc_offs_save -I firmware.bin /dev/sg4

به‌روزرسانی سفت‌افزار در چرخه خاموش و روشن بعدی محفظه رخ داد. در محفظه‌های امروزی، صفحه Extended Inquiry VPD مشخص می‌کند که ارتقای سفت‌افزار در چه شرایطی انجام خواهد شد.

وضعیت خروج sg_ses_microcode در صورت موفقیت ۰ است. در غیر این صورت به صفحه راهنمای sg3_utils(8) مراجعه کنید.

نوشته‌شده توسط Douglas Gilbert.

گزارش باگ‌ها را به <dgilbert at interlog dot com> بفرستید.

حق نشر © 2014-2026 Douglas Gilbert
این نرم‌افزار تحت مجوز BSD-2-Clause توزیع می‌شود. هیچ ضمانتی وجود ندارد؛ حتی برای قابلیت فروش یا مناسب بودن برای یک هدف خاص.

sg_ses, sg_write_buffer, sg_inq(sg3_utils)

March 2026 sg3_utils-1.43