On Thu, 12 Dec 2019 at 09:59, Ni, Ray <ray...@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...@intel.com> > > Cc: Laszlo Ersek <ler...@redhat.com>; edk2-devel-groups-io > > <devel@edk2.groups.io>; Leif Lindholm > > <leif.lindh...@linaro.org>; Gao, Zhichao <zhichao....@intel.com>; Ma, > > Maurice <maurice...@intel.com>; Dong, Guo > > <guo.d...@intel.com>; You, Benjamin <benjamin....@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.biesheu...@linaro.org> > > wrote: > > > > > > On Mon, 9 Dec 2019 at 03:12, Ni, Ray <ray...@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? > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#52157): https://edk2.groups.io/g/devel/message/52157 Mute This Topic: https://groups.io/mt/67470372/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
