From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::22b; helo=mail-it0-x22b.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 4E853202E59C2 for ; Mon, 23 Oct 2017 07:35:56 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id j140so6196317itj.1 for ; Mon, 23 Oct 2017 07:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=940ZiHMhbtAAI3xQqqbPn9Xa2eHF5SUtXvwBe0QxVL0=; b=TCJAdKuxj9sLhLQ5HSM3hSfuAr05D1YDvg/yNCZsQM3W7st2qPxV+haOdNjug/WE6q xmUWIY5OCFPoXuGAebyxT00aNDYWZ/dP0Smr4PyzxdNBjDeJSZy4O/P6IKNtIYFDOygw lgWGFn7Xgygv98RQVcqJjdBCFS4YFQDJV7Kcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=940ZiHMhbtAAI3xQqqbPn9Xa2eHF5SUtXvwBe0QxVL0=; b=Za0uHrRg9v68CkVZyol4sOjO11St9c4dvTE5fWjiCnPYUFse0xX6ieeoPnxm9o3pkE waA5x1zyB1wjfjSbtAMiOsojrB8PqmKW0f2I741n0MK6P6WBnOBd2hmiQ/6PhiqWPj4g GV06B4y2D9ql49ERUInwU+sa5Mea5IvtKZi+ri5M8EOiYV1lATwaEFs/BSUKriMpPcH5 hC7RDFi5pojAyb93msJ6o0jWpnhakAXuNmrbrrzCaRpcvS/STRs44FV1UZO9i1eKGgz0 hsk2ZbDM48CSgl43K2hLdu3p6KSJWNYZk/hmlXJzQL8jhef158a3AqSxhvjC3Np9ZM0T TUbw== X-Gm-Message-State: AMCzsaV//oyFgMecUcqp13sdiHpQVX6+ShtliCW+6Nqff4GI7zKqfktz OFBL8syeS1irjvHDqdLGEzfX7G0XI9zyr47ub7cNlbYW X-Google-Smtp-Source: ABhQp+SmgvzZdkrnlPOLGfiQj13xfLMBJRXi++R3PfK4EAUnSt8W9YcCS/aE7wVuwSwVCixVB74AeIpYIHuEZzVHYd8= X-Received: by 10.36.233.133 with SMTP id f127mr9061205ith.34.1508769578251; Mon, 23 Oct 2017 07:39:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.167 with HTTP; Mon, 23 Oct 2017 07:39:37 -0700 (PDT) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E16F647@SHSMSX104.ccr.corp.intel.com> References: <20171020112325.10814-1-ard.biesheuvel@linaro.org> <20171020130024.l73uww7cxsjnwbsv@bivouac.eciton.net> <51d0ef33-022f-7153-9acd-9bc4a26cdd59@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E16EABD@SHSMSX104.ccr.corp.intel.com> <7c7676f9-39b4-39b6-24b7-7c83840df72a@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E16F647@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Mon, 23 Oct 2017 15:39:37 +0100 Message-ID: To: "Gao, Liming" Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , Leif Lindholm Subject: Re: [PATCH] ArmPlatformPkg/PrePeiCore: seed temporary stack before entering PEI core X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 14:35:56 -0000 Content-Type: text/plain; charset="UTF-8" On 23 October 2017 at 15:18, Gao, Liming wrote: > This is for debug purpose. I think UINT32 is OK if AARCH64 can operate 32bit value. > Both my ARM and AARCH64 implementations write 16 bytes at a time, and so whether the source value is UINT32 or UINT64 or UINT16 does not make any difference at all. >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Saturday, October 21, 2017 1:19 AM >> To: Ard Biesheuvel >> Cc: Gao, Liming ; edk2-devel@lists.01.org; Leif Lindholm >> Subject: Re: [edk2] [PATCH] ArmPlatformPkg/PrePeiCore: seed temporary stack before entering PEI core >> >> On 10/20/17 18:52, Ard Biesheuvel wrote: >> > On 20 October 2017 at 17:51, Laszlo Ersek wrote: >> >> On 10/20/17 18:39, Ard Biesheuvel wrote: >> >>> On 20 October 2017 at 17:37, Gao, Liming wrote: >> >>>> Ard: >> >>>> This case is to share the same value between PeiCore and SecCore. I also think it will be better to define one fixed PCD in >> MdeModulePkg.dec for this value. Could you submit bugzillar to catch this issue first? >> >>>> >> >>> >> >>> Certainly! >> >> >> >> Would it be possible to define the PCD as UINT32, and task 64-bit SEC >> >> (and PEI_CORE) code to first construct the wider value manually (in a >> >> register or otherwise)? >> >> >> >> Just thinking out loud. >> >> >> > >> > Could you think the reasoning behind that out loud as well? >> >> Haha, good stab :) Sure. >> >> In your patch you have: >> >> +#define INIT_CAR_VALUE 0x5AA55AA55AA55AA5 >> >> for 64-bit, and >> >> +#define INIT_CAR_VALUE 0x5AA55AA5 >> >> for 32-bit. >> >> Both 64-bit assembly code in SEC, and 64-bit C-code in the PEI_CORE, can >> easily compose the large value from the small value, starting from >> FixedPcdGet32(). The alternatives are: >> >> - asking the 32-bit assembly code to truncate the 64-bit constant -- it >> won't compile, >> >> - defining *two* FixedAtBuild PCDs, one for 32-bit, another for 64-bit >> SEC -- an idea probably not universally liked. >> >> ... When I originally started writing my previous email, I even thought >> about introducing the PCD as UINT16 :) But then I realized, if any >> platform lacks *some* 32-bit mode when it sets up the stack in assembly, >> for C-language entry, then the platform won't be supported by edk2. >> >> Thanks >> Laszlo