On 9 April 2014 18:01, Russell King - ARM Linux wrote:
> It would be useful to see the register state from the undefined
> instruction exception. That needs this patch, CONFIG_DEBUG_USER in the
> kernel config enabled, and user_debug=1 passed on the kernel command
> line.
I have done two tests,
On Wed, Apr 09, 2014 at 05:50:57PM +0200, Arnd Bergmann wrote:
> On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote:
> > If it's called from ARM code, then \reg will contain a 4-byte aligned
> > address. If it's called from Thumb code, \reg will contain a 2-byte
> > aligned address
On Wednesday 09 April 2014 16:27:11 Russell King - ARM Linux wrote:
> On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote:
> > On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote:
> > > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > > > On 13 Dec
On Wed, Apr 09, 2014 at 05:13:26PM +0200, Uwe Kleine-König wrote:
> Hello Russell,
>
> On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > > On 13 December 2013 12:39, Russell King - ARM Linux
> > > wrote:
Hello Russell,
On Wed, Apr 09, 2014 at 04:06:40PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > On 13 December 2013 12:39, Russell King - ARM Linux
> > wrote:
> > > I see what's causing this: the kuser helpers are using "bx lr" to retur
On Wed, Apr 09, 2014 at 05:04:48PM +0200, Uwe Kleine-König wrote:
> On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> > On 13 December 2013 12:39, Russell King - ARM Linux
> > wrote:
> > > I see what's causing this: the kuser helpers are using "bx lr" to return
> > > which will be un
On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> On 13 December 2013 12:39, Russell King - ARM Linux
> wrote:
> > I see what's causing this: the kuser helpers are using "bx lr" to return
> > which will be undefined on non-Thumb CPUs. We generally cope fine with
> > non-Thumb CPUs,
On Wed, Apr 09, 2014 at 04:54:16PM +0200, Jonas Jensen wrote:
> On 13 December 2013 12:39, Russell King - ARM Linux
> wrote:
> > I see what's causing this: the kuser helpers are using "bx lr" to return
> > which will be undefined on non-Thumb CPUs. We generally cope fine with
> > non-Thumb CPUs,
On 13 December 2013 12:39, Russell King - ARM Linux
wrote:
> I see what's causing this: the kuser helpers are using "bx lr" to return
> which will be undefined on non-Thumb CPUs. We generally cope fine with
> non-Thumb CPUs, conditionalising where necessary on HWCAP_THUMB or the
> T bit in the PS
Boots without panic when bx is removed.
Diff and boot log:
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index b3fb8c9..ad736b3 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -737,8 +737,8 @@ ENDPROC(__switch_to)
.macro usr_ret
On Fri, Dec 13, 2013 at 11:51:09AM +0100, Jonas Jensen wrote:
> On 13 December 2013 10:56, Russell King - ARM Linux
> wrote:
> > So, having these symbols enabled (provided the right ones for FA526 are
> > also enabled) makes no difference. So I don't buy your explanation.
>
> The explanation is
On 13 December 2013 10:56, Russell King - ARM Linux
wrote:
> So, having these symbols enabled (provided the right ones for FA526 are
> also enabled) makes no difference. So I don't buy your explanation.
The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just fine.
That's not wh
On Fri, Dec 13, 2013 at 09:09:09AM +0100, Jonas Jensen wrote:
> CPU_FA526 lacks thumb state support and doesn't get along with some
> of the options enabled by ARCH_MULTI_V4T.
>
> More specifically it doesn't get along with CPU_ARM920T:
>
> CPU_ABRT_EV4T
> CPU_CACHE_V4WT
> CPU_COPY_V4WB
> CPU_TLB
13 matches
Mail list logo
