[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 Thu, Sep 4, 2014 at 1:58 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2014-09-03 at 10:55 -0700, Suriyan Ramasami wrote:
>> On Wed, Sep 3, 2014 at 3:03 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > 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 am a little confused here. We are using - compatible =
>> "samsung,exynos4210-sysram-ns" to pull the value for
>> sysram_ns_base_addr in function exynos5_smp_init(). I believe with the
>> exynos5250 DT you have quoted above, wouldn't that add up to 2020000 +
>> 2f000? (which is not what we want for the arndale?) I shall wait on
>> your thoughts on this.
>
> I think I mentioned this upthread. At the time I had no idea why but
> looking again:
>
> DT has 0x0204f000 whereas we are hardcoding 0x02020000. The DT lists
> 0x2020000 as the secure sysram. Aha! Looks like this was wrongly
> converted by:
>
>         4557c2292854d047ba8e44a69e2d60d99533d155
>         Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
>         Date:   Thu Aug 29 16:25:00 2013 +0100
>
>             xen: arm: rewrite start of day page table and cpu bring up
>
> which moved the CPU kick from secure mode to NS mode. Has SMP on arndale
> been broken since then? Probably.
>

So, it does make sense to fold it in and get rid of the 0x02020000
hardcoded value for Arndale. Right? I shall push a version 6 with this
change.

>> On the same train of thought, it would seem that EXYNOS5_MCT_BASE
>> should also be extracted from the DT (in function exynos5_init_time).
>
> Ideally, yes.
>
This has been incorporated in version 5 of the patch.
Thanks!

> 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®.