[PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Heinrich Schuchardt]

The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
attempt to access it from Linux leads to an immediate crash.

So let's make the same memory reservation as the vendor kernel.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
v2
	Move the change from armada-8040-mcbin.dts to armada-ap806.dtsi.
	I only have a MACCHIATObin for testing but
	https://github.com/MarvellEmbeddedProcessors/linux-marvell
	has the reservation in that file.
---
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 7d94c1fa592a..f8dafef83db0 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -28,6 +28,17 @@
 		method = "smc";
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		psci-area@4000000 {
+			reg = <0x0 0x4000000 0x0 0x200000>;
+			no-map;
+		};
+	};
+
 	ap806 {
 		#address-cells = <2>;
 		#size-cells = <2>;
-- 
2.19.2

Re: [PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Gregory CLEMENT]

Hi Heinrich,
 
 On ven., déc. 21 2018, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
> attempt to access it from Linux leads to an immediate crash.
>
> So let's make the same memory reservation as the vendor kernel.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

We got a similar patch one month ago and Russell King pointed that it
didn't match waht he saw on his MACCHIATObin:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/612360.html

on mine under U-Boot I got:

Marvell>> md 0x4000000
04000000: 00000000 00000007 00000005 00000040    ............@...
04000010: 00000001 00001000 00000007 00000001    ................
04000020: 00000008 00000000 00000009 00000000    ................
04000030: 0000000a 00000000 ffffffff ffffffff    ................
04000040: ffffffff ffffffff ffffffff ffffffff    ................
04000050: ffffffff ffffffff ffffffff ffffffff    ................
04000060: ffffffff ffffffff ffffffff ffffffff    ................
04000070: ffffffff ffffffff ffffffff ffffffff    ................
04000080: ffffffff ffffffff ffffffff ffffffff    ................
04000090: ffffffff ffffffff ffffffff ffffffff    ................
040000a0: ffffffff ffffffff ffffffff ffffffff    ................
040000b0: ffffffff ffffffff ffffffff ffffffff    ................
040000c0: ffffffff ffffffff ffffffff ffffffff    ................
040000d0: ffffffff ffffffff ffffffff ffffffff    ................
040000e0: ffffffff ffffffff ffffffff ffffffff    ................
040000f0: ffffffff ffffffff ffffffff ffffffff    ................

In my case I have an old ATF, however this kind of setting should be
done by the bootloader.

I am interested by your claim about causing an immediate crash when
accessing this region. How did you trigger it?

Gregory


> ---
> v2
> 	Move the change from armada-8040-mcbin.dts to armada-ap806.dtsi.
> 	I only have a MACCHIATObin for testing but
> 	https://github.com/MarvellEmbeddedProcessors/linux-marvell
> 	has the reservation in that file.
> ---
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 7d94c1fa592a..f8dafef83db0 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -28,6 +28,17 @@
>  		method = "smc";
>  	};
>  
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		psci-area@4000000 {
> +			reg = <0x0 0x4000000 0x0 0x200000>;
> +			no-map;
> +		};
> +	};
> +
>  	ap806 {
>  		#address-cells = <2>;
>  		#size-cells = <2>;
> -- 
> 2.19.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Heinrich Schuchardt]

