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

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

On Wed, Dec 12, 2018 at 07:53:04PM +0000, Pete Batard wrote:
> On 2018.12.12 18:32, Leif Lindholm wrote:
> > On Tue, Dec 11, 2018 at 08:16:07PM +0000, Pete Batard wrote:
> > > > I _think_ all of the ATF binaries we have in non-osi are
> > > > non-upstream. If the port for the rpi3 is upstream, I would be just as
> > > > happy to have simple build instructions of a known good commit (with
> > > > notes on toolchain version tested) in the Readme.md - and possibly a
> > > > placeholder directory with a .inf in to drop a prebuilt image into.
> > > 
> > > Well, while it is upstream, it is built using a custom rpi3 specific option
> > > which we had ATF to add, so that we could get a memory mapping that works
> > > with Windows (default one was okay for Linux but not Windows). So I doubt we
> > > will ever get upstream binaries that we can use as is, if that's what you
> > > are alluding to.
> > 
> > I don't really care all that much about that, but if we need
> > modifications to run Windows (and nothing prevents that from working
> > with Linux), then should we try to change the upstream defaults?
> 
> The problem here is U-Boot.
> 
> The RPi3 ATF has pretty much been designed around U-Boot usage (since it was
> its only consumer until now), so, to achieve the above, we'll need to
> validate that we aren't going to break anything for downstream RPi3/U-Boot
> users, which I don't think we can accomplish in a reasonable timeframe.
> 
> When I mentioned that the ATF works with Linux and Windows, I meant "when
> used as part of an UEFI payload". But I have yet to run any comprehensive
> test of our UEFI-tailored ATF within a U-Boot payload. And even though
> nobody should be relying on a fixed memory mapping, I do some have concerns
> that some people might have downstream elements that are tailored around the
> current U-Boot friendly memory mapping, which we might break.
> 
> As such, I'd rather first see usage of the UEFI bootloader take off with a
> few Linux distros, after it has been officialized in edk2-platforms, so that
> we can have a bit more weight in asking the U-Boot folks whether they'd
> consider using our memory mapping as default.

Understood - thank you for this background.

> > But for me, I'd be happy with just the build instructions you have,
> > and no binaries/license, in
> > edk2-platforms/Platform/RaspberryPi/RPi3/Arm-Tf/, with the user having
> > to drop in their own binaries.
> 
> In that case, I think I'd still like to provide some links to downloadable
> binaries, for people who don't want to have to rebuild ATF, and who consider
> that download links provided in an official readme should be trustworthy
> enough.
> 
> 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.

Regards,

Leif