From: Joel Fernandes <joelf@ti.com>
To: Dave Martin <Dave.Martin@arm.com>, Joel Fernandes <agnel.joel@gmail.com>
Cc: Nishanth Menon <nm@ti.com>, Russell King <linux@arm.linux.org.uk>,
Tony Lindgren <tony@atomide.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Linux OMAP List <linux-omap@vger.kernel.org>,
Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
Date: Tue, 29 Apr 2014 21:55:38 -0500 [thread overview]
Message-ID: <5360662A.50106@ti.com> (raw)
In-Reply-To: <20140429183131.GF3582@e103592.cambridge.arm.com>
On 04/29/2014 01:31 PM, Dave Martin wrote:
> On Tue, Apr 29, 2014 at 05:36:30PM +0100, Joel Fernandes wrote:
>
> [...]
>
>>>> Sorry what I meant is, say its of Type function. What tells the firmware
>>>> to switch to THUMB?
>>>>
>>>> What's typically done is a boot address register is written by the
>>>> kernel, and the firmware jumps to it after WFE.
>>>
>>> Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker
>>> for x to have the Thumb bit set if the code is Thumb.
>>>
>>> This means that any reference the linker fixes up for that symbol
>>> will have the Thumb bit set appropriately. This applies to any kind
>>> of reference, so code in another file that takes the address of the
>>> symbol and then passes that address to the firmware should result in the
>>> firmware getting an address with the Thumb bit.
>>>
>>> From the firmware's point of view it just gets a raw address, but
>>> the Thumb bit will now be set. The firmware still needs to handle
>>> this correctly when jumping, but from the look of the code this may
>>> already work on omap3/4. It would be interesting to know whether it
>>> works on omap5.
>>
>> Thanks a lot for the explanation. That makes perfect sense. I will try it and let you know if it works on OMAP5.
>
> ARM/thumb interworking making perfect sense? I'll have to frame that
> and put it on the wall :)
>
> objdump and nm conveniently mask off the Thumb bit from all function
> addresses they print out, but if you show the symbols using readelf
> instead you'll see addresses with bit 0 set for Thumb functions.
>
> It's possible that the firmware still doesn't handle branching to Thumb
> correctly, but if it does it would be nice to remove the requirement to
> build an odd piece of a Thumb-2 kernel in ARM.
Sure, it works great! thanks, I sent out a patch that applies on top of
the first one. Thanks for spotting it.
Regards,
-Joel
WARNING: multiple messages have this Message-ID (diff)
From: joelf@ti.com (Joel Fernandes)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
Date: Tue, 29 Apr 2014 21:55:38 -0500 [thread overview]
Message-ID: <5360662A.50106@ti.com> (raw)
In-Reply-To: <20140429183131.GF3582@e103592.cambridge.arm.com>
On 04/29/2014 01:31 PM, Dave Martin wrote:
> On Tue, Apr 29, 2014 at 05:36:30PM +0100, Joel Fernandes wrote:
>
> [...]
>
>>>> Sorry what I meant is, say its of Type function. What tells the firmware
>>>> to switch to THUMB?
>>>>
>>>> What's typically done is a boot address register is written by the
>>>> kernel, and the firmware jumps to it after WFE.
>>>
>>> Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker
>>> for x to have the Thumb bit set if the code is Thumb.
>>>
>>> This means that any reference the linker fixes up for that symbol
>>> will have the Thumb bit set appropriately. This applies to any kind
>>> of reference, so code in another file that takes the address of the
>>> symbol and then passes that address to the firmware should result in the
>>> firmware getting an address with the Thumb bit.
>>>
>>> From the firmware's point of view it just gets a raw address, but
>>> the Thumb bit will now be set. The firmware still needs to handle
>>> this correctly when jumping, but from the look of the code this may
>>> already work on omap3/4. It would be interesting to know whether it
>>> works on omap5.
>>
>> Thanks a lot for the explanation. That makes perfect sense. I will try it and let you know if it works on OMAP5.
>
> ARM/thumb interworking making perfect sense? I'll have to frame that
> and put it on the wall :)
>
> objdump and nm conveniently mask off the Thumb bit from all function
> addresses they print out, but if you show the symbols using readelf
> instead you'll see addresses with bit 0 set for Thumb functions.
>
> It's possible that the firmware still doesn't handle branching to Thumb
> correctly, but if it does it would be nice to remove the requirement to
> build an odd piece of a Thumb-2 kernel in ARM.
Sure, it works great! thanks, I sent out a patch that applies on top of
the first one. Thanks for spotting it.
Regards,
-Joel
next prev parent reply other threads:[~2014-04-30 2:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 18:31 [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU Joel Fernandes
2014-04-22 18:31 ` Joel Fernandes
2014-04-22 18:39 ` Santosh Shilimkar
2014-04-22 18:39 ` Santosh Shilimkar
2014-04-22 18:47 ` Nishanth Menon
2014-04-22 18:47 ` Nishanth Menon
2014-04-22 19:39 ` Joel Fernandes
2014-04-22 19:39 ` Joel Fernandes
2014-04-28 16:43 ` Dave Martin
2014-04-28 16:43 ` Dave Martin
2014-04-28 16:43 ` Dave Martin
2014-04-28 17:20 ` Joel Fernandes
2014-04-28 17:20 ` Joel Fernandes
2014-04-28 17:20 ` Joel Fernandes
2014-04-28 17:21 ` Joel Fernandes
2014-04-28 17:21 ` Joel Fernandes
2014-04-28 17:21 ` Joel Fernandes
2014-04-29 9:17 ` Dave Martin
2014-04-29 9:17 ` Dave Martin
2014-04-29 16:36 ` Joel Fernandes
2014-04-29 16:36 ` Joel Fernandes
2014-04-29 18:31 ` Dave Martin
2014-04-29 18:31 ` Dave Martin
2014-04-30 2:55 ` Joel Fernandes [this message]
2014-04-30 2:55 ` Joel Fernandes
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=5360662A.50106@ti.com \
--to=joelf@ti.com \
--cc=Dave.Martin@arm.com \
--cc=agnel.joel@gmail.com \
--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=santosh.shilimkar@ti.com \
--cc=tony@atomide.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.