On 02/04/19 19:31, Leif Lindholm wrote: > Hi Bob, Liming, > > So, I've been playing around with merging the .dsc/.fdf files in > OvmfPkg. Merging IA32 and X64 is simple enough, since you can test on > > !if $(ARCH) == "X64" > > However, from what I can tell, when trying to merge in the > OvmfPkgIa32X64 platform - what you actually end up with in $(ARCH) > when specifying multiple -a is a python list rather than a single > string. > > To explain the problem in code, tryin to build the platform described by > > --- > [Defines] > PLATFORM_NAME = Ovmf > PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b > PLATFORM_VERSION = 0.1 > DSC_SPECIFICATION = 0x00010005 > SUPPORTED_ARCHITECTURES = IA32|X64 > BUILD_TARGETS = DEBUG|NOOPT|RELEASE > !if "$(ARCH)" == "IA32 X64" or "$(ARCH)" == "X64 IA32" > OUTPUT_DIRECTORY = Build/OvmfDummy > !else > OUTPUT_DIRECTORY = Build/Ovmf$(ARCH)Real > !endif > --- > > using the command line 'build -t GCC5 -a IA32 -a X64 -b DEBUG -p Test.dsc' > inevitably results in an output like > > --- > Build environment: Linux-4.9.0-3-amd64-x86_64-with-debian-9.7 > Build start time: 18:21:33, Feb.04 2019 > > WORKSPACE = /work/git/edk2 > EDK_TOOLS_PATH = /work/git/edk2/BaseTools > CONF_PATH = /work/git/edk2/Conf > PYTHON_COMMAND = /usr/bin/python3.5 > > > > build.py... > /work/git/edk2/Test.dsc(11): error 3001: No space is allowed in > OUTPUT_DIRECTORY > Build/OvmfIA32 X64Real > > - Failed - > --- > > Now, the Ia32X64 target is very much of a special case, which I don't > necessarily see as usefully supported by the current .dsc > specification. But I believe we need to do one of > - banning (simultaneous) multi-architecture platforms > - treating them the same as multi-target (-b) builds (build them separately) > - have a defined way of handling them
Only option #3 can work here. OvmfPkgIa32X64.dsc is a platform where the Reset Vector, SEC and PEI phases are built for IA32, the rest (i.e. DXE+) is built for X64, and the images are finally organized into a single flash device (FD). The key PCD is gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE which you won't see in either the pure IA32 or the pure X64 OVMF platform -- as none of those have to switch from 32-bit mode to 64-bit (long) mode at the PEI/DXE boundary: - OvmfPkgIa32.dsc: gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE - OvmfPkgIa32X64.dsc: gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE - OvmfPkgX64.dsc: gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE Regarding the usefulness of the OvmfPkgIa32X64.dsc, that's presently the *only* OVMF platform that is suitable for production use. It is the only platform that: (a) supports Secure Boot, *and* (b) includes ACPI S3 suspend/resume support, *and* (c) protects sensitive data related to (a) and (b), i.e. non-volatile UEFI variables, and the LockBox data structure, respectively, by inclusion of the SMM driver stack, and usage of SMRAM, *and* (d) supports 64-bit OS-es. > So, am I missing something, or does this require a change in > BaseTools? I believe you may have missed that "-a IA32 -a X64" stands for more than just "build this set of modules for each of IA32 and X64, separately". AIUI, "-a IA32 -a X64" it means "build the Components.* sections (plural) as dictated by the '-a' flags, and then organize the full (multi-arch) set of modules into the flash device(s), described by FLASH_DEFINITION". Thanks, Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
