On Mon, 2018-03-05 at 08:16 -0600, Rob Herring wrote:

On Fri, Mar 2, 2018 at 5:27 PM, Sean Wang [off-list ref] wrote:

quoted

On Fri, 2018-03-02 at 09:42 -0600, Rob Herring wrote:

quoted

On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.wang at mediatek.com wrote:

quoted

From: Sean Wang <sean.wang@mediatek.com>

There is 2GB DDR3 available on bananapi-r2 board as [1] specified.

[1] http://www.banana-pi.org/r2.html

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 140ff78..3e8d02c 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts

@@ -38,6 +38,11 @@
                    default-state = "off";
            };
    };
+
+   memory {

Unit address?

If I did it with adding unit address

-       memory {
+       memory at 80000000 {
                device_type = "memory";
                reg = <0 0x80000000 0 0x80000000>;
        };


bad dtc blob is being generated and contains two memory nodes, one is
memory and the other is memory at 80000000 whose blob disassembly detail is
as the following.

      memory {
                device_type = "memory";
                reg = <0x0 0x0 0x0 0x0>;
        };



      memory at 80000000 {
                device_type = "memory";
                reg = <0x0 0x80000000 0x0 0x80000000>;
        };


and bad memory node with size 0 would cause the boot fails.


is it a dtc compiler problem ?

No, you are declaring "memory" node somewhere else. Perhaps using
skeleton.dtsi which we are trying to remove or you have some default.

Yes, your guess is right. the DTS explicitly includes skeleton64.dtsi so
two memory node is being generated.

Using just 'memory' is fine if the base address is variable and
determined at boot time or you have a bootloader that expects just
'memory'. Otherwise, this should be fixed, but you can do that after
this patch if you want.

The address where memory is located at is fixed so I should insert a
patch removing skeleton64.dtsi before adding a unit address to each
memory node.

Furthermore, the original DTS including skeleton64.dtsi seems to be a
little improper as CPU uses 32-bit addressing way to access all hardware
devices on MT7623 SoC. Thus, it seems to be better even necessary to
explicitly set both #address-cells and #size-cells to 1 at the root node
and change reg property for following the child nodes when
skeleton64.dtsi is being removed.

Rob