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
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
