From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Wed, 13 Apr 2016 23:26:14 +0200 Subject: [U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64 In-Reply-To: <570EA7A2.5000305@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> <570EA29C.7050802@suse.de> <570EA7A2.5000305@arm.com> Message-ID: <570EB976.2060801@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 22:10, Andr? Przywara wrote: > 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. I agree, but let's add some way to ask ATF for its current version, so that U-Boot can at least panic if it finds the wrong one. Alex