On Fri, 6 Dec 2019 at 00:05, Laszlo Ersek <ler...@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.muja...@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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#51825): https://edk2.groups.io/g/devel/message/51825 Mute This Topic: https://groups.io/mt/31432647/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
