From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1D4AB211C8337 for ; Mon, 4 Feb 2019 11:02:57 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 56562C0587C5; Mon, 4 Feb 2019 19:02:57 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-118-250.phx2.redhat.com [10.3.118.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4F337100191D; Mon, 4 Feb 2019 19:02:56 +0000 (UTC) To: Leif Lindholm , edk2-devel@lists.01.org Cc: Liming Gao References: <20190204183141.bv2z5u4w7cuyo77b@bivouac.eciton.net> From: Laszlo Ersek Message-ID: Date: Mon, 4 Feb 2019 20:02:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190204183141.bv2z5u4w7cuyo77b@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 04 Feb 2019 19:02:57 +0000 (UTC) Subject: Re: BaseTools: handling of $(ARCH) in .dsc/.fdf when multiple -a specified X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:02:58 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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