From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andr=c3=a9_Przywara?= Date: Wed, 13 Apr 2016 21:10:10 +0100 Subject: [U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64 In-Reply-To: <570EA29C.7050802@suse.de> References: <1459265351-19812-1-git-send-email-agraf@suse.de> <1459353236-153290-1-git-send-email-agraf@suse.de> <570EA21F.1070405@arm.com> <570EA29C.7050802@suse.de> Message-ID: <570EA7A2.5000305@arm.com> 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 20:48, Alexander Graf wrote: > > > 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? I wouldn't give anything on compatibility to those code versions. I expect both U-Boot, SPL/boot0 and ATF bundled together in some kind of firmware build or image. Also in the moment this is all in early development stage - I have removed more cruft from the ATF source and am tempted to switch to a proper upstream port soon. Also I am about to remove the SCP completely. So I'd like to see us doing proper upstream ports of all components, without caring about outdated and abandoned code bases. If people care about a certain feature or capability of some legacy firmware version, they are welcome to either port this properly or use that old build. That being said, let me fix the ATF to live in SRAM and publish that patch, then I will send a patch to U-Boot to revert this patch here. Cheers, Andre.