On Thu, 12 Dec 2019 at 10:05, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > > 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? >
Ping? > > > > > > > -----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 (#52507): https://edk2.groups.io/g/devel/message/52507 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] -=-=-=-=-=-=-=-=-=-=-=-
