From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=2607:f8b0:4864:20::12f; helo=mail-it1-x12f.google.com; envelope-from=mw@semihalf.com; receiver=edk2-devel@lists.01.org Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 4E2362194D387 for ; Wed, 23 Jan 2019 01:45:49 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id m62so2301473ith.5 for ; Wed, 23 Jan 2019 01:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fAjXG7lndfa4lbZXYJhajyo3Yti8JKahXaIwiv+stJ0=; b=zMWWFsPYaHLfD0bmtOg3YYWQUy9qyGUGVfQ/DR+GIdeRk45WY0r5OjjMuniAALfonD dG8gwYRTkIEl0xJuEvqpaCUS1dQlZvPetj4Zd180aUPWeR47vHYKHSwuYakizPXLDsdH oImMmDh40h7TjAsX2wobJyad/bpmpysaUbtPh0AVn7DAdcLfcssQaaMGN1wlagtmCw7+ QLyHLyHXO16eZEwosqCQPVVX/vHiESw7bLzqyN9aI84XptKuECN1WX24QytDUIZ1N/FT Z42DSWDcnkTML2MZASCkhe19Xcy9UGRYo0abYT4etaGHdVZc0d7A+nsvcNp0XsowC8WJ oy7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fAjXG7lndfa4lbZXYJhajyo3Yti8JKahXaIwiv+stJ0=; b=c/wwTmQGiVHFvYj64jt9ixY3x/SWFZ+daZ+Blh6KC3dafU29c45DCyu0k02NZ3G72g cGbX8F2CaYwjAqsFzEftCPKy+XoKCYBzPSkifSwq6v2oIwCdR8kMQMumfxMULqnsnMwL LeoXSbt+YFUuvRDDmh6VhD2dBK9prbSHBxv3p43QCmT7AmsmJNmFIDE+eRZOzxlbG1hh 5mUuJN7hcl2Y5cngMkyxuP9GoosX9Gpb5kx4td94hBOPj3+mD61SZsnD1q7LSRRcCKkK aVgabSbn0Zr59ySTcCCUzrNbPX0xgGfPi2Z2PPsENIhcn59CEcvsSRLOap1n9cnGloTZ 8qcA== X-Gm-Message-State: AJcUukdKlK4aM6Xav9PpL/gQWhhflNsLAINWjszoghwG0zgfTci/aBxB 2ZYiwjEpmykNlHwQldzBebYYagRcsc3vldGp4QEtow== X-Google-Smtp-Source: ALg8bN7MGhZ8uV1u+m4hNvdHbCv2CXVVCTdAG08NTkJAj+GqfOyBGiLVYziF41x1OsdyzLgOzgdLLljj86pmBvS7vTs= X-Received: by 2002:a02:9d0:: with SMTP id 77mr873444jam.14.1548236748253; Wed, 23 Jan 2019 01:45:48 -0800 (PST) MIME-Version: 1.0 References: <1548120742-11928-1-git-send-email-mw@semihalf.com> <1548120742-11928-2-git-send-email-mw@semihalf.com> <20190122172643.i6newphbfjiertsb@bivouac.eciton.net> <20190122190649.x2bh7gd5szxmfxy5@bivouac.eciton.net> <20190122202627.ccu3koeskydsvjus@bivouac.eciton.net> <20190122210937.rf44pvv6gaudlme7@bivouac.eciton.net> <20190123094225.ifxrr6r562htbnaw@bivouac.eciton.net> In-Reply-To: <20190123094225.ifxrr6r562htbnaw@bivouac.eciton.net> From: Marcin Wojtas Date: Wed, 23 Jan 2019 10:45:36 +0100 Message-ID: To: Leif Lindholm Cc: edk2-devel-01 , Ard Biesheuvel , nadavh@marvell.com, "jsd@semihalf.com" , Grzegorz Jaszczyk , Kostya Porotchkin Subject: Re: [platforms: PATCH v2 1/4] Marvell/Armada7k8k: Shift PEI stack base 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: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:45:49 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Leif, =C5=9Br., 23 sty 2019 o 10:42 Leif Lindholm napi= sa=C5=82(a): > > On Wed, Jan 23, 2019 at 09:28:40AM +0100, Marcin Wojtas wrote: > > wt., 22 sty 2019 o 22:10 Leif Lindholm napis= a=C5=82(a): > > > > > > On Tue, Jan 22, 2019 at 09:56:14PM +0100, Marcin Wojtas wrote: > > > > > > > I think I gave my suggestion for the resolution of this probl= em (with > > > > > > > moving StackBase to 0x05400000 as the alternative) in my prev= ious > > > > > > > reply. > > > > > > > > > > > > > > > > > > > Yes, and I answered, presenting the alternative memory map with > > > > > > additional 64kB "cut out" on top of 20MB "hole" of memory, whic= h I'm > > > > > > not fancy, given available space inside the 20MB chunk. > > > > > > > > > > Please go back and reread my first and my second email. > > > > > Then please point out where I have, other than as an alternative > > > > > solution, suggested growing the cutout size. > > > > > > > > > > Then perhaps we can rewind this conversation and try again? > > > > > > > > Ok. So would it be sufficient to replace > > > > gMarvellTokenSpaceGuid.PcdSecureRegionBase with two sets of separat= e > > > > PCDs for ARM-TF runtime services and OPTEE leaving the PEI stack ba= se > > > > @0x43f0000? > > > > > > That would be lovely, thank you :) > > > > > > (Although your reference to wanting to keep the PEI stack area out of > > > the hands of the operating system might mean that you want three? I'l= l > > > leave that to your discretion.) > > > > > > > PEI stack has its own PCDs: > > gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase > > gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize > > > > I want to keep it simple (and btw aligned with U-Boot booting the > > mainline DTB with single 20MB reserved memory area), so what I intend > > to do is to limit reserved region in Armada7k8kMemoryInitPeiLib.c with > > PcdArmTFRegionBase (@0x4000000) up to PcdOpteeRegionBase + > > PcdOpteeRegionSize (@0x5400000). > > I am totally online with you wanting to align the reservation of 20MB > of RAM with U-Boot. > > If you want to remove the 2MB gap between ARM-TF and Optee from use by > the OS, you need to reserve that 2MB window. Not pretend that it forms > part of an adjacent region that you also happen to want to keep out of > the hands of the OS. > > The point of the source code is not wiggling the correct signal lines > to create an expected behaviour. Were that the case, we'd be hacking > programs directly into binary. > The point of the source code is to describe what is being done such > that someone else can come in and understand it. > > Saving 15 (or 30, or whatever) lines of boilerplate text by making the > code misleading is not a win. > > You want to solve this by making PcdCPUCorePrimaryStackSize 2MB? > Fine. It's not misleading, and you could always shrink it if you need > the remainder for something else. > > You want to solve this by setting up a third reserved area of > (2MB - PcdCPUCorePrimaryStackSize)? > Fine. > > You want to solve this by making the source code say that a memory > region is simultaneously reserved for Secure world and where our > Non-secure stack resides? > Not fine. That is what I mean by semantic sense. > Thank you for your input. I will explicitly handle each region then. Best regards, Marcin