From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756791AbcLNVsi (ORCPT ); Wed, 14 Dec 2016 16:48:38 -0500 Received: from mout.gmx.net ([212.227.17.21]:59642 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbcLNVsg (ORCPT ); Wed, 14 Dec 2016 16:48:36 -0500 Subject: Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range To: Neil Armstrong , khilman@baylibre.com, carlo@caione.org References: <20161212101801.28491-1-narmstrong@baylibre.com> <09bb78ed-c8ec-d21f-d464-16e55c481d4e@gmx.de> <56869b90-6bee-f6ae-a7b1-884b4c0d72c0@baylibre.com> Cc: linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org From: Heinrich Schuchardt Message-ID: <5c06db98-f773-d84e-f2b4-828c9a615ee8@gmx.de> Date: Wed, 14 Dec 2016 22:44:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <56869b90-6bee-f6ae-a7b1-884b4c0d72c0@baylibre.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ULSaWvYxjfnvt2sT+QtwvESGP5QpolXzUApCk/Q06eeagI8FSWY JSdvRT7EyRPKDWnjpK9b3W8LqXaXe9hHo2RVn1fdajd40WUQPKqWdNDRPCA5UwL/cFkeigh +qV3XwvFFG5t4kyFfJOzJdS3sgwnEjU5GzpdjNZwSolvIYdhDoQhYWPupK0qzAQ8hxAVrN/ fgCF+8ulcHCCWsub86N6w== X-UI-Out-Filterresults: notjunk:1;V01:K0:2Mzqx9nz9DQ=:3Wzsk2OeVhiDGaa1rlsF7b QDr3Fuyb8dpyDYX1fp9P0HMYX3M67zSn76h7BgB2FR5qOey6R7ywbiPQ7+Sn3CoSMinLwlTfQ Ig0ogtYqCt9QK+7js7uPa9f/D6pWgW82HhZFefxy2GQLXl8M316HZxreqw9EtNOtaJs1q5N27 2j5VMKcFE3zpH8yueTefNnx94C4vGLneyNb8feMsdqXREHRHFw+ZU3aJaQzqJ0eFsuX+s4A85 OVlXMHy+f8AZV2SB3FPMy1h9tAIi5fQgrFkCGfweH1hfw13GZOjXC9Mt3etGza/h95JZ6iBw/ P01grbkbdnpfmTA1d5B4ttrLW6mBgxrYUy51czvT+4uKicANTP+3yYlT0M0UbkMw7u8S+yvF4 XrgRXFAIWh7PQTmif/Zewpu+8FprY7Kxl0Svd5w8ogwc1Mv+6N9j5T087mUEFX3xVRnphRJYz U3fwfQiMRu00HKVH5vH3toihVn9TwauTQFl+f9sCR0lEgbIw+nKGUxcUsw2h1GpkVudAee5dZ MGcjadq5NFbZHb3mKe2LgfH7dfT65SVJBTe2WlEch2jX+F73oE/nnj+DsfB2NWZ6vMoEsYs3h vBWfhDPiIRTP1nJTQ2Gu59ikmTMeRAIbEON21imBrIMWX4fh8+dY9h2OjwwEZ1D2vGEhecrCb 1kEXQpthP+cqgnhdixwy/q7WxthkLBUxn6dzE/oLFNNdL3ON/7MCqQZtUu5fWpqSJ+7n8c2iX D/ltdM00CbjERiiZY6cJUXsD3tjR8epYDMNz6QNV5E0hNTHn8ED2jjXJTP3AGhIHhCvkyKXlr pioY4iz Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/14/2016 10:52 AM, Neil Armstrong wrote: > On 12/12/2016 10:22 PM, Heinrich Schuchardt wrote: >> On 12/12/2016 11:18 AM, Neil Armstrong wrote: >>> The Amlogic Meson GXBB secure monitor uses part of the memory space, this >>> patch adds these reserved zones and redefines the usable memory range for >>> each boards. >>> >>> Signed-off-by: Neil Armstrong >>> --- >>> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 +++++++++++++++++++++ >>> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +- >>> .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +- >>> .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +- >>> .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +- >>> .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +- >>> .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +- >>> 11 files changed, 31 insertions(+), 10 deletions(-) >>> >>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >>> index 7a078be..ac40b2d 100644 >>> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >>> @@ -56,7 +56,7 @@ >>> >>> memory@0 { >>> device_type = "memory"; >>> - reg = <0x0 0x0 0x0 0x80000000>; >>> + reg = <0x0 0x1000000 0x0 0x7f000000>; >>> }; >>> >>> vddio_boot: regulator-vddio_boot { >>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >>> index fc033c0..e085588 100644 >>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >>> @@ -55,6 +55,27 @@ >>> #address-cells = <2>; >>> #size-cells = <2>; >>> >>> + reserved-memory { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + ranges; >>> + >>> + secos: secos { >>> + reg = <0x0 0x05300000 0x0 0x2000000>; >>> + no-map; >>> + }; >> >> Hello Neil, >> >> In >> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts >> the secos region does not exist. In linux-next I find no reference to >> the secos label. Where is the consumer of the region defined? >> >>> + >>> + pstore: pstore { >>> + reg = <0x0 0x07300000 0x0 0x100000>; >>> + no-map; >>> + }; >> >> In >> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/amlogic/gxbb_skt.dts >> and other files pstore uses a different position >> (reg = <0x0 0x20000000 0x0 0x100000>;). >> Why are we moving this? >> Should this region be marked >> compatible = "ramoops"; ? >> Cf. Documentation/devicetree/bindings/reserved-memory/ramoops.txt. >> >> It would be nice if you could add a short description of each reserved >> area to the commit message. >> >> Regards >> >> Heinrich Schuchardt >> >>> + >>> + secmon: secmon { >>> + reg = <0x0 0x10000000 0x0 0x200000>; >>> + no-map; >>> + }; >>> + }; >>> + >>> cpus { >>> #address-cells = <0x2>; >>> #size-cells = <0x0>; >> >> > > Hi Heinrich, > > Thanks for testing and for the report, > we are still struggling into finding what are these zones and how to label them correctly. > > We need to identify the zones on all boards, the patch I provided works on a non-odroid-c2 and gxm and gxl boards. > > Neil > Hi Neil, the 3.14 Ubuntu kernel provided by Hardkernel for Odroid C2 has no fixed address reserved-memory inside the first 2GB and does not show the problem I have been observing with the linux-next kernel. Many zones for interfacing different peripherals are defined but these are all above 2GB. For small loads I never saw any oops. So I recommend that on the boards which you think are working, make a full linux-next git checkout and try to build the kernel natively for the respective board. Best regards Heinrich Schuchardt