On 5/18/20 2:52 PM, Tom Rini wrote:
> On Sun, May 17, 2020 at 12:48:42PM +1000, Jonathan Gray wrote:
>> On Sat, May 16, 2020 at 02:54:39PM -0400, Tom Rini wrote:
>>> Add building the 'tools-only' target on macOS X 'Catalina'. Hopefully
>>> this will catch changes to host tools that are incompatible on BSD style
>>> environments.
>>>
>>> Signed-off-by: Tom Rini <tr...@konsulko.com>
>>> ----
>>> Note that at this time commit 3b4847cbee7c
>>> ("efi_loader: support building UEFI binaries on sandbox") is causing
>>> this to fail as non-GNU make does not support 'undefine' and there's not
>>> gmake nor do we need (seemingly) to use gmake otherwise. If we must, we
>>> can look in to 'brew install gmake' I think but I'm trying to have this
>>> be a typical BSD build environment.
>>
>> For building U-Boot (with around 70 targets) in OpenBSD ports we depend
>> on the following additional ports not in the base system:
>>
>> devel/gmake
>> devel/bison
>> devel/dtc
>> devel/swig
>> textproc/gsed (with check-config.sh patched to use it over base sed)
>> lang/python (python3)
>>
>> for aarch64 targets
>> devel/arm-none-eabi/gcc-linaro,aarch64
>> devel/py-elftools
>> sysutils/arm-trusted-firmware
>>
>> for arm targets
>> devel/arm-none-eabi/gcc-linaro
>>
>> The host/system compiler on most OpenBSD platforms is clang.
>>
>> I would like to move to doing native builds when building on aarch64 and
>> armv7 platforms with the system clang. I wonder how many of the
>> warnings in doc/README.clang still apply.
>
> Thanks. Any updates to doc/README.clang would be good. It looks like
> there's still a large number of blocking problems on aarch64 for someone
> to solve (no libgcc, but could we just solve that another way?) and
> linking U-Boot itself fails, but maybe we can use the clang linker by
> now?
>
> On both 32 and 64bit ARM, EFI loader needs to be disabled for rpi at
> least to finish compiling, and on 32bit it does link and run.
>
In lib/efi_loader/efi_boottime.c and in lib/trace.c we are saving and
setting gd.
arch/arm/include/asm/global_data.h defines a function get_gd() which is
used with clang to retrieve the value of gd:
#ifdef __clang__
#define DECLARE_GLOBAL_DATA_PTR
#define gd get_gd()
...
So any statement
gd = foo;
like in __efi_entry_check() is bound to fail with clang.
Does that match your compilation problems with EFI_LOADER=y and clang?
Best regards
Heinrich
