[U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes

[Bin Meng]

Hi Simon,

On Sun, Oct 13, 2019 at 1:53 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Bin,
>
> On Fri, 11 Oct 2019 at 22:48, Bin Meng <bmeng.cn at gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Sat, Oct 12, 2019 at 11:38 AM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Thu, 10 Oct 2019 at 03:50, Bin Meng <bmeng.cn at gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Wed, Sep 25, 2019 at 10:59 PM Simon Glass <sjg at chromium.org> wrote:
> > > > >
> > > > > Newer Intel SoCs have different ways of setting up cache-as-ram (CAR).
> > > > > Add support for these along with suitable configuration options.
> > > > >
> > > >
> > > > I wonder why do we need do this in U-Boot. Isn't FSP-T doing the CAR for us?
> > >
> > > Well actually I have not tried using FSP-T yet on apollolake. I'll see
> > > how it looks.
> >
> > It looks so far only FSP-M is used on your apollolake port.
> >
> > What I'd like to see is a complete FSP 2.0 support in U-Boot, which
> > means we need FSP-T for the CAR and FSP-S for the silicon-specific
> > initialization. With FSP-S, I believe most of your platform support
> > codes in this patch series are no longer needed.
>
> I have actually got FSP-S running - see u-boot-dm/coral2-working,
> along with display, MMC, etc. There is very little init in U-Boot
> itself and my feeling is that most of the TPL/SPL init is actually
> needed. We cannot run FSP-S until the CAR is turned off, so it has to
> run in U-Boot.

OK, so why do we want to introduce TPL on ApolloLake? I think there is
no size limitation that you can just run U-Boot directly on
ApolloLake, no?

>
> I also just got an Up board so can give that a try one day assuming I
> have the SPI adaptor. But I think you might have some apollolake
> boards too?

Yes, I have one of the ApolloLake CRB from Intel and planned to try at
some point but some other stuff has been occupying my time :)

Regards,
Bin