[U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/04/2016 10:12 AM, Alexander Graf wrote:
>
>
> On 04/11/2016 17:08, york sun wrote:
>> On 11/04/2016 09:53 AM, Alexander Graf wrote:
>>>
>>>
>>> On 04/11/2016 16:43, york sun wrote:
>>>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>>>>>
>>>>>>> Yes, with the attached patch on top of your original 2 patches,
>>>>>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>>>>>> and Juno R0, R1 and R2.
>>>>>>>
>>>>>>> I don't think it would be good to stack these three patches the way
>>>>>>> they are presented in the upstream tree because it would not be
>>>>>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>>>>>
>>>>>>> Note: I haven't attempted to understand what any of this code is
>>>>>>> doing, I'm just testing it with my standard boot flow to make sure
>>>>>>> nothing is broken for me.
>>>>>>
>>>>>> Ryan,
>>>>>>
>>>>>> I support Alison's patch order for her 32-bit patch sets. This feature
>>>>>> doesn't exist before her first set. It is functional if you run U-Boot
>>>>>> at EL3 after the first patch.
>>>>>
>>>>> Which I don't do.  I follow the boot flow recommended by ARM and it
>>>>> doesn't work for that setup, which I don't think is the right thing to
>>>>> do.
>>>>>
>>>>>
>>>>>> It gets EL2 working after the 2nd set. If
>>>>>> there is room to clarify in the commit message, please kindly suggest.
>>>>>>
>>>>>
>>>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>>>>> a tree that wasn't bootable at any point in the patch sequence.
>>>>> That's generally unacceptable on most projects I work on.  Keeping the
>>>>> tree bisect-able to prove which commit caused a problem is considered
>>>>> to be a valuable tool.
>>>>>
>>>>
>>>> Ryan,
>>>>
>>>> Thanks for sharing your concern. I support git-bisect. It is valuable,
>>>> no doubt. Let me try to understand the issue here. Without Alison's
>>>> patches, everything boots OK. With her first set, does something break?
>>>
>>> Yes, with the patches booting 64bit Linux with U-Boot running in EL2
>>> breaks according to Ryan.
>>>
>>>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
>>>> then she needs to fix it.
>>>
>>> That's his point :). And I concur.
>>
>> Thanks for the confirmation.
>>
>>>
>>> (btw, you guys really should start thinking about following the ARM
>>> recommended boot model. It's pretty cumbersome to do everything
>>> different just for NXP)
>>
>> If you are referring the trusted firmware, we are following that
>> direction. Just not fully up yet on some platform.
>>
>> It is definitely not our intention to be cumbersome. Please point out
>> where it went sideway beside the trusted firmware.
>
> Basically it boils down to the fact that you are the only platform that
> runs U-Boot in EL3 :).
>
> If you want to keep the memory initialization inside of U-Boot, I think
> that's great. But you could either split that into SPL/EL2 or degrade
> yourself into EL2 as soon as possible by calling into an EL3 firmware.
> Whether you build that firmware as part of U-Boot (the stock one could
> be very trivial) or externally is not really too much of a problem.
>
> Things like Alison's patches could then do a simple PSCI call into said
> EL3 firmware to call into 32bit code in EL2 for example.
>

Basically I agree with you. U-Boot will run at EL2 as soon as we have 
the trusted firmware in place.

York