On 20. 11. 20 11:48, Michael Walle wrote:
> Am 2020-11-20 11:14, schrieb Michal Simek:
>> Hi,
>>
>> On 18. 11. 20 17:45, Michael Walle wrote:
>>> Newer TF-A versions provide a new image loading protocol. This is
>>> used on
>>> (newer?) NXP's SoCs. Normally, the bootflow is bl1 -> bl2 -> bl31 ->
>>> u-boot. With this series it is possible that U-Boot SPL loads the bl31
>>> directly and thus replacing bl1 and bl2 from the TF-A.
>>>
>>> This was tested on the Kontron sl28 board using NXPs bl31 and the
>>> upstream
>>> version of the OP-TEE Trusted OS.
>>
>> I still have some questions about this.
>>
>> As I see from TFA previous image format has been removed in 2018 by
>>
>> commit ed51b51f7a9163a7fc48289c5ed97a3fe4fe504f
>> Author:     Roberto Vargas <roberto.var...@arm.com>
>> AuthorDate: Mon Sep 24 17:20:48 2018 +0100
>> Commit:     Antonio Nino Diaz <antonio.ninod...@arm.com>
>> CommitDate: Fri Sep 28 15:31:52 2018 +0100
>>
>>     Remove build option LOAD_IMAGE_V2
>>
>>     The code of LOAD_IMAGE_V2=0 has been removed.
>>
>>     Change-Id: Iea03e5bebb90c66889bdb23f85c07d0c9717fffe
>>     Co-authored-by: Antonio Nino Diaz <antonio.ninod...@arm.com>
>>     Signed-off-by: Antonio Nino Diaz <antonio.ninod...@arm.com>
>>
>>
> 
> DOH! Lol, I'm using just one non-upstream part for the whole board
> and of course it is doing something miserable. I wasn't aware of this.
> 
>> On Xilinx ZynqMP I use SPL->bl31 loading but not using that TFA
>> structure because xilinx is using own format.
>>
>> But I am curious if V2 was removed in 2018 who is really using previous
>> one and also if current implemenation is origin or also not full v2.
> 
> NXP,
> https://source.codeaurora.org/external/qoriq/qoriq-components/atf/tree/plat/nxp/common/common.mk#n55
> 
> 
> The last non-nxp commit there was from around March 2018..
> 
>> And these patches are not breaking boot on zynqmp that's why not big
>> deal for me.
> 
> I was looking at porting TFA to upstream for this board but there is
> such a huge gap. Therefore, it seemed to be easier to just use the
> vendor version for now.

Please get this reviewed by people who are using current blX code.
As I said this series is not breaking our flow on xilinx zynqmp soc but
maybe your code is more or less duplication of what's there now.
Or maybe if there is any NXP private way it should be handled
differently as I do for zynqmp.

Thanks,
Michal

Reply via email to