diff mbox

[v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range

Message ID 1484129414-23325-1-git-send-email-narmstrong@baylibre.com (mailing list archive)
State New, archived
Headers show

Commit Message

Neil Armstrong Jan. 11, 2017, 10:10 a.m. UTC
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.

The memory node is also moved from the dtsi files into the proper dts files
to handle variants memory sizes.

This patch also fixes the memory sizes for the following platforms :
- gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi       |  5 -----
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi                 | 12 ++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts    |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts       |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts           |  9 +++++++++
 arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts           |  9 +++++++++
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi          |  5 -----
 arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts  |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts   |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts     |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts      |  9 +++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts      |  9 +++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts      |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts       |  6 +++++-
 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts       |  9 +++++++++
 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts       |  9 +++++++++
 17 files changed, 106 insertions(+), 18 deletions(-)

Changes since resent v2 at [4]:
- Fix invalid comment of useable memory attributes

Changes since original v2 at [3]:
- Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB

Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone

Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone

[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong@baylibre.com
[2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong@baylibre.com
[3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong@baylibre.com
[4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong@baylibre.com

Comments

Kevin Hilman Jan. 13, 2017, 8:03 p.m. UTC | #1
Neil Armstrong <narmstrong@baylibre.com> writes:

> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
> this patch adds this reserved zone and redefines the usable memory range.
>
> The memory node is also moved from the dtsi files into the proper dts files
> to handle variants memory sizes.
>
> This patch also fixes the memory sizes for the following platforms :
> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

Queued for v4.10-rc.

Kevin
Andreas Färber Jan. 15, 2017, 2:43 p.m. UTC | #2
Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
> Neil Armstrong <narmstrong@baylibre.com> writes:
> 
>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>> this patch adds this reserved zone and redefines the usable memory range.
>>
>> The memory node is also moved from the dtsi files into the proper dts files
>> to handle variants memory sizes.
>>
>> This patch also fixes the memory sizes for the following platforms :
>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> 
> Queued for v4.10-rc.

What is the motivation for this change? I have a local U-Boot patch to
detect the amount of memory available as done downstream, but U-Boot
only updates the reg property that you seem to be abandoning here...

So for devices that come in multiple RAM configurations - like R-Box Pro
- this would require separate .dts files now! This looks very wrong to
me, especially since I am not aware of other platforms doing the same.
Instead, there's memory reservations for top and bottom done in U-Boot
for reg, plus reserved-memory nodes for anything in the middle.

Another thing to consider is that uEFI boot (bootefi) handles memory
reservation differently yet again, on the bootloader level. I have had
that working fine on Odroid-C2 and Vega S95.

So if there's no bug this is fixing (none mentioned in commit message) I
strongly object to this patch.

Regards,
Andreas
Neil Armstrong Jan. 16, 2017, 10:39 a.m. UTC | #3
On 01/15/2017 03:43 PM, Andreas Färber wrote:
> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds this reserved zone and redefines the usable memory range.
>>>
>>> The memory node is also moved from the dtsi files into the proper dts files
>>> to handle variants memory sizes.
>>>
>>> This patch also fixes the memory sizes for the following platforms :
>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Queued for v4.10-rc.
> 
> What is the motivation for this change? I have a local U-Boot patch to
> detect the amount of memory available as done downstream, but U-Boot
> only updates the reg property that you seem to be abandoning here...
> 
> So for devices that come in multiple RAM configurations - like R-Box Pro
> - this would require separate .dts files now! This looks very wrong to
> me, especially since I am not aware of other platforms doing the same.
> Instead, there's memory reservations for top and bottom done in U-Boot
> for reg, plus reserved-memory nodes for anything in the middle.
> 
> Another thing to consider is that uEFI boot (bootefi) handles memory
> reservation differently yet again, on the bootloader level. I have had
> that working fine on Odroid-C2 and Vega S95.
> 
> So if there's no bug this is fixing (none mentioned in commit message) I
> strongly object to this patch.
> 
> Regards,
> Andreas
> 

Hi Andreas,

Like I replied of my RFT patch :
I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
a lot of u-boot versions 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.

Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
their advices.

Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
running stock u-boot version on various shipped products and Amlogic's own development boards.

The bug is easily triggered by running :
# stress --vm 4 --vm-bytes 128M --timeout 10s &
[   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
...
[   47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
...

Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.

Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...

Neil
Andreas Färber Jan. 16, 2017, 3:06 p.m. UTC | #4
Hi Neil,

Am 16.01.2017 um 11:39 schrieb Neil Armstrong:
> On 01/15/2017 03:43 PM, Andreas Färber wrote:
>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>
>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>> to handle variants memory sizes.
>>>>
>>>> This patch also fixes the memory sizes for the following platforms :
>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> Queued for v4.10-rc.
>>
>> What is the motivation for this change? I have a local U-Boot patch to
>> detect the amount of memory available as done downstream, but U-Boot
>> only updates the reg property that you seem to be abandoning here...
>>
>> So for devices that come in multiple RAM configurations - like R-Box Pro
>> - this would require separate .dts files now! This looks very wrong to
>> me, especially since I am not aware of other platforms doing the same.
>> Instead, there's memory reservations for top and bottom done in U-Boot
>> for reg, plus reserved-memory nodes for anything in the middle.
>>
>> Another thing to consider is that uEFI boot (bootefi) handles memory
>> reservation differently yet again, on the bootloader level. I have had
>> that working fine on Odroid-C2 and Vega S95.
>>
>> So if there's no bug this is fixing (none mentioned in commit message) I
>> strongly object to this patch.
>>
>> Regards,
>> Andreas
>>
> 
> Hi Andreas,
[snip]

Let's not copy&paste replies, see my response there.

> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
> their advices.

My point is, this should be thought through _before_ merging the patch,
not after.

It is the bootloader's task to deliver the correct memory _size_, with
kernel .dts having the minimum. If there's 1G and 2G models then the
linux.git .dts will have 1G, so that it can run on both, should the
bootloader fail to update it.
The consequence of your change would be that U-Boot needs to set
different $fdtfile values based on memory size, which is a plain stupid
idea for the reasons I already gave. And it has been fought by DT
maintainers in previous cases, such as FPGA configurations or
daughter-boards. Amlogic's vendor U-Boot does have the "fdt" command
available, for any user to adequately tweak a loaded .dtb for use with
mainline Linux (e.g., add linux,usable-memory there) - it can be
automated via environment variables or for lack of "source" command
maybe via "autoscr".

The reason that there are three vega-s95 .dts files never was the
differing memory reg size (which gets overridden), but rather connector
and Wifi chipset features as well as them simply having different names
and therefore different compatible strings.

Ideally I expect to be able to use one .dts for both R-Box Pro models as
well as for both Khadas Vim models - they are not marketed with
differing names, so the differences should hopefully be minor,
especially when we're using brcm,bcm4329-fmac for any chipset anyway.

> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
> running stock u-boot version on various shipped products and Amlogic's own development boards.
> 
> The bug is easily triggered by running :
> # stress --vm 4 --vm-bytes 128M --timeout 10s &

First, that should've gone into the commit message please.

But this is what I get for that command line:

flag provided but not defined: -vm
Usage of stress:
  -failure regexp
    	fail only if output matches regexp
  -ignore regexp
    	ignore failure if output matches regexp
  -kill
    	kill timed out processes if true, otherwise just print pid (to
attach with gdb) (default true)
  -p N
    	run N processes in parallel (default 8)
  -timeout duration
    	timeout each process after duration (default 10m0s)

The only "stress" I found is in golang-org-x-tools package.

> [   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [   47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
> 
> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.

I have been running "large" KVM guests on a Vega S95 Telos, with vendor
U-Boot as well as mainline U-Boot, and did not run into such a problem.

What I did run into yesterday during a large system update was multiple:

INFO: task grub2-probe:22018 blocked for more than 120 seconds.
      Not tainted 4.10.0-rc3-next-20170113+ #58
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
grub2-probe     D    0 22018  22017 0x00000000
Call trace:
[<ffffff8008085628>] __switch_to+0x90/0xa8
[<ffffff8008746238>] __schedule+0x188/0x570
[<ffffff8008746658>] schedule+0x38/0xa0
[<ffffff80081fb234>] wb_wait_for_completion+0x4c/0x80
[<ffffff80081fb2f0>] __writeback_inodes_sb_nr+0x88/0xa0
[<ffffff80081fb34c>] writeback_inodes_sb+0x2c/0x38
[<ffffff80081ff494>] sync_filesystem+0x3c/0xa8
[<ffffff8008208688>] fsync_bdev+0x20/0x70
[<ffffff80083508e8>] blkdev_ioctl+0x8b0/0x9d8
[<ffffff800820801c>] block_ioctl+0x34/0x40
[<ffffff80081e2d04>] do_vfs_ioctl+0xa4/0x748
[<ffffff80081e3434>] SyS_ioctl+0x8c/0xa0
[<ffffff8008082f30>] el0_svc_naked+0x24/0x28

I'm assuming that's an unrelated linux-next regression.

I have also been running vendor U-Boot on the R-Box Pro, without problems.

On the Odroid-C2 however the bootloader is provided on SD by the user,
so there is no excuse really for the user to use a broken bootloader.
Even if not using the mainline version for lack of MMC drivers, the
Hardkernel branch can easily be patched if necessary.

> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...

Whatever the issue is, this patch is clearly wrong by design. Please
revert it ASAP!

For starters, have you tried simply adding a reserved-memory node for
0..0x01000000? v1 did not have that and instead messed with reg.

Regards,
Andreas
Olof Johansson Jan. 17, 2017, 6:07 a.m. UTC | #5
On Mon, Jan 16, 2017 at 2:39 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 01/15/2017 03:43 PM, Andreas Färber wrote:
>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>
>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>> to handle variants memory sizes.
>>>>
>>>> This patch also fixes the memory sizes for the following platforms :
>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> Queued for v4.10-rc.
>>
>> What is the motivation for this change? I have a local U-Boot patch to
>> detect the amount of memory available as done downstream, but U-Boot
>> only updates the reg property that you seem to be abandoning here...
>>
>> So for devices that come in multiple RAM configurations - like R-Box Pro
>> - this would require separate .dts files now! This looks very wrong to
>> me, especially since I am not aware of other platforms doing the same.
>> Instead, there's memory reservations for top and bottom done in U-Boot
>> for reg, plus reserved-memory nodes for anything in the middle.
>>
>> Another thing to consider is that uEFI boot (bootefi) handles memory
>> reservation differently yet again, on the bootloader level. I have had
>> that working fine on Odroid-C2 and Vega S95.
>>
>> So if there's no bug this is fixing (none mentioned in commit message) I
>> strongly object to this patch.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
>
> Like I replied of my RFT patch :
> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
> a lot of u-boot versions 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.
>
> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
> their advices.

Is there a way to detect what firmware is running and marking off
memory from early kernel init instead? That'll take care of the
concerns about memory size variance as well.

> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
> running stock u-boot version on various shipped products and Amlogic's own development boards.
>
> The bug is easily triggered by running :
> # stress --vm 4 --vm-bytes 128M --timeout 10s &
> [   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [   47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
>
> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
>
> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...

Technically we're not in regression territory here, since the platform
is obviously still in bringup and these aren't bugs that have been
introduced in this release. So I think we can take a little while to
sort out if there's a solution that, even if not ideal, at least is on
the path towards the proper fix and not away from it -- which this
seems to be.


-Olof
Neil Armstrong Jan. 17, 2017, 8:21 a.m. UTC | #6
On 01/17/2017 07:07 AM, Olof Johansson wrote:
> On Mon, Jan 16, 2017 at 2:39 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 01/15/2017 03:43 PM, Andreas Färber wrote:
>>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>>
>>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>>
>>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>>> to handle variants memory sizes.
>>>>>
>>>>> This patch also fixes the memory sizes for the following platforms :
>>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>>
>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>
>>>> Queued for v4.10-rc.
>>>
>>> What is the motivation for this change? I have a local U-Boot patch to
>>> detect the amount of memory available as done downstream, but U-Boot
>>> only updates the reg property that you seem to be abandoning here...
>>>
>>> So for devices that come in multiple RAM configurations - like R-Box Pro
>>> - this would require separate .dts files now! This looks very wrong to
>>> me, especially since I am not aware of other platforms doing the same.
>>> Instead, there's memory reservations for top and bottom done in U-Boot
>>> for reg, plus reserved-memory nodes for anything in the middle.
>>>
>>> Another thing to consider is that uEFI boot (bootefi) handles memory
>>> reservation differently yet again, on the bootloader level. I have had
>>> that working fine on Odroid-C2 and Vega S95.
>>>
>>> So if there's no bug this is fixing (none mentioned in commit message) I
>>> strongly object to this patch.
>>>
>>> Regards,
>>> Andreas
>>>
>>
>> Hi Andreas,
>>
>> Like I replied of my RFT patch :
>> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
>> a lot of u-boot versions 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.
>>
>> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
>> their advices.
> 
> Is there a way to detect what firmware is running and marking off
> memory from early kernel init instead? That'll take care of the
> concerns about memory size variance as well.
> 
>> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
>> running stock u-boot version on various shipped products and Amlogic's own development boards.
>>
>> The bug is easily triggered by running :
>> # stress --vm 4 --vm-bytes 128M --timeout 10s &
>> [   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
>> ...
>> [   47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
>> ...
>>
>> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
>> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
>>
>> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
>> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
> 
> Technically we're not in regression territory here, since the platform
> is obviously still in bringup and these aren't bugs that have been
> introduced in this release. So I think we can take a little while to
> sort out if there's a solution that, even if not ideal, at least is on
> the path towards the proper fix and not away from it -- which this
> seems to be.
> 
> 
> -Olof
> 

Hi Olof, Andreas,

As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
overrides the reg property that is changed by the bootloader to provide the "real" memory size.

As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.

The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
recently merged DRM driver.
You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
But it should be confirmed.

Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.

I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
fixup for a future DTS cleanup.

Andreas, is this ok for you ?

This issue exists since forever on mainline linux, and even 4.9 has it.
Olof, How could a similar fix go in 4.9 stable ?

Thanks,
Neil
Andreas Färber Jan. 18, 2017, midnight UTC | #7
Hi Neil,

Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
> overrides the reg property that is changed by the bootloader to provide the "real" memory size.

Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
intended, but at the same time it ignored any lowered or heightened
upper limit coming from the bootloader side.

As a rule of thumb, any nodes that have device_type set can be expected
to be modified during boot.

> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
> 
> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
> zones,

Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)

> but I also got the issue while running a fully fledged Desktop Environment thanks to the
> recently merged DRM driver.

I'll happily test once HDMI is ready. :)

> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
> But it should be confirmed.

Confirming no issues on three runs on meson-gxm-rbox-pro:

boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
[1] 2528
boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
stress-ng: info:  [2528] cache allocate: default cache size: 256K
stress-ng: info:  [2528] successful run completed in 10.07s

[1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
stress-ng: info:  [2537] dispatching hogs: 4 vm
stress-ng: info:  [2537] cache allocate: default cache size: 256K
stress-ng: info:  [2537] successful run completed in 10.07s
boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
stress-ng: info:  [2546] dispatching hogs: 4 vm
stress-ng: info:  [2546] cache allocate: default cache size: 256K
stress-ng: info:  [2546] successful run completed in 10.07s
boxer:~ #

> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
> 
> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
> fixup for a future DTS cleanup.
> 
> Andreas, is this ok for you ?

Yes, sounds fine to me, thanks. I'll note a few more nits to consider.

Kevin, I noticed that this supposedly applied patch did not show up in
linux-next for testing - could you merge your fixes branch into for-next
please for those of us working on new stuff?

> This issue exists since forever on mainline linux, and even 4.9 has it.
> Olof, How could a similar fix go in 4.9 stable ?

I guess it would then be best to consider splitting this patch up per
board/SoC so that you can set appropriate Fixes: headers indicating how
far back each one needs to be fixed.

Regards,
Andreas
Andreas Färber Jan. 18, 2017, 12:09 a.m. UTC | #8
Am 11.01.2017 um 11:10 schrieb Neil Armstrong:
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index eada0b5..66677b5 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -55,6 +55,18 @@
>  	#address-cells = <2>;
>  	#size-cells = <2>;
>  
> +	reserved-memory {

Should this get a label for future gx*-level additions?

> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		/* 2MiB reserved for ARM Trusted Firmware (BL31) */

"2 MiB" please. Ditto for the to-be-refactored 16 MiB node.

> +		secmon: secmon {
> +			reg = <0x0 0x10000000 0x0 0x200000>;
> +			no-map;
> +		};
> +	};
> +
>  	cpus {
>  		#address-cells = <0x2>;
>  		#size-cells = <0x0>;

Regards,
Andreas
Andreas Färber Jan. 18, 2017, 12:27 a.m. UTC | #9
Am 18.01.2017 um 01:00 schrieb Andreas Färber:
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
> 
> Confirming no issues on three runs on meson-gxm-rbox-pro:
> 
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
> stress-ng: info:  [2528] cache allocate: default cache size: 256K
> stress-ng: info:  [2528] successful run completed in 10.07s
> 
> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2537] dispatching hogs: 4 vm
> stress-ng: info:  [2537] cache allocate: default cache size: 256K
> stress-ng: info:  [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2546] dispatching hogs: 4 vm
> stress-ng: info:  [2546] cache allocate: default cache size: 256K
> stress-ng: info:  [2546] successful run completed in 10.07s
> boxer:~ #

Similar results on meson-gxbb-vega-s95-telos (except 512K cache size),
with both mainline EFI and vendor U-Boot.

I notice that I don't have CONFIG_DRM enabled - maybe related?

Regards,
Andreas
Neil Armstrong Jan. 18, 2017, 10:57 a.m. UTC | #10
On 01/18/2017 01:00 AM, Andreas Färber wrote:
> Hi Neil,
> 
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
>> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
> 
> Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
> intended, but at the same time it ignored any lowered or heightened
> upper limit coming from the bootloader side.
> 
> As a rule of thumb, any nodes that have device_type set can be expected
> to be modified during boot.
> 
>> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
>> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
>> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>>
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones,
> 
> Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
> 
>> but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
> 
> I'll happily test once HDMI is ready. :)
> 
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
> 
> Confirming no issues on three runs on meson-gxm-rbox-pro:
> 
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
> stress-ng: info:  [2528] cache allocate: default cache size: 256K
> stress-ng: info:  [2528] successful run completed in 10.07s
> 
> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2537] dispatching hogs: 4 vm
> stress-ng: info:  [2537] cache allocate: default cache size: 256K
> stress-ng: info:  [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2546] dispatching hogs: 4 vm
> stress-ng: info:  [2546] cache allocate: default cache size: 256K
> stress-ng: info:  [2546] successful run completed in 10.07s
> boxer:~ #

For 2 GiB boards, you may need to increase the vm threads :
# stress-ng --vm 16 --vm-bytes 128M --timeout 10s
stress-ng: info:  [1292] dispatching hogs: 16 vm
stress-ng: info:  [1292] cache allocate: default cache size: 512K
stress: info: [1275] dispatching hogs: 0 cpu, 0 io, 16 vm, 0 hdd
[  948.832694] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
[  948.832812] Bad mode in Error handler detected on CPU3, code 0xbf000000 -- SError
[  948.832832] CPU: 3 PID: 1279 Comm: stress Not tainted 4.10.0-rc4-00004-gba7e7b8 #14
...

On a Wetek Play2 board with 2GiB.

> 
>> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
>> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>>
>> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
>> fixup for a future DTS cleanup.
>>
>> Andreas, is this ok for you ?
> 
> Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
> 
> Kevin, I noticed that this supposedly applied patch did not show up in
> linux-next for testing - could you merge your fixes branch into for-next
> please for those of us working on new stuff?
> 
>> This issue exists since forever on mainline linux, and even 4.9 has it.
>> Olof, How could a similar fix go in 4.9 stable ?
> 
> I guess it would then be best to consider splitting this patch up per
> board/SoC so that you can set appropriate Fixes: headers indicating how
> far back each one needs to be fixed.
> 
> Regards,
> Andreas
>
Neil Armstrong Jan. 18, 2017, 10:58 a.m. UTC | #11
On 01/18/2017 01:27 AM, Andreas Färber wrote:
> Am 18.01.2017 um 01:00 schrieb Andreas Färber:
>> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>>> zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
>>> recently merged DRM driver.
>>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>>> But it should be confirmed.
>>
>> Confirming no issues on three runs on meson-gxm-rbox-pro:
>>
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
>> [1] 2528
>> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
>> stress-ng: info:  [2528] cache allocate: default cache size: 256K
>> stress-ng: info:  [2528] successful run completed in 10.07s
>>
>> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> stress-ng: info:  [2537] dispatching hogs: 4 vm
>> stress-ng: info:  [2537] cache allocate: default cache size: 256K
>> stress-ng: info:  [2537] successful run completed in 10.07s
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> stress-ng: info:  [2546] dispatching hogs: 4 vm
>> stress-ng: info:  [2546] cache allocate: default cache size: 256K
>> stress-ng: info:  [2546] successful run completed in 10.07s
>> boxer:~ #
> 
> Similar results on meson-gxbb-vega-s95-telos (except 512K cache size),
> with both mainline EFI and vendor U-Boot.
> 
> I notice that I don't have CONFIG_DRM enabled - maybe related?

Yes, It may add more pressure on the memory allocation.

Neil

> 
> Regards,
> Andreas
>
Kevin Hilman Jan. 18, 2017, 7:54 p.m. UTC | #12
Andreas Färber <afaerber@suse.de> writes:

> Hi Neil,
>
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
>> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
>
> Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
> intended, but at the same time it ignored any lowered or heightened
> upper limit coming from the bootloader side.
>
> As a rule of thumb, any nodes that have device_type set can be expected
> to be modified during boot.
>
>> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
>> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
>> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>> 
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones,
>
> Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
>
>> but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>
> I'll happily test once HDMI is ready. :)
>
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
>
> Confirming no issues on three runs on meson-gxm-rbox-pro:
>
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
> stress-ng: info:  [2528] cache allocate: default cache size: 256K
> stress-ng: info:  [2528] successful run completed in 10.07s
>
> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2537] dispatching hogs: 4 vm
> stress-ng: info:  [2537] cache allocate: default cache size: 256K
> stress-ng: info:  [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2546] dispatching hogs: 4 vm
> stress-ng: info:  [2546] cache allocate: default cache size: 256K
> stress-ng: info:  [2546] successful run completed in 10.07s
> boxer:~ #
>
>> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
>> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>> 
>> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
>> fixup for a future DTS cleanup.
>> 
>> Andreas, is this ok for you ?
>
> Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
>
> Kevin, I noticed that this supposedly applied patch did not show up in
> linux-next for testing - could you merge your fixes branch into for-next
> please for those of us working on new stuff?

Any fixes I have queued are always in my for-mext branch (which is
included i linux-next.)

This fix was there as well, but was removed due to objections shortly
after I added it, so it never quite made it to linux-next (or may have
for one day, I'm not sure.)

Kevin
diff mbox

Patch

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..360ec0d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -54,11 +54,6 @@ 
 		stdout-path = "serial0:115200n8";
 	};
 
-	memory@0 {
-		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
-	};
-
 	vddio_boot: regulator-vddio_boot {
 		compatible = "regulator-fixed";
 		regulator-name = "VDDIO_BOOT";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..66677b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@ 
 	#address-cells = <2>;
 	#size-cells = <2>;
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/* 2MiB reserved for ARM Trusted Firmware (BL31) */
+		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 4cbd626..54ffbff 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,11 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x40000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <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..1b474ba 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,11 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
 	};
 
 	usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index 03e3d76..af7b151 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -49,6 +49,15 @@ 
 / {
 	compatible = "amlogic,p200", "amlogic,meson-gxbb";
 	model = "Amlogic Meson GXBB P200 Development Board";
+
+	memory@0 {
+		device_type = "memory";
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+	};
 };
 
 &i2c_B {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 39bb037..215096c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -49,4 +49,13 @@ 
 / {
 	compatible = "amlogic,p201", "amlogic,meson-gxbb";
 	model = "Amlogic Meson GXBB P201 Development Board";
+
+	memory@0 {
+		device_type = "memory";
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+	};
 };
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..8052a39 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -53,11 +53,6 @@ 
 		stdout-path = "serial0:115200n8";
 	};
 
-	memory@0 {
-		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x40000000>;
-	};
-
 	usb_pwr: regulator-usb-pwrs {
 		compatible = "regulator-fixed";
 
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..8d6cfb9 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,10 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <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..543e03a 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,10 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x40000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <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..9a76fb5 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,10 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <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 cea4a3e..ac874ac 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,11 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
 	};
 
 	vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939c..2e2b821 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -49,6 +49,15 @@ 
 / {
 	compatible = "amlogic,p230", "amlogic,s905d", "amlogic,meson-gxl";
 	model = "Amlogic Meson GXL (S905D) P230 Development Board";
+
+	memory@0 {
+		device_type = "memory";
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+	};
 };
 
 /* P230 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
index 95992cf..d252da9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
@@ -49,6 +49,15 @@ 
 / {
 	compatible = "amlogic,p231", "amlogic,s905d", "amlogic,meson-gxl";
 	model = "Amlogic Meson GXL (S905D) P231 Development Board";
+
+	memory@0 {
+		device_type = "memory";
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+	};
 };
 
 /* P231 has only internal PHY port */
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..86f7db0 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,11 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
 	};
 };
 
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 5a337d3..2b65e06 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,11 @@ 
 
 	memory@0 {
 		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
 	};
 
 	vddio_boot: regulator-vddio-boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
index 5dbc660..cdfe618 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
@@ -49,6 +49,15 @@ 
 / {
 	compatible = "amlogic,q200", "amlogic,s912", "amlogic,meson-gxm";
 	model = "Amlogic Meson GXM (S912) Q200 Development Board";
+
+	memory@0 {
+		device_type = "memory";
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+	};
 };
 
 /* Q200 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
index 95e11d7..9047ffa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
@@ -49,6 +49,15 @@ 
 / {
 	compatible = "amlogic,q201", "amlogic,s912", "amlogic,meson-gxm";
 	model = "Amlogic Meson GXM (S912) Q201 Development Board";
+
+	memory@0 {
+		device_type = "memory";
+		/*
+		 * The first 16MiB of the DDR memory zone
+		 * is reserved to the Hardware ROM Firmware
+		 */
+		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+	};
 };
 
 /* Q201 has only internal PHY port */