Re: Boot failure for ArmVExpress-FVP-AArch64, CpuArch protocol does not appear to be registered

[Laszlo Ersek <lersek@redhat.com>]

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