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 <[email protected]>
---
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;
+ };
+
+ pstore: pstore {
+ reg = <0x0 0x07300000 0x0 0x100000>;
+ no-map;
+ };
+
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 9696820..25b8832 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ reg = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..839c66a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..9a39518 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -55,7 +55,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ reg = <0x0 0x1000000 0x0 0x3f000000>;
};
usb_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..287a4c7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..8bdbbe2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ reg = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..2d85295 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index e99101a..4ec2bbb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..b8b5b74 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index f859d75..1544747 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
--
2.7.0
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 <[email protected]>
> ---
> 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(-)
>
I added your patch to next-20161212.
My kernel config is available as
https://github.com/xypron/kernel-odroid-c2/blob/5ec4be0c1b45297bbcbc1ce3d3d787e45dac66b6/config/config-next-20161212
To build the same kernel just run ./build-dpkg.sh (or make) on
https://github.com/xypron/kernel-odroid-c2/tree/5ec4be0c1b45297bbcbc1ce3d3d787e45dac66b6
Free showed 0x2301000 less total memory available than next-20161209
without the patch.
When git cloning linux-next I got the following error on Hardkernel
Odroid C2:
[ 811.602365] Bad mode in Error handler detected on CPU2, code
0xbf000000 -- SError
[ 811.604205] CPU: 2 PID: 1447 Comm: git Not tainted
4.9.0-next-20161212-r005-arm64 #1
[ 811.611876] Hardware name: Hardkernel ODROID-C2 (DT)
[ 811.616793] task: ffff8000745c5780 task.stack: ffff800072d3c000
[ 811.622660] PC is at 0xaaaad3770f28
[ 811.626107] LR is at 0xffffab54e53c
[ 811.629558] pc : [<0000aaaad3770f28>] lr : [<0000ffffab54e53c>]
pstate: 20000000
[ 811.636888] sp : 0000ffffd3a1d950
[ 811.640166] x29: 0000ffffd3a1d950 x28: 0000ffff9853a050
[ 811.645427] x27: 00000000000ffc5e x26: 0000ffff8fe00020
[ 811.650688] x25: 0000ffffd3a1da98 x24: 0000000000000000
[ 811.655949] x23: 0000aaaad3770f28 x22: 0000000000000010
[ 811.661211] x21: 0000ffff9809bae0 x20: 000000000003de04
[ 811.666472] x19: 0000ffff8fe00010 x18: 0000000023c57c32
[ 811.671733] x17: 0000ffffab58f988 x16: 0000ffffab660008
[ 811.676994] x15: 00000000000006dc x14: 0000000000000000
[ 811.682255] x13: 00000000002549ea x12: 0000000029555c36
[ 811.687517] x11: 00000000002549eb x10: 0000000029555c36
[ 811.692778] x9 : 00000000002549ea x8 : 0000000029555c36
[ 811.698039] x7 : 00000000002549e9 x6 : 0000000029555c36
[ 811.703300] x5 : 0000ffff98d54b40 x4 : 0000ffff8f93c030
[ 811.708562] x3 : 00000000ffffffff x2 : 0000000000000000
[ 811.713823] x1 : 0000ffff9853a050 x0 : 0000ffff9809bae0
[ 811.720561] Internal error: Attempting to execute userspace memory:
8600000f [#1] PREEMPT SMP
[ 811.729004] Modules linked in: meson_rng rng_core ip_tables x_tables
ipv6 realtek
[ 811.736422] CPU: 2 PID: 1447 Comm: git Not tainted
4.9.0-next-20161212-r005-arm64 #1
[ 811.744097] Hardware name: Hardkernel ODROID-C2 (DT)
[ 811.749014] task: ffff8000745c5780 task.stack: ffff800072d3c000
[ 811.754879] PC is at 0xffffab54e53c
[ 811.758328] LR is at 0xffffab54e53c
[ 811.761779] pc : [<0000ffffab54e53c>] lr : [<0000ffffab54e53c>]
pstate: 600003c5
[ 811.769109] sp : ffff800072d3fec0
[ 811.772387] x29: 0000000000000000 x28: ffff8000745c5780
[ 811.777648] x27: 00000000000ffc5e x26: 0000ffff8fe00020
[ 811.782909] x25: 0000ffffd3a1da98 x24: 0000000000000000
[ 811.788171] x23: 0000000020000000 x22: 0000aaaad3770f28
[ 811.793432] x21: ffffffffffffffff x20: 000080006e538000
[ 811.798693] x19: 0000000000000000 x18: 0000000000000010
[ 811.803954] x17: 0000ffffab58f988 x16: 0000ffffab660008
[ 811.809215] x15: 0000000000000006 x14: ffff000088b2eabf
[ 811.814477] x13: ffff000008b2eacd x12: 0000000000000105
[ 811.819738] x11: 0000000000000002 x10: 0000000000000106
[ 811.824999] x9 : ffff800072d3fb40 x8 : 00000000000af8ec
[ 811.830260] x7 : 0000000000000000 x6 : 0000000000000a65
[ 811.835522] x5 : 000000000a660a65 x4 : 0000000000000000
[ 811.840783] x3 : 0000000000000002 x2 : 0000000000000a66
[ 811.846044] x1 : ffff8000745c5780 x0 : 0000000000000000
[ 811.852773] Process git (pid: 1447, stack limit = 0xffff800072d3c000)
[ 811.859156] Stack: (0xffff800072d3fec0 to 0xffff800072d40000)
[ 811.864849] fec0: 0000ffff9809bae0 0000ffff9853a050 0000000000000000
00000000ffffffff
[ 811.872611] fee0: 0000ffff8f93c030 0000ffff98d54b40 0000000029555c36
00000000002549e9
[ 811.880374] ff00: 0000000029555c36 00000000002549ea 0000000029555c36
00000000002549eb
[ 811.888136] ff20: 0000000029555c36 00000000002549ea 0000000000000000
00000000000006dc
[ 811.895898] ff40: 0000ffffab660008 0000ffffab58f988 0000000023c57c32
0000ffff8fe00010
[ 811.903661] ff60: 000000000003de04 0000ffff9809bae0 0000000000000010
0000aaaad3770f28
[ 811.911423] ff80: 0000000000000000 0000ffffd3a1da98 0000ffff8fe00020
00000000000ffc5e
[ 811.919186] ffa0: 0000ffff9853a050 0000ffffd3a1d950 0000ffffab54e53c
0000ffffd3a1d950
[ 811.926949] ffc0: 0000aaaad3770f28 0000000020000000 0000000000000000
ffffffffffffffff
[ 811.934711] ffe0: 0000000000000000 0000000000000000 3136363920746e61
3064613364666464
[ 811.942473] Call trace:
[ 811.944888] Exception stack(0xffff800072d3fcf0 to 0xffff800072d3fe20)
[ 811.951270] fce0: 0000000000000000
0001000000000000
[ 811.959034] fd00: ffff800072d3fec0 0000ffffab54e53c ffff8000731ab640
0000000000000000
[ 811.966796] fd20: 0000000000000004 ffff000008ab9818 ffff8000745c5780
000000000808540c
[ 811.974559] fd40: ffff800072d3fd90 ffff0000080c8858 ffff800072d3fe40
ffff8000745c5780
[ 811.982321] fd60: 0000000000000004 00000000000003c0 ffff800072d3fe40
0000000000000000
[ 811.990084] fd80: 0000ffffd3a1da98 0000ffff8fe00020 0000000000000000
ffff8000745c5780
[ 811.997846] fda0: 0000000000000a66 0000000000000002 0000000000000000
000000000a660a65
[ 812.005609] fdc0: 0000000000000a65 0000000000000000 00000000000af8ec
ffff800072d3fb40
[ 812.013371] fde0: 0000000000000106 0000000000000002 0000000000000105
ffff000008b2eacd
[ 812.021134] fe00: ffff000088b2eabf 0000000000000006 0000ffffab660008
0000ffffab58f988
[ 812.028896] [<0000ffffab54e53c>] 0xffffab54e53c
[ 812.033382] Code: aa1c03e1 aa1503e0 8b16027a d63f02e0 (7100001f)
[ 812.039501] ---[ end trace e791f586be1831bb ]---
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 <[email protected]>
> ---
> 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>;
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 <[email protected]>
>> ---
>> 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
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 <[email protected]>
>>> ---
>>> 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
On 12/14/2016 10:52 AM, Neil Armstrong wrote:
> 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
>
Hello Neil,
the configuration below works for me on the Hardkernel Odroid C2.
ramoops is needed for CONFIG_PSTORE_RAM.
Debian Stretch has CONFIG_PSTORE_RAM=m. Same is true for Fedora.
I have chosen the address arbitrarily. To accommodate 512 MB boards we
would have to put it below 0x20000000.
The size parameters are the same as in hisilicon/hi6220-hikey.dts and
qcom-apq8064-asus-nexus7-flo.dts.
linux,cma is used for contiguous memory assignment. I have taken the
align parameter from arm-src-kernel-2016-08-18-26e194264c.tar.gz
provided by Amlogic at
http://openlinux.amlogic.com:8000/download/ARM/kernel/ .
See Documentation/DMA-API.txt for the usage of align.
They use the same value 0x400000 for all GXBB boards.
So we want to put this zone into meson-gxbb.dtsi.
secmon is used by drivers/firmware/meson/meson_sm.c.
Amlogic uses the same address range for all 64bit boards.
memory@0 {
device_type = "memory";
linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
reserved-memory {
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;
ramoops@0x23f00000 {
compatible = "ramoops";
reg = <0x0 0x23f00000 0x0 0x100000>;
record-size = <0x20000>;
console-size = <0x20000>;
ftrace-size = <0x20000>;
};
secmon: secmon {
compatible = "amlogic, aml_secmon_memory";
reg = <0x0 0x10000000 0x0 0x200000>;
no-map;
};
linux,cma {
compatible = "shared-dma-pool";
reusable;
size = <0x0 0xbc00000>;
alignment = <0x0 0x400000>;
linux,cma-default;
};
};
Best regards
Heinrich Schuchardt
On 12/22/2016 11:02 AM, Heinrich Schuchardt wrote:
> On 12/14/2016 10:52 AM, Neil Armstrong wrote:
>
>> 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
>>
> Hello Neil,
>
> the configuration below works for me on the Hardkernel Odroid C2.
>
> ramoops is needed for CONFIG_PSTORE_RAM.
> Debian Stretch has CONFIG_PSTORE_RAM=m. Same is true for Fedora.
> I have chosen the address arbitrarily. To accommodate 512 MB boards we
> would have to put it below 0x20000000.
> The size parameters are the same as in hisilicon/hi6220-hikey.dts and
> qcom-apq8064-asus-nexus7-flo.dts.
>
> linux,cma is used for contiguous memory assignment. I have taken the
> align parameter from arm-src-kernel-2016-08-18-26e194264c.tar.gz
> provided by Amlogic at
> http://openlinux.amlogic.com:8000/download/ARM/kernel/ .
> See Documentation/DMA-API.txt for the usage of align.
> They use the same value 0x400000 for all GXBB boards.
> So we want to put this zone into meson-gxbb.dtsi.
>
> secmon is used by drivers/firmware/meson/meson_sm.c.
> Amlogic uses the same address range for all 64bit boards.
>
> memory@0 {
> device_type = "memory";
> linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> reserved-memory {
> #address-cells = <0x2>;
> #size-cells = <0x2>;
> ranges;
>
> ramoops@0x23f00000 {
> compatible = "ramoops";
> reg = <0x0 0x23f00000 0x0 0x100000>;
> record-size = <0x20000>;
> console-size = <0x20000>;
> ftrace-size = <0x20000>;
> };
>
> secmon: secmon {
> compatible = "amlogic, aml_secmon_memory";
> reg = <0x0 0x10000000 0x0 0x200000>;
> no-map;
> };
>
> linux,cma {
> compatible = "shared-dma-pool";
> reusable;
> size = <0x0 0xbc00000>;
> alignment = <0x0 0x400000>;
> linux,cma-default;
> };
> };
>
> Best regards
>
> Heinrich Schuchardt
>
Hello Neil,
it really makes a difference if we write
memory@0 {
device_type = "memory";
linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
or
memory@0 {
device_type = "memory";
reg = <0x0 0x1000000 0x0 0x7f000000>;
};
The second version leads to failure of the Odroid C2.
When I looked at /sys/firmware/fdt I saw this difference:
--- fails
+++ works
memory@0 {
- device_type = "memory";
reg = <0x0 0x0 0x0 0x78000000>;
+ device_type = "memory";
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
I found the following sentence in the NXP forum:
In case you want to overwrite the memory usage passed from u-boot, you
can use "linux,usable-memory".
https://community.nxp.com/thread/382284
Best regards
Heinrich Schuchardt