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

[Leif Lindholm <leif.lindholm@linaro.org>]

On Fri, Dec 14, 2018 at 05:08:05PM +0000, Pete Batard wrote:
> 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.

Sure, that works for me.

/
    Leif