On 12/26/18 5:16 PM, Gregory CLEMENT wrote:
> Hi Heinrich,
>  
>  On ven., déc. 21 2018, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> 
>> The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
>> attempt to access it from Linux leads to an immediate crash.
>>
>> So let's make the same memory reservation as the vendor kernel.
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> 
> We got a similar patch one month ago and Russell King pointed that it
> didn't match waht he saw on his MACCHIATObin:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/612360.html
> 
> on mine under U-Boot I got:
> 
> Marvell>> md 0x4000000
> 04000000: 00000000 00000007 00000005 00000040    ............@...
> 04000010: 00000001 00001000 00000007 00000001    ................
> 04000020: 00000008 00000000 00000009 00000000    ................
> 04000030: 0000000a 00000000 ffffffff ffffffff    ................
> 04000040: ffffffff ffffffff ffffffff ffffffff    ................
> 04000050: ffffffff ffffffff ffffffff ffffffff    ................
> 04000060: ffffffff ffffffff ffffffff ffffffff    ................
> 04000070: ffffffff ffffffff ffffffff ffffffff    ................
> 04000080: ffffffff ffffffff ffffffff ffffffff    ................
> 04000090: ffffffff ffffffff ffffffff ffffffff    ................
> 040000a0: ffffffff ffffffff ffffffff ffffffff    ................
> 040000b0: ffffffff ffffffff ffffffff ffffffff    ................
> 040000c0: ffffffff ffffffff ffffffff ffffffff    ................
> 040000d0: ffffffff ffffffff ffffffff ffffffff    ................
> 040000e0: ffffffff ffffffff ffffffff ffffffff    ................
> 040000f0: ffffffff ffffffff ffffffff ffffffff    ................
> 
> In my case I have an old ATF, however this kind of setting should be
> done by the bootloader.
> 
> I am interested by your claim about causing an immediate crash when
> accessing this region. How did you trigger it?
> 
> Gregory

Hello Gregory,

judging from you U-Boot prompt you are not using mainline U-Boot. With
the legacy Marvell U-Boot I get the same output as you provide above.
But you are looking in the wrong place to confirm that this is ATF:

Marvell>> md 04017200
04017200: 616d6920 74206567 5043206f 474d2031     image to CP1 MG
04017210: 746f6e20 70757320 74726f70 000a6465     not supported..
04017220: 4f525245 20203a52 50435320 324c425f    ERROR:   SCP_BL2
04017230: 6f727720 6920676e 6620676d 616d726f     wrong img forma
04017240: 63282074 745f336d 3d657079 0a296425    t (cm3_type=%d).
04017250: 544f4e00 3a454349 43532020 6d492050    .NOTICE:  SCP Im
04017260: 20656761 73656f64 2074276e 746e6f63    age doesn't cont
04017270: 206e6961 66204d50 776d7269 0a657261    ain PM firmware.
04017280: 00000000 00000000 040144d0 00000000    .........D......
04017290: 00000001 00000019 4f525245 20203a52    ........ERROR:
040172a0: 6e695720 20776f64 203a6425 65736162     Window %d: base
040172b0: 64646120 73736572 616e7520 6e67696c     address unalign
040172c0: 74206465 7830206f 000a7825 67696c41    ed to 0x%x..Alig
040172d0: 7075206e 65687420 73616220 64612065    n up the base ad
040172e0: 73657264 6f742073 25783020 000a786c    dress to 0x%lx..
040172f0: 4f525245 20203a52 6e695720 20776f64    ERROR:   Window

Possibly the legacy Marvell U-Boot is running at exception level 3
(EL3). This would explain why you cannot reproduce the crash with that
U-Boot.

The legacy Marvell U-Boot is in bad shape: their booti command cannot
load the initrd.img created by Debian. This is why I use mainline
U-Boot. Here you can find my recipe:

https://github.com/xypron/u-boot-build/blob/macchiatobin/Makefile (for
U-Boot v2018.11)

When I issue the md command for the region in mainline U-Boot  I get a
crash:

=> md 0x4000000


04000000:"Synchronous Abort" handler, esr 0x96000210


elr: 000000000006b878 lr : 000000000006b7f4 (reloc)


elr: 000000007ff8b878 lr : 000000007ff8b7f4


x0 : 0000000000000009 x1 : 0000000000000000


x2 : 000000000000003a x3 : 0000000004000000


x4 : 0000000000000000 x5 : 000000007ffae306


x6 : 0000000000000004 x7 : 000000007fb0a1e0


x8 : 000000007fb0a0a0 x9 : 0000000000000008


x10: 00000000ffffffd0 x11: 0000000000000006


