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

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

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?

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.

> For the record, there's a readme located in the directory where the ATF
> binaries are provided, that has the full build command we used, as well as
> the description of the memory mapping.

Good stuff.

> > (If it isn't upstream, non-osi is the way to go for now.)
> > ((This isn't a "do what I say", this is a "you don't have to".))
> 
> I guess that means we'll keep the binaries in non-osi for now then.
> 
> However, I have been thinking about renaming the directory that contains the
> ATF blobs from "Binary/" to "Atf/" to make it more explicit. I'll probably
> do for the v3, unless someone has a different idea.

Your call, after reading the above.

> > I fully agree with this, but...
> > 
> > Now for the bikeshedding: Bcm2837 is the SoC used in Pi 3. It is not
> > an alternative name for the Pi 3. And since the board design is open,
> > it is plausible that there may be derivative boards.
> > So ideally, I would like to see something like:
> > 
> > Platform/RaspberryPi/Pi3
> > Silicon/Broadcom/Bcm283x
> > 
> > With (if practically possible) a split between SoC and board modules
> > and configuration files.
> 
> Okay. I was half expecting such a request, so I'll see what I can do.

Thanks :)

> I'll be waiting to see if Ard has additional feedback before I start working
> on this as part of a v3.
> 
> > I would expect the Pi3.dsc/.fdf to be fairly minimal and including
> > .dsc.inc/.fdf.inc files from Bcm283x.
> > 
> > > * The ARM Trusted Firmware being used is a vanilla version built from the
> > >    latest tree, as we worked with that project to get necessary patches
> > >    integrated.
> > 
> > Sweet!
> > 
> > > * Detailed instructions on how to build and test the platform firmware are
> > >    included in the Readme.md found at the root of the platform.
> > 
> > Splendid!
> > 
> > > * As detailed in the Readme, the resulting platform firmware has been
> > >    successfully used to install and run Linux OSes, such as Ubuntu 18.10, as
> > >    well as Windows 10 1809 (*full* UI version, not IoT).
> > 
> > Very nice!
> > 
> > Could you also add an entry to the top-level Readme.md with a link to
> > the rpi3 Readme.md? (But hold off until I push some updates from
> > Nariman.)
> 
> Will do.

(This has now been partly pushed.)

Regards,

Leif