راهنمای یکپارچه سازی به روز رسانی های سفت افزار Fwupd

نسخه: 1.0.2
آخرین به روز رسانی: 2025-03-12

TL; DR

این سند در نظر گرفته شده است تا توضیحی در مورد چگونگی اجرای fwupd توسط فروشندگان برای پروژه های آینده باشد. این شامل بینشی است که مستقیماً از نگهبانان LVFS نقل شده است. Fwupd یک چارچوب به‌روزرسانی میان‌افزار منبع باز است که می‌تواند به متمرکز کردن روش انجام به‌روزرسانی میان‌افزار در مشارکت با فروشندگان خارجی کمک کند.

مرحله اول - جمع آوری اطلاعات و ارائه راهنمایی

برای فروشندگان - ابتدا بپرسید:

  • سوالات مربوط به مؤلفه (های) قابل به روز رسانی

    • به روز رسانی اندازه

    • زمان به روز رسانی

    • نوع به روز رسانی موجود (A/B یا مدل بوت لودر/ زمان اجرا)

    • در حین به روز رسانی چه اتفاقی برای عملکرد مؤلفه می افتد؟

    • برای شروع استفاده از یک آپدیت موفق چه اتفاقی باید برای سیستم بیفتد؟

    • آیا لازم است چندین مؤلفه به ترتیب خاصی نصب شوند؟

  • آشنایی با کار با LVFS/fwupd یا آشنایی با آن

  • امکان استفاده از منابع eng برای کمک به پیاده سازی افزونه (برای جزئیات بیشتر به زیر مراجعه کنید)

  • تعهد به پلاگین منبع باز به LGPLv2+ (کدی که سفت‌افزار را روی جزء می‌نویسد) و امکان توزیع مجدد میان‌افزار توسط LVFS

برای فروشندگان - راهنمایی اولیه:

  • به‌روزرسانی باید زمان تحت تأثیر قرار گرفتن عملکرد اجزای جانبی یا داخلی را به حداقل برساند، در حالت ایده‌آل تا چند ثانیه. بخش طولانی‌تر به‌روزرسانی باید به‌صورت بی‌صدا در پس‌زمینه و بدون ایجاد اختلال در کاربر انجام شود

    • اگر این ابزار جانبی به شیوه‌ای آشکار بر تجربه کاربر تأثیر بگذارد (مثلاً نمایشگر کار نمی‌کند)، این الزام حتی سخت‌تر می‌شود.

  • برای فعال کردن این نوع به‌روزرسانی بی‌صدا، به‌روزرسانی‌های A/B قویاً توصیه می‌شوند

    • به‌روزرسانی‌های A/B که می‌توانند در قطع برق محیطی فعال شوند، برای به حداقل رساندن اختلال کاربر ایده‌آل هستند

  • به‌روزرسانی باید قابل بازیابی باشد - اگر دستگاه را خاموش کنید، دستگاه جانبی را از برق بکشید و غیره، به‌روزرسانی نباید دستگاه یا دستگاه جانبی را آجر کند. برای بازیابی بدون اقدام کاربر باید قوی باشد.

    • فرض اولیه باید این باشد که هیچ اقدام کاربر در طول کل به روز رسانی وجود نداشته باشد، اسکریپت ها و مراحل مناسب به روز رسانی باید به طور مستقل هدایت شوند.

مرحله دوم - استفاده از fwupd

