On 11/22/2016 09:02 AM, Alexander Graf wrote:
> On 11/21/2016 10:48 PM, york sun wrote:
>> On 11/21/2016 01:07 PM, Alexander Graf wrote:
>>>
>>> On 21/11/2016 21:45, york sun wrote:
>>>> On 11/21/2016 12:40 PM, Alexander Graf wrote:
>>>>>
>>>>> On 21/11/2016 21:23, york sun wrote:
>>>>>> On 11/09/2016 07:02 PM, Alison Wang wrote:
>>>>>>> To support loading a 32-bit OS, the execution state will change from
>>>>>>> AArch64 to AArch32 when jumping to kernel.
>>>>>>>
>>>>>>> The architecture information will be got through checking FIT image,
>>>>>>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>>>>>>
>>>>>>> Signed-off-by: Ebony Zhu <ebony....@nxp.com>
>>>>>>> Signed-off-by: Alison Wang <alison.w...@nxp.com>
>>>>>>> Signed-off-by: Chenhui Zhao <chenhui.z...@nxp.com>
>>>>>>> ---
>>>>>>> Changes in v8:
>>>>>>> - Fix the issue when U-Boot is running in EL2 or EL1.
>>>>>>>
>>>>>> Alison,
>>>>>>
>>>>>> There is a conflict when merging with upstream code. Alex Graf merged
>>>>>> his change to support EFI booting. See commit
>>>>>> 69bd459d343fe1e5a68a6f187d8c99c78c6fc6ce. Specifically these lines
>>>>>>
>>>>>>
>>>>>> if (current_el() == 3) {
>>>>>> smp_kick_all_cpus();
>>>>>> dcache_disable();
>>>>>> armv8_switch_to_el2();
>>>>>> dcache_enable();
>>>>>> }
>>>>>>
>>>>>> Function armv8_switch_to_el2() didn't take any argument before you
>>>>>> change. With your proposed change to support 32-bit OS, you added
>>>>>> arguments to this function, and presume this function always load OS.
>>>>>> This may be flawed. Would it be possible to keep armv8_switch_to_el2()
>>>>>> but introduce another function to carry out switching EL while loading
>>>>>> OS?
>>>>> Alison introduced it based on my comments - and I'd prefer if we only
>>>>> have the function call based version :).
>>>>>
>>>>> It should be reasonably straight forward to move to it here. Just create
>>>>> a new helper stub that enables the dcache and calls entry().
>>>>>
>>>> Alex,
>>>>
>>>> Do you always load OS when calling armv8_switch_to_el2()? In this case
>>>> of efi booting, kernel entry point needs to be passed to the new
>>>> armv8_switch_to_el2 function. The new armv8_switch_to_el2 function
>>>> doesn't return, so you cannot continue to run the code.
>>> We always call some random function pointer in the new flow. That can be
>>> a kernel entry point, but it can also just be a function pointer. In
>>> this case, the code would basically look like this:
>>>
>>> static ulong efi_run_in_el2(ulong (*entry), void *arg1, void *arg2)
>>> {
>>> dcache_enable();
>>> return entry(arg1, arg2);
>>> }
>>>
>>> if (current_el() == 3) {
>>> ...
>>> return armv8_switch_to_el2(efi_run_in_el2, entry,
>>> &loaded_image_info, &systab);
>>> }
>>>
>> Alex,
>>
>> Since you are most familiar with EFI boot code, can you send a patch to
>> address this? I can squash it with Alison's patch after testing. My
>> current test branch is
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.denx.de%2F%3Fp%3Du-boot%2Fu-boot-fsl-qoriq.git%3Ba%3Dshortlog%3Bh%3Drefs%2Fheads%2Ftest_qoriq&data=01%7C01%7Cyork.sun%40nxp.com%7C0b9b6fdb53c94e1a953d08d412f9502f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=ALW8GdHxkPJghve%2BxbKQ1E9ssjFxSOf35PvVuY34ZiA%3D&reserved=0.
>
> While trying to fix this up, I ran across another compile breakage:
>
> arch/arm/cpu/armv8/fsl-layerscape/mp.c:114: undefined reference to
> `initiator_type'
> arch/arm/cpu/armv8/fsl-layerscape/mp.c:123: undefined reference to
> `initiator_type'
>
Possibly cause by a new set of patches sent by Priyanka for LS2088A.
Let's use upstream master branch plus Alison's three patches.
York
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
