From: Tony Lindgren <tony@atomide.com>
To: Nishanth Menon <nm@ti.com>
Cc: "Ивайло Димитров" <freemangordon@abv.bg>,
pali.rohar@gmail.com, linux@arm.linux.org.uk,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Date: Mon, 4 Mar 2013 10:58:06 -0800 [thread overview]
Message-ID: <20130304185806.GS11806@atomide.com> (raw)
In-Reply-To: <CAGo_u6omQdSzpfthHNAU1UvgSvkgq3ZC6g1Ha9oi0nc9QJ71nA@mail.gmail.com>
* Nishanth Menon <nm@ti.com> [130301 06:42]:
> On Fri, Mar 1, 2013 at 1:47 AM, Ивайло Димитров <freemangordon@abv.bg> wrote:
> >
> > They look similar, but they are not equivalent :). The first major difference is here (code taken from omap-smc.S)
> >
> >> ENTRY(omap_smc2)
> >> stmfd sp!, {r4-r12, lr}
> >> mov r3, r2
> >> mov r2, r1
> >> mov r1, #0x0 @ Process ID
> >> mov r6, #0xff
> >> mov r12, #0x00 @ Secure Service ID
> >
> > Always zero, while RX51 PPA expects a real value. I wonder if it is a bug, but anyway I don't see the id parameter (R0) used.
> >
> >> mov r7, #0
> >> mcr p15, 0, r7, c7, c5, 6
> >
> > According to ARM TRM, this is "Invalidate entire branch predictor array"(IIUC). NFC why it is needed here, but this will not work on RX-51 until IBE bit in ACR is set.
> >
> >> dsb
> >> dmb
> >> smc #0
> >
> > RX-51 needs smc #1 ;)
> >
> >> ldmfd sp!, {r4-r12, pc}
> >
> >
> > The next major difference is that RX-51 expects parameter count passed in R3[0] to be the count of the remaining parameters +1, but omap_secure_dispatcher (in omap-secure.c) is passing the exact count of the remaining parameters.
> >
> > I guess all of the above problems can be fixed/workarounded, but I wonder does it worth. Not to say that I don't have BB around to test if the code still works if I make changes to omap2-secure.c/omap-smc.S :)
> >
> >
>
> Yep, that was my point - instead of introducing new functions,
> extending the existing functions to handle new requirements is better
> solution, IMHO.
I think there have been patches posted for ARM generic SMC
handling. Might be worth looking at those a bit and see if
this can be made generic. I think only the SMC call numbering
is different for various SoCs?
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Date: Mon, 4 Mar 2013 10:58:06 -0800 [thread overview]
Message-ID: <20130304185806.GS11806@atomide.com> (raw)
In-Reply-To: <CAGo_u6omQdSzpfthHNAU1UvgSvkgq3ZC6g1Ha9oi0nc9QJ71nA@mail.gmail.com>
* Nishanth Menon <nm@ti.com> [130301 06:42]:
> On Fri, Mar 1, 2013 at 1:47 AM, ?????? ???????? <freemangordon@abv.bg> wrote:
> >
> > They look similar, but they are not equivalent :). The first major difference is here (code taken from omap-smc.S)
> >
> >> ENTRY(omap_smc2)
> >> stmfd sp!, {r4-r12, lr}
> >> mov r3, r2
> >> mov r2, r1
> >> mov r1, #0x0 @ Process ID
> >> mov r6, #0xff
> >> mov r12, #0x00 @ Secure Service ID
> >
> > Always zero, while RX51 PPA expects a real value. I wonder if it is a bug, but anyway I don't see the id parameter (R0) used.
> >
> >> mov r7, #0
> >> mcr p15, 0, r7, c7, c5, 6
> >
> > According to ARM TRM, this is "Invalidate entire branch predictor array"(IIUC). NFC why it is needed here, but this will not work on RX-51 until IBE bit in ACR is set.
> >
> >> dsb
> >> dmb
> >> smc #0
> >
> > RX-51 needs smc #1 ;)
> >
> >> ldmfd sp!, {r4-r12, pc}
> >
> >
> > The next major difference is that RX-51 expects parameter count passed in R3[0] to be the count of the remaining parameters +1, but omap_secure_dispatcher (in omap-secure.c) is passing the exact count of the remaining parameters.
> >
> > I guess all of the above problems can be fixed/workarounded, but I wonder does it worth. Not to say that I don't have BB around to test if the code still works if I make changes to omap2-secure.c/omap-smc.S :)
> >
> >
>
> Yep, that was my point - instead of introducing new functions,
> extending the existing functions to handle new requirements is better
> solution, IMHO.
I think there have been patches posted for ARM generic SMC
handling. Might be worth looking at those a bit and see if
this can be made generic. I think only the SMC call numbering
is different for various SoCs?
Regards,
Tony
next prev parent reply other threads:[~2013-03-04 18:58 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 7:47 [PATCH] arm: omap: RX-51: ARM errata 430973 workaround Ивайло Димитров
2013-03-01 14:38 ` Nishanth Menon
2013-03-01 14:38 ` Nishanth Menon
2013-03-04 18:58 ` Tony Lindgren [this message]
2013-03-04 18:58 ` Tony Lindgren
2013-03-06 14:09 ` Pali Rohár
2013-03-06 14:09 ` Pali Rohár
2013-03-06 17:51 ` Tony Lindgren
2013-03-06 17:51 ` Tony Lindgren
2013-03-06 19:13 ` Pali Rohár
2013-03-06 19:13 ` Pali Rohár
2013-03-24 14:26 ` Pali Rohár
2013-03-24 14:26 ` Pali Rohár
2013-03-27 20:56 ` Tony Lindgren
2013-03-27 20:56 ` Tony Lindgren
2013-03-27 20:56 ` Tony Lindgren
2013-03-27 21:05 ` Pali Rohár
2013-03-27 21:05 ` Pali Rohár
2013-03-27 21:12 ` Tony Lindgren
2013-03-27 21:12 ` Tony Lindgren
2013-03-28 9:50 ` Russell King - ARM Linux
2013-03-28 9:50 ` Russell King - ARM Linux
2013-03-28 10:07 ` Santosh Shilimkar
2013-03-28 10:07 ` Santosh Shilimkar
2013-03-28 15:53 ` Tony Lindgren
2013-03-28 15:53 ` Tony Lindgren
-- strict thread matches above, loose matches on Subject: below --
2013-03-30 22:31 Ивайло Димитров
2013-03-31 7:37 ` Pavel Machek
2013-03-31 7:37 ` Pavel Machek
2013-03-28 5:30 Ивайло Димитров
2013-03-28 15:58 ` Tony Lindgren
2013-03-28 15:58 ` Tony Lindgren
2013-03-28 15:58 ` Tony Lindgren
2013-03-06 9:32 Ивайло Димитров
2013-03-01 10:09 Ивайло Димитров
2013-03-01 23:51 ` Aaro Koskinen
2013-03-01 23:51 ` Aaro Koskinen
2013-03-01 23:51 ` Aaro Koskinen
2013-02-28 9:42 Pali Rohár
2013-02-28 9:42 ` Pali Rohár
2013-02-28 9:42 ` Pali Rohár
2013-02-28 14:40 ` Nishanth Menon
2013-02-28 14:40 ` Nishanth Menon
2013-02-28 14:40 ` Nishanth Menon
2013-03-01 9:43 ` Peter De Schrijver
2013-03-01 9:43 ` Peter De Schrijver
2013-03-30 18:36 ` Pavel Machek
2013-03-30 18:36 ` Pavel Machek
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=20130304185806.GS11806@atomide.com \
--to=tony@atomide.com \
--cc=freemangordon@abv.bg \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nm@ti.com \
--cc=pali.rohar@gmail.com \
/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.