* linux-omap-psp and security code
@ 2012-07-19 10:31 Vladimir Zapolskiy
2012-07-31 20:16 ` Denys Dmytriyenko
0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Zapolskiy @ 2012-07-19 10:31 UTC (permalink / raw)
To: meta-ti
Hello,
I have a question about linux-omap-psp-2.6.32 kernel and boards, which
uses this kernel, in particular about
0038-ARM-Expose-some-CPU-control-registers-via-sysfs.patch. The recent
toolchains based on binutils-2.21 or later imply more accurate handling
with `smc #0' instructions, which are found in the aforementioned patch.
The compilation of the linux-omap-psp kernel with such toolchains leads
to "selected processor does not support ARM mode `smc #0'" errors. The
patch itself adds /sys/devices/system/cpu/cpuN/ nodes providing access
to control register, auxiliary control register, and L2 cache auxiliary
control register.
I see several possible solutions of the problem, and I'd be glad to find
out the best one. First of all it might have sense to remove the patch
completely, because its functionality is purely optional, presumably it
is not used by any userspace programs and therefore can be omitted. As a
soft alternative CONFIG_CPU_V7_SYSFS kernel option for a list of boards
could be disabled in default kernel config files, but I personally don't
like this variant, because it merely veils a problem, better to remove
the patch itself.
One more option is to fix the patch, either remove store feature of
/sys/devices/system/cpu/cpuN/(l2_)?aux_control files or provide
-march=armv7-a+sec AFLAGS in Makefile.
Any suggestions and comments are appreciated.
With best wishes,
Vladimir
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux-omap-psp and security code
2012-07-19 10:31 linux-omap-psp and security code Vladimir Zapolskiy
@ 2012-07-31 20:16 ` Denys Dmytriyenko
2012-07-31 20:59 ` Vladimir Zapolskiy
0 siblings, 1 reply; 3+ messages in thread
From: Denys Dmytriyenko @ 2012-07-31 20:16 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: meta-ti
This one got stuck in the moderation queue with all the spam... Just wanted to
comment on the third option, though.
On Thu, Jul 19, 2012 at 01:31:26PM +0300, Vladimir Zapolskiy wrote:
> One more option is to fix the patch, either remove store feature of
> /sys/devices/system/cpu/cpuN/(l2_)?aux_control files or provide
> -march=armv7-a+sec AFLAGS in Makefile.
FWIW, I previously made a similar fix for this type of issue:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=051482e3b03ba7e2d6cecc0d8f85cc3be22dc8b2
But either way it's better to update to a more recent 2.6.37 kernel for AM37x
anyway, which I'll work on next.
--
Denys
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux-omap-psp and security code
2012-07-31 20:16 ` Denys Dmytriyenko
@ 2012-07-31 20:59 ` Vladimir Zapolskiy
0 siblings, 0 replies; 3+ messages in thread
From: Vladimir Zapolskiy @ 2012-07-31 20:59 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: meta-ti
Hi Denys,
On 31.07.2012 23:16, Denys Dmytriyenko wrote:
> This one got stuck in the moderation queue with all the spam... Just wanted to
> comment on the third option, though.
>
> On Thu, Jul 19, 2012 at 01:31:26PM +0300, Vladimir Zapolskiy wrote:
>> One more option is to fix the patch, either remove store feature of
>> /sys/devices/system/cpu/cpuN/(l2_)?aux_control files or provide
>> -march=armv7-a+sec AFLAGS in Makefile.
>
> FWIW, I previously made a similar fix for this type of issue:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=051482e3b03ba7e2d6cecc0d8f85cc3be22dc8b2
Eventually I verified this alternative and found that it won't work
as expected in this particular case. Here assembly instructions are
ingrained in C code, and after compilation there will be ".arch armv7"
directive in the generated assembly sources, which has precedence
over -march assembler flag. So, the only remaining option is to fix C
code.
But asflags method shall work fine with pure assembly sources like
in your fix.
> But either way it's better to update to a more recent 2.6.37 kernel for AM37x
> anyway, which I'll work on next.
Indeed. Excluding two problematic (and IMO useless and potentially
destructive) patches may be a good immediate measure to restore the
builds, but it's up to you to disable them or not. Having support
of the boards in 2.6.37 is the best option for sure.
With best wishes,
Vladimir
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-07-31 20:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-19 10:31 linux-omap-psp and security code Vladimir Zapolskiy
2012-07-31 20:16 ` Denys Dmytriyenko
2012-07-31 20:59 ` Vladimir Zapolskiy
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.