Re: [edk2-devel] [PATCH v1 1/1] ArmPkg: Dispatch deferred images after EndOfDxe

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

On Fri, 6 Dec 2019 at 00:05, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 12/06/19 00:54, Laszlo Ersek wrote:
> > On 12/05/19 21:25, Ard Biesheuvel wrote:
> >> On Wed, 1 May 2019 at 15:02, Sami Mujawar <sami.mujawar@arm.com>
> >> wrote:
>
> >> I'm still curious why this difference exists,
> >
> > What difference do you mean?
> >
> > (I can't see the original patch posting in my list folder, so I could
> > be missing parts of the discussion thus far.)
>
> Haha, I missed that Sami's email, which you just replied to, is dated "1
> May 2019" -- that's the reason I couldn't find the original posting in
> my edk2-devel folder. That message has already been moved into one of my
> archive folders :)
>
> But, now I do see it, and I also see that your first question in
> response was spot-on:
>
>   https://edk2.groups.io/g/devel/message/39901
>
> (alternative link:
>
>   http://mid.mail-archive.com/CAKv+Gu92gPzGvGZ3M9B52q1TOAvnBjgxpvykbAZPevMULkcF6w@mail.gmail.com
> )
>
> Your question there had a small typo -- I think you meant, "It might be
> that the PCI hierarchy is enumerated *after* EndOfDxe on Juno, and
> *before* on the other platforms."
>
> And yes, that would explain the difference between Juno and {SynQuacer,
> Overdrive} very well -- i.e. why Juno was broken and the other platforms
> were OK. (Assuming in all cases, the 3rd party dispatch occurred after
> EndOfDxe, where it is supposed to.)
>

Hi Laszlo,

Thanks for chiming in.

My question did not have a typo: if Juno enumerates PCI before
EndOfDxe, any option ROMs it encounters will not be dispatched and put
on the deferred list, which never gets processed. If it enumerates
after EndOfDxe, they just get dispatched immediately. That would
explain this behavior, *except* for the fact that these platforms use
the same PCI host bridge and bus drivers, the only difference is the
PciHostBridgeLib used.

The difference is probably explained by the explicit
gBS->ConnectController () connecting the PCI root bridge that takes
place in ArmJunoDxe in an EndOfDxe handler, which seems to be there so
we can set the MAC address on the Marvell Yukon. We should probably
move that to a protocol registration notification callback on the
PciIo protocol, and remove the ConnectController altogether.

Concerning your analysis regarding the order of connecting the PCI
root bridge and signalling EndOfDxe: I agree the OvmfPkg order is
better, since it permits builtin drivers (which are 'trusted') to
attach to devices in the PCIe hierarchy before EndOfDxe is signalled,
which may be useful.