From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Wang Subject: Re: [PATCH v1 16/19] arm: dts: mt7623: fixup available memory size on bananapi-r2 Date: Mon, 5 Mar 2018 23:46:48 +0800 Message-ID: <1520264808.8089.261.camel@mtkswgap22> References: <20180302154215.xr3b2zlmuojw5i6l@rob-hp-laptop> <1520033229.8089.198.camel@mtkswgap22> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Rob Herring Cc: Matthias Brugger , Mark Rutland , devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "linux-kernel@vger.kernel.org" List-Id: devicetree@vger.kernel.org On Mon, 2018-03-05 at 08:16 -0600, Rob Herring wrote: > On Fri, Mar 2, 2018 at 5:27 PM, Sean Wang wrote: > > On Fri, 2018-03-02 at 09:42 -0600, Rob Herring wrote: > >> On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.wang@mediatek.com wrote: > >> > From: Sean Wang > >> > > >> > 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 > >> > --- > >> > 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@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@80000000 whose blob disassembly detail is > > as the following. > > > > memory { > > device_type = "memory"; > > reg = <0x0 0x0 0x0 0x0>; > > }; > > > > > > > > memory@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