[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)



On Wed, 2014-08-27 at 12:27 -0700, Suriyan Ramasami wrote:
> On Tue, Aug 26, 2014 at 2:01 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> > On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
> >> +static int __init exynos5250_smp_init(void)
> >> +{
> >> +    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
> >> +}
> >> +
> >> +static int __init exynos5_smp_init(void)
> >> +{
> >> +    struct dt_device_node *node;
> >> +    u64 sysram_ns_base_addr;
> >> +    u64 size;
> >> +    int rc;
> >> +
> >> +    node = dt_find_compatible_node(NULL, NULL, 
> >> "samsung,exynos4210-sysram-ns");
> >
> >
> > Looking at Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> > in the Linx tree it seems that this node is supposed to be present on
> > all systems, including 5250 and it seems to be present in all the DTBs I
> > can see.
> >
> > IOW I think exynos5_smp_init and exynos5250_smp_init can just be
> > exynos5_smp_init (perhaps even folding in exynos_smp_init too).
> >
> It definitely can be folded in, but as you have mentioned later on in
> this email that Exynos5250 will stop booting cause of the erroneous
> value of 0x204f000 instead of 0x2020000. If this is folded in, then
> the arndale DT should be possibly corrected for it to play well with
> XEN.

I think this is already done, looking at v3.16-rc6 (just because I had
it checked out) arch/arm/boot/dts/exynos5250.dtsi has:
        sysram@02020000 {
                compatible = "mmio-sram";
                reg = <0x02020000 0x30000>;
                #address-cells = <1>;
                #size-cells = <1>;
                ranges = <0 0x02020000 0x30000>;

                smp-sysram@0 {
                        compatible = "samsung,exynos4210-sysram";
                        reg = <0x0 0x1000>;
                };

                smp-sysram@2f000 {
                        compatible = "samsung,exynos4210-sysram-ns";
                        reg = <0x2f000 0x1000>;
                };
        };

> > I'm unsure whether we should fallback to the existing PA_SYSRAM value,
> > but my initial feeling is that we can get away without.
> >
> > My only concern is that right now EXYNOS5250_PA_SYSRAM == 0x02020000 but
> > the DTB contains:
> >
> >         sysram@02020000 {
> > [...]
> >                 smp-sysram@0 {
> > [...]
> >                 smp-sysram@2f000 {
> >                         compatible = "samsung,exynos4210-sysram-ns";
> >                         reg = <0x2f000 0x1000>;
> >                 };
> >         };
> >
> > IOW I think the final address for the NS sysram will be 0x204f000 and
> > not 0x2020000. I'm confused how this work{s,ed}. since the DT seem to
> > suggest that the sysram at 0x2020000 is secure mode, so we can't be
> > using it.
> >
> I was going over linux kernels (not mainline but vendor modified)
> 3.10/3.13/3.14 and I find that though they have a DT, they do not seem
> to use it entirely. Especially the Exynos modified ones. They have
> many hardcoded values which they pull out of thin air and not use the
> DT ones. I am guessing that is the reason they are working. I wonder
> if the linux mainline 3.16 or 3.17 which I believe has support for the
> arndale exynos5250 boots up because of the erroneous (or so I think)
> sysram-ns value?

I've not tried something more modern on an arndale but I'm told they are
now multiplatform capable, which implies most stuff is correctly driven
by DT, proof will be in the pudding though!

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.