Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2017-01-16 Thread Andreas Färber 
Am 16.01.2017 um 11:26 schrieb Neil Armstrong:
> On 01/15/2017 04:44 PM, Andreas Färber wrote:
>> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>>> it really makes a difference if we write
>>>
>>> memory@0 {
>>> device_type = "memory";
>>> linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>
>>> or
>>>
>>> memory@0 {
>>> device_type = "memory";
>>> reg = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>
>>> 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 0x7800>;
>>> +   device_type = "memory";
>>> +   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>
>>> 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
>>
>> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
>> instead of forcing the creation of unnecessary new .dts files onto
>> everyone due to hardcoded linux,usable-memory properties. In fact, it
>> already reserves 0x100, so it seems you are merely using an older
>> U-Boot.
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>>
>> I would bet that the upper limit is unrelated here.
>>
>> Regards,
>> Andreas
>>
> 
> Hi Andreas,
> 
> I really disagree about relying on any work or properties added by any 
> bootloader here, Amlogic SoCs has
> a lot of u-boot version in the field, and the Odroid-C2 is part of this.
> 
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel 
> should work using
> any U-boot version even with the one provided by Amlogic on their openlinux 
> distribution channel.

That is not the position of the kernel maintainers though. They
deliberately rely on timers being enabled before entering Linux, which
broke my afboot-stm32 (which I could fix) as well as s5pv210 and vf610
based platforms by F+S (which remain broken to date).

And I documented how to chainload mainline U-Boot from downstream
Amlogic U-Boot, so it is easily fixable on Meson. The only thing missing
is Carlo resubmitting his MMC patches.

A bug somewhere does not justify breaking the whole Meson-gx* .dts
design for everyone, especially not without CC'ing me as the original
creator!

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2017-01-16 Thread Andreas Färber 
Am 16.01.2017 um 11:26 schrieb Neil Armstrong:
> On 01/15/2017 04:44 PM, Andreas Färber wrote:
>> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>>> it really makes a difference if we write
>>>
>>> memory@0 {
>>> device_type = "memory";
>>> linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>
>>> or
>>>
>>> memory@0 {
>>> device_type = "memory";
>>> reg = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>
>>> 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 0x7800>;
>>> +   device_type = "memory";
>>> +   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>
>>> 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
>>
>> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
>> instead of forcing the creation of unnecessary new .dts files onto
>> everyone due to hardcoded linux,usable-memory properties. In fact, it
>> already reserves 0x100, so it seems you are merely using an older
>> U-Boot.
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>>
>> I would bet that the upper limit is unrelated here.
>>
>> Regards,
>> Andreas
>>
> 
> Hi Andreas,
> 
> I really disagree about relying on any work or properties added by any 
> bootloader here, Amlogic SoCs has
> a lot of u-boot version in the field, and the Odroid-C2 is part of this.
> 
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel 
> should work using
> any U-boot version even with the one provided by Amlogic on their openlinux 
> distribution channel.

That is not the position of the kernel maintainers though. They
deliberately rely on timers being enabled before entering Linux, which
broke my afboot-stm32 (which I could fix) as well as s5pv210 and vf610
based platforms by F+S (which remain broken to date).

And I documented how to chainload mainline U-Boot from downstream
Amlogic U-Boot, so it is easily fixable on Meson. The only thing missing
is Carlo resubmitting his MMC patches.

A bug somewhere does not justify breaking the whole Meson-gx* .dts
design for everyone, especially not without CC'ing me as the original
creator!

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2017-01-16 Thread Neil Armstrong 
On 01/15/2017 04:44 PM, Andreas Färber wrote:
> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>> it really makes a difference if we write
>>
>>  memory@0 {
>>  device_type = "memory";
>>  linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>>  };
>>
>> or
>>
>>  memory@0 {
>>  device_type = "memory";
>>  reg = <0x0 0x100 0x0 0x7f00>;
>>  };
>>
>> 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 0x7800>;
>> +   device_type = "memory";
>> +   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>> };
>>
>> 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
> 
> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
> instead of forcing the creation of unnecessary new .dts files onto
> everyone due to hardcoded linux,usable-memory properties. In fact, it
> already reserves 0x100, so it seems you are merely using an older
> U-Boot.
> 
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
> 
> I would bet that the upper limit is unrelated here.
> 
> Regards,
> Andreas
> 

Hi Andreas,

I really disagree about relying on any work or properties added by any 
bootloader here, Amlogic SoCs has
a lot of u-boot version in the field, and the Odroid-C2 is part of this.

Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel 
should work using
any U-boot version even with the one provided by Amlogic on their openlinux 
distribution channel.

Neil

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2017-01-16 Thread Neil Armstrong 
On 01/15/2017 04:44 PM, Andreas Färber wrote:
> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>> it really makes a difference if we write
>>
>>  memory@0 {
>>  device_type = "memory";
>>  linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>>  };
>>
>> or
>>
>>  memory@0 {
>>  device_type = "memory";
>>  reg = <0x0 0x100 0x0 0x7f00>;
>>  };
>>
>> 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 0x7800>;
>> +   device_type = "memory";
>> +   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>> };
>>
>> 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
> 
> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
> instead of forcing the creation of unnecessary new .dts files onto
> everyone due to hardcoded linux,usable-memory properties. In fact, it
> already reserves 0x100, so it seems you are merely using an older
> U-Boot.
> 
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
> 
> I would bet that the upper limit is unrelated here.
> 
> Regards,
> Andreas
> 

Hi Andreas,

I really disagree about relying on any work or properties added by any 
bootloader here, Amlogic SoCs has
a lot of u-boot version in the field, and the Odroid-C2 is part of this.

Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel 
should work using
any U-boot version even with the one provided by Amlogic on their openlinux 
distribution channel.

Neil

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2017-01-15 Thread Andreas Färber 
Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
> it really makes a difference if we write
> 
>   memory@0 {
>   device_type = "memory";
>   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>   };
> 
> or
> 
>   memory@0 {
>   device_type = "memory";
>   reg = <0x0 0x100 0x0 0x7f00>;
>   };
> 
> 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 0x7800>;
> +   device_type = "memory";
> +   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
> };
> 
> 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

The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
instead of forcing the creation of unnecessary new .dts files onto
everyone due to hardcoded linux,usable-memory properties. In fact, it
already reserves 0x100, so it seems you are merely using an older
U-Boot.

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39

I would bet that the upper limit is unrelated here.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2017-01-15 Thread Andreas Färber 
Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
> it really makes a difference if we write
> 
>   memory@0 {
>   device_type = "memory";
>   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
>   };
> 
> or
> 
>   memory@0 {
>   device_type = "memory";
>   reg = <0x0 0x100 0x0 0x7f00>;
>   };
> 
> 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 0x7800>;
> +   device_type = "memory";
> +   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
> };
> 
> 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

