Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1637993 > unrolled thread

[PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware

Started byPhil Elwell <phil@raspberrypi.org>
First post2017-05-09 11:10 +0200
Last post2017-05-09 19:00 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware Phil Elwell <phil@raspberrypi.org> - 2017-05-09 11:10 +0200
    Re: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware Florian Fainelli <f.fainelli@gmail.com> - 2017-05-09 18:30 +0200
    Re: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware Florian Fainelli <f.fainelli@gmail.com> - 2017-05-09 19:00 +0200
      Re: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware Eric Anholt <eric@anholt.net> - 2017-05-09 20:20 +0200
    Re: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware Eric Anholt <eric@anholt.net> - 2017-05-09 19:00 +0200

#1637993 — [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware

FromPhil Elwell <phil@raspberrypi.org>
Date2017-05-09 11:10 +0200
Subject[PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
Message-ID<tF9jz-89r-3@gated-at.bofh.it>
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(+)

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.
-- 
1.9.1

[toc] | [next] | [standalone]


#1638266

FromFlorian Fainelli <f.fainelli@gmail.com>
Date2017-05-09 18:30 +0200
Message-ID<tFgbo-4bu-13@gated-at.bofh.it>
In reply to#1637993
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.
> 


-- 
Florian

[toc] | [prev] | [next] | [standalone]


#1638284

FromFlorian Fainelli <f.fainelli@gmail.com>
Date2017-05-09 19:00 +0200
Message-ID<tFgEq-4pa-9@gated-at.bofh.it>
In reply to#1637993
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

[toc] | [prev] | [next] | [standalone]


#1638335

FromEric Anholt <eric@anholt.net>
Date2017-05-09 20:20 +0200
Message-ID<tFhTP-5nA-19@gated-at.bofh.it>
In reply to#1638284

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]


#1638285

FromEric Anholt <eric@anholt.net>
Date2017-05-09 19:00 +0200
Message-ID<tFgEp-4pa-7@gated-at.bofh.it>
In reply to#1637993

[Multipart message — attachments visible in raw view] — view raw

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!

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web