From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by mx.groups.io with SMTP id smtpd.web12.4115.1576141563126162592 for ; Thu, 12 Dec 2019 01:06:03 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=U+Xw7q7v; spf=pass (domain: linaro.org, ip: 209.85.128.68, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f68.google.com with SMTP id b11so1454792wmj.4 for ; Thu, 12 Dec 2019 01:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aL9iRhILN+eU/Zu/SFmDyW3P8Nto9QanCFMu6d/rbAk=; b=U+Xw7q7vBKgMM19AiYAw1EHPQ3AeGNflcFj1c3kLBtolgH7EOT+LHas4n8R7k8ZhOo TRyfkd0iNM6TVmlRrgrrX9SpFOca/KM19owfN4E5dLa5XSmQ9ANKZ8w/ZU953ZJ0L+cy ITs+gal49czUfKp8vPPOyci/fpE+NW1/Bv+GktLPX9y+h+MLnvkBbW0jri1A9xwIrWiv OaR3wxMsLIJ51tgClKfrJ9Qa4v3o8LaWoyn/85/4CD0gnZozpJZEdTCB1pvL2SLQeQsz rEE4h02HHDbRpomzm2cvrUnLm/BRsz7zNH+x6j2RJOi1szXlEIJziAd/VGjRt0cVqKMn w+bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aL9iRhILN+eU/Zu/SFmDyW3P8Nto9QanCFMu6d/rbAk=; b=lJZSEdLkWmd0KsqKERqT+Kz96FwDrs44yQZD74wuEwP9EwvokPS9xMGf42+Z47+in1 ksHImgiKP5pap+RFMTTSa2Twun83YgHW2e02Kz0qzmsXPKfcpMFCpyx6FkhAXMHKHZOr WDtUaZgRlN/J0Zpj6ve8QV5QeifLz1KlCh72XRse3QiahAYPhZ4YH7DYwrNK/d9y6XcN NeMZJcASiAjHsdy6VhpatEXjBWbXhHNdz7NxHMrCTKA30hjT/3LkReYkaHCfd9LWUT7Z Y6Q8IdzVypd3vNSmDMcibqNXlLdDVQ02UZsPvNF/DBay+asEqL28jMpuzit7w0ZoIovG bodw== X-Gm-Message-State: APjAAAV/QnmTuu65yhgOR+8bn7CCD7vCbHsFBF2yFBPDA3Wzn7Dpdrwx HOhTWbAr/HTeSKwBJvCFt2SsXZAGCWVI4iLFNrlWhw== X-Google-Smtp-Source: APXvYqxTl2axxUxql/OothBfriWDN9owLzEcGGgv9Y9TbvWFhKxdB5bWhxeTJxLKaJUhTqZGhugbekgo24iIuHDfJn8= X-Received: by 2002:a1c:a795:: with SMTP id q143mr5021694wme.52.1576141561543; Thu, 12 Dec 2019 01:06:01 -0800 (PST) MIME-Version: 1.0 References: <20191206143128.19371-1-ard.biesheuvel@linaro.org> <20191206143128.19371-3-ard.biesheuvel@linaro.org> <8d49cca6-b1b9-cddc-0590-4e4a84643e4f@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C39604F@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C399C9C@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C399C9C@SHSMSX104.ccr.corp.intel.com> From: "Ard Biesheuvel" Date: Thu, 12 Dec 2019 09:05:59 +0000 Message-ID: Subject: Re: [edk2-devel] [RFC PATCH 2/2] MdeModulePkg/BdsDxe: allow consoles on drivers loaded via Driver#### To: "Ni, Ray" Cc: "devel@edk2.groups.io" , Laszlo Ersek , Leif Lindholm , "Gao, Zhichao" , "Ma, Maurice" , "Dong, Guo" , "You, Benjamin" Content-Type: text/plain; charset="UTF-8" On Thu, 12 Dec 2019 at 09:59, Ni, Ray 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 On Behalf Of Ard Biesheuvel > > Sent: Wednesday, December 11, 2019 6:40 PM > > To: Ni, Ray > > Cc: Laszlo Ersek ; edk2-devel-groups-io ; Leif Lindholm > > ; Gao, Zhichao ; Ma, Maurice ; Dong, Guo > > ; You, Benjamin > > 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 wrote: > > > > > > On Mon, 9 Dec 2019 at 03:12, Ni, Ray 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? > > > > >