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 11:08 +0100, Ian Campbell wrote:
> 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).

And to further clarify an apparent misunderstanding in the first mail: A
reg property is a list of <address> <size> pairs, with each consuming
the appropriate #foo-cells (so 2 for both here, meaning each entry is 4
cells in total).

Ian.


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