The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
instead of forcing the creation of unnecessary new .dts files onto
everyone due to hardcoded linux,usable-memory properties. In fact, it
already reserves 0x100, so it seems you are merely using an older
U-Boot.

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39

I would bet that the upper limit is unrelated here.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-23 Thread 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 0x2000.
> 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 0x40 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 0x100 0x0 0x7f00>;
>   };
> 
>   reserved-memory {
>   #address-cells = <0x2>;
>   #size-cells = <0x2>;
>   ranges;
> 
>   ramoops@0x23f0 {
>   compatible = "ramoops";
>   reg = <0x0 0x23f0 0x0 0x10>;
>   record-size = <0x2>;
>   console-size = <0x2>;
>   ftrace-size = <0x2>;
>   };
> 
>   secmon: secmon {
>   compatible = "amlogic, aml_secmon_memory";
>   reg = <0x0 0x1000 0x0 0x20>;
>   no-map;
>   };
> 
>   linux,cma {
>   compatible = "shared-dma-pool";
>   reusable;
>   size = <0x0 0xbc0>;
>   alignment = <0x0 0x40>;
>   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 0x100 0x0 0x7f00>;
};

or

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

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 0x7800>;
+   device_type = "memory";
+   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
};

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

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-23 Thread 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 0x2000.
> 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 0x40 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 0x100 0x0 0x7f00>;
>   };
> 
>   reserved-memory {
>   #address-cells = <0x2>;
>   #size-cells = <0x2>;
>   ranges;
> 
>   ramoops@0x23f0 {
>   compatible = "ramoops";
>   reg = <0x0 0x23f0 0x0 0x10>;
>   record-size = <0x2>;
>   console-size = <0x2>;
>   ftrace-size = <0x2>;
>   };
> 
>   secmon: secmon {
>   compatible = "amlogic, aml_secmon_memory";
>   reg = <0x0 0x1000 0x0 0x20>;
>   no-map;
>   };
> 
>   linux,cma {
>   compatible = "shared-dma-pool";
>   reusable;
>   size = <0x0 0xbc0>;
>   alignment = <0x0 0x40>;
>   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 0x100 0x0 0x7f00>;
};

or

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

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 0x7800>;
+   device_type = "memory";
+   linux,usable-memory = <0x0 0x100 0x0 0x7f00>;
};

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

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-22 Thread 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 0x2000.
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 0x40 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 0x100 0x0 0x7f00>;
};

