Linux Vendor
Firmware Service

Introduction

This page provides a information for hardware vendors wishing to automatically deploy firmware updates, typically cab files. This fire-and-forget service allows vendors to submit firmware updates quickly and easily.

Clients such as fwupd check for updated metadata at this site and will offer the firmware to end users or be installed automatically depending on site policy.

NOTE: This service should only be used to distribute firmware that is flashed onto non-volatile memory. It is not designed for firmware that has to be uploaded to devices every time the device is used.

There is no charge to vendors for the hosting or distribution of content.

When files are submitted the following actions are performed:

  1. The update metadata is checked for correctness.
  2. The firmware capsule is signed with our GPG key.
  3. The new cab file is moved to our infrastructure.
  4. The metadata is added to our database.

Upload Firmware

Please log in and upload files using the new secure admin console. If you need a new user created please see this page for more details.

Three classes of user exist:

Help With Submitting Firmware

If you are not using the UEFI capsule update method you need to write a plugin for fwupd to trigger the firmware update from userspace. At the moment there is just UEFI and ColorHug providers, but others are welcome.

As per the Microsoft guidelines package up your firmware into a cab file, with these files inside:

You can create a cab file using makecab.exe on Windows and gcab --create on Linux.

It is recommended you name the cab file with the vendor, device and version number, e.g. hughski-colorhug-als-1.2.3.cab. It is suggested that the files inside the cab file have the same basename, for example this is would be ideal:

    hughski-colorhug-als-1.2.3.cab
     |- firmware.inf
     |- firmware.bin
     \- firmware.metainfo.xml

An example inf file looks like this:

[Version]
Class=Firmware
ClassGuid={f2e7dd72-6468-4e36-b6f1-6488f42c1b52}
DriverVer=03/03/2015,3.0.2

[Firmware_CopyFiles]
firmware.bin

[Firmware_AddReg]
HKR,,FirmwareId,,{84f40464-9272-4ef7-9399-cd95f12da696}
HKR,,FirmwareVersion,%REG_DWORD%,0x0000000
HKR,,FirmwareFilename,,firmware.bin

[Strings]
REG_DWORD=0x00010001

An example metainfo.xml file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2015 Richard Hughes  -->
<component type="firmware">
  <id>com.hughski.ColorHugALS.firmware</id>
  <name>ColorHugALS</name>
  <summary>Firmware for the Hughski ColorHug Ambient Light Sensor</summary>
  <description>
    <p>
      Updating the firmware on your ColorHugALS device improves performance and
      adds new features.
    </p>
  </description>
  <provides>
    <firmware type="flashed">84f40464-9272-4ef7-9399-cd95f12da696</firmware>
  </provides>
  <url type="homepage">http://www.hughski.com/</url>
  <metadata_license>CC0-1.0</metadata_license>
  <project_license>GPL-2.0+</project_license>
  <developer_name>Hughski Limited</developer_name>
  <releases>
    <release version="3.0.2" timestamp="1424116753">
      <description>
        <p>This stable release fixes the following bugs:</p>
        <ul>
          <li>Fix the return code from GetHardwareVersion</li>
          <li>Scale the output of TakeReadingRaw by the datasheet values</li>
        </ul>
      </description>
    </release>
  </releases>
</component>

If the firmware is not free software you have to indicate it in the metainfo.xml file with <project_license>proprietary</project_license>.

Sometimes the firmware capsule file has to have a different filename for other workflow or legacy reasons. To achieve this just change the value of Firmware_CopyFiles and FirmwareFilename in the inf file, and also add this to the metainfo.xml file:

  <release version="0xtheversion" timestamp="1424116753">
    <checksum filename="my-custom-name.bin" target="content"/>
    ...

Metainfo Style Guide

<id>

<name>

<summary>

<description>

Why does the LVFS project sign my firmware?

The Linux Vendor Firmware Project signs the firmware image and repacks the files into a new cabinet file for several reasons:

Validation

The best way to validate the metainfo file or firmware before submission is by using the appstream-util validate tool available from the appstream-glib project.

Go back to the main page