All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Tushar Behera <tushar.behera@linaro.org>,
	Javi Merino <javi.merino@arm.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Mike Turquette <mturquette@linaro.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Sachin Kamat <sachin.kamat@linaro.org>,
	Chander Kashyap <chander.kashyap@linaro.org>
Subject: Re: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
Date: Tue, 04 Mar 2014 13:03:33 +0100	[thread overview]
Message-ID: <5315C115.3060000@gmail.com> (raw)
In-Reply-To: <CAHbNUh2kbYUa1OegRrOXMAEmKRjsf4PifT6tZnKdBx7NoDkq6A@mail.gmail.com>

On 04.03.2014 13:01, Tushar Behera wrote:
> On 4 March 2014 16:09, Javi Merino <javi.merino@arm.com> wrote:
>> On Tue, Mar 04, 2014 at 10:30:19AM +0000, Sylwester Nawrocki wrote:
>>> On 04/03/14 11:16, Javi Merino wrote:
>>>> Yes, with [1] applied I don't get a kernel panic but the kernel fails
>>>> to boot later on with an Imprecise external abort.  Removing the mdma
>>>> nodes from the dts gets rid of that.  I guess what's missing is what
>>>> you said: clocks for the mdma devices.
>>>
>>> Is removing mdm0 node enough to fix the boot failure, or both have to be
>>> removed ?
>>
>> Actually, you it's only mdma1.  Just removing the mdma1 node from the
>> dt fixes the imprecise external abort.
>>
>
> MDMA1 can support both secure and non-secure AXI transactions, the
> actual behaviour is controlled by trustzone software. It may be the
> case that MDMA1 is configured to be used in secure mode only, hence
> accessing it in non-secure mode is causing the oops.
>
> Right now, the only solution looks like disabling this node in
> Arndale-Octa dts file.
>
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -354,4 +354,16 @@
>                  samsung,i2s-controller = <&i2s0>;
>                  samsung,audio-codec = <&i2s_stub>;
>          };
> +
> +       amba {
> +               mdma1: mdma@11C10000 {
> +                       /*
> +                        * MDMA1 can support both secure and non-secure
> +                        * AXI transactions. When this is enabled in the kernel
> +                        * for boards that run in secure mode, we are getting
> +                        * imprecise external aborts causing the kernel to oops.
> +                        */
> +                       status = "disabled";
> +               };
> +       };
>
> If it works, I will submit this patch.

On Exynos 4 SoCs there were two instances of MDMA1, one secure and one 
non-secure. Isn't it the case for Exynos5420 as well? If yes, the common 
DTSI could be changed to always use the non-secure one.

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [REGRESSION] Arndale Octa panics when booting 3.14-rc1
Date: Tue, 04 Mar 2014 13:03:33 +0100	[thread overview]
Message-ID: <5315C115.3060000@gmail.com> (raw)
In-Reply-To: <CAHbNUh2kbYUa1OegRrOXMAEmKRjsf4PifT6tZnKdBx7NoDkq6A@mail.gmail.com>

On 04.03.2014 13:01, Tushar Behera wrote:
> On 4 March 2014 16:09, Javi Merino <javi.merino@arm.com> wrote:
>> On Tue, Mar 04, 2014 at 10:30:19AM +0000, Sylwester Nawrocki wrote:
>>> On 04/03/14 11:16, Javi Merino wrote:
>>>> Yes, with [1] applied I don't get a kernel panic but the kernel fails
>>>> to boot later on with an Imprecise external abort.  Removing the mdma
>>>> nodes from the dts gets rid of that.  I guess what's missing is what
>>>> you said: clocks for the mdma devices.
>>>
>>> Is removing mdm0 node enough to fix the boot failure, or both have to be
>>> removed ?
>>
>> Actually, you it's only mdma1.  Just removing the mdma1 node from the
>> dt fixes the imprecise external abort.
>>
>
> MDMA1 can support both secure and non-secure AXI transactions, the
> actual behaviour is controlled by trustzone software. It may be the
> case that MDMA1 is configured to be used in secure mode only, hence
> accessing it in non-secure mode is causing the oops.
>
> Right now, the only solution looks like disabling this node in
> Arndale-Octa dts file.
>
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -354,4 +354,16 @@
>                  samsung,i2s-controller = <&i2s0>;
>                  samsung,audio-codec = <&i2s_stub>;
>          };
> +
> +       amba {
> +               mdma1: mdma at 11C10000 {
> +                       /*
> +                        * MDMA1 can support both secure and non-secure
> +                        * AXI transactions. When this is enabled in the kernel
> +                        * for boards that run in secure mode, we are getting
> +                        * imprecise external aborts causing the kernel to oops.
> +                        */
> +                       status = "disabled";
> +               };
> +       };
>
> If it works, I will submit this patch.

On Exynos 4 SoCs there were two instances of MDMA1, one secure and one 
non-secure. Isn't it the case for Exynos5420 as well? If yes, the common 
DTSI could be changed to always use the non-secure one.

Best regards,
Tomasz

  reply	other threads:[~2014-03-04 12:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03 18:57 [REGRESSION] Arndale Octa panics when booting 3.14-rc1 Javi Merino
2014-03-03 18:57 ` Javi Merino
2014-03-03 19:04 ` Tomasz Figa
2014-03-03 19:04   ` Tomasz Figa
2014-03-03 20:53   ` Sylwester Nawrocki
2014-03-03 20:53     ` Sylwester Nawrocki
2014-03-04 10:16     ` Javi Merino
2014-03-04 10:16       ` Javi Merino
2014-03-04 10:30       ` Sylwester Nawrocki
2014-03-04 10:30         ` Sylwester Nawrocki
2014-03-04 10:39         ` Javi Merino
2014-03-04 10:39           ` Javi Merino
2014-03-04 12:01           ` Tushar Behera
2014-03-04 12:01             ` Tushar Behera
2014-03-04 12:03             ` Tomasz Figa [this message]
2014-03-04 12:03               ` Tomasz Figa
2014-03-04 12:09               ` Tushar Behera
2014-03-04 12:09                 ` Tushar Behera
2014-03-04 14:24             ` Javi Merino
2014-03-04 14:24               ` Javi Merino
2014-03-04  1:07   ` Mike Turquette
2014-03-04  1:07     ` Mike Turquette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5315C115.3060000@gmail.com \
    --to=tomasz.figa@gmail.com \
    --cc=chander.kashyap@linaro.org \
    --cc=javi.merino@arm.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=s.nawrocki@samsung.com \
    --cc=sachin.kamat@linaro.org \
    --cc=tushar.behera@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.