Bug 1846139 - Review Request: mlxbf-aarch64-firmware - Boot firmware (ATF, UEFI...) for Mellanox BlueField
Summary: Review Request: mlxbf-aarch64-firmware - Boot firmware (ATF, UEFI...) for Mel...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1656148 1853081
TreeView+ depends on / blocked
 
Reported: 2020-06-10 21:13 UTC by Spencer Lingard
Modified: 2020-07-01 21:52 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---


Attachments (Terms of Use)

Description Spencer Lingard 2020-06-10 21:13:03 UTC
Spec URL: https://download.copr.fedorainfracloud.org/results/slingard/mlxbf-aarch64-firmware/fedora-rawhide-aarch64/01441155-mlxbf-aarch64-firmware/mlxbf-aarch64-firmware.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/slingard/mlxbf-aarch64-firmware/fedora-rawhide-aarch64/01441155-mlxbf-aarch64-firmware/mlxbf-aarch64-firmware-3.0.beta1.11287-2.fc33.src.rpm
Scratch Koji URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=45583529
Source Repository: https://github.com/Mellanox/bootimages/tree/bluefield-rel/3.x
Fedora Account System Username: slingard

Description: This is a binary package that contains firmware required to boot the ARM64 cores in Mellanox BlueField chips. These files do nothing on their own, but may be installed with a tool such as mlxbf-bootctl (BZ #1835452).

Taken together, this package and mlxbf-bootctl are the minimum required to install new boot firmware on BlueField.

Comment 1 Robert-André Mauchin 🐧 2020-06-26 20:35:55 UTC
 - Source must be a URL, or you must document how to generate the archive.

Source: mlxbf-aarch64-firmware.tar.gz

 - Not needed:

%defattr(644, root, root)

 - Latest tag is 3.0.beta1-2, please get the archive from Github directly

 - BetaX goes into Release field (as extraver) or use the tilde notation. See https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde

Version: 3.0~beta1-2
Release: 2%{?dist}

- This is basically binary firmwares with no source on how to build them?

Policy on Firmware for the record

Some applications, drivers, and hardware require binary-only firmware to boot Fedora or function properly. Fedora permits inclusion of these files as long as they meet the following requirements:

Requirements:

  x  The files are non-executable within the Fedora OS context (note: this means that the files cannot run on their own, not that they are just chmod -x)
  x  The files are not libraries, within the Fedora OS context.
  x The files are standalone, not embedded in executable or library code (within the Fedora OS context).
  x The files must be necessary for the functionality of open source code being included in Fedora OR to enable Fedora to boot on a specific device, where no other reliable and supported mechanisms exist.
  x The files are available under an acceptable firmware license, which is included with the files in the packaging.

The Fedora Project considers a firmware license acceptable if:

    it allows some form of royalty-free use, subject to restrictions that the Fedora Project has determined are acceptable for firmware licenses (see below), and
    it does not restrict redistribution in ways that would make a software license unacceptable under Fedora licensing guidelines, except by:
        requiring that the firmware be redistributed only as incorporated in the redistributor's product (or as a maintenance update for existing end users of the redistributor's product), possibly limited further to those products of the redistributor that support or contain the hardware associated with the licensed firmware; and
        requiring the redistributor to pass on or impose conditions on users that are no more restrictive than those authorized by this Fedora firmware licensing policy.

A non-exhaustive list of restrictions on use that Fedora considers acceptable for firmware licenses are:

    any restrictions that are found in software licenses that are acceptable for Fedora;
    prohibitions on modification;
    prohibitions on reverse engineering, disassembly or decompilation;
    restricting use to use in conjunction with the hardware associated with the firmware license.

If you are unsure whether or not your files meet these requirements, ask on fedora-devel-list, and we will examine them for you.

The License tag for any firmware that disallows modification must be set to: "Redistributable, no modification permitted"

Firmware packages must be named <foo>-firmware, where <foo> is the driver or other hardware component that the firmware is for. In cases of firmware used to boot Fedora on a device, <foo> must be the type of device(s) that the firmware is intended for (e.g. raspberrypi). 

I'm gonna ask legal or devel to be sure.

Comment 2 Xose Vazquez Perez 2020-06-26 21:24:29 UTC
Firmware should be sent to upstream repo: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

Follow the instructions of: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README

Comment 3 Peter Robinson 2020-06-28 11:27:03 UTC
(In reply to Xose Vazquez Perez from comment #2)
> Firmware should be sent to upstream repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

No, I don't believe the early boot firmware such as ATF/UEFI etc fit the linux-firmware.

The question here is if it's for updating firmwares using UEFI capsule updates on a SPI flash or whether they have to be on the same storage as the OS. If it's capsule updates these firmwares should use the LVFS and be dealt with separately to the OS.


Note You need to log in before you can comment on or make changes to this bug.