Re: [edk2-devel] [RFC PATCH 2/2] MdeModulePkg/BdsDxe: allow consoles on drivers loaded via Driver####

["Ard Biesheuvel" <ard.biesheuvel@linaro.org>]

On Thu, 12 Dec 2019 at 09:59, Ni, Ray <ray.ni@intel.com> wrote:
>
> Ard,
> I still cannot understand it.
>
> Since Driver#### are processed (process = LoadImage + StartImage) after EndOfDxe, they are not deferred.
> It means the Driver#### entrypoints are called directly.
> Inside the entrypoints, driverbinding protocols are installed.
>
> After that, EfiBootManagerConnectAllDefaultConsoles () uses driver model logic to start the proper GOP driver.
>

It only does that if the GOP console is already in the
ConIn/ConOut/ConErr variables, no?

Today, we have code in the PlatformBdsLib to traverse the PCI
hierarchy to populate those ConXXX variables if we encounter any PCI
graphics cards, but this is done in
PlatformBootManagerBeforeConsole(), so if the Driver#### is loaded
*after* PlatformBootManagerBeforeConsole(), it will not be added to
ConXXX. So we need to process Driver#### before calling
PlatformBootManagerBeforeConsole(), so that the driver is dispatches
right after we call DispatchDeferredImages() but before we do the
traversal and populate the COnXXX variables.

How else do you propose we could make PCI graphics controllers
supported by Driver#### options appear in COnXXX before
EfiBootManagerConnectAllDefaultConsoles() is called?



>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard Biesheuvel
> > Sent: Wednesday, December 11, 2019 6:40 PM
> > To: Ni, Ray <ray.ni@intel.com>
> > Cc: Laszlo Ersek <lersek@redhat.com>; edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm
> > <leif.lindholm@linaro.org>; Gao, Zhichao <zhichao.gao@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Dong, Guo
> > <guo.dong@intel.com>; You, Benjamin <benjamin.you@intel.com>
> > Subject: Re: [edk2-devel] [RFC PATCH 2/2] MdeModulePkg/BdsDxe: allow consoles on drivers loaded via Driver####
> >
> > On Mon, 9 Dec 2019 at 09:42, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > >
> > > On Mon, 9 Dec 2019 at 03:12, Ni, Ray <ray.ni@intel.com> wrote:
> > > >
> > > > > Exactly. This flow is identical to how option ROMs are processed if
> > > > > they are discovered before EndOfDxe signalling completes (which is why
> > > > > the Juno platform was broken without the call to
> > > > > EfiBootManagerDispatchDeferredImages() in
> > > > > PlatformBootManagerBeforeConsole())
> > > > >
> > > >
> > > > Ard,
> > > > I checked ArmPkg's PlatformBootManagerLib and found it doesn't
> > > > call *DispatchDeferredImages() after signaling EndOfDxe.
> > > >
> > >
> > > It does. We just added this in 0f9395d7c5cc6ae2beaa2d87008fe158d04a8069
> > >
> > > > The deferred image dispatch mechanism assumes the platform
> > > > needs to call the *DispatchDeferredImages() after signaling EndOfDxe.
> > > >
> > >
> > > Indeed.
> > >
> > > > I don't understand why the deferred image can be loaded with your patch.
> > > > They are still deferred because the loading time is before EndOfDxe.
> > > >
> > >
> > > Yes, but because PlatformBootManagerBeforeConsole () does all of this,
> > > the only way to get Driver#### to work for consoles on GOP drivers, we
> > > need to move it before that call.
> >
> > Any further comments on this patch?
> >
> > 
>