From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Wed, 13 Apr 2016 21:48:44 +0200 Subject: [U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64 In-Reply-To: <570EA21F.1070405@arm.com> References: <1459265351-19812-1-git-send-email-agraf@suse.de> <1459353236-153290-1-git-send-email-agraf@suse.de> <570EA21F.1070405@arm.com> Message-ID: <570EA29C.7050802@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 13.04.16 21:46, Andre Przywara wrote: > Hi, > > sorry for the late reply, just found your series here. > > On 30/03/16 16:53, Alexander Graf wrote: >> On the A64 we usually boot with ATF running in EL3. ATF as it is available >> today resides in the first 16MB of RAM. > > So this is actually a mistake Allwinner made and which we haven't fixed yet. > ATF (at least BL3-1, which is the runtime service part we use for the > A64) should at least run in secure memory, actually in secure SRAM. > Having it in DRAM is a kludge, unnecessary (it's small enough to reside > in some SRAM), a waste of memory (it should get along with something > like 32KB) and also insecure, as long as we don't use the TrustZone > controller to mark this part of DRAM as secure. > >> So we should make sure we reserve >> that space in our memory maps. > > I will try to load ATF into one of the SRAM regions the A64 has, and tag > that as secure. U-Boot shouldn't care about ATF then, we don't need to > reserve any memory for it - after all those SRAM regions look like some > kind of MMIO device which we wouldn't touch anyway. I think that's a great plan moving forward. Is there any way we can runtime detect this in U-Boot to run with both old and new ATF versions or should we just break backwards compatibility? Alex