اگر فروشنده ای هرگز از fwupd استفاده نکرده باشد

  • سیستم عامل Chrome الزامات به روز رسانی سیستم عامل را از طریق fwupd به OEM ارائه می دهد. OEM باید این موضوع را مستقیماً به تأمین کنندگان تراشه / قطعه ارسال کند

  • در برخی موارد، ODM می تواند به رابط OEM به طور مستقیم با فروشندگان تراشه کمک کند. این مسئولیت OEM است که این الزامات را بر اساس آن ارتباط برقرار کند

  • لطفاً توجه داشته باشید که در صورت ارائه کد منبع با مجوز LGPLv2+، استخراج افزونه از این کد معمولاً امکان پذیر نیست (پیچیدگی های زیادی). بنابراین در این سناریو، فروشنده تراشه ملزم به داشتن شخصی است که بتواند با نگهبانان fwupd و مهندسان Google کار کند.

  • OEM می تواند فعال باشد و به جلب تعهد فروشندگان تراشه برای همکاری نزدیک با نگهبانان کمک کند. درخواست پشتیبانی مهندسی از طرف فروشنده دارای شرایط زیر است:

    • بسیار آشنا با ویژگی‌های طراحی و ویژگی‌های سخت‌افزاری قابل به‌روزرسانی، حتی ترجیحاً در همان تیمی باشید که سیستم‌افزار را نوشته است.

    • تفاوت بین مجوزهای متن باز رایج (مانند LGPLv2 و MIT) را درک کنید.

    • در زبان C مهارت داشته باشید، با درک اولیه GLib و GObject، به ویژه درک GErrors نیز

    • یک حساب github داشته باشید و بدانید که چگونه یک درخواست کشش را باز و به روز کنید، کدهای GitHub را بررسی کنید، و یاد بگیرید که چگونه fwupd با تمام کمک هایی که fwupd ارائه می دهد (مثلاً تکه تکه کردن، پیوست/جدا کردن، تلاش مجدد دستگاه، HID و غیره) ساختار یافته است.

    • اختیاری: توانایی ارسال نمونه‌های سخت‌افزار به انگلستان - برای نگهدارنده‌های fwupd برای کمک به فروشنده در رفع اشکال‌ها و اضافه کردن برد به آزمایش‌های fwupd که در هر نسخه اجرا می‌شوند بسیار مفید است. مورد دوم برای جلوگیری از رگرسیون در شاخه توسعه مهم است.

  • به موازات آن، OEM می تواند از طریق لیست پستی fwupd یا با ریچارد هیوز (hughsient@gmail.com) مستقیماً شروع به تعامل کند و قبل از نوشتن کد افزونه، طرح را بررسی کند.

  • اگر یک شرکت کوچک است و منابع مهندسی کم یا بدون درک منبع باز دارد، پیشنهاد زیر ممکن است کمک کند:

    • فروشنده مؤلفه می تواند از شرکت های مشاوره ای استفاده کند که با کار منبع باز آشنا هستند (نه اینکه هزینه اضافی را متحمل شود)

    • در حالی که این پیشنهاد می تواند به مقیاس کمک کند، ارزش فروشنده ای که آن را در داخل انجام می دهد این است که مهندسان با این فرآیند آشنا شده و می توانند به راحتی VID/PID را در آینده برای سخت افزار جدید اضافه کنند. همچنین سریعتر در مورد سؤالات / مسائل برای رفع اشکال در سخت افزار بسته می شود

مرحله سوم - مراحل نهایی

  • در نهایت کد با استفاده از تمام عملکردهای مشترک در fwupd به commit های کوچک قابل بررسی تبدیل می شود.

  • پس از تکمیل، افزونه در بالادست ادغام می شود

    • کد استفاده شده در بالادست همان کد در ChromeOS خواهد بود

    • باینری‌های به‌روزرسانی میان‌افزاری که خارج از ChromeOS استفاده می‌شوند در LVFS توزیع می‌شوند

به طور خاص در مورد ChromeOS:

  • OEM باید باینری سیستم عامل را از طریق CPFE در سرورهای ما آپلود کند

  • هنوز باید آرشیوهای کابینت به روز رسانی قابل توزیع مجدد در LVFS وجود داشته باشد تا تست های رگرسیون سخت افزاری کار کنند.

