Re: Bug in devicetree_for_each_node() in xen/arch/arm/bootfdt.c ?

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-06-23 at 10:57 +0100, Ian Campbell wrote:
> On Tue, 2015-06-23 at 10:44 +0100, David Vrabel wrote:
> > On 23/06/15 00:02, Chris (Christopher) Brand wrote:
> > > I’ve been trying to figure out why Xen only reports 2GB on my ARM
> > > platform that actually has 3GB, and I think I’ve found a bug, but I’m
> > > not familiar enough with the Xen code to fix it.
> > > 
> > > The relevant parts of my dts are:
> > > 
> > > /dts-v1/;
> > > / {
> > > 
> > >      model = "Broadcom STB (7445d0)";
> > >      compatible = "brcm,bcm7445d0", "brcm,brcmstb";
> > >      #address-cells = <0x2>;
> > >      #size-cells = <0x2>;
> > >      interrupt-parent = <0x1>;
> > > 
> > >      memory {
> > >            #address-cells = <0x1>;
> > >            #size-cells = <0x1>;
> > >            device_type = "memory";
> > >            reg = <0x0 0x0 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>;
> > 
> > It's been a while since I've looked at device tree stuff but I think you
> > need 64-bit values for this reg property because the parent node has
> > #address-cells == 0x2 and #size-cells == 0x2.
> 
> Yes, the prevailing sizes will be 0x2 here, since the 0x1 only apply to
> _children_. However you still need to write the cells as separate 32-bit
> entries, so the above encodes to memory regions from 0x0.0 to
> 0x0.40000000 and 0x0.40000000 to 0x0.80000000 (using . to show where the
> cell boundary lies).
> 
> I don't know this platform, but that seems a plausible description of 2x
> 1GB regions.

I read the original report backwards, thinking 2GB was expected, but
rereading I see that 3GB was expected. In which case I think there is a
region missing in the DTB (or the hardware really only has 2GB).

Ian.


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