From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::42a; helo=mail-wr1-x42a.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0C1CB21962301 for ; Tue, 5 Feb 2019 03:08:22 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id z18so2374896wrh.2 for ; Tue, 05 Feb 2019 03:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=esd3Tx8xkkJwVBjm/216yJsKE2SDrY4g5F87s7/dqHY=; b=GcWSBrkvs40LFcLCPAtqunyDQ1lPqjkrdzLleZpT1578+TJRj+YB4ovbJmzE1uasUi sQa8re+FTXhEnBar9KeY/HwVL3M4f52thIQwQ7wM0eP50p+pY4NWJub9M/oVdc0Mv5Ap ZFmzPsHaRQpG/7bjzJlvjUbK3hG1taiC+tXRrXxQGCW7FGAxDfFZHnjGqqYedaWpkREd m0NaeUleCweQ8l+pS47dlVmMUiKzUixEBmqK2eZZX3mLJL+LyD2sYBYIdxQTOJUW9/l9 5TF+ZkTA/R27/ACzmYr2s3/3J+Is1IW6SW68ZpAO4uqOqOqfiPuzYiNItu9Qht7KXQ82 7aSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=esd3Tx8xkkJwVBjm/216yJsKE2SDrY4g5F87s7/dqHY=; b=MMieZ9PYcCVjE0q/uSXcBmW4oz1Il/nwVjsp5nbtMTeyNxMTC2TWG/XSdPRBAOBWWf htpfTbVJxEzc5WXk7v7oHCY866WlSJF46rYvIr/gC5GvECx8nxNpp9TjQqcs28sEKStR n+fYfREJWk/Uy8Zg2D3TZbSYcR7zlpdy/8zTeljVOPx9NQv6JOnwU1cHOTAVbi+FK49P Ru8GvYbUQfF7tufiixhTZDD7LDvwxxZvMky+6oxFXtyIiVWv3oA4wWt4eX/1UHwTZK4w JEOUjrwgbUMjTxIg4Dk4WzODQZja8upNfKeU1ULtZFaPPSGygCgu1sFN++lr95Nc+w38 z/Rg== X-Gm-Message-State: AHQUAuaBJVVN/9E32iMIG32oeXs1slx+YpgKC2j7ZQ0jgGq/9U++0W+a U7kHdjuX8fYa4n2QDV1WfSl0AA== X-Google-Smtp-Source: AHgI3IaW94ML+KQjYxpucOlZtWl4NroNkg34HU8pKmqJSJL0CEynajOP6eCdnaMJcJ+Mp31WJbBplA== X-Received: by 2002:a5d:488f:: with SMTP id g15mr3170236wrq.15.1549364901196; Tue, 05 Feb 2019 03:08:21 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id p4sm15476578wrs.74.2019.02.05.03.08.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Feb 2019 03:08:20 -0800 (PST) Date: Tue, 5 Feb 2019 11:08:19 +0000 From: Leif Lindholm To: Laszlo Ersek Cc: edk2-devel@lists.01.org, Liming Gao Message-ID: <20190205110819.snxii7yoqyd5zwhu@bivouac.eciton.net> References: <20190204183141.bv2z5u4w7cuyo77b@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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: Tue, 05 Feb 2019 11:08:23 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 04, 2019 at 08:02:55PM +0100, Laszlo Ersek wrote: > > 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. OK, at that point I totally agree only option #3 is workable. > > 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". Nope, I did spot that actually :) Although I was certainly confused the first 10 times I looked at those .dscs. And it could still be squashed into a common .dsc/.fdf if there was a useful way of handling $(ARCH) when multiple -a have been specified to the build command. / Leif