| Message ID | b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 05/09/2017 02:04 AM, Phil Elwell wrote: > The Raspberry Pi startup stub files for multi-core BCM27XX processors > make the secondary CPUs spin until the corresponding mailbox is > written. These stubs are loaded at physical address 0x00000xxx (as seen > by the ARMs), but this page will be reused by the kernel unless it is > explicitly reserved, causing the waiting cores to execute random code. > > Use the /memreserve/ Device Tree directive to mark the first page as > off-limits to the kernel. This reserves a 4KB page here, is this good enough, or should we just go directly to the maximum page granule size possible on an ARM64/Linux system to be on the safe side? > > See: https://github.com/raspberrypi/linux/issues/1989 > > Signed-off-by: Phil Elwell <phil@raspberrypi.org> > --- > > Changes in V2: > - Rebase against linux-next > - Drop downstream-only patch > > arch/arm/boot/dts/bcm283x.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi > index a3106aa..6d12c3e8 100644 > --- a/arch/arm/boot/dts/bcm283x.dtsi > +++ b/arch/arm/boot/dts/bcm283x.dtsi > @@ -3,6 +3,8 @@ > #include <dt-bindings/clock/bcm2835-aux.h> > #include <dt-bindings/gpio/gpio.h> > > +/memreserve/ 0x00000000 0x00001000; Can you put a comment above this /memreserve entry here to remind about what this is useful for? Thanks! > + > /* This include file covers the common peripherals and configuration between > * bcm2835 and bcm2836 implementations, leaving the CPU configuration to > * bcm2835.dtsi and bcm2836.dtsi. >
Phil Elwell <phil@raspberrypi.org> writes: > The Raspberry Pi startup stub files for multi-core BCM27XX processors > make the secondary CPUs spin until the corresponding mailbox is > written. These stubs are loaded at physical address 0x00000xxx (as seen > by the ARMs), but this page will be reused by the kernel unless it is > explicitly reserved, causing the waiting cores to execute random code. > > Use the /memreserve/ Device Tree directive to mark the first page as > off-limits to the kernel. > > See: https://github.com/raspberrypi/linux/issues/1989 > > Signed-off-by: Phil Elwell <phil@raspberrypi.org> This looks great. We're currently in the merge window, so I can't generate a new bcm2835-dt-next yet, but I'll pick this patch up when I do. Thanks for submitting upstream!
On 05/09/2017 09:48 AM, Eric Anholt wrote: > Phil Elwell <phil@raspberrypi.org> writes: > >> The Raspberry Pi startup stub files for multi-core BCM27XX processors >> make the secondary CPUs spin until the corresponding mailbox is >> written. These stubs are loaded at physical address 0x00000xxx (as seen >> by the ARMs), but this page will be reused by the kernel unless it is >> explicitly reserved, causing the waiting cores to execute random code. >> >> Use the /memreserve/ Device Tree directive to mark the first page as >> off-limits to the kernel. >> >> See: https://github.com/raspberrypi/linux/issues/1989 >> >> Signed-off-by: Phil Elwell <phil@raspberrypi.org> > > This looks great. We're currently in the merge window, so I can't > generate a new bcm2835-dt-next yet, but I'll pick this patch up when I > do. > > Thanks for submitting upstream! Considering that this is a fix, we could actually squeeze it in the devicetree/fixes branch and we could submit those as soon as v4.12-rc1 is tagged, your call.
Florian Fainelli <f.fainelli@gmail.com> writes: > On 05/09/2017 09:48 AM, Eric Anholt wrote: >> Phil Elwell <phil@raspberrypi.org> writes: >> >>> The Raspberry Pi startup stub files for multi-core BCM27XX processors >>> make the secondary CPUs spin until the corresponding mailbox is >>> written. These stubs are loaded at physical address 0x00000xxx (as seen >>> by the ARMs), but this page will be reused by the kernel unless it is >>> explicitly reserved, causing the waiting cores to execute random code. >>> >>> Use the /memreserve/ Device Tree directive to mark the first page as >>> off-limits to the kernel. >>> >>> See: https://github.com/raspberrypi/linux/issues/1989 >>> >>> Signed-off-by: Phil Elwell <phil@raspberrypi.org> >> >> This looks great. We're currently in the merge window, so I can't >> generate a new bcm2835-dt-next yet, but I'll pick this patch up when I >> do. >> >> Thanks for submitting upstream! > > Considering that this is a fix, we could actually squeeze it in the > devicetree/fixes branch and we could submit those as soon as v4.12-rc1 > is tagged, your call. While the issue is a bit obscure, I know I've hit it as well. I agree that it's a good stable candidate, so unless you'd like to pick it yourself and cc stable, I'll just send you a PR doing so when rc1 rolls around.
Am 09.05.2017 um 11:04 schrieb Phil Elwell: > The Raspberry Pi startup stub files for multi-core BCM27XX processors Curiously, while this V2 was rebased to apply against the bcm283x rather than bcm2710 file, it changed the text from BCM283X to BCM27XX. > make the secondary CPUs spin until the corresponding mailbox is > written. These stubs are loaded at physical address 0x00000xxx (as seen > by the ARMs), but this page will be reused by the kernel unless it is > explicitly reserved, causing the waiting cores to execute random code. > > Use the /memreserve/ Device Tree directive to mark the first page as > off-limits to the kernel. > > See: https://github.com/raspberrypi/linux/issues/1989 > > Signed-off-by: Phil Elwell <phil@raspberrypi.org> > --- > > Changes in V2: > - Rebase against linux-next > - Drop downstream-only patch > > arch/arm/boot/dts/bcm283x.dtsi | 2 ++ > 1 file changed, 2 insertions(+) Regards, Andreas
Florian Fainelli <f.fainelli@gmail.com> writes: > On 05/09/2017 02:04 AM, Phil Elwell wrote: >> The Raspberry Pi startup stub files for multi-core BCM27XX processors >> make the secondary CPUs spin until the corresponding mailbox is >> written. These stubs are loaded at physical address 0x00000xxx (as seen >> by the ARMs), but this page will be reused by the kernel unless it is >> explicitly reserved, causing the waiting cores to execute random code. >> >> Use the /memreserve/ Device Tree directive to mark the first page as >> off-limits to the kernel. > > This reserves a 4KB page here, is this good enough, or should we just go > directly to the maximum page granule size possible on an ARM64/Linux > system to be on the safe side? > >> >> See: https://github.com/raspberrypi/linux/issues/1989 >> >> Signed-off-by: Phil Elwell <phil@raspberrypi.org> >> --- >> >> Changes in V2: >> - Rebase against linux-next >> - Drop downstream-only patch >> >> arch/arm/boot/dts/bcm283x.dtsi | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi >> index a3106aa..6d12c3e8 100644 >> --- a/arch/arm/boot/dts/bcm283x.dtsi >> +++ b/arch/arm/boot/dts/bcm283x.dtsi >> @@ -3,6 +3,8 @@ >> #include <dt-bindings/clock/bcm2835-aux.h> >> #include <dt-bindings/gpio/gpio.h> >> >> +/memreserve/ 0x00000000 0x00001000; > > Can you put a comment above this /memreserve entry here to remind about > what this is useful for? > > Thanks! Phil, I chatted with Florian and added in: +/* firmware-provided startup stubs live here, where the secondary CPUs are + * spinning. + */ and tagged and sent a PR for 4.12. Thanks!
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi index a3106aa..6d12c3e8 100644 --- a/arch/arm/boot/dts/bcm283x.dtsi +++ b/arch/arm/boot/dts/bcm283x.dtsi @@ -3,6 +3,8 @@ #include <dt-bindings/clock/bcm2835-aux.h> #include <dt-bindings/gpio/gpio.h> +/memreserve/ 0x00000000 0x00001000; + /* This include file covers the common peripherals and configuration between * bcm2835 and bcm2836 implementations, leaving the CPU configuration to * bcm2835.dtsi and bcm2836.dtsi.
The Raspberry Pi startup stub files for multi-core BCM27XX processors make the secondary CPUs spin until the corresponding mailbox is written. These stubs are loaded at physical address 0x00000xxx (as seen by the ARMs), but this page will be reused by the kernel unless it is explicitly reserved, causing the waiting cores to execute random code. Use the /memreserve/ Device Tree directive to mark the first page as off-limits to the kernel. See: https://github.com/raspberrypi/linux/issues/1989 Signed-off-by: Phil Elwell <phil@raspberrypi.org> --- Changes in V2: - Rebase against linux-next - Drop downstream-only patch arch/arm/boot/dts/bcm283x.dtsi | 2 ++ 1 file changed, 2 insertions(+)