reserved-memory {
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;

ramoops@0x23f0 {
compatible = "ramoops";
reg = <0x0 0x23f0 0x0 0x10>;
record-size = <0x2>;
console-size = <0x2>;
ftrace-size = <0x2>;
};

secmon: secmon {
compatible = "amlogic, aml_secmon_memory";
reg = <0x0 0x1000 0x0 0x20>;
no-map;
};

linux,cma {
compatible = "shared-dma-pool";
reusable;
size = <0x0 0xbc0>;
alignment = <0x0 0x40>;
linux,cma-default;
};
};

Best regards

Heinrich Schuchardt

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-22 Thread 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 0x2000.
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 0x40 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 0x100 0x0 0x7f00>;
};

reserved-memory {
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;

ramoops@0x23f0 {
compatible = "ramoops";
reg = <0x0 0x23f0 0x0 0x10>;
record-size = <0x2>;
console-size = <0x2>;
ftrace-size = <0x2>;
};

secmon: secmon {
compatible = "amlogic, aml_secmon_memory";
reg = <0x0 0x1000 0x0 0x20>;
no-map;
};

linux,cma {
compatible = "shared-dma-pool";
reusable;
size = <0x0 0xbc0>;
alignment = <0x0 0x40>;
linux,cma-default;
};
};

Best regards

