Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support

[Suriyan Ramasami <suriyan.r@xxxxxxxxx>]

On Thu, Feb 11, 2016 at 1:40 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:

On Wed, 2016-02-10 at 17:47 -0800, Suriyan Ramasami wrote:
>
>
> On Wed, Feb 10, 2016 at 2:03 AM, Ian Campbell <ian.campbell@xxxxxxxxxx>
> wrote:
> > On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami wrote:
> > > ÂI agree on the first two paragraphs.
> > > > > For the third paragraph, the rebuttal is that the exynos5800 and
> > > > > exynos5422 based SoCs can have both clusters on at the same time.
> > Hence,
> > > > > the third paragrapah comment will have to be tweaked further.
> > Possibly
> > > > > reading:
> > > > > The exynos5800 and exynos5422 can have both clusters on at the
> > same time.
> > > > > The exynos5800 boots up with cpu0 on cluster0 (A15). The
> > exynos5422 can
> > > > > boot up on either clusters as its pin controlled. In this case
> > the DTS
> > > > > should properly reflect the cpu order.
> > > >
> > > > Does the OS need to be aware of all these combinations though? Is
> > it not
> > > > sufficient to know how to bring up an A15 core and how to bring up
> > an A7
> > > > core and then just do so based on the information in the DTS,
> > without
> > > > needing to worry about which sort of core we happened to have
> > booted on?
> > > >
> > > >
> > > Unfortunately, at least looking at the boot up code for the
> > Exynos5422,
> > > the OS needs to be aware of it. This is what I see in the linux
> > source
> > > code. If it boots up on an A7, then a special reset is needed which
> > is
> > > not needed when booted up otherwise. I do not have much more details
> > on
> > > that other than the Linux code.
> > > Without that reset sequence, I have also verified that the powered on
> > CPU
> > > does not come up.
> >
> > Are we able to say that if we are booted on cluster 1 (always the A7s)
> > then
> > we always need this magic reset? i.e. is true for all SoCs which have
> > an A7
> > cluster and can boot from it? (it's tautologically true for SocS which
> > either have no A7's or cannot boot from them).
> >
> I do not have the information to answer the question. I am limited to
> what I know (albeit a little bit) wrt the hardkernel related boards -
> Exynos 5410 (odroid-XU) and the Exynos 5422 (Odoird XU3/XU4). With my
> limited knowledge, I am only aware of Exynos 5410 which is capable of
> booting off of an A7 or an A15.
> Â
> > ÂMaybe I'm looking for similarities between different exynos variants
> > which
> > doesn't exist though. If we are going to talk about specific SoCs in
> > the
> > comments then I would rather that the code was also explicit rather
> > than
> > assuming cluster 1 will only be found on the 5800, that might be as
> > simple
> > as mapping the compatible string to a max_cluster (default 0 for
> > unknown
> > SoC) and warning if pcluster > max_cluster.
> Can you please elaborate on the mapping that you talk about above. I am
> lost here :-(

What I mean is can we say:
  exynos 1234 => Two clusters (max_cluster == 1)
  exynos 5678 => One cluster (max_cluster == 0)
  exynos ABCD => Two clusters (max_cluster == 1)Â
  Unknown   => Assume one cluster

and can we also assume that cluster 0 always consists of A15s and cluster 1
(if it exists) always consists of A7s?

If so then we can say:

 max_cluster = look_up_by_compat(compat)
 pcluster = figure out from midr
 pcpu = figure it out

 if (pcluster >= max_cluster)
  error

 do bringup

 if (pluster == 1)
  do special handling for cluster 1 == a7

The difference compared with what you have is that it adds a check that we
expect a second cluster for the SoC before it goes poking at stuff.

What I'm trying to avoid is coming across some other SoC variant which has
2 clusters but has something different to the A7s or which requires some
different handling.

If we were confident that all exynosXXXX SoCs always require the same
special handling for cluster 1 then we wouldn't really need this, but I
don't think we know that?

I did some looking at the linux 4.4.y dts for exynos, and this is what I see:

exynos3250: cpu0, cpu1 = A7 (1 cluster)

exynos4210: cpu0, cpu1 = A9 (1 cluster)

exynos4212: cpu0, cpu1 = A9 (1 cluster)

exynos4412: cpu0, cpu1, cpu2, cpu3 = A9 (1 cluster)

exynos4415: cpu0, cpu1, cpu2, cpu3 = A9 (1 cluster)

exynos5250: cpu0, cpu1 = A15 (1 cluster)

exynos5260: cpu0, cpu1 = A15. cpu2, cpu3, cpu4, cpu5 = A7 (2 clusters)

exynos5410: cpu0, cpu1, cpu2, cpu3 = A15 (1 cluster - even thougg it has 2 clusters, but not both can be on at same time)

exynos5420: cpu0, cpu1, cpu2, cpu3 = A15. cpu4, cpu5, cpu6, cpu7 = A7 (2 clusters)

exynos5422: cpu0, cpu1, cpu2, cpu3 = A7. cpu4, cpu5, cpu6, cpu7 = A15 (2 clusters)

exynos5440: cpu0, cpu1, cpu2, cpu3 = A15 (1 cluster)

If we look at the ones that can potentially support hardware virtualization, limits us to the A7s and the A15s. That gives us:

exynos3250: cpu0, cpu1 = A7 (1 cluster)

exynos5250: cpu0, cpu1 = A15 (1 cluster)

exynos5260: cpu0, cpu1 = A15. cpu2, cpu3, cpu4, cpu5 = A7 (2 clusters)

exynos5410: cpu0, cpu1, cpu2, cpu3 = A15 (1 cluster)

exynos5420: cpu0, cpu1, cpu2, cpu3 = A15. cpu4, cpu5, cpu6, cpu7 = A7 (2 clusters)

exynos5422: cpu0, cpu1, cpu2, cpu3 = A7. cpu4, cpu5, cpu6, cpu7 = A15 (2 clusters)

exynos5440: cpu0, cpu1, cpu2, cpu3 = A15 (1 cluster)

Of these the only ones which has A7 as the 1st cluster are:

exynos3250: cpu0, cpu1 = A7

exynos5420: cpu0, cpu1, cpu2, cpu3 = A15. cpu4, cpu5, cpu6, cpu7 = A7 (2 clusters)

Note that the exynos5800 has the same cpu config as the exysno5420.

I was looking at the cpu bring up code, and notice that if the secondary cpu being brought up is an A7, then it invariably does the below:

For the exynos3250: in platsmp.c

void exynos_core_restart(u32 core_id)

{Â

    u32 val;

    if (!of_machine_is_compatible("samsung,exynos3250"))

        return;

    while (!pmu_raw_readl(S5P_PMU_SPARE2))

        udelay(10);

    udelay(10);

    val = pmu_raw_readl(EXYNOS_ARM_CORE_STATUS(core_id));

    val |= S5P_CORE_WAKEUP_FROM_LOCAL_CFG;

    pmu_raw_writel(val, EXYNOS_ARM_CORE_STATUS(core_id));

    pmu_raw_writel(EXYNOS_CORE_PO_RESET(core_id), EXYNOS_SWRESET);

}

And for the exynos5800/exynos5422: mcpm-exynos.c

static int exynos_cpu_powerup(unsigned int cpu, unsigned int cluster)

{

    unsigned int cpunr = cpu + (cluster * EXYNOS5420_CPUS_PER_CLUSTER);

    pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);

    if (cpu >= EXYNOS5420_CPUS_PER_CLUSTER ||

        cluster >= EXYNOS5420_NR_CLUSTERS)

        return -EINVAL;

    if (!exynos_cpu_power_state(cpunr)) {

        exynos_cpu_power_up(cpunr);

        /*

        Â* This assumes the cluster number of the big cores(Cortex A15)

        Â* is 0 and the Little cores(Cortex A7) is 1.

        * When the system was booted from the Little core,

        Â* they should be reset during power up cpu.

        Â*/

        if (cluster &&

          cluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {

            /*

            Â* Before we reset the Little cores, we should wait

            Â* the SPARE2 register is set to 1 because the init

            Â* codes of the iROM will set the register after

            Â* initialization.

            Â*/

            while (!pmu_raw_readl(S5P_PMU_SPARE2))

                udelay(10);

            pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),

                    EXYNOS_SWRESET);

        }

    }

    return 0;

}

