[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Renesas R-Car Gen3 SoCs earlyprintk support.

Dear Julien,

On 06.07.17 15:35, Julien Grall wrote:
I don't count the chosen node. This could be done via the u-boot command line, so no need to load a separate DT.
I looked through all available manuals.
Most of them imply significant amount of manual actions to start the system. From one hand it is good for understanding of the required changes, from other hand - to play with the system one will reinvent the wheel to automate those actions. Our approach is to hide all details under the hood to provide a system to play with. Also, as I know, Renesas does not provide any prebuilts, the yocto build is the only way to get binaries, so IMHO providing meta-layer over their pack is pretty natural.
The wiki page gives the false impression that Xen upstream is fully
supported on Renesas, whilst from what you said this is not true and
change are required in the BSP.
I would say in different words: XEN upstream is fully supported on
Renesas, but due to XEN functionality gaps the BSP should be adjusted

You can't say in the same sentence, the board is fully supported and
there are missing functionality that requires change in the BSP. They
are incompatible.

I agree that we are able to boot Xen on Renesas (not sure to which
extend without modification). But you can't claim it is fully
supported until all those gaps are fixed.
Do you say that calls to ARM TEE from XEN domains works for all
supported boards? And smc trapping is somehow Renesas specific?

I am not aware of any board we currently support requiring to issue SMC calls.

We used to have one in the past, but this has been fixed in the BSP to avoid issuing SMC when it is not allowed.
Or you state that TEE is never provided as a part of BSP for supported
boards? So nobody mention the gap?

You are the first person looking actively at TEE with Xen upstream. I personally don't have any board that is using TEE.

Are you saying TEE will not be detected via the Device Tree and the BSP will always assume it is present?
Yep, it is. At the moment it seems to be weird.

If the bootloader does not leave you in EL2, then it is a bug in the bootloader that should be fixed in the official BSP.
In Renesas'es case, that is a matter of configuration. ATFW by default is built without the option to run bootloader in EL2.

Not in a separate repository just for Xen.
At least here [1] it is described in such a way.

My point is we should work with Renesas to get the official BSP to support Xen rather than forking the BSP and carry all the changes.
It is fair enough. We are working with Renesas to put required changes to the official BSP. But this directly depends on what Volodymyr Babchuk does for SMC.

This is more sustainable and less overhead for everyone in the future.
I do apologize for being too expressive.
I just want to understand how to claim R-Car Gen3 support in XEN with what we have now. With known limitations and patches to the BSP.
Having required changes in the official BSP will take much more time.

[1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner#Bootloader


*Andrii Anisov*

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.