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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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?

> Â
> > Â
> > >
> > > > Â>Â 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 :-(

Ian.

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