This switches the ROCK64 over to the open-source RAM init as it now
works flawlessly. It also removes the HDCP flag from the ATF for the
RK3328 as it cannot use it, it is only used in the RK3399. This makes
the ROCK64 u-boot now fully open.
There is also an issue with the ROCK64 v2 revision where the DRAM
routing is marginal, making some of them unstable. So also package a
variant which uses a lower-speed DDR3 timing configuration which is
stable on these boards.
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.
