On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall <julien.gr...@arm.com> wrote:
On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall <julien.gr...@arm.com> wrote:
Somehow I thought the platform was 64-bit and found a SOC name very
to it. Sorry for the confusion. PSCI seems indeed not supported for that
R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)
However, the code looks fairly different than what we have in Xen. For
instance secondary CPU seems to require to initialize CNTVOFF, the
to power on a CPU also looks different.
Sorry, which code you are taking about, U-Boot or Linux?
The SMP code in Linux vs the SMP code in Xen for the R-Car. In most of the
cases, Xen should replicate what Linux does.
I am trying to understand why such differences at the moment.
As I understand, the SMP code for Linux can't be used in Xen, since
the requirement is to boot into Xen with cores already being in
But, all cores seems to start in Monitor mode after powering them up.
So, they must be switched into Hypervisor mode beforehand, correct?
I am quite confused here. If a CPU will be in hypervisor mode for Xen,
how come the same CPU will boot in monitor mode for Linux? Surely there
should be no difference in term of boot here. Are you using different
U-Boot brings non-boot cores up (using ported from Linux's
platsmp-apmu code functions). Then U-Boot switches all cores to HYP
Who did the port? Is it upstream?
While jump into Xen on a boot core, all non-boot cores are left in
U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
Platform R-Car2 code in Xen doesn't power on cores, it just "brings
them to Xen".
What does the address 0xe63c0000 corresponds too? From the DT it seems
it is part of the ICRAM. But it is not clear why you write in there.
Could you point to any relevant documentation?
Xen-devel mailing list