Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
Am 16.01.2017 um 11:26 schrieb Neil Armstrong: > On 01/15/2017 04:44 PM, Andreas Färber wrote: >> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt: >>> it really makes a difference if we write >>> >>> memory@0 { >>> device_type = "memory"; >>> linux,usable-memory = <0x0 0x100 0x0 0x7f00>; >>> }; >>> >>> or >>> >>> memory@0 { >>> device_type = "memory"; >>> reg = <0x0 0x100 0x0 0x7f00>; >>> }; >>> >>> The second version leads to failure of the Odroid C2. >>> >>> When I looked at /sys/firmware/fdt I saw this difference: >>> >>> --- fails >>> +++ works >>> >>> memory@0 { >>> - device_type = "memory"; >>> reg = <0x0 0x0 0x0 0x7800>; >>> + device_type = "memory"; >>> + linux,usable-memory = <0x0 0x100 0x0 0x7f00>; >>> }; >>> >>> I found the following sentence in the NXP forum: >>> In case you want to overwrite the memory usage passed from u-boot, you >>> can use "linux,usable-memory". >>> https://community.nxp.com/thread/382284 >> >> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot >> instead of forcing the creation of unnecessary new .dts files onto >> everyone due to hardcoded linux,usable-memory properties. In fact, it >> already reserves 0x100, so it seems you are merely using an older >> U-Boot. >> >> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39 >> >> I would bet that the upper limit is unrelated here. >> >> Regards, >> Andreas >> > > Hi Andreas, > > I really disagree about relying on any work or properties added by any > bootloader here, Amlogic SoCs has > a lot of u-boot version in the field, and the Odroid-C2 is part of this. > > Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel > should work using > any U-boot version even with the one provided by Amlogic on their openlinux > distribution channel. That is not the position of the kernel maintainers though. They deliberately rely on timers being enabled before entering Linux, which broke my afboot-stm32 (which I could fix) as well as s5pv210 and vf610 based platforms by F+S (which remain broken to date). And I documented how to chainload mainline U-Boot from downstream Amlogic U-Boot, so it is easily fixable on Meson. The only thing missing is Carlo resubmitting his MMC patches. A bug somewhere does not justify breaking the whole Meson-gx* .dts design for everyone, especially not without CC'ing me as the original creator! Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 01/15/2017 04:44 PM, Andreas Färber wrote: > Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt: >> it really makes a difference if we write >> >> memory@0 { >> device_type = "memory"; >> linux,usable-memory = <0x0 0x100 0x0 0x7f00>; >> }; >> >> or >> >> memory@0 { >> device_type = "memory"; >> reg = <0x0 0x100 0x0 0x7f00>; >> }; >> >> The second version leads to failure of the Odroid C2. >> >> When I looked at /sys/firmware/fdt I saw this difference: >> >> --- fails >> +++ works >> >> memory@0 { >> - device_type = "memory"; >> reg = <0x0 0x0 0x0 0x7800>; >> + device_type = "memory"; >> + linux,usable-memory = <0x0 0x100 0x0 0x7f00>; >> }; >> >> I found the following sentence in the NXP forum: >> In case you want to overwrite the memory usage passed from u-boot, you >> can use "linux,usable-memory". >> https://community.nxp.com/thread/382284 > > The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot > instead of forcing the creation of unnecessary new .dts files onto > everyone due to hardcoded linux,usable-memory properties. In fact, it > already reserves 0x100, so it seems you are merely using an older > U-Boot. > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39 > > I would bet that the upper limit is unrelated here. > > Regards, > Andreas > Hi Andreas, I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has a lot of u-boot version in the field, and the Odroid-C2 is part of this. Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using any U-boot version even with the one provided by Amlogic on their openlinux distribution channel. Neil
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt: > it really makes a difference if we write > > memory@0 { > device_type = "memory"; > linux,usable-memory = <0x0 0x100 0x0 0x7f00>; > }; > > or > > memory@0 { > device_type = "memory"; > reg = <0x0 0x100 0x0 0x7f00>; > }; > > The second version leads to failure of the Odroid C2. > > When I looked at /sys/firmware/fdt I saw this difference: > > --- fails > +++ works > > memory@0 { > - device_type = "memory"; > reg = <0x0 0x0 0x0 0x7800>; > + device_type = "memory"; > + linux,usable-memory = <0x0 0x100 0x0 0x7f00>; > }; > > I found the following sentence in the NXP forum: > In case you want to overwrite the memory usage passed from u-boot, you > can use "linux,usable-memory". > https://community.nxp.com/thread/382284 The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot instead of forcing the creation of unnecessary new .dts files onto everyone due to hardcoded linux,usable-memory properties. In fact, it already reserves 0x100, so it seems you are merely using an older U-Boot. http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39 I would bet that the upper limit is unrelated here. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 12/22/2016 11:02 AM, Heinrich Schuchardt wrote: > On 12/14/2016 10:52 AM, Neil Armstrong wrote: > >> Hi Heinrich, >> >> Thanks for testing and for the report, >> we are still struggling into finding what are these zones and how to label >> them correctly. >> >> We need to identify the zones on all boards, the patch I provided works on a >> non-odroid-c2 and gxm and gxl boards. >> >> Neil >> > Hello Neil, > > the configuration below works for me on the Hardkernel Odroid C2. > > ramoops is needed for CONFIG_PSTORE_RAM. > Debian Stretch has CONFIG_PSTORE_RAM=m. Same is true for Fedora. > I have chosen the address arbitrarily. To accommodate 512 MB boards we > would have to put it below 0x2000. > The size parameters are the same as in hisilicon/hi6220-hikey.dts and > qcom-apq8064-asus-nexus7-flo.dts. > > linux,cma is used for contiguous memory assignment. I have taken the > align parameter from arm-src-kernel-2016-08-18-26e194264c.tar.gz > provided by Amlogic at > http://openlinux.amlogic.com:8000/download/ARM/kernel/ . > See Documentation/DMA-API.txt for the usage of align. > They use the same value 0x40 for all GXBB boards. > So we want to put this zone into meson-gxbb.dtsi. > > secmon is used by drivers/firmware/meson/meson_sm.c. > Amlogic uses the same address range for all 64bit boards. > > memory@0 { > device_type = "memory"; > linux,usable-memory = <0x0 0x100 0x0 0x7f00>; > }; > > reserved-memory { > #address-cells = <0x2>; > #size-cells = <0x2>; > ranges; > > ramoops@0x23f0 { > compatible = "ramoops"; > reg = <0x0 0x23f0 0x0 0x10>; > record-size = <0x2>; > console-size = <0x2>; > ftrace-size = <0x2>; > }; > > secmon: secmon { > compatible = "amlogic, aml_secmon_memory"; > reg = <0x0 0x1000 0x0 0x20>; > no-map; > }; > > linux,cma { > compatible = "shared-dma-pool"; > reusable; > size = <0x0 0xbc0>; > alignment = <0x0 0x40>; > linux,cma-default; > }; > }; > > Best regards > > Heinrich Schuchardt > Hello Neil, it really makes a difference if we write memory@0 { device_type = "memory"; linux,usable-memory = <0x0 0x100 0x0 0x7f00>; }; or memory@0 { device_type = "memory"; reg = <0x0 0x100 0x0 0x7f00>; }; The second version leads to failure of the Odroid C2. When I looked at /sys/firmware/fdt I saw this difference: --- fails +++ works memory@0 { - device_type = "memory"; reg = <0x0 0x0 0x0 0x7800>; + device_type = "memory"; + linux,usable-memory = <0x0 0x100 0x0 0x7f00>; }; I found the following sentence in the NXP forum: In case you want to overwrite the memory usage passed from u-boot, you can use "linux,usable-memory". https://community.nxp.com/thread/382284 Best regards Heinrich Schuchardt
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 12/14/2016 10:52 AM, Neil Armstrong wrote: > Hi Heinrich, > > Thanks for testing and for the report, > we are still struggling into finding what are these zones and how to label > them correctly. > > We need to identify the zones on all boards, the patch I provided works on a > non-odroid-c2 and gxm and gxl boards. > > Neil > Hello Neil, the configuration below works for me on the Hardkernel Odroid C2. ramoops is needed for CONFIG_PSTORE_RAM. Debian Stretch has CONFIG_PSTORE_RAM=m. Same is true for Fedora. I have chosen the address arbitrarily. To accommodate 512 MB boards we would have to put it below 0x2000. The size parameters are the same as in hisilicon/hi6220-hikey.dts and qcom-apq8064-asus-nexus7-flo.dts. linux,cma is used for contiguous memory assignment. I have taken the align parameter from arm-src-kernel-2016-08-18-26e194264c.tar.gz provided by Amlogic at http://openlinux.amlogic.com:8000/download/ARM/kernel/ . See Documentation/DMA-API.txt for the usage of align. They use the same value 0x40 for all GXBB boards. So we want to put this zone into meson-gxbb.dtsi. secmon is used by drivers/firmware/meson/meson_sm.c. Amlogic uses the same address range for all 64bit boards. memory@0 { device_type = "memory"; linux,usable-memory = <0x0 0x100 0x0 0x7f00>; }; reserved-memory { #address-cells = <0x2>; #size-cells = <0x2>; ranges; ramoops@0x23f0 { compatible = "ramoops"; reg = <0x0 0x23f0 0x0 0x10>; record-size = <0x2>; console-size = <0x2>; ftrace-size = <0x2>; }; secmon: secmon { compatible = "amlogic, aml_secmon_memory"; reg = <0x0 0x1000 0x0 0x20>; no-map; }; linux,cma { compatible = "shared-dma-pool"; reusable; size = <0x0 0xbc0>; alignment = <0x0 0x40>; linux,cma-default; }; }; Best regards Heinrich Schuchardt
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 12/14/2016 10:52 AM, Neil Armstrong wrote: > On 12/12/2016 10:22 PM, Heinrich Schuchardt wrote: >> On 12/12/2016 11:18 AM, Neil Armstrong wrote: >>> The Amlogic Meson GXBB secure monitor uses part of the memory space, this >>> patch adds these reserved zones and redefines the usable memory range for >>> each boards. >>> >>> Signed-off-by: Neil Armstrong >>> --- >>> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 >>> + >>> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi| 2 +- >>> .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +- >>> .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts| 2 +- >>> .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +- >>> .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +- >>> .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +- >>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +- >>> 11 files changed, 31 insertions(+), 10 deletions(-) >>> >>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >>> b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >>> index 7a078be..ac40b2d 100644 >>> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >>> @@ -56,7 +56,7 @@ >>> >>> memory@0 { >>> device_type = "memory"; >>> - reg = <0x0 0x0 0x0 0x8000>; >>> + reg = <0x0 0x100 0x0 0x7f00>; >>> }; >>> >>> vddio_boot: regulator-vddio_boot { >>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >>> index fc033c0..e085588 100644 >>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >>> @@ -55,6 +55,27 @@ >>> #address-cells = <2>; >>> #size-cells = <2>; >>> >>> + reserved-memory { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + ranges; >>> + >>> + secos: secos { >>> + reg = <0x0 0x0530 0x0 0x200>; >>> + no-map; >>> + }; >> >> Hello Neil, >> >> In >> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts >> the secos region does not exist. In linux-next I find no reference to >> the secos label. Where is the consumer of the region defined? >> >>> + >>> + pstore: pstore { >>> + reg = <0x0 0x0730 0x0 0x10>; >>> + no-map; >>> + }; >> >> In >> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/amlogic/gxbb_skt.dts >> and other files pstore uses a different position >> (reg = <0x0 0x2000 0x0 0x10>;). >> Why are we moving this? >> Should this region be marked >> compatible = "ramoops"; ? >> Cf. Documentation/devicetree/bindings/reserved-memory/ramoops.txt. >> >> It would be nice if you could add a short description of each reserved >> area to the commit message. >> >> Regards >> >> Heinrich Schuchardt >> >>> + >>> + secmon: secmon { >>> + reg = <0x0 0x1000 0x0 0x20>; >>> + no-map; >>> + }; >>> + }; >>> + >>> cpus { >>> #address-cells = <0x2>; >>> #size-cells = <0x0>; >> >> > > Hi Heinrich, > > Thanks for testing and for the report, > we are still struggling into finding what are these zones and how to label > them correctly. > > We need to identify the zones on all boards, the patch I provided works on a > non-odroid-c2 and gxm and gxl boards. > > Neil > Hi Neil, the 3.14 Ubuntu kernel provided by Hardkernel for Odroid C2 has no fixed address reserved-memory inside the first 2GB and does not show the problem I have been observing with the linux-next kernel. Many zones for interfacing different peripherals are defined but these are all above 2GB. For small loads I never saw any oops. So I recommend that on the boards which you think are working, make a full linux-next git checkout and try to build the kernel natively for the respective board. Best regards Heinrich Schuchardt
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 12/12/2016 10:22 PM, Heinrich Schuchardt wrote: > On 12/12/2016 11:18 AM, Neil Armstrong wrote: >> The Amlogic Meson GXBB secure monitor uses part of the memory space, this >> patch adds these reserved zones and redefines the usable memory range for >> each boards. >> >> Signed-off-by: Neil Armstrong >> --- >> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +- >> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 >> + >> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +- >> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- >> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi| 2 +- >> .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +- >> .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts| 2 +- >> .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +- >> .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +- >> .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +- >> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +- >> 11 files changed, 31 insertions(+), 10 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >> b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >> index 7a078be..ac40b2d 100644 >> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi >> @@ -56,7 +56,7 @@ >> >> memory@0 { >> device_type = "memory"; >> -reg = <0x0 0x0 0x0 0x8000>; >> +reg = <0x0 0x100 0x0 0x7f00>; >> }; >> >> vddio_boot: regulator-vddio_boot { >> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >> index fc033c0..e085588 100644 >> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi >> @@ -55,6 +55,27 @@ >> #address-cells = <2>; >> #size-cells = <2>; >> >> +reserved-memory { >> +#address-cells = <2>; >> +#size-cells = <2>; >> +ranges; >> + >> +secos: secos { >> +reg = <0x0 0x0530 0x0 0x200>; >> +no-map; >> +}; > > Hello Neil, > > In > https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts > the secos region does not exist. In linux-next I find no reference to > the secos label. Where is the consumer of the region defined? > >> + >> +pstore: pstore { >> +reg = <0x0 0x0730 0x0 0x10>; >> +no-map; >> +}; > > In > https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/amlogic/gxbb_skt.dts > and other files pstore uses a different position > (reg = <0x0 0x2000 0x0 0x10>;). > Why are we moving this? > Should this region be marked > compatible = "ramoops"; ? > Cf. Documentation/devicetree/bindings/reserved-memory/ramoops.txt. > > It would be nice if you could add a short description of each reserved > area to the commit message. > > Regards > > Heinrich Schuchardt > >> + >> +secmon: secmon { >> +reg = <0x0 0x1000 0x0 0x20>; >> +no-map; >> +}; >> +}; >> + >> cpus { >> #address-cells = <0x2>; >> #size-cells = <0x0>; > > Hi Heinrich, Thanks for testing and for the report, we are still struggling into finding what are these zones and how to label them correctly. We need to identify the zones on all boards, the patch I provided works on a non-odroid-c2 and gxm and gxl boards. Neil
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 12/12/2016 11:18 AM, Neil Armstrong wrote: > The Amlogic Meson GXBB secure monitor uses part of the memory space, this > patch adds these reserved zones and redefines the usable memory range for > each boards. > > Signed-off-by: Neil Armstrong > --- > arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +- > arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 > + > .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi| 2 +- > .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +- > .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts| 2 +- > .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +- > .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +- > .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +- > 11 files changed, 31 insertions(+), 10 deletions(-) > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi > b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi > index 7a078be..ac40b2d 100644 > --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi > +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi > @@ -56,7 +56,7 @@ > > memory@0 { > device_type = "memory"; > - reg = <0x0 0x0 0x0 0x8000>; > + reg = <0x0 0x100 0x0 0x7f00>; > }; > > vddio_boot: regulator-vddio_boot { > diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi > b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi > index fc033c0..e085588 100644 > --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi > +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi > @@ -55,6 +55,27 @@ > #address-cells = <2>; > #size-cells = <2>; > > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + secos: secos { > + reg = <0x0 0x0530 0x0 0x200>; > + no-map; > + }; Hello Neil, In https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts the secos region does not exist. In linux-next I find no reference to the secos label. Where is the consumer of the region defined? > + > + pstore: pstore { > + reg = <0x0 0x0730 0x0 0x10>; > + no-map; > + }; In https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/amlogic/gxbb_skt.dts and other files pstore uses a different position (reg = <0x0 0x2000 0x0 0x10>;). Why are we moving this? Should this region be marked compatible = "ramoops"; ? Cf. Documentation/devicetree/bindings/reserved-memory/ramoops.txt. It would be nice if you could add a short description of each reserved area to the commit message. Regards Heinrich Schuchardt > + > + secmon: secmon { > + reg = <0x0 0x1000 0x0 0x20>; > + no-map; > + }; > + }; > + > cpus { > #address-cells = <0x2>; > #size-cells = <0x0>;
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 12/12/2016 11:18 AM, Neil Armstrong wrote: > The Amlogic Meson GXBB secure monitor uses part of the memory space, this > patch adds these reserved zones and redefines the usable memory range for > each boards. > > Signed-off-by: Neil Armstrong > --- > arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +- > arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 > + > .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi| 2 +- > .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +- > .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts| 2 +- > .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +- > .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +- > .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +- > 11 files changed, 31 insertions(+), 10 deletions(-) > I added your patch to next-20161212. My kernel config is available as https://github.com/xypron/kernel-odroid-c2/blob/5ec4be0c1b45297bbcbc1ce3d3d787e45dac66b6/config/config-next-20161212 To build the same kernel just run ./build-dpkg.sh (or make) on https://github.com/xypron/kernel-odroid-c2/tree/5ec4be0c1b45297bbcbc1ce3d3d787e45dac66b6 Free showed 0x2301000 less total memory available than next-20161209 without the patch. When git cloning linux-next I got the following error on Hardkernel Odroid C2: [ 811.602365] Bad mode in Error handler detected on CPU2, code 0xbf00 -- SError [ 811.604205] CPU: 2 PID: 1447 Comm: git Not tainted 4.9.0-next-20161212-r005-arm64 #1 [ 811.611876] Hardware name: Hardkernel ODROID-C2 (DT) [ 811.616793] task: 8000745c5780 task.stack: 800072d3c000 [ 811.622660] PC is at 0xd3770f28 [ 811.626107] LR is at 0xab54e53c [ 811.629558] pc : [] lr : [ ] pstate: 2000 [ 811.636888] sp : d3a1d950 [ 811.640166] x29: d3a1d950 x28: 9853a050 [ 811.645427] x27: 000ffc5e x26: 8fe00020 [ 811.650688] x25: d3a1da98 x24: [ 811.655949] x23: d3770f28 x22: 0010 [ 811.661211] x21: 9809bae0 x20: 0003de04 [ 811.666472] x19: 8fe00010 x18: 23c57c32 [ 811.671733] x17: ab58f988 x16: ab660008 [ 811.676994] x15: 06dc x14: [ 811.682255] x13: 002549ea x12: 29555c36 [ 811.687517] x11: 002549eb x10: 29555c36 [ 811.692778] x9 : 002549ea x8 : 29555c36 [ 811.698039] x7 : 002549e9 x6 : 29555c36 [ 811.703300] x5 : 98d54b40 x4 : 8f93c030 [ 811.708562] x3 : x2 : [ 811.713823] x1 : 9853a050 x0 : 9809bae0 [ 811.720561] Internal error: Attempting to execute userspace memory: 860f [#1] PREEMPT SMP [ 811.729004] Modules linked in: meson_rng rng_core ip_tables x_tables ipv6 realtek [ 811.736422] CPU: 2 PID: 1447 Comm: git Not tainted 4.9.0-next-20161212-r005-arm64 #1 [ 811.744097] Hardware name: Hardkernel ODROID-C2 (DT) [ 811.749014] task: 8000745c5780 task.stack: 800072d3c000 [ 811.754879] PC is at 0xab54e53c [ 811.758328] LR is at 0xab54e53c [ 811.761779] pc : [ ] lr : [ ] pstate: 63c5 [ 811.769109] sp : 800072d3fec0 [ 811.772387] x29: x28: 8000745c5780 [ 811.777648] x27: 000ffc5e x26: 8fe00020 [ 811.782909] x25: d3a1da98 x24: [ 811.788171] x23: 2000 x22: d3770f28 [ 811.793432] x21: x20: 80006e538000 [ 811.798693] x19: x18: 0010 [ 811.803954] x17: ab58f988 x16: ab660008 [ 811.809215] x15: 0006 x14: 88b2eabf [ 811.814477] x13: 08b2eacd x12: 0105 [ 811.819738] x11: 0002 x10: 0106 [ 811.824999] x9 : 800072d3fb40 x8 : 000af8ec [ 811.830260] x7 : x6 : 0a65 [ 811.835522] x5 : 0a660a65 x4 : [ 811.840783] x3 : 0002 x2 : 0a66 [ 811.846044] x1 : 8000745c5780 x0 : [ 811.852773] Process git (pid: 1447, stack limit = 0x800072d3c000) [ 811.859156] Stack: (0x800072d3fec0 to 0x800072d4) [ 811.864849] fec0: 9809bae0 9853a050 [ 811.872611] fee0: 8f93c030 98d54b40 29555c36 002549e9 [ 811.880374] ff00: 29555c36 002549ea 29555c36 002549eb [ 811.888136] ff20: 29555c36 002549ea 06dc [ 811.895898] ff40: ab660008 ab58f988 23c57c32 8fe00010 [ 811.903661] ff