Heinrich Schuchardt

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-14 Thread Heinrich Schuchardt 
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 0x8000>;
>>> +   reg = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>  
>>> 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 0x0530 0x0 0x200>;
>>> +   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 0x0730 0x0 0x10>;
>>> +   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 0x2000 0x0 0x10>;).
>> 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 0x1000 0x0 0x20>;
>>> +   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

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-14 Thread Heinrich Schuchardt 
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 0x8000>;
>>> +   reg = <0x0 0x100 0x0 0x7f00>;
>>> };
>>>  
>>> 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 0x0530 0x0 0x200>;
>>> +   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 0x0730 0x0 0x10>;
>>> +   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 0x2000 0x0 0x10>;).
>> 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 0x1000 0x0 0x20>;
>>> +   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

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-14 Thread Neil Armstrong 
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 0x8000>;
>> +reg = <0x0 0x100 0x0 0x7f00>;
>>  };
>>  
>>  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 0x0530 0x0 0x200>;
>> +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 0x0730 0x0 0x10>;
>> +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 0x2000 0x0 0x10>;).
> 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 0x1000 0x0 0x20>;
>> +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

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-14 Thread Neil Armstrong 
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 0x8000>;
>> +reg = <0x0 0x100 0x0 0x7f00>;
>>  };
>>  
>>  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 0x0530 0x0 0x200>;
>> +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 0x0730 0x0 0x10>;
>> +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 0x2000 0x0 0x10>;).
> 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 0x1000 0x0 0x20>;
>> +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

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-12 Thread Heinrich Schuchardt 
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 0x8000>;
> + reg = <0x0 0x100 0x0 0x7f00>;
>   };
>  
>   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 0x0530 0x0 0x200>;
> + 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 0x0730 0x0 0x10>;
> + 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 0x2000 0x0 0x10>;).
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 0x1000 0x0 0x20>;
> + no-map;
> + };
> + };
> +
>   cpus {
>   #address-cells = <0x2>;
>   #size-cells = <0x0>;

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-12 Thread Heinrich Schuchardt 
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 0x8000>;
> + reg = <0x0 0x100 0x0 0x7f00>;
>   };
>  
>   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 0x0530 0x0 0x200>;
> + 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 0x0730 0x0 0x10>;
> + 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 0x2000 0x0 0x10>;).
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 0x1000 0x0 0x20>;
> + no-map;
> + };
> + };
> +
>   cpus {
>   #address-cells = <0x2>;
>   #size-cells = <0x0>;

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-12 Thread Heinrich Schuchardt 
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(-)
> 

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
0xbf00 -- 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: 8000745c5780 task.stack: 800072d3c000
[  811.622660] PC is at 0xd3770f28
[  811.626107] LR is at 0xab54e53c
[  811.629558] pc : [] lr : []
pstate: 2000
[  811.636888] sp : d3a1d950
[  811.640166] x29: d3a1d950 x28: 9853a050
[  811.645427] x27: 000ffc5e x26: 8fe00020
[  811.650688] x25: d3a1da98 x24: 
[  811.655949] x23: d3770f28 x22: 0010
[  811.661211] x21: 9809bae0 x20: 0003de04
[  811.666472] x19: 8fe00010 x18: 23c57c32
[  811.671733] x17: ab58f988 x16: ab660008
[  811.676994] x15: 06dc x14: 
[  811.682255] x13: 002549ea x12: 29555c36
[  811.687517] x11: 002549eb x10: 29555c36
[  811.692778] x9 : 002549ea x8 : 29555c36
[  811.698039] x7 : 002549e9 x6 : 29555c36
[  811.703300] x5 : 98d54b40 x4 : 8f93c030
[  811.708562] x3 :  x2 : 
[  811.713823] x1 : 9853a050 x0 : 9809bae0

[  811.720561] Internal error: Attempting to execute userspace memory:
860f [#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: 8000745c5780 task.stack: 800072d3c000
[  811.754879] PC is at 0xab54e53c
[  811.758328] LR is at 0xab54e53c
[  811.761779] pc : [] lr : []
pstate: 63c5
[  811.769109] sp : 800072d3fec0
[  811.772387] x29:  x28: 8000745c5780
[  811.777648] x27: 000ffc5e x26: 8fe00020
[  811.782909] x25: d3a1da98 x24: 
[  811.788171] x23: 2000 x22: d3770f28
[  811.793432] x21:  x20: 80006e538000
[  811.798693] x19:  x18: 0010
[  811.803954] x17: ab58f988 x16: ab660008
[  811.809215] x15: 0006 x14: 88b2eabf
[  811.814477] x13: 08b2eacd x12: 0105
[  811.819738] x11: 0002 x10: 0106
[  811.824999] x9 : 800072d3fb40 x8 : 000af8ec
[  811.830260] x7 :  x6 : 0a65
[  811.835522] x5 : 0a660a65 x4 : 
[  811.840783] x3 : 0002 x2 : 0a66
[  811.846044] x1 : 8000745c5780 x0 : 

[  811.852773] Process git (pid: 1447, stack limit = 0x800072d3c000)
[  811.859156] Stack: (0x800072d3fec0 to 0x800072d4)
[  811.864849] fec0: 9809bae0 9853a050 

[  811.872611] fee0: 8f93c030 98d54b40 29555c36
002549e9
[  811.880374] ff00: 29555c36 002549ea 29555c36
002549eb
[  811.888136] ff20: 29555c36 002549ea 
06dc
[  811.895898] ff40: ab660008 ab58f988 23c57c32

Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-12 Thread Heinrich Schuchardt 
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(-)
> 

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
0xbf00 -- 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: 8000745c5780 task.stack: 800072d3c000
[  811.622660] PC is at 0xd3770f28
[  811.626107] LR is at 0xab54e53c
[  811.629558] pc : [] lr : []
pstate: 2000
[  811.636888] sp : d3a1d950
[  811.640166] x29: d3a1d950 x28: 9853a050
[  811.645427] x27: 000ffc5e x26: 8fe00020
[  811.650688] x25: d3a1da98 x24: 
[  811.655949] x23: d3770f28 x22: 0010
[  811.661211] x21: 9809bae0 x20: 0003de04
[  811.666472] x19: 8fe00010 x18: 23c57c32
[  811.671733] x17: ab58f988 x16: ab660008
[  811.676994] x15: 06dc x14: 
[  811.682255] x13: 002549ea x12: 29555c36
[  811.687517] x11: 002549eb x10: 29555c36
[  811.692778] x9 : 002549ea x8 : 29555c36
[  811.698039] x7 : 002549e9 x6 : 29555c36
[  811.703300] x5 : 98d54b40 x4 : 8f93c030
[  811.708562] x3 :  x2 : 
[  811.713823] x1 : 9853a050 x0 : 9809bae0

[  811.720561] Internal error: Attempting to execute userspace memory:
860f [#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: 8000745c5780 task.stack: 800072d3c000
[  811.754879] PC is at 0xab54e53c
[  811.758328] LR is at 0xab54e53c
[  811.761779] pc : [] lr : []
pstate: 63c5
[  811.769109] sp : 800072d3fec0
[  811.772387] x29:  x28: 8000745c5780
[  811.777648] x27: 000ffc5e x26: 8fe00020
[  811.782909] x25: d3a1da98 x24: 
[  811.788171] x23: 2000 x22: d3770f28
[  811.793432] x21:  x20: 80006e538000
[  811.798693] x19:  x18: 0010
[  811.803954] x17: ab58f988 x16: ab660008
[  811.809215] x15: 0006 x14: 88b2eabf
[  811.814477] x13: 08b2eacd x12: 0105
[  811.819738] x11: 0002 x10: 0106
[  811.824999] x9 : 800072d3fb40 x8 : 000af8ec
[  811.830260] x7 :  x6 : 0a65
[  811.835522] x5 : 0a660a65 x4 : 
[  811.840783] x3 : 0002 x2 : 0a66
[  811.846044] x1 : 8000745c5780 x0 : 

[  811.852773] Process git (pid: 1447, stack limit = 0x800072d3c000)
[  811.859156] Stack: (0x800072d3fec0 to 0x800072d4)
[  811.864849] fec0: 9809bae0 9853a050 

[  811.872611] fee0: 8f93c030 98d54b40 29555c36
002549e9
[  811.880374] ff00: 29555c36 002549ea 29555c36
002549eb
[  811.888136] ff20: 29555c36 002549ea 
06dc
[  811.895898] ff40: ab660008 ab58f988 23c57c32
8fe00010
[  811.903661]

[RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-12 Thread Neil Armstrong 
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 0x8000>;
+   reg = <0x0 0x100 0x0 0x7f00>;
};
 
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 0x0530 0x0 0x200>;
+   no-map;
+   };
+
+   pstore: pstore {
+   reg = <0x0 0x0730 0x0 0x10>;
+   no-map;
+   };
+
+   secmon: secmon {
+   reg = <0x0 0x1000 0x0 0x20>;
+   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 0x4000>;
+   reg = <0x0 0x100 0x0 0x3f00>;
};
 
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 0x8000>;
+   reg = <0x0 0x100 0x0 0x7f00>;
};
 
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 0x4000>;
+   reg = <0x0 0x100 0x0 0x3f00>;
};
 
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 0x8000>;
+   reg = <0x0 0x100 0x0 0x7f00>;
};
 };
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 0x4000>;
+   reg = <0x0 0x100 0x0 0x3f00>;
};
 };
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts

[RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range

2016-12-12 Thread Neil Armstrong 
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 0x8000>;
+   reg = <0x0 0x100 0x0 0x7f00>;
};
 
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 0x0530 0x0 0x200>;
+   no-map;
+   };
+
+   pstore: pstore {
+   reg = <0x0 0x0730 0x0 0x10>;
+   no-map;
+   };
+
+   secmon: secmon {
+   reg = <0x0 0x1000 0x0 0x20>;
+   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 0x4000>;
+   reg = <0x0 0x100 0x0 0x3f00>;
};
 
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 0x8000>;
+   reg = <0x0 0x100 0x0 0x7f00>;
};
 
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 0x4000>;
+   reg = <0x0 0x100 0x0 0x3f00>;
};
 
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 0x8000>;
+   reg = <0x0 0x100 0x0 0x7f00>;
};
 };
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 0x4000>;
+   reg = <0x0 0x100 0x0 0x3f00>;
};
 };
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