[meta-xilinx] [PATCH] arm-trusted-firmware: Use constants for memory addresses

[Nathan Rossi]

On Thu, Sep 29, 2016 at 7:46 PM, Mike Looijmans <mike.looijmans at topic.nl> wrote:
> On 28-09-16 17:20, Nathan Rossi wrote:
>>
>> On Wed, Sep 28, 2016 at 10:50 AM, Manjukumar Harthikote Matha
>> <manjukumar.harthikote-matha at xilinx.com> wrote:
>>>
>>> Hi Mike,
>>>
>>> <.....>
>>>>>>
>>>>>>   LD[unexport] = "1"
>>>>>>
>>>>>> +ZYNQMP_ATF_MEM_BASE = "0xfffe5000"
>>>>>> +ZYNQMP_ATF_MEM_SIZE =    "0x16000"
>>>>>
>>>>> Maybe reading the load address from elf might help. I think MEM_BASE
>>>>> address might change going forward.
>>>>>
>>>>> For example:
>>>>> https://github.com/Xilinx/arm-trusted-firmware/commit/eb4fa652d424b895
>>>>> 7a927c6137e2ae3652b0b1bb
>>>>>
>>>>
>>>> This patch was to accommodate that. The current version will load it at
>>>> the wrong
>>>> location.
>>>>
>>> I am looking to see if we can read from the generated elf and populate
>>> the MEM_BASE and MEM_SIZE
>>> With the current patch, I think it will be maintenance burden every
>>> release, trying to mitigate it if possible.
>>
>>
>> The generated bl31.elf is populated with the correct entry point address:
>>    Entry point address:               0xfffe5000
>>
>> Which is pointing to bl31_entrypoint,
>>
>> https://github.com/Xilinx/arm-trusted-firmware/blob/eb4fa652d424b8957a927c6137e2ae3652b0b1bb/bl31/bl31.ld.S#L35
>>
>> Which could be used as an alternate source of the address:
>>     625: 00000000fffe5000   212 FUNC    GLOBAL DEFAULT    1
>> bl31_entrypoint
>>
>> My only query is whether the ZYNQ_ATF_MEM_* variables make sense as
>> overrides? Essentially if there is a potential use case when bl31
>> needs to be built to execute in an older/newer environment that
>> differs from the default values (of the current version used)?
>>
>
> What I really wanted is the opposite, get the address from the binary. That
> would solve the "magic number" that you have to put in the recipe. I
> couldn't find a way to do that, so I did the opposite, make sure that both
> code and recipe share the same magic number.
>
> I had no intention of making this "configurable" or so, I just wanted it
> consistent.
>
>

That makes it simpler then :). I have a sent a patch that does the
dynamic reading from the elf to solve this. If you could please give
it a test and let me know that it works as you expect.

Thanks,
Nathan

>
>
>
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijmans at topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
>
>