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

[Alexander Graf]

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.


Alex