Re: [PATCH v2 edk2-platforms 00/20] Platform/Broadcom: Add Raspberry Pi 3 support

[Pete Batard <pete@akeo.ie>]

Hi Philippe, Hi Leif,

On 2018.12.14 16:36, Leif Lindholm wrote:
> On Fri, Dec 14, 2018 at 05:14:05PM +0100, Philippe Mathieu-Daudé wrote:
>>>> I can certainly upload binary releases for the required ATF files in my
>>>> github clone of ATF, and then add links to that in the readme with the
>>>> instructions on how to rebuild ATF.
>>>>
>>>> However, I'd rather wait to do that until there has been an official tagged
>>>> new release for ATF (which would be 2.1 at this stage, since our changes
>>>> have been applied after 2.0), as it'll look better for Pi users to see an
>>>> initial ATF serial output that says "BL<#>: v2.1(release)" instead of the
>>>> current "BL<#>: v2.0(release):v2.0-278-gc3859557"
>>>>
>>>> How about this then: If ATF produces a formal release before this proposal
>>>> is integrated, I'll amend it to remove the ATF binary blobs and apply the
>>>> suggestion above, with the Atf/ build/link data moved out of non-osi. But if
>>>> they don't, I'll keep the proposal for ATF as is, and then submit a patch to
>>>> remove the non-osi data and apply the above at a later date, once there has
>>>> been a new ATF release.
>>>
>>> Yeah, this certainly works for me.
>>
>> I setup this Dockerfile [1] to have reproducible builds and avoid to
>> store those binaries in the non-osi repository, what do you think about
>> this approach?
> 
> Get off my lawn? :)
> 
>> [1] available here:
>> https://gitlab.com/philmd/edk2-platforms/blob/raspi3-atf/Platform/RaspberryPi/RPi3/Arm-Tf/Dockerfile
> 
> I think it's a good thing to have, especially for something like the
> Pi. I guess if that exists, we can trust people who prefer not to use
> containers to be happy to follow the Readme, or grab binaries from
> Pete's github?

That's one way to do it. As I indicated, as soon as ATF creates a 2.1 
tagged release, I will look into removing the binary blobs from non-osi.

However I am not planning to do that sooner. As a matter of fact, given 
that this is not a blocking issue and given the scope of what still 
needs to be addressed for RPi3 integration, I am kind of hoping we won't 
see an ATF release for another month or two, so that we can get through 
the current integration process, with the current binary blobs in 
non-osi, and then sort out their removal post integration.

Personally, I also expect that anybody who wants to build the binaries 
locally, can simply be directed to follow the official ATF build notes 
on how to set up their tool chain, and then refer to the build 
parameters from our readme. But then again, if we have a nice Docker 
solution to provide, I don't see why we shouldn't also point to it.

On the other hand, when it comes to providing trustworthy links, and 
since there exists a MinGW32 version of the Linaro GCC compilers, I'd 
much rather use AppVeyor for automated build of ATF binaries. The nice 
thing is that AppVeyor can keep and serve its build artefacts, so we'd 
be able to directly link to those, which should give some level of trust 
that the binaries haven't been tampered with by the owner of the repo 
(or at least that, if they have, the source would reflect it). And you 
can also easily configure AppVeyor to only build on tagged commits, 
which I think is what we want.

At any rate, I think there exists more than one solution to address the 
ATF binary provision problem for RPi3, while also not having to ask 
users to blindly trust any binaries we might link to. Maybe Docker or 
AppVeyor are what we want to use. Maybe there is yet another option on 
the table that we haven't talked about yet.

If we believe this is necessary, I can look into adding AppVeyor builds 
of the official ATF ASAP. But for the time being, I would prefer if we 
start discussing this in earnest once ATF 2.1 has been tagged for 
release, and I send a formal proposal to address the removal of the 
non-osi ATF binaries.

Regards,

/Pete