linux-kernel - Re: [PATCH v1 16/19] arm: dts: mt7623: fixup available memory size on bananapi-r2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Mar 2018 23:46:48 +0800
From:   Sean Wang <sean.wang@...iatek.com>
To:     Rob Herring <robh@...nel.org>
CC:     Matthias Brugger <matthias.bgg@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        <devicetree@...r.kernel.org>, <linux-mediatek@...ts.infradead.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 16/19] arm: dts: mt7623: fixup available memory size
 on bananapi-r2

On Mon, 2018-03-05 at 08:16 -0600, Rob Herring wrote:
> On Fri, Mar 2, 2018 at 5:27 PM, Sean Wang <sean.wang@...iatek.com> 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@...iatek.com wrote:
> >> > From: Sean Wang <sean.wang@...iatek.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@...iatek.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@...00000 {
> >                 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@...00000 whose blob disassembly detail is
> > as the following.
> >
> >       memory {
> >                 device_type = "memory";
> >                 reg = <0x0 0x0 0x0 0x0>;
> >         };
> >
> >
> >
> >       memory@...00000 {
> >                 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