버전: 1.0.2
최종 업데이트: 2025년 3월 12일
요약
이 문서는 공급업체가 향후 프로젝트에 fwupd를 구현하는 방법을 안내하는 걸음걸이입니다. LVFS 유지보수자의 의견도 직접 인용하여 포함합니다. Fwupd는 외부 공급업체와 협력하여 펌웨어 업데이트를 실행하는 방식을 중앙 집중화하는 데 도움이 되는 오픈소스 펌웨어 업데이트 프레임워크입니다.
첫 번째 단계 - 정보 수집 및 안내 제공
공급업체의 경우 - 첫 번째 문의:
업데이트 가능한 구성요소에 관한 질문
업데이트 크기
업데이트 시간
기존 업데이트 유형 (A/B 또는 부트로더/런타임 모델)
업데이트 중에 구성요소의 기능은 어떻게 되나요?
업데이트를 성공적으로 사용하려면 시스템에 어떤 일이 일어나야 하나요?
여러 구성요소를 특정 순서로 설치해야 하나요?
LVFS/fwupd 사용에 익숙하거나 이에 대한 지식
플러그인 구현을 지원하기 위해 엔지니어링 리소스를 커밋할 수 있는 기능 (자세한 내용은 아래 참고)
LGPLv2+에 플러그인을 오픈소스로 제공하고 (구성요소에 펌웨어를 쓰는 코드) LVFS에서 펌웨어를 재배포할 수 있도록 허용하기 위한 노력
공급업체를 위한 초기 안내:
업데이트는 주변기기 또는 내부 구성요소 기능이 영향을 받는 시간을 최소화해야 합니다(최대 몇 초). 업데이트의 긴 부분은 사용자에게 방해가 되지 않고 백그라운드에서 자동으로 실행되어야 합니다.
- 이 주변기기가 명백한 방식으로 사용자 환경에 영향을 미치는 경우 (예: 디스플레이가 작동하지 않음) 이 요구사항이 더욱 엄격해집니다.
이러한 유형의 무음 업데이트를 사용 설정하려면 A/B 업데이트를 적극 권장합니다.
- 주변기기의 전원 플러그를 뽑을 때 활성화할 수 있는 A/B 업데이트는 사용자에게 미치는 영향을 최소화하는 데 이상적입니다.
업데이트는 복구 가능해야 합니다. 전원을 끄거나 주변기기를 분리하는 등의 경우 업데이트로 인해 기기나 주변기기가 비정상 종료되어서는 안 됩니다. 사용자 작업 없이 복구할 수 있을 만큼 견고해야 합니다.
- 전체 업데이트 중에 사용자 작업이 없다는 것이 초기 가정되어야 하며 적절한 스크립트와 업데이트 단계가 자동으로 실행되어야 합니다.
두 번째 단계 - fwupd 사용
공급업체가 fwupd를 사용한 적이 없는 경우
Chrome OS는 fwupd를 통해 OEM에 펌웨어 업데이트 요구사항을 제공합니다. OEM은 칩 / 구성요소 공급업체에 이를 직접 전달해야 합니다.
경우에 따라 ODM이 OEM이 칩 공급업체와 직접 상호작용하는 것을 도울 수 있습니다. OEM은 이러한 요구사항을 적절하게 전달할 책임이 있습니다.
LGPLv2+ 라이선스로 소스 코드를 제공하는 경우 일반적으로 이 코드에서 플러그인을 파생하는 것은 불가능합니다 (많은 복잡성). 따라서 이 시나리오에서는 칩 공급업체에 fwupd 유지보수자 및 Google 엔지니어와 협력할 수 있는 담당자가 있어야 합니다.
OEM은 유지보수 담당자와 긴밀하게 협력하겠다는 칩 공급업체의 약속을 얻기 위해 사전에 조치를 취할 수 있습니다. 공급업체 측의 엔지니어링 지원 요청에는 다음과 같은 요구사항이 있습니다.
업데이트 가능한 하드웨어 구성요소의 특징과 설계 기능에 매우 익숙하며, 가능하면 펌웨어를 작성한 팀에 속해 있는 것이 좋습니다.
일반적인 오픈소스 라이선스 (예: LGPLv2 및 MIT)의 차이점 이해
C에 능숙하고 GLib 및 GObject에 대한 기본적인 이해가 있으며 특히 GErrors도 이해함
GitHub 계정이 있고, pull 요청을 열고 업데이트하는 방법, GitHub 코드 검토를 수행하는 방법, fwupd가 제공하는 모든 도우미 (예: 청크 처리, 연결/연결 해제, 기기 재시도, HID 등)를 사용하여 fwupd가 구성되는 방식을 알아야 합니다.
선택사항: 영국으로 하드웨어 샘플을 보낼 수 있는 기능 - fwupd 유지관리자가 공급업체의 문제 디버깅을 지원하고 각 출시에서 실행되는 fwupd 테스트에 보드를 추가하는 데 매우 유용합니다. 후자는 개발 브랜치에서 회귀를 중지하는 데 중요합니다.
동시에 OEM은 fwupd 메일링 리스트를 통해 또는 리처드 휴즈 (hughsient@gmail.com)와 직접 소통을 시작하고 플러그인 코드가 작성되기 전에 계획을 검토할 수 있습니다.
엔지니어링 리소스가 거의 없거나 오픈소스에 대한 이해가 부족한 소규모 기업인 경우 다음 제안이 도움이 될 수 있습니다.
구성요소 공급업체는 오픈소스 작업에 익숙한 컨설팅 회사를 사용할 수 있습니다 (추가 비용이 발생하지 않음).
이 제안은 확장에 도움이 될 수 있지만, 공급업체에서 자체적으로 처리하면 엔지니어가 프로세스에 익숙해지고 향후 새 하드웨어에 VID/PID를 쉽게 추가할 수 있다는 이점이 있습니다. 하드웨어에서 디버그할 질문 / 문제를 더 빠르게 종료할 수도 있습니다.
3단계 - 최종 단계
결국 코드는 fwupd의 모든 공유 기능을 사용하여 검토 가능한 작은 커밋으로 리팩터링됩니다.
완료되면 플러그인이 업스트림으로 병합됩니다.
업스트림에서 사용되는 코드는 ChromeOS의 코드와 동일합니다.
ChromeOS 외부에서 사용되는 펌웨어 업데이트 바이너리가 LVFS에 배포됩니다.
특히 ChromeOS의 경우:
OEM은 CPFE를 통해 펌웨어 바이너리를 Google 서버에 업로드해야 합니다.
하드웨어 회귀 테스트가 작동하려면 LVFS에 재배포 가능한 업데이트 캐비닛 보관 파일이 여전히 있어야 합니다.
4단계 (선택사항) - 새 구성요소 추가
- fwupd 프레임워크가 이미 있는 경우 업데이트 가능한 구성요소 공급업체가 풀 리퀘스트에서 하드웨어 변형의 버그 및 VID/PID를 추가하는 작업만 하면 됩니다.
기타 안내 - LVFS 작업
새 공급업체 계정 만들기 (설정 시간: 약 2분)
공급업체는 자체 도메인의 사용자를 만들거나 Azure AD와 같은 도구를 사용하여 사용자 계정을 LVFS에 동기화합니다. 매우 적은 수의 확인으로 비공개 및 공급업체 엠바고에 무료로 완전히 펌웨어를 업로드할 수 있습니다. 따라서 엔지니어가 처음부터 이를 수행하는 경우가 많습니다.
결국 테스트 또는 안정화 버전으로 푸시하려면 LVFS가 펌웨어를 재배포하고 분석할 수 있다고 명시된 법무 부서의 서류가 필요합니다. PDF 가이드라인은 리처드가 제공합니다. ● 공급업체가 단순한 칩 공급업체 또는 ODM인 경우 OEM의 '제휴사'가 되어 OEM을 대신하여 펌웨어를 업로드할 수 있으며, OEM은 자신의 이름으로 브랜딩된 펌웨어의 상황을 완전히 파악할 수 있습니다.
설정해야 할 다른 사항이 많습니다 (예: 공급업체 ID는 PCI 또는 USB ID 집합으로 제한됨). 하지만 대부분의 공급업체에는 이미 할당된 ID가 있으며 설정하는 데 20초가 소요됩니다.
기타 안내 - Chrome OS 관련 정보
이 경우 펌웨어 업데이트 바이너리가 LVFS에서 직접 가져오지 않습니다. 대신 CAB 파일이 로컬 파일 시스템 (rootfs)에 저장됩니다.
- 향후 워크스트림: 적절한 포트리지 오버레이에서 포트리지 ebuild를 만들어 DLC에 펌웨어 바이너리를 통합합니다.
적절한 시점에 CLI fwupdtool을 통해 fwupd를 호출해야 합니다. 업데이트 가능한 각 구성요소에 대해 fwuptool-update upstart 이벤트를 내보내는 udev 규칙 (또는 이에 상응하는 스크립트)을 만들어야 합니다. 이 이벤트는 올바른 인수와 적절한 샌드박스 (minijail)를 사용하여 fwupdtool을 실행하도록 자동으로 처리됩니다.
또 다른 구성요소는 업데이트된 구성요소의 특성에 따라 특정 상황에서만 UI가 필요한지 결정하는 것입니다. PM 및 엔지니어링팀에서 평가합니다. 첫 번째 단계에서 언급한 것처럼 상위 수준의 안내는 사용자 측의 작업을 최소화하는 것입니다.
공급업체를 위한 추가 리소스
외부 문서 참조: https://lvfs.readthedocs.io/
외부 공급업체 계약 참조: fwupd.org/lvfs/docs/agreement
플러그인 개발 튜토리얼: https://fwupd.github.io/tutorial.html
플러그인 디버깅 튜토리얼: https://lvfs.readthedocs.io/ko/latest/custom-plugin.html
샘플 버그 파일: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
업데이트 기록
| 날짜 | 버전 | 참고 |
|---|---|---|
| 2025-03-12 | 1.0.2 | pdf에서 마크다운으로 텍스트 변환 |
| 2024-01-31 | 1.0.1 | 새 플랫폼에 게시 |
| 2023-10-12 | 1.0 | 최초 게시 |