Monocultures are bad [Was: Re: [PATCH] build: Extract trusted-firmware-a.mk]

[Hauke Mehrtens]

On 10/12/20 8:45 PM, Tomasz Maciej Nowak wrote:
> Hi.
> 
> W dniu 12.10.2020 o 16:32, Andre Heider pisze:
>> On 12/10/2020 12:21, Petr Štetiar wrote:
>>> Hauke Mehrtens <hauke at hauke-m.de> [2020-10-11 20:41:21]:
>>>
>>> Hi,
>>>
>>>    (I've expressed this already in my initial review[1] which was not addressed
>>>     and pushed anyway.)
>>>
>>>> +TFA_MAKE_FLAGS += \
>>>> +        CROSS_CM3=$(STAGING_DIR_IMAGE)/$(LINARO_NAME)-$(LINARO_RELEASE).$(LINARO_VERSION)/bin/arm-linux-gnueabi- \
>>>
>>> AFAIU this is Linux only toolchain, so we should either stop pretending, that
>>> we support usage of FreeBSD/macOS as the build host OS or fix this for good.
>>
>> As with other boards, we need a secondary cross compiler for a cortex m3 cpu here. Yes, currently a linux binary toolchain is downloaded. It's not optimal, and I'm not a fan of this solution either. But that's already used, this patch doesn't change that fact.
> 
> But It'll force other targets to comply with that or workaround it.
> 
>>
>> Building a firmware for these boards is a total clusterfuck. So one goal of all the espressobin PRs has been for openwrt to provide binary firmware files. With that in mind I see two options:
>>
>> 1) Error out on !Linux build hosts. Maybe that's good enough, because we mainly want it to work on buildbot
>> 2) build a cm3 cross compiler
>>
>> I'd go for 2), but the main question is if that's acceptable, because every buildslave would need to build it. We just need a bare metal toolchain though, so just binutils and gcc, no libc, g++ and whatnot. That's actually not as much as it sounds. And if we had that, the sunxi and rockchip atf package could use it too instead of downloading binaries (yay).

sunxi builds ATF/TF-A from source with the normal aarch64 toolchain we 
also use for the rest of the system like the Linux kernel. Looks like 
Allwinner has the best chip design here. ;-)

> That's also what I suggested on the same PR [2]. But building another toolchain consumes resources on buildbot and I think people managing buildbots won't like that.
> 
>>
>>> BTW I'm wondering why this can't be handled in the same way
>>> arm-trusted-firmware-rockchip is?
>>
>> For sunxi and rockchip, you start with an atf build, and then pass the filename of the resulting binary to the u-boot build system.
> 
> U-Boot build system cares little for ATF. It doesn't need it to build itself.
> 
>>
>> For A3700, it's the other way around. You cannot ship atf binaries (yuck), because atf is the last element in the build chain.
> 
> You can change that. The resulting bootloader is actually an FIP image[3] packed with fiptool, which is part of ATF build system. You can build each binary (wtmi, atf, u-boot) individually and later combine them with fiptool (never done that personally). As I understand it, because fiptool is part of ATF, the build process was tailored so that You can build ready-to-flash bootloader in one go.
> What could be done to split the process:
> a) modify ATF Makefile to skip packaging the FIP image and do it when requested from provided components,
> b) build the wtmi binaries with https://github.com/atf-builds (I don't know if that'll be accepted, since that's not exactly ATF and it needs additional dependencies) or create another entity to do that,
> c) download binaries and create the FIP image within ATF package.
> 
> or
> 
> a) modify ATF Makefile to skip packaging the FIP image and build ATF with wtmi binaries with https://github.com/atf-builds,
> b) download the binaries within ATF package,
> c) add fiptool to tools,
> d) combine binaries with fiptool in whichever OpenWrt buildroot place You want.
> 
> I don't have time to tackle that ATM and it's waaaay on the bottom on my ToDo list with very low priority, so whoever has motivation and time please do.

I also do not like that we download an extra toolchain here, but I would 
suggest to make this part Linux only for now. Building ATF and U-Boot 
for A3700 should then only be selected on Linux hosts, but the rest like 
mvebu Linux kernel and rootfs can still be build on Linux and macOS.

If someone wants to implement the better solution as proposed by Tomasz, 
this would be nice.

For which image (wtmi, atf, u-boot) do we need the cortex m3 toolchain?

Hauke