[edk2] [PATCH v2 edk2-platforms 00/20] Platform/Broadcom: Add Raspberry Pi 3 support
pete at akeo.ie
Wed Dec 12 11:53:04 PST 2018
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
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
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.
More information about the edk2-devel