On 04/11/18 17:34, Supreeth Venkatesh wrote: > Laszlo/Steve, > > I ran into the same problem on ArmVExpress-FVP-AArch64 while running > management mode. > I have fixed this problem in this patch by reordering driver load > order here: > https://lists.01.org/pipermail/edk2-devel/2018-April/023550.html > > Not sure whether Leif/Ard/Laszlo agree with this.
Unfortunately, that's not a fix, just an unreliable work-around. The dispatch order between DXE modules is unspecified beyond the order imposed by their dependency expressions (hence "depex"). I don't claim that it's always feasible to fix the problem with custom NULL protocols, but whenever it is, I suggest that we do. The protocol dependency mechanism is clean and extensible, unlike "BEFORE" depex opcodes, or the "naked" listing order in FDF files. Admittedly, sometimes there's no way around specifying a precise (partial) load order for several modules. For that, the APRIORI DXE file should be used, if possible. And, the APRIORI DXE file should be kept as small as possible (listing as few modules as possible). I think we should implement the following changes. (1) "ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" produces two custom protocols already, gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid. These are installed on the following call path: InterruptDxeInitialize() [ArmPkg/Drivers/ArmGic/ArmGicDxe.c] GicV2DxeInitialize() | GicV3DxeInitialize() [ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c] InstallAndRegisterInterruptService() [ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c] The GUIDs come from "EmbeddedPkg/Include/Protocol/HardwareInterrupt.h" and "EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h", respectively. Annotate "ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" that it produces gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid, and that it consumes (with a protocol notify) gEfiCpuArchProtocolGuid. (2) Replace "AFTER gArmGicDxeFileGuid" in "ArmPkg/Drivers/CpuDxe/CpuDxe.inf" with "gHardwareInterruptProtocolGuid OR gHardwareInterrupt2ProtocolGuid". (3) Replace "BEFORE gVariableRuntimeDxeFileGuid" in "ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf" with "gEfiCpuArchProtocolGuid". (4) In all platforms that use NorFlashDxe without formatting a variable store template at build time, make the variable driver depend on NorFlashDxe's runtime formatting, with the trick I described earlier. In fact, I haven't booted ArmVirtQemu in a while, and now I'm finding it is afflicted by the same assertion failure as the one reported by Steve. This is somewhat strange because I don't see any Arm*Pkg changes since my commit 34711bf19833 ("ArmVirtPkg/PlatformBootManagerLib: return to "-kernel before boot devices"", 2018-03-16). I definitely tested that commit successfully, so I wonder what may have triggered / exposed the issue recently. Possibly BaseTools changes? That wouldn't be surprising; again, the dispatch order is unspecified beyond depexes. Either way, I guess I better get to work on this. Thanks, Laszlo _______________________________________________ edk2-devel mailing list email@example.com https://lists.01.org/mailman/listinfo/edk2-devel