x12: 000000000001869f x13: 000000000000440c


x14: 000000007fb0a43c x15: 0000000000000008


x16: 000000007ffb49ea x17: 000000007ffb49ea


x18: 000000007fb0fdd8 x19: 0000000000000040


x20: 0000000004000000 x21: 0000000004000000


x22: 000000007ffacff1 x23: 0000000000000008


x24: 0000000000000004 x25: 0000000000000004


x26: 0000000000000004 x27: 000000007fb0a268


x28: 0000000000000000 x29: 000000007fb0a1e0



Resetting CPU ...

In Linux 4.20 without my patch I regularly experience crashes like the
one below. With the patch I never experience such a crash.

[  683.992558] Internal error: synchronous external a
bort: 96000210 [#1] PREEMPT SMP

[  684.000084] Modules linked in: crct10dif_ce omap_rng rng_core sg
ip_tables x_tables ipv6 sr_mod cdrom n
vme nvme_core marvell

[  684.011369] CPU: 2 PID: 2607 Comm: dd Not tainted 4.20.0-rc7-arm64 #3

[  684.017839] Hardware name: Marvell 8040 MACCHIATOBin (DT)

[  684.023265] pstate: 20000005 (nzCv daif -PAN -UAO)

[  684.028090] pc : __arch_copy_to_user+0x180/0x220

[  684.032732] lr : copyout+0x54/0x68

[  684.036148] sp : ffff00000d803c30

[  684.039477] x29: ffff00000d803c30 x28: ffff800073661d98

[  684.044815] x27: ffff8000695900d8 x26: 000000000006f09e

[  684.050153] x25: 0000000000000000 x24: ffff00000d803d78

[  684.055490] x23: 000000000009e000 x22: 0000000000001000

[  684.060827] x21: ffff00000d803db0 x20: 0000000000001000

[  684.066164] x19: ffff800004000000 x18: 0000000000000000

[  684.071501] x17: 0fffc00000020016 x16: 0000000000000000

[  684.076838] x15: 0000000000000000 x14: 0000000000000000

[  684.082175] x13: 0000000000000000 x12: 0000000000000000

[  684.087515] x11: 0000000000000000 x10: 0000000000000000

[  684.092852] x9 : 0000000000000000 x8 : 0000000000000000

[  684.098189] x7 : 000000000006f09e x6 : 0000ffffb58a2000

[  684.103526] x5 : 0000ffffb58a3000 x4 : 0000000000000000

[  684.108864] x3 : 0000ffffb58a2000 x2 : 0000000000000f80

[  684.114201] x1 : ffff800004000000 x0 : 0000ffffb58a2000

[  684.119540] Process dd (pid: 2607, stack limit = 0x0000000004d531a7)

[  684.125924] Call trace:

[  684.128385]  __arch_copy_to_user+0x180/0x220

[  684.132676]  copy_page_to_iter+0xec/0x320

[  684.136706]  generic_file_read_iter+0x2ec/0x7b0

[  684.141260]  blkdev_read_iter+0x38/0x48

[  684.145115]  __vfs_read+0x110/0x148

[  684.148620]  vfs_read+0x8c/0x160

[  684.151863]  ksys_read+0x5c/0xc0

[  684.155106]  __arm64_sys_read+0x18/0x20

[  684.158963]  el0_svc_common+0x84/0xd8

[  684.162642]  el0_svc_handler+0x2c/0x80

[  684.166410]  el0_svc+0x8/0xc

[  684.169306] Code: d503201f d503201f d503201f d503201f (a8c12027)

[  684.175429] ---[ end trace 5fd69e42c5988a37 ]---

[  684.180240] SError Interrupt on CPU2, code 0xbf000002 -- SError

[  684.180242] CPU: 2 PID: 2607 Comm: dd Tainted: G      D
4.20.0-rc7-arm64 #3
[  684.180243] Hardware name: Marvell 8040 MACCHIATOBin (DT)

[  684.180244] pstate: a0000005 (NzCv daif -PAN -UAO)

[  684.180245] pc : unmap_page_range+0x468/0xa38

[  684.180246] lr : unmap_page_range+0x414/0xa38

[  684.180247] sp : ffff00000d803750

[  684.180248] x29: ffff00000d803750 x28: ffff00000d8038f0

[  684.180250] x27: ffff800055c6b130 x26: 0400000000000001

[  684.180253] x25: 0000000000000000 x24: ffff7e00019b6500

[  684.180255] x23: 0000aaaad4c27000 x22: 0000aaaad4c26000

[  684.180257] x21: ffff00000d803838 x20: 0000aaaad4c27000

[  684.180259] x19: 0000aaaad4c30000 x18: 0000000000000010

[  684.180261] x17: 00000000ffffffff x16: 0000000000000000

[  684.180263] x15: ffffffffffffffff x14: 0720072007200720

[  684.180266] x13: 0720072007200720 x12: 0720072007200720

[  684.180268] x11: ffff80007ffaa650 x10: 0720072007200720

[  684.180270] x9 : 0720072007200720 x8 : ffff80007ffaa640

[  684.180272] x7 : 0000000000000010 x6 : ffff80007ffaa640

[  684.180274] x5 : 0000aaaad4c26000 x4 : ffff800055c7e3c0

[  684.180276] x3 : 0000000000066d94 x2 : 0020000066d94fd3

[  684.180278] x1 : 0000000000000009 x0 : 0000000000000009

[  684.180281] Kernel panic - not syncing: Asynchronous SError Interrupt

[  684.180295] SMP: stopping secondary CPUs

[  684.180296] Kernel Offset: disabled

[  684.180297] CPU features: 0x2,21806000

[  684.180298] Memory Limit: none

[  684.317162] ---[ end Kernel panic - not syncing: Asynchronous SError
Interrupt ]---

Best regards

Heinrich

> 
> 
>> ---
>> v2
>> 	Move the change from armada-8040-mcbin.dts to armada-ap806.dtsi.
>> 	I only have a MACCHIATObin for testing but
>> 	https://github.com/MarvellEmbeddedProcessors/linux-marvell
>> 	has the reservation in that file.
>> ---
>>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
>> index 7d94c1fa592a..f8dafef83db0 100644
>> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
>> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
>> @@ -28,6 +28,17 @@
>>  		method = "smc";
>>  	};
>>  
>> +	reserved-memory {
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		psci-area@4000000 {
>> +			reg = <0x0 0x4000000 0x0 0x200000>;
>> +			no-map;
>> +		};
>> +	};
>> +
>>  	ap806 {
>>  		#address-cells = <2>;
>>  		#size-cells = <2>;
>> -- 
>> 2.19.2
>>
> 

Re: [PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Emmanuel Vadot]

 Hello all,

 Sorry I forgot to answer this email.

On Wed, 26 Dec 2018 18:09:04 +0100
Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> On 12/26/18 5:16 PM, Gregory CLEMENT wrote:
> > Hi Heinrich,
> >  
> >  On ven., déc. 21 2018, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > 
> >> The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
> >> attempt to access it from Linux leads to an immediate crash.
> >>
> >> So let's make the same memory reservation as the vendor kernel.
> >>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > 
> > We got a similar patch one month ago and Russell King pointed that it
> > didn't match waht he saw on his MACCHIATObin:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/612360.html
> > 
> > on mine under U-Boot I got:
> > 
> > Marvell>> md 0x4000000
> > 04000000: 00000000 00000007 00000005 00000040    ............@...
> > 04000010: 00000001 00001000 00000007 00000001    ................
> > 04000020: 00000008 00000000 00000009 00000000    ................
> > 04000030: 0000000a 00000000 ffffffff ffffffff    ................
> > 04000040: ffffffff ffffffff ffffffff ffffffff    ................
> > 04000050: ffffffff ffffffff ffffffff ffffffff    ................
> > 04000060: ffffffff ffffffff ffffffff ffffffff    ................
> > 04000070: ffffffff ffffffff ffffffff ffffffff    ................
> > 04000080: ffffffff ffffffff ffffffff ffffffff    ................
> > 04000090: ffffffff ffffffff ffffffff ffffffff    ................
> > 040000a0: ffffffff ffffffff ffffffff ffffffff    ................
> > 040000b0: ffffffff ffffffff ffffffff ffffffff    ................
> > 040000c0: ffffffff ffffffff ffffffff ffffffff    ................
> > 040000d0: ffffffff ffffffff ffffffff ffffffff    ................
> > 040000e0: ffffffff ffffffff ffffffff ffffffff    ................
> > 040000f0: ffffffff ffffffff ffffffff ffffffff    ................
> > 
> > In my case I have an old ATF, however this kind of setting should be
> > done by the bootloader.
> > 
> > I am interested by your claim about causing an immediate crash when
> > accessing this region. How did you trigger it?
> > 
> > Gregory
> 
> Hello Gregory,
> 
> judging from you U-Boot prompt you are not using mainline U-Boot. With
> the legacy Marvell U-Boot I get the same output as you provide above.
> But you are looking in the wrong place to confirm that this is ATF:
> 
> Marvell>> md 04017200
> 04017200: 616d6920 74206567 5043206f 474d2031     image to CP1 MG
> 04017210: 746f6e20 70757320 74726f70 000a6465     not supported..
> 04017220: 4f525245 20203a52 50435320 324c425f    ERROR:   SCP_BL2
> 04017230: 6f727720 6920676e 6620676d 616d726f     wrong img forma
> 04017240: 63282074 745f336d 3d657079 0a296425    t (cm3_type=%d).
> 04017250: 544f4e00 3a454349 43532020 6d492050    .NOTICE:  SCP Im
> 04017260: 20656761 73656f64 2074276e 746e6f63    age doesn't cont
> 04017270: 206e6961 66204d50 776d7269 0a657261    ain PM firmware.
> 04017280: 00000000 00000000 040144d0 00000000    .........D......
> 04017290: 00000001 00000019 4f525245 20203a52    ........ERROR:
> 040172a0: 6e695720 20776f64 203a6425 65736162     Window %d: base
> 040172b0: 64646120 73736572 616e7520 6e67696c     address unalign
> 040172c0: 74206465 7830206f 000a7825 67696c41    ed to 0x%x..Alig
> 040172d0: 7075206e 65687420 73616220 64612065    n up the base ad
> 040172e0: 73657264 6f742073 25783020 000a786c    dress to 0x%lx..
> 040172f0: 4f525245 20203a52 6e695720 20776f64    ERROR:   Window

 I do confirm what Heinrich is saying, this is needed (and made for)
mainline U-Boot.

> Possibly the legacy Marvell U-Boot is running at exception level 3
> (EL3). This would explain why you cannot reproduce the crash with that
> U-Boot.
> 
> The legacy Marvell U-Boot is in bad shape: their booti command cannot
> load the initrd.img created by Debian. This is why I use mainline
> U-Boot. Here you can find my recipe:

 I personnaly uses mainline U-Boot because the efi part is too old and
buggy on Marvell fork.

> https://github.com/xypron/u-boot-build/blob/macchiatobin/Makefile (for
> U-Boot v2018.11)
> 
> When I issue the md command for the region in mainline U-Boot  I get a
> crash:
> 
> => md 0x4000000
> 
> 
> 04000000:"Synchronous Abort" handler, esr 0x96000210
> 
> 
> elr: 000000000006b878 lr : 000000000006b7f4 (reloc)
> 
> 
> elr: 000000007ff8b878 lr : 000000007ff8b7f4
> 
> 
> x0 : 0000000000000009 x1 : 0000000000000000
> 
> 
> x2 : 000000000000003a x3 : 0000000004000000
> 
> 
> x4 : 0000000000000000 x5 : 000000007ffae306
> 
> 
> x6 : 0000000000000004 x7 : 000000007fb0a1e0
> 
> 
> x8 : 000000007fb0a0a0 x9 : 0000000000000008
> 
> 
> x10: 00000000ffffffd0 x11: 0000000000000006
> 
> 
> x12: 000000000001869f x13: 000000000000440c
> 
> 
> x14: 000000007fb0a43c x15: 0000000000000008
> 
> 
> x16: 000000007ffb49ea x17: 000000007ffb49ea
> 
> 
> x18: 000000007fb0fdd8 x19: 0000000000000040
> 
> 
> x20: 0000000004000000 x21: 0000000004000000
> 
> 
> x22: 000000007ffacff1 x23: 0000000000000008
> 
> 
> x24: 0000000000000004 x25: 0000000000000004
> 
> 
> x26: 0000000000000004 x27: 000000007fb0a268
> 
> 
> x28: 0000000000000000 x29: 000000007fb0a1e0
> 
> 
> 
> Resetting CPU ...
> 
> In Linux 4.20 without my patch I regularly experience crashes like the
> one below. With the patch I never experience such a crash.

 For me this is 100% reproducible with the FreeBSD kernel, not the same
kind of crash but a hang as soon as we try to call PSCI/SMCCC functions.

 I don't care personnaly which patch is taken as long as it's applied.

 Cheers,

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

Re: [PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Gregory CLEMENT]

Hi Emmanuel,
 
 On jeu., janv. 10 2019, Emmanuel Vadot <manu@bidouilliste.com> wrote:

>  Hello all,
>
>  Sorry I forgot to answer this email.
>
> On Wed, 26 Dec 2018 18:09:04 +0100
> Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>> On 12/26/18 5:16 PM, Gregory CLEMENT wrote:
>> > Hi Heinrich,
>> >  
>> >  On ven., déc. 21 2018, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> > 
>> >> The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
>> >> attempt to access it from Linux leads to an immediate crash.
>> >>
>> >> So let's make the same memory reservation as the vendor kernel.
>> >>
>> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> > 
>> > We got a similar patch one month ago and Russell King pointed that it
>> > didn't match waht he saw on his MACCHIATObin:
>> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/612360.html
>> > 
>> > on mine under U-Boot I got:
>> > 
>> > Marvell>> md 0x4000000
>> > 04000000: 00000000 00000007 00000005 00000040    ............@...
>> > 04000010: 00000001 00001000 00000007 00000001    ................
>> > 04000020: 00000008 00000000 00000009 00000000    ................
>> > 04000030: 0000000a 00000000 ffffffff ffffffff    ................
>> > 04000040: ffffffff ffffffff ffffffff ffffffff    ................
>> > 04000050: ffffffff ffffffff ffffffff ffffffff    ................
>> > 04000060: ffffffff ffffffff ffffffff ffffffff    ................
>> > 04000070: ffffffff ffffffff ffffffff ffffffff    ................
>> > 04000080: ffffffff ffffffff ffffffff ffffffff    ................
>> > 04000090: ffffffff ffffffff ffffffff ffffffff    ................
>> > 040000a0: ffffffff ffffffff ffffffff ffffffff    ................
>> > 040000b0: ffffffff ffffffff ffffffff ffffffff    ................
>> > 040000c0: ffffffff ffffffff ffffffff ffffffff    ................
>> > 040000d0: ffffffff ffffffff ffffffff ffffffff    ................
>> > 040000e0: ffffffff ffffffff ffffffff ffffffff    ................
>> > 040000f0: ffffffff ffffffff ffffffff ffffffff    ................
>> > 
>> > In my case I have an old ATF, however this kind of setting should be
>> > done by the bootloader.
>> > 
>> > I am interested by your claim about causing an immediate crash when
>> > accessing this region. How did you trigger it?
>> > 
>> > Gregory
>> 
>> Hello Gregory,
>> 
>> judging from you U-Boot prompt you are not using mainline U-Boot. With
>> the legacy Marvell U-Boot I get the same output as you provide above.
>> But you are looking in the wrong place to confirm that this is ATF:
>> 
>> Marvell>> md 04017200
>> 04017200: 616d6920 74206567 5043206f 474d2031     image to CP1 MG
>> 04017210: 746f6e20 70757320 74726f70 000a6465     not supported..
>> 04017220: 4f525245 20203a52 50435320 324c425f    ERROR:   SCP_BL2
>> 04017230: 6f727720 6920676e 6620676d 616d726f     wrong img forma
>> 04017240: 63282074 745f336d 3d657079 0a296425    t (cm3_type=%d).
>> 04017250: 544f4e00 3a454349 43532020 6d492050    .NOTICE:  SCP Im
>> 04017260: 20656761 73656f64 2074276e 746e6f63    age doesn't cont
>> 04017270: 206e6961 66204d50 776d7269 0a657261    ain PM firmware.
>> 04017280: 00000000 00000000 040144d0 00000000    .........D......
>> 04017290: 00000001 00000019 4f525245 20203a52    ........ERROR:
>> 040172a0: 6e695720 20776f64 203a6425 65736162     Window %d: base
>> 040172b0: 64646120 73736572 616e7520 6e67696c     address unalign
>> 040172c0: 74206465 7830206f 000a7825 67696c41    ed to 0x%x..Alig
>> 040172d0: 7075206e 65687420 73616220 64612065    n up the base ad
>> 040172e0: 73657264 6f742073 25783020 000a786c    dress to 0x%lx..
>> 040172f0: 4f525245 20203a52 6e695720 20776f64    ERROR:   Window
>
>  I do confirm what Heinrich is saying, this is needed (and made for)
> mainline U-Boot.
>
>> Possibly the legacy Marvell U-Boot is running at exception level 3
>> (EL3). This would explain why you cannot reproduce the crash with that
>> U-Boot.
>> 
>> The legacy Marvell U-Boot is in bad shape: their booti command cannot
>> load the initrd.img created by Debian. This is why I use mainline
>> U-Boot. Here you can find my recipe:
>
>  I personnaly uses mainline U-Boot because the efi part is too old and
> buggy on Marvell fork.
>
>> https://github.com/xypron/u-boot-build/blob/macchiatobin/Makefile (for
>> U-Boot v2018.11)
>> 
>> When I issue the md command for the region in mainline U-Boot  I get a
>> crash:
>> 
>> => md 0x4000000
>> 
>> 
>> 04000000:"Synchronous Abort" handler, esr 0x96000210
>> 
>> 
>> elr: 000000000006b878 lr : 000000000006b7f4 (reloc)
>> 
>> 
>> elr: 000000007ff8b878 lr : 000000007ff8b7f4
>> 
>> 
>> x0 : 0000000000000009 x1 : 0000000000000000
>> 
>> 
>> x2 : 000000000000003a x3 : 0000000004000000
>> 
>> 
>> x4 : 0000000000000000 x5 : 000000007ffae306
>> 
>> 
>> x6 : 0000000000000004 x7 : 000000007fb0a1e0
>> 
>> 
>> x8 : 000000007fb0a0a0 x9 : 0000000000000008
>> 
>> 
>> x10: 00000000ffffffd0 x11: 0000000000000006
>> 
>> 
>> x12: 000000000001869f x13: 000000000000440c
>> 
>> 
>> x14: 000000007fb0a43c x15: 0000000000000008
>> 
>> 
>> x16: 000000007ffb49ea x17: 000000007ffb49ea
>> 
>> 
>> x18: 000000007fb0fdd8 x19: 0000000000000040
>> 
>> 
>> x20: 0000000004000000 x21: 0000000004000000
>> 
>> 
>> x22: 000000007ffacff1 x23: 0000000000000008
>> 
>> 
>> x24: 0000000000000004 x25: 0000000000000004
>> 
>> 
>> x26: 0000000000000004 x27: 000000007fb0a268
>> 
>> 
>> x28: 0000000000000000 x29: 000000007fb0a1e0
>> 
>> 
>> 
>> Resetting CPU ...
>> 
>> In Linux 4.20 without my patch I regularly experience crashes like the
>> one below. With the patch I never experience such a crash.
>
>  For me this is 100% reproducible with the FreeBSD kernel, not the same
> kind of crash but a hang as soon as we try to call PSCI/SMCCC functions.
>
>  I don't care personnaly which patch is taken as long as it's applied.

Thanks for your confirmation I will apply it.

Gregory

>
>  Cheers,
>
> -- 
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Gregory CLEMENT]

Hi Heinrich,
 
 On ven., déc. 21 2018, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
> attempt to access it from Linux leads to an immediate crash.
>
> So let's make the same memory reservation as the vendor kernel.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


Applied on mvebu/fixes

I added a comment about the use with a mainline /U-Boot

Thanks,

Gregory


> ---
> v2
> 	Move the change from armada-8040-mcbin.dts to armada-ap806.dtsi.
> 	I only have a MACCHIATObin for testing but
> 	https://github.com/MarvellEmbeddedProcessors/linux-marvell
> 	has the reservation in that file.
> ---
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 7d94c1fa592a..f8dafef83db0 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -28,6 +28,17 @@
>  		method = "smc";
>  	};
>  
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		psci-area@4000000 {
> +			reg = <0x0 0x4000000 0x0 0x200000>;
> +			no-map;
> +		};
> +	};
> +
>  	ap806 {
>  		#address-cells = <2>;
>  		#size-cells = <2>;
> -- 
> 2.19.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Heinrich Schuchardt]

On 1/10/19 12:04 PM, Gregory CLEMENT wrote:
> Hi Heinrich,
>  
>  On ven., déc. 21 2018, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> 
>> The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
>> attempt to access it from Linux leads to an immediate crash.
>>
>> So let's make the same memory reservation as the vendor kernel.
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> 
> 
> Applied on mvebu/fixes
> 
> I added a comment about the use with a mainline /U-Boot
> 
> Thanks,
> 
> Gregory
> 
> 


Hello Greg,

please, consider

arm64: dts: marvell: armada-ap806: reserve PSCI area
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc2&id=132ac39cffbcfed80ada38ef0fc6d34d95da7be6

for backporting to v4.19.

This patch is needed to run Linux on the MACCHIATObin and other boards.

Best regards

Heinrich

Re: [PATCH v2 1/1] arm64: dts: marvell: armada-ap806: reserve PSCI area

[Greg Kroah-Hartman]

On Sun, Jan 20, 2019 at 03:14:05PM +0100, Heinrich Schuchardt wrote:
> On 1/10/19 12:04 PM, Gregory CLEMENT wrote:
> > Hi Heinrich,
> >  
> >  On ven., déc. 21 2018, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > 
> >> The memory area [0x4000000-0x4200000[ is occupied by the PSCI firmware. Any
> >> attempt to access it from Linux leads to an immediate crash.
> >>
> >> So let's make the same memory reservation as the vendor kernel.
> >>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > 
> > 
> > Applied on mvebu/fixes
> > 
> > I added a comment about the use with a mainline /U-Boot
> > 
> > Thanks,
> > 
> > Gregory
> > 
> > 
> 
> 
> Hello Greg,
> 
> please, consider
> 
> arm64: dts: marvell: armada-ap806: reserve PSCI area
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc2&id=132ac39cffbcfed80ada38ef0fc6d34d95da7be6
> 
> for backporting to v4.19.
> 
> This patch is needed to run Linux on the MACCHIATObin and other boards.

Now queued up, thanks.

greg k-h