[ArmVirtPkg] So in 2014 would could not start an ARM FV @ address 0x00000000, why is that still true today?

[ArmVirtPkg] So in 2014 would could not start an ARM FV @ address 0x00000000, why is that still true today?

[Andrew Fish]

I’m a little confused on why we can’t put an ARM FV at address 0x00000000 [1]? Obviously the zero vector for the FV is getting patch as this ARM code is jumping to the 1st byte of the FV when it is present at 0x1000. I don’t know of any generic limitation in our tools. This kind of feels like an 8 year old bug that got fixed at some point? Anyone know the history here? Do we need to file a BZ to get something fixed?

[1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtQemu.fdf#L56

#
# UEFI has trouble dealing with FVs that reside at physical address 0x0.
# So instead, put a hardcoded 'jump to 0x1000' at offset 0x0, and put the
# real FV at offset 0x1000
#
0x00000000|0x00001000
DATA = {
!if $(ARCH) == AARCH64
  0x00, 0x04, 0x00, 0x14   # 'b 0x1000' in AArch64 ASM
!else
  0xfe, 0x03, 0x00, 0xea   # 'b 0x1000' in AArch32 ASM
!endif
}

0x00001000|$(FVMAIN_COMPACT_SIZE)
gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
FV = FVMAIN_COMPACT

Thanks,

Andrew Fish