מדריך לשילוב עדכוני קושחה של Fwupd

גרסה: 1.0.2
תאריך עדכון אחרון: 12 במרץ 2025

אמ;לק

המסמך הזה נועד להסביר איך ספקים יכולים להטמיע את fwupd בפרויקטים עתידיים. הוא כולל גם תובנות שצוטטו ישירות מהמפתחים של LVFS. Fwupd היא מסגרת לעדכון קושחה בקוד פתוח, שיכולה לעזור לנו למרכז את האופן שבו אנחנו מבצעים עדכוני קושחה בשותפות עם ספקים חיצוניים.

שלב ראשון – איסוף מידע ומתן הנחיות

לספקים – קודם צריך לשאול:

  • שאלות על רכיבים שניתן לעדכן

    • גודל העדכון

    • מועד העדכון

    • סוג העדכון הקיים (A/B או מודל של מנהל אתחול/זמן ריצה)

    • מה קורה לפונקציונליות של הרכיב במהלך עדכון?

    • מה צריך לקרות למערכת כדי להתחיל להשתמש בעדכון מוצלח?

    • האם צריך להתקין כמה רכיבים בסדר מסוים?

  • היכרות עם עבודה עם LVFS/fwupd או ידע בנושא

  • יכולת להקצות משאבים מהנדסה כדי לעזור בהטמעת הפלאגין (פרטים נוספים מופיעים בהמשך)

  • התחייבות לפרסם את הפלאגין בקוד פתוח ב-LGPLv2+ (קוד שכותב את הקושחה לרכיב) ולאפשר ל-LVFS להפיץ מחדש את הקושחה

לספקים – הנחיה ראשונית:

  • העדכון צריך לצמצם את משך הזמן שבו הפונקציונליות של הרכיב ההיקפי או הפנימי מושפעת, רצוי לכמה שניות. החלק הארוך של העדכון אמור להתבצע ברקע ללא הפרעה למשתמש.

    • אם ההתקן ההיקפי הזה משפיע על חוויית המשתמש באופן ברור (למשל, המסך מפסיק לפעול), הדרישה הזו מחמירה עוד יותר.

  • כדי להפעיל את סוג העדכון הזה, מומלץ מאוד להשתמש בעדכוני A/B.

    • עדכוני A/B שאפשר להפעיל בזמן ניתוק של ציוד היקפי הם אידיאליים כדי למזער את ההפרעה למשתמשים

  • צריך להיות אפשרי לשחזר את העדכון – אם מכבים את המכשיר, מנתקים את הציוד ההיקפי וכו', העדכון לא אמור להפוך את המכשיר או את הציוד ההיקפי לבלתי שמיש. הוא צריך להיות עמיד כדי שניתן יהיה לשחזר אותו ללא פעולה מצד המשתמש.

    • ההנחה הראשונית צריכה להיות שאין פעולה של משתמש במהלך כל העדכון, והסקריפטים והשלבים המתאימים של העדכון צריכים לפעול באופן עצמאי.

שלב שני – שימוש ב-fwupd

