From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness
Date: Tue, 16 Oct 2012 13:49:56 +0100 [thread overview]
Message-ID: <20121016124956.GC26075@linaro.org> (raw)
In-Reply-To: <CAKw8HL154a=K9O7CzPFZ-EqtT+BxYU-uRHodtutdRfYmNpWVww@mail.gmail.com>
On Mon, Oct 15, 2012 at 11:33:08PM +0800, Fei Yang wrote:
> 2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
> > Yangfei (Felix) writes:
> > > Hi all,
> > >
> > > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
> > > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
> > > / *
> > > * here's the WFI
> > > */
> > > asm(".word 0xe320f003\n"
> > > :
> > > :
> > > : "memory", "cc");
> > >
> > > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
> > >
> > > Here the code should be:
> > > / *
> > > * here's the WFI
> > > */
> > > asm("WFI\n"
> > > :
> > > :
> > > : "memory", "cc");
> > >
> > > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
> > > Can anyone tell me who owns this part? I can prepare a patch then.
> > > Thanks.
> >
> > Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
> > (see the MAINTAINERS file), with an optional cc: to the regular LKML.
> >
> > BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
> > different endianess. GAS supports an ".inst" directive which is like ".word"
> > except the data is assumed to be code. This matters for disassembly, and may
> > also be required for BE-8.
> >
> > That is, just s/.word/.inst/g above and report back if that works or not.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>
> Hi Mikael,
>
> Thanks for the reply. I modified the code as suggested and rebuilt the
> kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
> platform.
> Since the ARM core can be configured by system software to work in
> big-endian mode, it's necessary to fix this problem. And here is a
> small patch :
>
> diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
> linux/arch/arm/mach-exynos/hotplug.c
> --- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
> @@ -72,7 +72,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
The cleanest fix would simply be to build these files with appropriate
modified CFLAGS (-march=armv6k or -march=armv7-a), and use the proper
"wfi" mnemonic.
Failing that, you could use the facilities in <asm/opcodes.h> to
declare a wrapper macro for injecting this opcode (see
<asm/opcodes-virt.h> for an example). However, putting custom
opcodes into the assembler should only be done if it's really
necessary. Nowadays, I think we can consider tools which don't
understand the WFI mnemonic to be obsolete, at least for platforms
which only build for v7 and above.
The relevant board maintainers would need to sign off on such a
change, so we don't end up breaking their builds.
If any of these boards needs to build for v6K, the custom opcode might
be worth it -- some people might just possibly be relying on older tools
for such platforms.
Cheers
---Dave
> :
> :
> : "memory", "cc");
> diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
> linux/arch/arm/mach-realview/hotplug.c
> --- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
> @@ -66,7 +66,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
> :
> :
> : "memory", "cc");
> diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
> linux/arch/arm/mach-shmobile/hotplug.c
> --- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
> @@ -53,7 +53,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
> :
> :
> : "memory", "cc");
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2012-10-16 12:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <DA41BE1DDCA941489001C7FBD7A8820E3CB407A4@szxeml549-mbx.china.huawei.com>
[not found] ` <20603.47887.262025.941051@pilspetsen.it.uu.se>
2012-10-15 10:30 ` 答复: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness Yangfei (Felix)
2012-10-15 15:33 ` [PATCH] " Fei Yang
2012-10-16 12:49 ` Dave Martin [this message]
2012-10-16 16:33 ` Fei Yang
2012-10-16 17:25 ` Dave Martin
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=20121016124956.GC26075@linaro.org \
--to=dave.martin@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).