arm-trusted-firmware: set unfree only if hdcp.bin is used; otherwise delete it before building

[ghost]

This minimizes the scope of a user-visible behavior change relative to 21.11, so it is worth at least considering backporting it before the release deadline. #172160

Description of changes

The unfreeIncludeHDCPBlob parameter for arm-trusted-firmware was introduced as a result of this reviewer request and ultimately merged as part of #158310. This was part of correcting the fact that, previously, arm-trusted-firmware had the wrong meta.license.

The default value unfreeIncludeHDCPBlob?true causes a change in the meta.license field for all of the subpackages within pkgs/misc/arm-trusted-firmware/, and results in them needing NIXPKGS_ALLOW_NONFREE=1.

For Rockchip platforms this change is unavoidable; we are correcting an incorrect license declaration.

For non-Rockchip platforms the file hdcp.bin does not get included in the output; the blob is for a Synopsys HDCP core that is currently used only by Rockchip (although other companies could license it from Synopsys in the future). Therefore on non-Rockchip we can delete hdcp.bin before building instead of changing the license. This preserves the ability to build them without NIXPKGS_ALLOW_NONFREE=1.

Let's do that.

Deleting hdcp.bin ensures that we won't be caught by surprise if some future non-Rockchip Arm CPU licenses the same Synopsys HDCP core that Rockchip is using.

Thanks to @samueldr for pointing out the overly-broad NIXPKGS_ALLOW_NONFREE=1 requirement.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[Mindavi]

Isn't this possible to do with a single parameter? This looks like it may cause issues in the future due to the increased complexity.

I like doing this in general.

[ghost]

Isn't this possible to do with a single parameter?

There is only one top-level parameter visible outside of the file: unfreeIncludeHDCPBlob.

The other parameter platformCanUseHDCPBlob is not visible outside of arm-trusted-firmware.nix. The arm-trusted-firmware.nix file actually builds five platform-specific packages for five different CPUs. The platformCanUseHDCPBlob flag indicates which of these CPUs can delete hdcp.bin (without any change in functionality) rather than having to mark the package as unfree.

Perhaps I missed some other strategy here?

[ghost]

The other parameter platformCanUseHDCPBlob is not visible outside of arm-trusted-firmware.nix.

Okay that is not entirely true.

The new parameter is not exposed to users of the armTrustedFirmware${PLATFORM} packages.

However it is exposed to users who call buildArmTrustedFirmware directly. For example, somebody writing a nixpkgs expression for a new ARM CPU which isn't yet included in arm-trusted-firmware.nix. But for those users it should be exposed so they can set it correctly: only they know if the new CPU uses hdcp.bin or not.

So I do think we actually need two parameters here. platformCanUseHDCPBlob is an objective fact about the CPU in question whereas unfreeIncludeHDCPBlob is a user preference.

[ghost]

Added a comment to explain the new parameter, and reordered the args list to place it next to platform. No other changes.

[ghost]

Latest push just squashes to a single commit, no other changes.

In a moment I will submit another PR with an alternative implementation that might do a better job of addressing @Mindavi's concern.

[ghost]

In a moment I will submit another PR with an alternative implementation that might do a better job of addressing @Mindavi's concern.

#175372

I have verified that the top-level expressions are extensionally equivalent -- they nix-instantiate to the same derivation for both this PR and #175372.

[mweinelt]

You're pinging people left and right, please be more mindful about what you force-push.

[ghost]

You're pinging people left and right

I know. I don't want to send these pings. Please tell me how to disable or retract the pings.

[Mindavi]

Ok yeah, I do like this one more, I guess.

Ofborg results also seem ok, it indeed refuses to build the rk3399 but does build the normal allwinner one.

[Mindavi]

@ofborg build armTrustedFirmwareRK3399 armTrustedFirmwareAllwinner

[ghost]

Actually you need to

@ofborg build pkgsCross.aarch64-multiplatform.armTrustedFirmwareRK3399

I think ofborg runs with NIXPKGS_ALLOW_UNFREE=1.

[ghost]

For completeness, to cover the platformCanUseHDCPBlob=false case:

@ofborg build pkgsCross.aarch64-multiplatform.armTrustedFirmwareAllwinner

And the buildPlatform-side tooling, which has a somewhat-different build path:

@ofborg build pkgsCross.armTrustedFirmwareTools

That should cover the important stuff.