אם ספק אף פעם לא השתמש ב-fwupd

  • Chrome OS מעביר את הדרישות לעדכון הקושחה דרך fwupd ל-OEM. יצרני ציוד מקורי צריכים להעביר את המידע הזה ישירות לספקים של שבבים או רכיבים

  • במקרים מסוימים, ספקי ODM יכולים לעזור ליצרני ציוד מקורי ליצור קשר ישירות עם ספקי שבבים. באחריות יצרן הציוד המקורי להעביר את הדרישות האלה בהתאם.

  • לתשומת ליבכם: אם אתם מספקים קוד מקור ברישיון LGPLv2+, בדרך כלל לא ניתן להסיק את הפלאגין מהקוד הזה (יש הרבה פרטים מורכבים). לכן בתרחיש הזה, ספק הצ'יפים יצטרך למצוא מישהו שיכול לעבוד עם המטפלים ב-fwupd ועם מהנדסי Google.

  • יצרני הציוד המקורי יכולים לפעול באופן יזום ולעזור לקבל התחייבות של ספקי הצ'יפים לעבוד בשיתוף פעולה הדוק עם המטפלים. הדרישות לבקשה לתמיכה מהנדסית מצד הספק הן:

    • ידע מעמיק במיוחד לגבי תכונות העיצוב והתכונות המיוחדות של רכיב החומרה שניתן לעדכון, רצוי שגם יהיה באותו צוות שכתב את הקושחה

    • הסבר על ההבדל בין רישיונות נפוצים של קוד פתוח (למשל LGPLv2 ו-MIT)

    • ידע מעשי בשפת C, עם הבנה בסיסית של GLib ו-GObject, ובמיוחד הבנה של GErrors

    • יש לכם חשבון GitHub ואתם יודעים איך לפתוח ולעדכן בקשת משיכה, לבצע בדיקות קוד ב-GitHub וללמוד איך fwupd מובנה עם כל הכלים ש-fwupd מספק (למשל, חלוקה למקטעים, צירוף/ניתוק, ניסיונות חוזרים במכשיר, HID וכו')

    • אופציונלי: אפשרות לשלוח דוגמאות חומרה לבריטניה – שימושית מאוד למנהלי fwupd כדי לעזור לספק לנפות באגים ולהוסיף את הלוח לבדיקות fwupd שמתבצעות בכל גרסה. הבדיקה האחרונה חשובה כדי למנוע נסיגה (regression) בהסתעפות הפיתוח.

  • במקביל, יצרני הציוד המקורי יכולים להתחיל לפעול דרך רשימת התפוצה של fwupd או ישירות עם Richard Hughes‏ (hughsient@gmail.com) ולעבור על התוכנית לפני כתיבת הקוד של הפלאגין.

  • אם מדובר בחברה קטנה עם מעט משאבים מהנדסיים או ללא הבנה של קוד פתוח, ההצעה הבאה עשויה לעזור:

    • ספק הרכיב יכול להשתמש בחברות ייעוץ שמכירות את עבודת הקוד הפתוח (לא שתהיה עלות נוספת)

    • ההצעה הזו יכולה לעזור בהתאמה לעומס, אבל היתרון של הבעלים של המכשיר שעושים את זה בעצמם הוא שהמהנדסים מתרגלים לתהליך ויכולים להוסיף בקלות VID/PID בעתיד לחומרה חדשה. בנוסף, קל יותר לסגור שאלות או בעיות כדי לנפות באגים בחומרה.

שלב שלישי – השלבים האחרונים

  • בסופו של דבר, הקוד עובר עיבוד מחדש ל-commits קטנים שניתנים לבדיקה, תוך שימוש בכל הפונקציונליות המשותפת ב-fwupd.

  • בסיום, הפלאגין ימוזג לקוד המקור.

    • הקוד שמשמש ב-upstream יהיה אותו קוד ב-ChromeOS

    • קובצי הבינאריים של עדכון הקושחה שנעשה בהם שימוש מחוץ ל-ChromeOS יפורסמו ב-LVFS

במקרה של ChromeOS באופן ספציפי:

  • יצרן הציוד המקורי צריך להעלות את הקובץ הבינארי של הקושחה לשרתים שלנו דרך CPFE

  • עדיין צריך להיות בארכיון LVFS ארכיונים של ארונות עדכונים שניתן להפיץ מחדש כדי שבדיקות רגרסיה של החומרה יפעלו

שלב רביעי (אופציונלי) – הוספת רכיבים חדשים

  • אם מסגרת fwupd כבר מותקנת, השלב הנוסף היחיד הוא שספק הרכיב הניתן לעדכון צריך לעבוד על בקשות משיכה כדי להוסיף תכונות ייחודיות ו-VID/PIDs לגרסאות חומרה שונות.

הנחיות נוספות – עבודה עם LVFS

  • יצירת חשבון ספק חדש (הגדרה של כ-2 דקות)

  • ספקים יוצרים משתמשים לדומיין שלהם או משתמשים בשירות כמו Azure AD כדי לסנכרן את חשבונות המשתמשים עם LVFS. הם יכולים להעלות קושחת למאגרים פרטיים ולמאגרים עם אמברגו של ספקים ללא תשלום ובבדיקות מועטות מאוד (לכן לרוב המהנדסים עושים זאת כבר מההתחלה).

  • בסופו של דבר, כדי לדחוף גרסה לבדיקה או לגרסה יציבה, נדרש מסמך כלשהו מהמחלקה המשפטית שלהם, שבו כתוב בבירור ש-LVFS יכול להפיץ מחדש ולנתח את הקושחה. ההנחיה בנושא קובצי PDF ניתנה על ידי Richard. ● אם הספק הוא רק ספק סיליקון או ODM, הוא יכול להפוך ל'שותף עצמאי' של יצרן הציוד המקורי (OEM) ולהעלות קושחת בשם יצרן הציוד המקורי. יצרן הציוד המקורי יקבל גישה מלאה למה שקורה עם הקושחה שממותגת בשם שלו.

  • יש עוד הרבה דברים שצריך להגדיר (למשל, מזהה הספק מגביל אותם לקבוצה של מזהי PCI או USB), אבל לרוב הספקים כבר הוקצה מזהה וההגדרה שלו נמשכת 20 שניות.

הנחיות נוספות – קטעים ספציפיים ל-Chrome OS

  • במקרה שלנו, קובצי הבינארי של עדכון הקושחה לא נשלפים ישירות מ-LVFS. במקום זאת, קובץ ה-CAB יישמר במערכת הקבצים המקומית (rootfs)

    • זרם עבודה עתידי: שילוב הבינאר של הקושחה ב-DLC על ידי יצירת ebuild של portage בשכבת-העל המתאימה של portage

  • צריך להפעיל את fwupd (דרך ה-CLI שלו, fwupdtool) בזמן הנכון. לכל רכיב שניתן לעדכון, צריך ליצור כלל udev (או סקריפט מקביל) שיוצר אירוע fwuptool-update upstart. האירוע הזה יטפל באופן אוטומטי בהפעלת fwupdtool עם הארגומנטים הנכונים ובארגז חול מתאים (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

  • קובץ quirk לדוגמה: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk

היסטוריית גרסאות

תאריך גרסה הערות
2025-03-12 1.0.2 המרת טקסט מקובץ PDF ל-Markdown
2024-01-31 1.0.1 פרסום מחדש בפלטפורמה חדשה
2023-10-12 1.0 פרסום ראשוני