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

[Pete Batard <pete@akeo.ie>]

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.

> 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.

Regards,

/Pete