[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board
Hi Oleksandr,
On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
Hi, Julien
Hi Oleksandr,
Hi Julien
On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
Hi,
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
Renesas "Stout" development board (with different expansion boards)
is also based on R-Car Gen2 SoC. So extend compat array with
board's compatible strings.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
CC: Julien Grall <julien.grall@xxxxxxx>
---
xen/arch/arm/platforms/rcar2.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/platforms/rcar2.c
b/xen/arch/arm/platforms/rcar2.c
index df0ac84..ee2ded0 100644
--- a/xen/arch/arm/platforms/rcar2.c
+++ b/xen/arch/arm/platforms/rcar2.c
@@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
static const char *const rcar2_dt_compat[] __initconst =
{
"renesas,lager",
+ "renesas,r8a7790stout",
+ "renesas,r8a7790stout-view",
+ "renesas,r8a7790stout-had",
+ "renesas,r8a7790stout-full",
I am quite reluctant to add compatible that are not present in upstream
Linux. Looking at the DT upstreamed in Linux, the compatible for r8a7790
SoC
seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all the
boards? But ...
This compatible came from official BSP for this board...
https://elinux.org/R-Car/Boards/Yocto#Running
I have just checked "renesas,r8a7790" and you was right, it covers
these modifications. So, I will change.
Moreover, we can just have only single compatible, which will cover (I
hope) all boards based on R-Car H2 SoC, including Lager board
(compatible = "renesas,lager", "renesas,r8a7790")
static const char *const rcar2_dt_compat[] __initconst =
{
- "renesas,lager",
+ "renesas,r8a7790",
NULL
};
What do you think?
That would be the best.
... don't you have PSCI support on those platforms?
AFAIK, no.
This code is definitely needed for Stout board as well, since the SoC
is the same (R-Car Gen2).
When I looked at the device-tree upstreamed for R-Car Gen2 (I think
r8a7790), PSCI is supported. So I am a bit surprised that the Stout (or even
lager) does not support it. Are you sure you are not using an old firmware?
This is the topic I am not quite familiar with, so may mistake...
Yes, the BSP I use is quite old, but I managed to run it on top of Xen...
Just to clarify, saying firmware you mean something running in Secure
World, like ARM TF, for example
and providing PSCI services? If yes, the BSP for R-Car Gen2 seems
doesn't contain it. Only U-Boot is available.
But U-Boot was modified to be able to switch A15 cores to HYP mode.
Here [1] you can see how it was done for Lager board,
something similar I did for Stout board.
So, in a nutshell, SMP bring-up under Xen is done in following way:
- U-Boot switches all cores to HYP mode and jumps to Xen on a boot
core, while non-boot cores are waiting in U-Boot.
- Platform SMP init code (rcar2.c) brings each non-boot core to Xen.
If not, can you please point me to the code in Linux (upstream or BSP) doing
the SMP bring-up for the R-Car?
BSP is based on + additional patches in Yocto layers:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/boot/dts/r8a7790.dtsi?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/mach-shmobile/platsmp-apmu.c?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
Upstream code:
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/r8a7790.dtsi
https://github.com/torvalds/linux/blob/master/arch/arm/mach-shmobile/platsmp-apmu.c
Could you point me a link to device-tree where PSCI is supported?
Somehow I thought the platform was 64-bit and found a SOC name very
similar to it. Sorry for the confusion. PSCI seems indeed not supported
for that platform.
However, the code looks fairly different than what we have in Xen. For
instance secondary CPU seems to require to initialize CNTVOFF, the
function to power on a CPU also looks different.
Could you explain why such differences?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
