| Message ID | 1484129414-23325-1-git-send-email-narmstrong@baylibre.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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
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
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
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
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
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 >
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 >
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 --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 */
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