This pretty much indicates that when bringing up the A7s, the special reset sequence is deemed essential. Probably, we could generalize that it might be true for future exynos's having A7s.

Â

> Â
> > Â
> > >
> > > > Â>Â The exynos5410 can have only one cluster on at a time, and it
> > boots
> > > > up
> > > > > with pcluster == 0.
> > > > > Any tweaks and comments on the above is appreciated.
> > > >
> > > > How much of this is down to physical h/w limitations and how much
> > of it
> > > > is
> > > > down to firmware or software limitations? Can you flip the to the
> > other
> > > > cluster somehow?
> > > > ÂÂ
> > > The 5410 boots up on an A15, and only those 4 A15 CPUs in cluster 0
> > are
> > > brought up. Hence, no flipping is required.
> >
> > What I meant was, given that the 5410 has a cluster of A15 and a
> > cluster of
> > A7s (right?) and you can only have one on at a time, how does an OS
> > make
> > use of the A7s if it wants to? As you say it boots from the A15, so how
> > can
> > the A7s be used?
> >
> >
> The Linux OS has a bL (big - little) switcher module/code which handles
> that. It maps one big core to one little core, and when the load is not
> high, it switches off the big cluster, and turns on the small cluster -
> AFAICT.

So this is an OS limitation, not a h/w one? What's to stop an OS from
brninging up the A15s and the A7s at the same time?

> Also, are we still on wrt the two cpu pool suggestion and to have 4 cores
> from cluster 0 in cpupool0 and 4 cores from cluster 1 in cpupool1. It
> would be great if you can point me to some code as well. I have been
> looking at cpupool.c and also on the system call interface that it
> provides.

I'm afraid I'm not really very familiar with this side of things myself :-(

Thanks, I shall dig into this some more.

Â

Ian.

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