[U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64

Alexander Graf agraf at suse.de
Wed Apr 13 23:26:14 CEST 2016



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


More information about the U-Boot mailing list