As explained in the new comment, we trick the build system here to build
its build tools for the host platform. To make this even more foolproof
/ reliable, stop adding CC_FOR_BUILD to the environment, so there can be
no mix up.
Some of the firmware requires an arm-embedded toolchain to be in PATH.
The Makefile offers a similar mechanism to CROSS_COMPILE for letting it
know what naming scheme is used for the accompanying tools.
sptool was replaced by a Python script. It wouldn't be too hard to install/wrap
the new script, but I doubt anyone uses it. I made sptool part of the
armTrustedFirmwareTools package when I created it simply because it was trivial
to add, not because it was actually necessary.
Fixes:
```
.../aarch64-unknown-linux-gnu-ld.bfd: warning: /build/source/build/rk3399/release/bl31/bl31.elf has a LOAD segment with RWX permissions
.../aarch64-unknown-linux-gnu-ld.bfd: warning: /build/source/build/rk3399/release/bl31/bl31.elf has a LOAD segment with RWX permissions
.../aarch64-unknown-linux-gnu-ld.bfd: warning: /build/source/build/rk3399/release/bl31/bl31.elf has a LOAD segment with RWX permissions
make: *** [Makefile:1306: /build/source/build/rk3399/release/bl31/bl31.elf] Error 1
```
See: https://developer.trustedfirmware.org/T996
The arm-trusted-firmware/default.nix expression exposes
`buildArmTrustedFirmware` and its `version?"2.7"` field to
`top-level/all-packages.nix`. Unfortunately it doesn't work.
Changing the version field doesn't change what version of the ATF
source code is used. Attempting to "lock" an installation to a
specific version by overriding this field (e.g. version="2.7") won't
work either; when nixpkgs bumps the version to 2.8 the user will end
up building the 2.8 source code but the resulting expression will be
labeled misleadingly in the store:
```
/nix/store/eeee...-arm-trusted-firmware-2.7/
```
**using the 2.8 source code**. So not only does `version` not lock
the version, it will actually *conceal* the fact that the underlying
source code has been upgraded!
Let's just remove the `version` field. It doesn't work and never did.
https://github.com/NixOS/nixpkgs/pull/185004#discussion_r939526830
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
The `unfreeIncludeHDCPBlob` parameter was introduced as a result of
this reviewer request:
https://github.com/NixOS/nixpkgs/issues/148890#issuecomment-1032002903
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 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.
Use easier-to-follow names for controlling the blob
inclusion/exclusion. Also, if the blob is believed to be unnecessary,
delete it beforehand so we will know if we were wrong about that belief.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
This change implements @lukegb's idea:
https://github.gitop.top/NixOS/nixpkgs/issues/148890#issuecomment-1032002903
Specifically, it introduces a new parameter unfreeIncludeHDCPBlob
(defaults to true):
* If unfreeIncludeHDCPBlob==true then the license is changed to
unfreeRedistributable, which will alert the user to the fact that
the blob is being included (unless they set NIXPKGS_ALLOW_UNFREE=1).
* If unfreeIncludeHDCPBlob==false then the license is kept as bsd3, but
a patch is applied to remove the HDCP blob from the build.
ARM trusted firmware is required as part of the boot process on some ARMv8-A
boards. Currently, only the RK3328 is supported in nixpkgs.
This makes the Rock64 u-boot image bootable.
