public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64
Date: Wed, 13 Apr 2016 23:26:14 +0200	[thread overview]
Message-ID: <570EB976.2060801@suse.de> (raw)
In-Reply-To: <570EA7A2.5000305@arm.com>



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

      reply	other threads:[~2016-04-13 21:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 15:29 [U-Boot] [PATCH 0/6] Add Pine64 support Alexander Graf
2016-03-29 15:29 ` [U-Boot] [PATCH 1/6] sunxi: Move cpu independent code to mach directory Alexander Graf
2016-03-29 15:29 ` [U-Boot] [PATCH 2/6] sunxi: Depend SPL configs on SUPPORT_SPL Alexander Graf
2016-03-29 15:29 ` [U-Boot] [PATCH 3/6] arm: Allow u32 as addrs for readX/writeX Alexander Graf
2016-03-29 15:46   ` Hans de Goede
2016-03-29 15:29 ` [U-Boot] [PATCH 4/6] sunxi: Explicitly cast u32 pointer conversions Alexander Graf
2016-03-29 15:29 ` [U-Boot] [PATCH 5/6] sunxi: Add support for Allwinner A64 SoCs Alexander Graf
2016-03-29 15:29 ` [U-Boot] [PATCH 6/6] sunxi: Add Pine64+ support Alexander Graf
2016-03-29 15:45 ` [U-Boot] [PATCH 0/6] Add Pine64 support Hans de Goede
2016-03-29 16:08   ` Alexander Graf
2016-03-30  7:35     ` Hans de Goede
2016-03-31 18:53     ` Hans de Goede
2016-03-31 19:15       ` Alexander Graf
2016-03-31 19:22         ` Hans de Goede
2016-03-31 19:23           ` Hans de Goede
2016-03-30 15:53 ` [U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64 Alexander Graf
2016-04-01 11:06   ` Ian Campbell
2016-04-01 11:08     ` Alexander Graf
2016-04-01 11:12       ` Ian Campbell
2016-04-01 11:23         ` Alexander Graf
2016-04-13 19:46   ` Andre Przywara
2016-04-13 19:48     ` Alexander Graf
2016-04-13 20:10       ` André Przywara
2016-04-13 21:26         ` Alexander Graf [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=570EB976.2060801@suse.de \
    --to=agraf@suse.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox