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 <[email protected]>
---
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
Hi Heinrich,
On ven., déc. 21 2018, Heinrich Schuchardt <[email protected]> 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 <[email protected]>
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
On 12/26/18 5:16 PM, Gregory CLEMENT wrote:
> Hi Heinrich,
>
> On ven., déc. 21 2018, Heinrich Schuchardt <[email protected]> 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 <[email protected]>
>
> 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
>>
>
Hello all,
Sorry I forgot to answer this email.
On Wed, 26 Dec 2018 18:09:04 +0100
Heinrich Schuchardt <[email protected]> wrote:
> On 12/26/18 5:16 PM, Gregory CLEMENT wrote:
> > Hi Heinrich,
> >
> > On ven., d?c. 21 2018, Heinrich Schuchardt <[email protected]> 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 <[email protected]>
> >
> > 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 <[email protected]> <[email protected]>
Hi Heinrich,
On ven., déc. 21 2018, Heinrich Schuchardt <[email protected]> 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 <[email protected]>
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
Hi Emmanuel,
On jeu., janv. 10 2019, Emmanuel Vadot <[email protected]> wrote:
> Hello all,
>
> Sorry I forgot to answer this email.
>
> On Wed, 26 Dec 2018 18:09:04 +0100
> Heinrich Schuchardt <[email protected]> wrote:
>
>> On 12/26/18 5:16 PM, Gregory CLEMENT wrote:
>> > Hi Heinrich,
>> >
>> > On ven., déc. 21 2018, Heinrich Schuchardt <[email protected]> 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 <[email protected]>
>> >
>> > 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 <[email protected]> <[email protected]>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
On 1/10/19 12:04 PM, Gregory CLEMENT wrote:
> Hi Heinrich,
>
> On ven., déc. 21 2018, Heinrich Schuchardt <[email protected]> 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 <[email protected]>
>
>
> 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
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 <[email protected]> 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 <[email protected]>
> >
> >
> > 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