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

[Julien Grall <julien.grall@xxxxxxx>]

On 07/07/17 11:47, Andrii Anisov wrote:
> 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.
Not really, you can modify the U-boot environment and save it...

> 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
> > > > > appropriately.
> > > > 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.
> > > Well...
> > > 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.
The bootloader section is not Xen specific. It points to the official 
sunxi bootloader.
> > 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.
You can say it is supported and listing known limitations, not saying it 
is fully supported. As you said, there is a long way to end up fully 
support.
Cheers,

> 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
--
Julien Grall

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