Re: [Xen-devel] [PATCH v2] xen: arm64: Add support for Renesas RCar Gen3 H3 Salvator-X platform

[Andre Przywara <andre.przywara@xxxxxxx>]

Hi Dirk,

On 08/07/16 12:38, Dirk Behme wrote:
> Hi Andre,
> 
> On 05.07.2016 16:29, Andre Przywara wrote:
>> Hi,
>>
>> On 05/07/16 15:22, Dirk Behme wrote:
>>> On 05.07.2016 15:45, Andre Przywara wrote:
>>>> Hi,
>>>>
>>>> On 05/07/16 14:34, Julien Grall wrote:
>>>>> (CC Andre)
>>>>>
>>>>> On 05/07/16 14:04, Dirk Behme wrote:
>>>>>> On 05.07.2016 14:45, Julien Grall wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 05/07/16 13:09, Dirk Behme wrote:
>>>>>>>> Hi Julien,
>>>>>>>>
>>>>>>>> On 05.07.2016 13:39, Julien Grall wrote:
>>>>>>>>> Hi Dirk,
>>>>>>>>>
>>>>>>>>> On 05/07/16 07:37, Dirk Behme wrote:
>>>>>>>>>> Signed-off-by: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
>>>>>>>>>
>>>>>>>>> This patch looks good to me, however I would like to see the
>>>>>>>>> documentation on the wiki page (see [1]) before giving any formal
>>>>>>>>> ack.
>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, many thanks for your review!
>>>>>>>>
>>>>>>>> Yes, I understood that something more is needed.
>>>>>>>>
>>>>>>>>
>>>>>>>> I just wonder if we keep the patch on the mailing list for a
>>>>>>>> moment.
>>>>>>>> With this it's publically available and we can see how's the public
>>>>>>>> interest for this board.
>>>>>>>>
>>>>>>>> Additionally, getting Xen running on this board and describe all
>>>>>>>> this in
>>>>>>>> the wiki isn't that easy. You either need to modify the flashed
>>>>>>>> firmware. Or, like me, load everything via a JTAG debugger ...
>>>>>>>
>>>>>>> Can you details why you think it is not easy? Why do you have to
>>>>>>> modify
>>>>>>> the firmware? Is it because it does not boot the hypervisor in EL2?
>>>>>>
>>>>>>
>>>>>> The board boots via ATF, which starts U-Boot in EL1, then. You
>>>>>> have to
>>>>>> find a way to load Xen into memory (e.g. U-Boot TFTP) and then
>>>>>> switch to
>>>>>> EL2 to start Xen.
>>>>>
>>>>> But ATF is running in EL3, right? If so, can ATF just starts U-boot
>>>>> in EL2?
>>>>>
>>>>> I have a board at home (pine64) which also uses ATF and U-Boot and is
>>>>> able to boot Xen without any SMC call because the U-Boot is entered
>>>>> in EL2.
>>>>
>>>>  From having a very quick look into the rcar ATF port on github[1] I
>>>> see:
>>>>
>>>> +#elif (RCAR_BL33_EXECUTION_EL == BL33_EL2)
>>>> +    return (uint32_t)SPSR_64(MODE_EL2, MODE_SP_ELX,
>>>> DISABLE_ALL_EXCEPTIONS);
>>>>
>>>> So if you rebuild ATF with RCAR_BL33_EXECUTION_EL set to BL33_EL2 that
>>>> should enter U-Boot in EL2.
>>>>
>>>> The fix for the Pine64 was equally simple and works fine since then.
>>>
>>>
>>> This is an other solution most probably I meant when talking about
>>> "modifying the firmware" ;)
>>>
>>> I'm somehow unsure about the pros and cons running U-Boot at EL1 versus
>>> EL2, though.
>>
>> It shouldn't matter, really. U-Boot on AArch64 (called armv8 here) is
>> able to run in any exception level (in contrast to ARMv7).
>> Actually running in EL2 is the architecturally recommended way, even
>> with ATF (by default it drops into EL2 when returning to non-secure
>> world). On Juno (and the Pine64) is works fine this way.
>>
>> As U-Boot only uses an identity mapping, many differences between EL2
>> and EL1 don't matter.
> 
> An understanding question regarding this: We found that running U-Boot
> at EL2 works fine and starting Xen works fine, then, too. So many thanks
> for that hint!
> 
> But we found that the Linux native boot case (without Xen) does fail,
> then. I.e. running U-Boot in EL1 starts the native Linux kernel
> successfully. While running U-Boot in EL2 starting the native Linux
> kernel fails, then.

That's rather odd, can you provide some debug information?

> Any idea regarding this?
> 
> Who is responsible to switch to EL1 for the native Linux boot case if
> U-Boot runs at EL2?

That's well supported kernel code in arch/arm64/kernel/head.S. If it
sees the kernel to be entered in EL2 (which is highly recommended, btw),
it installs the KVM HYP stub and drops into EL1 (after some register setup).
You might want to check the code in there to see if something springs to
mind or use some debug UART output to see where it gets stuck (if it
gets stuck). I usually do something like "mov x1, #UART_TR; mov w0,
#'1'; str w0, [x1]" to get an idea where low level code hangs.

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel