On 6/9/22 18:06, Vagrant Cascadian wrote:
It looks like u-boot 2022.07-rc1 introduced a reproducibility issue that
is dependent on the running kernel.
I believe the commit that triggered this issue is:
f7691a6d736bec7915c227ac14076f9993a27367 sandbox: allow cross-compiling
sandbox
Thanks for reporting the issue.
Said patch does not change the value of MK_ARCH for CROSS_COMPILE="".
So this is not the relevant patch.
While the use of uname in the Makefile goes back well before this
commit, previously it had no apparent effect on the builds...
When building natively (e.g. CROSS_COMPILE is not set) with a 32-bit
userland toolchain, but running a 64-bit kernel, 32-bit arm targets end up
with BOOTAA64.EFI embedded in the binaries:
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/u-boot.html
The EFI boot manager can boot according to boot options define as UEFI
variables BOOT. We recently introduced support for booting via these
variables if they only point to a block device without a filename. In
this case we need to provide the name of the EFI binary. Only for the
sandbox this should depend on host architecture.
I need to correct include/efi_default_filename.h to only use variable
HOST_ARCH for the sandbox.
Best regards
Heinrich
/EFI/BOOT/BOOTARM.EFI
vs.
/EFI/BOOT/BOOTAA64.EFI
live well,
vagrant