مرحله چهارم (اختیاری) - افزودن اجزای جدید

  • اگر چارچوب fwupd در حال حاضر وجود داشته باشد، تنها مرحله اضافی این است که تأمین‌کننده مؤلفه‌های قابل به‌روزرسانی باید روی درخواست‌های کششی برای اضافه کردن ویژگی‌ها و VID/PID برای انواع سخت‌افزار کار کند.

راهنمایی های دیگر - کار بر روی LVFS

  • ایجاد یک حساب فروشنده جدید (2 دقیقه برای راه اندازی)

  • فروشندگان کاربرانی را برای دامنه خود ایجاد می کنند یا از چیزی مانند Azure AD برای همگام سازی حساب های کاربری با LVFS استفاده می کنند. آن‌ها می‌توانند سیستم‌افزار را به صورت کاملاً رایگان و با بررسی‌های بسیار کمی روی خصوصی و تحریم‌های فروشنده آپلود کنند (بنابراین اغلب مهندسان این کار را از همان ابتدا انجام می‌دهند)

  • در نهایت فشار برای آزمایش یا پایدار نیاز به نوعی سند از بخش حقوقی آنها دارد که به وضوح می گوید LVFS می تواند سیستم عامل را مجددا توزیع و تجزیه و تحلیل کند. راهنمای PDF توسط ریچارد ارائه شده است. ● اگر فروشنده فقط یک تامین‌کننده سیلیکون یا یک ODM باشد، می‌تواند به "وابسته‌های" OEM تبدیل شود و می‌تواند از طرف خود سفت‌افزار را آپلود کند، در حالی که OEM از آنچه در میان‌افزار مارک‌شده با نام خود روی می‌دهد کاملاً قابل مشاهده است.

  • چیزهای زیادی برای تنظیم وجود دارد (مثلاً شناسه فروشنده آنها را به مجموعه ای از شناسه های PCI یا USB محدود می کند) اما اکثر فروشندگان قبلاً یک شناسه اختصاص داده شده دارند و تنظیم آن 20 ثانیه است.

سایر راهنمایی ها - بیت های خاص سیستم عامل Chrome

  • در مورد ما، باینری های به روز رسانی سیستم عامل مستقیماً از LVFS خارج نمی شوند. در عوض فایل CAB در سیستم فایل محلی (rootfs) ذخیره خواهد شد.

    • جریان کاری آینده: باینری سیستم عامل را در DLC با ایجاد یک ebuild portage بر روی همپوشانی پورتاژ مناسب وارد کنید

  • fwupd باید (از طریق CLI fwupdtool) در زمان مناسب فراخوانی شود. برای هر جزء قابل به‌روزرسانی، یک قانون udev (یا اسکریپت معادل) باید ایجاد شود که یک رویداد upstart fwuptool-update را منتشر می‌کند. این رویداد به طور خودکار برای اجرای fwupdtool با آرگومان‌های مناسب و sandboxing مناسب (minijail) مدیریت می‌شود.

  • مؤلفه دیگر تصمیم گیری در مورد نیاز به رابط کاربری است - فقط در شرایط خاصی بسته به ماهیت مؤلفه به روز شده. برای ارزیابی توسط تیم PM و Eng. راهنمایی سطح بالاتر، همانطور که در مرحله اول ذکر شد، به حداقل رساندن عمل از سمت کاربر است

منابع اضافی برای فروشندگان

  • مرجع اسناد خارجی: https://lvfs.readthedocs.io/

  • مرجع قراردادهای فروشنده خارجی: fwupd.org/lvfs/docs/agreement

  • آموزش توسعه افزونه: https://fwupd.github.io/tutorial.html

  • آموزش رفع اشکال افزونه: https://lvfs.readthedocs.io/en/latest/custom-plugin.html

  • نمونه فایل عجیب و غریب: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk

تاریخچه تجدید نظر

تاریخ نسخه یادداشت ها
12-03-2025 1.0.2 تبدیل متن از پی دی اف به علامت گذاری
31-01-2024 1.0.1 جمهوری در پلت فرم جدید
12-10-2023 1.0 انتشار اولیه