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

[york sun]

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.

York