[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Bug in devicetree_for_each_node() in xen/arch/arm/bootfdt.c ?
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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |