diff mbox

ARM v4t support

Message ID 20091127111731.GA11982@kyllikki.org
State New
Headers show

Commit Message

Vincent Sanders Nov. 27, 2009, 11:17 a.m. UTC
I appear to be unable to take a hint, your silence on this patch in
the past probably ought to have been a clue. however this will be the
last time I bother to try and get anything merged so you wont have to
be disturbed again.

The attached patch adds V4t support to the ARM emulation, its pretty
much the same as the last time it was posted. It is correct in
everything it does to the best of my knowledge however you will as
usual no doubt find a corner case it does not cover and reject it.

---

From 5a242e7cdc76c654d599b482cc85ec5bd85e36a3 Mon Sep 17 00:00:00 2001
From: Vincent Sanders <vince@kyllikki.org>
Date: Fri, 29 May 2009 13:41:16 +0100
Subject: [PATCH] Update ARM emulation to include version 4t.

Update ARM emulation to be version 4t by default and add v5 as a
feature. Implementation is very similar to the way the v6 features are
presented.

The affected instructions and program counter load behaviour are made
CPU version dependant and the ARM920T cpu id is introduced.

Signed-off-by: Vincent Sanders <vince@simtec.co.uk>
---
 target-arm/cpu.h       |    2 ++
 target-arm/helper.c    |   16 ++++++++++++++++
 target-arm/translate.c |   22 +++++++++++++++-------
 3 files changed, 33 insertions(+), 7 deletions(-)

Comments

Filip Navara Nov. 27, 2009, 11:35 a.m. UTC | #1
On Fri, Nov 27, 2009 at 12:17 PM, Vincent Sanders <vince@kyllikki.org> wrote:
> I appear to be unable to take a hint, your silence on this patch in
> the past probably ought to have been a clue. however this will be the
> last time I bother to try and get anything merged so you wont have to
> be disturbed again.
>
> The attached patch adds V4t support to the ARM emulation, its pretty
> much the same as the last time it was posted. It is correct in
> everything it does to the best of my knowledge however you will as
> usual no doubt find a corner case it does not cover and reject it.

I have already sent more complete patch for ARM7TDMI emulation:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg17205.html
http://patchwork.ozlabs.org/patch/36841/

F.
Marc Andre Tanner Nov. 27, 2009, 1:46 p.m. UTC | #2
Hi,

On Fri, Nov 27, 2009 at 11:17:32AM +0000, Vincent Sanders wrote:
> The affected instructions and program counter load behaviour are made
> CPU version dependant and the ARM920T cpu id is introduced.

It would be nice if qemu had an arm920t cpu selectin option because then
I could do some automated test for Openmoko's GTA02/Freerunner under
emulation.
 
So please merge it with Filip's patch and push it for inclusion.

Thanks,
Marc
Rob Landley Nov. 29, 2009, 7 a.m. UTC | #3
On Friday 27 November 2009 05:35:26 Filip Navara wrote:
> On Fri, Nov 27, 2009 at 12:17 PM, Vincent Sanders <vince@kyllikki.org> 
wrote:
> > I appear to be unable to take a hint, your silence on this patch in
> > the past probably ought to have been a clue. however this will be the
> > last time I bother to try and get anything merged so you wont have to
> > be disturbed again.
> >
> > The attached patch adds V4t support to the ARM emulation, its pretty
> > much the same as the last time it was posted. It is correct in
> > everything it does to the best of my knowledge however you will as
> > usual no doubt find a corner case it does not cover and reject it.
>
> I have already sent more complete patch for ARM7TDMI emulation:
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg17205.html
> http://patchwork.ozlabs.org/patch/36841/

That's a link to an archive that gives you html but not a raw patch.  (Huh, it 
says you sent it to the list but I'm not finding it in my mail folder.  
Rummage, rummage, rummage...  Ah, your original patch was dated December 31 
1969.)

Ok, dug it up, applied it, booted an -M versatilepb kernel built with an 
armv4tl compiler that I'm assured works for real armv4tl hardware, and I get 
no boot messages if I say "-cpu arm7tdmi", but it boots fine if I don't say 
that.

Let's try my armv4l setup (which I've booted on real armv4tl hardware, albeit 
with a different kernel .config but qemu hasn't got a board emulation for the 
Tin Can Tools Hammer, last I checked...)  That's an OABI which doesn't depend 
on the Thumb extensions...

Nope, that's armv4 OABI, and I've tested the output of that compiler on real 
hardware, albeit with a different kernel .config.

Your patch does not work for me.  Is there a kernel .config change I need to do 
for this?  Looking in the kernel kconfig stuff, the only way to select arm7tdmi 
is to disable MMU support.  Is this a nommu processor?  (I know there are 
armv4t processors _with_ mmu...)

What kernel .config, -M, and -cpu and  did you use to test an armv4t system 
image with your patch?

Rob
Filip Navara Nov. 29, 2009, 9:57 a.m. UTC | #4
On Sun, Nov 29, 2009 at 8:00 AM, Rob Landley <rob@landley.net> wrote:
> On Friday 27 November 2009 05:35:26 Filip Navara wrote:
>> On Fri, Nov 27, 2009 at 12:17 PM, Vincent Sanders <vince@kyllikki.org>
> wrote:
>> > I appear to be unable to take a hint, your silence on this patch in
>> > the past probably ought to have been a clue. however this will be the
>> > last time I bother to try and get anything merged so you wont have to
>> > be disturbed again.
>> >
>> > The attached patch adds V4t support to the ARM emulation, its pretty
>> > much the same as the last time it was posted. It is correct in
>> > everything it does to the best of my knowledge however you will as
>> > usual no doubt find a corner case it does not cover and reject it.
>>
>> I have already sent more complete patch for ARM7TDMI emulation:
>>
>> http://www.mail-archive.com/qemu-devel@nongnu.org/msg17205.html
>> http://patchwork.ozlabs.org/patch/36841/
>
> That's a link to an archive that gives you html but not a raw patch.  (Huh, it
> says you sent it to the list but I'm not finding it in my mail folder.
> Rummage, rummage, rummage...  Ah, your original patch was dated December 31
> 1969.)

Yep, a bug in TortoiseGIT that was later fixed.

> Ok, dug it up, applied it, booted an -M versatilepb kernel built with an
> armv4tl compiler that I'm assured works for real armv4tl hardware, and I get
> no boot messages if I say "-cpu arm7tdmi", but it boots fine if I don't say
> that.
>
> Let's try my armv4l setup (which I've booted on real armv4tl hardware, albeit
> with a different kernel .config but qemu hasn't got a board emulation for the
> Tin Can Tools Hammer, last I checked...)  That's an OABI which doesn't depend
> on the Thumb extensions...
>
> Nope, that's armv4 OABI, and I've tested the output of that compiler on real
> hardware, albeit with a different kernel .config.
>
> Your patch does not work for me.  Is there a kernel .config change I need to do
> for this?  Looking in the kernel kconfig stuff, the only way to select arm7tdmi
> is to disable MMU support.  Is this a nommu processor?  (I know there are
> armv4t processors _with_ mmu...)

It is nommu processor, so I would be surprised to see any of the
kernels running. Unfortunately I don't have a ready-to-use kernel
.config file for it, since I never even tried it with Linux.

> What kernel .config, -M, and -cpu and  did you use to test an armv4t system
> image with your patch?

-M at91pes (which is included in other patches from around the same
time, but was never merged)
-cpu arm7tdmi
the images I used for the test were mostly Atmel examples, FreeRTOS
and other non-Linux systems.

Best regards,
Filip Navara
Rob Landley Nov. 29, 2009, 9:12 p.m. UTC | #5
On Sunday 29 November 2009 03:57:37 Filip Navara wrote:
> On Sun, Nov 29, 2009 at 8:00 AM, Rob Landley <rob@landley.net> wrote:
> > On Friday 27 November 2009 05:35:26 Filip Navara wrote:
> >> On Fri, Nov 27, 2009 at 12:17 PM, Vincent Sanders <vince@kyllikki.org>
> >
> > wrote:
> >> > I appear to be unable to take a hint, your silence on this patch in
> >> > the past probably ought to have been a clue. however this will be the
> >> > last time I bother to try and get anything merged so you wont have to
> >> > be disturbed again.
> >> >
> >> > The attached patch adds V4t support to the ARM emulation, its pretty
> >> > much the same as the last time it was posted. It is correct in
> >> > everything it does to the best of my knowledge however you will as
> >> > usual no doubt find a corner case it does not cover and reject it.
> >>
> >> I have already sent more complete patch for ARM7TDMI emulation:
> >>
> >> http://www.mail-archive.com/qemu-devel@nongnu.org/msg17205.html
> >> http://patchwork.ozlabs.org/patch/36841/
> >
> > That's a link to an archive that gives you html but not a raw patch.
> >  (Huh, it says you sent it to the list but I'm not finding it in my mail
> > folder. Rummage, rummage, rummage...  Ah, your original patch was dated
> > December 31 1969.)
>
> Yep, a bug in TortoiseGIT that was later fixed.
>
> > Ok, dug it up, applied it, booted an -M versatilepb kernel built with an
> > armv4tl compiler that I'm assured works for real armv4tl hardware, and I
> > get no boot messages if I say "-cpu arm7tdmi", but it boots fine if I
> > don't say that.
> >
> > Let's try my armv4l setup (which I've booted on real armv4tl hardware,
> > albeit with a different kernel .config but qemu hasn't got a board
> > emulation for the Tin Can Tools Hammer, last I checked...)  That's an
> > OABI which doesn't depend on the Thumb extensions...
> >
> > Nope, that's armv4 OABI, and I've tested the output of that compiler on
> > real hardware, albeit with a different kernel .config.
> >
> > Your patch does not work for me.  Is there a kernel .config change I need
> > to do for this?  Looking in the kernel kconfig stuff, the only way to
> > select arm7tdmi is to disable MMU support.  Is this a nommu processor?
> >  (I know there are armv4t processors _with_ mmu...)
>
> It is nommu processor, so I would be surprised to see any of the
> kernels running. Unfortunately I don't have a ready-to-use kernel
> .config file for it, since I never even tried it with Linux.

Did you add any armv4t processors with mmu?  I believe the actual hardware I 
tested was an ARM920T.  Vincent's patch claims to add arm920T, I tested yours 
because you claimed it was "more complete".

I guess I should go test vincent's.

> > What kernel .config, -M, and -cpu and  did you use to test an armv4t
> > system image with your patch?
>
> -M at91pes (which is included in other patches from around the same
> time, but was never merged)

"Included in other patches"...  How _many_ other patches?  And how far is 
"around"?

If you'd like to resubmit them as a batch, I can try coming up with a kernel 
.config.  (And a uClibc .config since I haven't actually tried a nommu system 
yet.)

Thanks,

Rob
Filip Navara Nov. 30, 2009, 9:10 a.m. UTC | #6
On Sun, Nov 29, 2009 at 10:12 PM, Rob Landley <rob@landley.net> wrote:
> On Sunday 29 November 2009 03:57:37 Filip Navara wrote:
>> On Sun, Nov 29, 2009 at 8:00 AM, Rob Landley <rob@landley.net> wrote:
>> > On Friday 27 November 2009 05:35:26 Filip Navara wrote:
>> >> On Fri, Nov 27, 2009 at 12:17 PM, Vincent Sanders <vince@kyllikki.org>
>> >
>> > wrote:
>> >> > I appear to be unable to take a hint, your silence on this patch in
>> >> > the past probably ought to have been a clue. however this will be the
>> >> > last time I bother to try and get anything merged so you wont have to
>> >> > be disturbed again.
>> >> >
>> >> > The attached patch adds V4t support to the ARM emulation, its pretty
>> >> > much the same as the last time it was posted. It is correct in
>> >> > everything it does to the best of my knowledge however you will as
>> >> > usual no doubt find a corner case it does not cover and reject it.
>> >>
>> >> I have already sent more complete patch for ARM7TDMI emulation:
>> >>
>> >> http://www.mail-archive.com/qemu-devel@nongnu.org/msg17205.html
>> >> http://patchwork.ozlabs.org/patch/36841/
>> >
>> > That's a link to an archive that gives you html but not a raw patch.
>> >  (Huh, it says you sent it to the list but I'm not finding it in my mail
>> > folder. Rummage, rummage, rummage...  Ah, your original patch was dated
>> > December 31 1969.)
>>
>> Yep, a bug in TortoiseGIT that was later fixed.
>>
>> > Ok, dug it up, applied it, booted an -M versatilepb kernel built with an
>> > armv4tl compiler that I'm assured works for real armv4tl hardware, and I
>> > get no boot messages if I say "-cpu arm7tdmi", but it boots fine if I
>> > don't say that.
>> >
>> > Let's try my armv4l setup (which I've booted on real armv4tl hardware,
>> > albeit with a different kernel .config but qemu hasn't got a board
>> > emulation for the Tin Can Tools Hammer, last I checked...)  That's an
>> > OABI which doesn't depend on the Thumb extensions...
>> >
>> > Nope, that's armv4 OABI, and I've tested the output of that compiler on
>> > real hardware, albeit with a different kernel .config.
>> >
>> > Your patch does not work for me.  Is there a kernel .config change I need
>> > to do for this?  Looking in the kernel kconfig stuff, the only way to
>> > select arm7tdmi is to disable MMU support.  Is this a nommu processor?
>> >  (I know there are armv4t processors _with_ mmu...)
>>
>> It is nommu processor, so I would be surprised to see any of the
>> kernels running. Unfortunately I don't have a ready-to-use kernel
>> .config file for it, since I never even tried it with Linux.
>
> Did you add any armv4t processors with mmu?  I believe the actual hardware I
> tested was an ARM920T.  Vincent's patch claims to add arm920T, I tested yours
> because you claimed it was "more complete".

No, I didn't. My patch is more complete in the underlying ARM V4 bits,
not in the formal definitions of the processor models. Adding ARM920T
is matter of adding these two lines to target-arm/cpu.h (as in
Vincent's patch):

#define ARM_CPUID_ARM920T     0x41129200
{ ARM_CPUID_ARM920T, "arm920t"},

and then adding the processor definition into helper.c:

    case ARM_CPUID_ARM920T:
        set_feature(env, ARM_FEATURE_ABORT_BU);
        set_feature(env, ARM_FEATURE_CP15);
        env->cp15.c0_cachetype = 0x0d172172;
        env->cp15.c1_sys = 0x00000078;
        break;

>
> I guess I should go test vincent's.
>
>> > What kernel .config, -M, and -cpu and  did you use to test an armv4t
>> > system image with your patch?
>>
>> -M at91pes (which is included in other patches from around the same
>> time, but was never merged)
>
> "Included in other patches"...  How _many_ other patches?  And how far is
> "around"?

http://repo.or.cz/w/qemu/navara.git

The repository is desperately in need of rebasing, but I still didn't
find a time to do so.

> If you'd like to resubmit them as a batch, I can try coming up with a kernel
> .config.  (And a uClibc .config since I haven't actually tried a nommu system
> yet.)

I'll resubmit them soon and maybe merge some of the AT91SAM9 work,
including the ARM920T cpu.

Best regards,
Filip Navara
Rob Landley Dec. 1, 2009, 8:15 a.m. UTC | #7
On Friday 27 November 2009 05:17:32 Vincent Sanders wrote:
> I appear to be unable to take a hint, your silence on this patch in
> the past probably ought to have been a clue. however this will be the
> last time I bother to try and get anything merged so you wont have to
> be disturbed again.
>
> The attached patch adds V4t support to the ARM emulation, its pretty
> much the same as the last time it was posted. It is correct in
> everything it does to the best of my knowledge however you will as
> usual no doubt find a corner case it does not cover and reject it.

Confirming: Vincent's patch (this one) works for me.

I booted an armv4tl kernel and root filesystem under -cpu arm920t with this 
patch.

I added "-cpu arm920t" to the qemu command line and switched the kernel .config  
from "CONFIG_CPU_ARM926T=y" to "CONFIG_CPU_ARM920T=y", and it booted when 
built with my armv4tl toolchain from 
http://impactlinux.com/fwl/downloads/binaries/cross-compiler-armv4tl.tar.bz2

Acked-by: Rob Landley <rob@landley.net>

Rob
diff mbox

Patch

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 4a1c53f..6b9a64f 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -334,6 +334,7 @@  enum arm_features {
     ARM_FEATURE_AUXCR,  /* ARM1026 Auxiliary control register.  */
     ARM_FEATURE_XSCALE, /* Intel XScale extensions.  */
     ARM_FEATURE_IWMMXT, /* Intel iwMMXt extension.  */
+    ARM_FEATURE_V5,
     ARM_FEATURE_V6,
     ARM_FEATURE_V6K,
     ARM_FEATURE_V7,
@@ -374,6 +375,7 @@  void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
 #define ARM_CPUID_ARM1026     0x4106a262
 #define ARM_CPUID_ARM926      0x41069265
 #define ARM_CPUID_ARM946      0x41059461
+#define ARM_CPUID_ARM920T     0x41129200
 #define ARM_CPUID_TI915T      0x54029152
 #define ARM_CPUID_TI925T      0x54029252
 #define ARM_CPUID_PXA250      0x69052100
diff --git a/target-arm/helper.c b/target-arm/helper.c
index b3aec99..426c544 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -44,18 +44,25 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
 {
     env->cp15.c0_cpuid = id;
     switch (id) {
+    case ARM_CPUID_ARM920T:
+        env->cp15.c0_cachetype = 0x0d172172;
+        env->cp15.c1_sys = 0x00000078;
+        break;
     case ARM_CPUID_ARM926:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_VFP);
         env->vfp.xregs[ARM_VFP_FPSID] = 0x41011090;
         env->cp15.c0_cachetype = 0x1dd20d2;
         env->cp15.c1_sys = 0x00090078;
         break;
     case ARM_CPUID_ARM946:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_MPU);
         env->cp15.c0_cachetype = 0x0f004006;
         env->cp15.c1_sys = 0x00000078;
         break;
     case ARM_CPUID_ARM1026:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_VFP);
         set_feature(env, ARM_FEATURE_AUXCR);
         env->vfp.xregs[ARM_VFP_FPSID] = 0x410110a0;
@@ -64,6 +71,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         break;
     case ARM_CPUID_ARM1136_R2:
     case ARM_CPUID_ARM1136:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_VFP);
         set_feature(env, ARM_FEATURE_AUXCR);
@@ -75,6 +83,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_cachetype = 0x1dd20d2;
         break;
     case ARM_CPUID_ARM11MPCORE:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_V6K);
         set_feature(env, ARM_FEATURE_VFP);
@@ -87,6 +96,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_cachetype = 0x1dd20d2;
         break;
     case ARM_CPUID_CORTEXA8:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_V6K);
         set_feature(env, ARM_FEATURE_V7);
@@ -129,6 +139,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
         break;
     case ARM_CPUID_CORTEXM3:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_THUMB2);
         set_feature(env, ARM_FEATURE_V7);
@@ -136,6 +147,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         set_feature(env, ARM_FEATURE_DIV);
         break;
     case ARM_CPUID_ANY: /* For userspace emulation.  */
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_V6K);
         set_feature(env, ARM_FEATURE_V7);
@@ -149,6 +161,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         break;
     case ARM_CPUID_TI915T:
     case ARM_CPUID_TI925T:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_OMAPCP);
         env->cp15.c0_cpuid = ARM_CPUID_TI925T; /* Depends on wiring.  */
         env->cp15.c0_cachetype = 0x5109149;
@@ -161,6 +174,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
     case ARM_CPUID_PXA260:
     case ARM_CPUID_PXA261:
     case ARM_CPUID_PXA262:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_XSCALE);
         /* JTAG_ID is ((id << 28) | 0x09265013) */
         env->cp15.c0_cachetype = 0xd172172;
@@ -172,6 +186,7 @@  static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
     case ARM_CPUID_PXA270_B1:
     case ARM_CPUID_PXA270_C0:
     case ARM_CPUID_PXA270_C5:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_XSCALE);
         /* JTAG_ID is ((id << 28) | 0x09265013) */
         set_feature(env, ARM_FEATURE_IWMMXT);
@@ -306,6 +321,7 @@  struct arm_cpu_t {
 };
 
 static const struct arm_cpu_t arm_cpu_names[] = {
+    { ARM_CPUID_ARM920T, "arm920t"},
     { ARM_CPUID_ARM926, "arm926"},
     { ARM_CPUID_ARM946, "arm946"},
     { ARM_CPUID_ARM1026, "arm1026"},
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 45bf772..298cc08 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -34,6 +34,7 @@ 
 #define GEN_HELPER 1
 #include "helpers.h"
 
+#define ENABLE_ARCH_5     arm_feature(env, ARM_FEATURE_V5)
 #define ENABLE_ARCH_5J    0
 #define ENABLE_ARCH_6     arm_feature(env, ARM_FEATURE_V6)
 #define ENABLE_ARCH_6K   arm_feature(env, ARM_FEATURE_V6K)
@@ -6244,7 +6245,7 @@  static void disas_arm_insn(CPUState * env, DisasContext *s)
                 tmp = load_reg(s, rm);
                 gen_bx(s, tmp);
             } else if (op1 == 3) {
-                /* clz */
+                ARCH(5); /* clz */
                 rd = (insn >> 12) & 0xf;
                 tmp = load_reg(s, rm);
                 gen_helper_clz(tmp, tmp);
@@ -6267,14 +6268,15 @@  static void disas_arm_insn(CPUState * env, DisasContext *s)
             if (op1 != 1)
               goto illegal_op;
 
-            /* branch link/exchange thumb (blx) */
+            ARCH(5); /* branch link/exchange thumb (blx) */
             tmp = load_reg(s, rm);
             tmp2 = new_tmp();
             tcg_gen_movi_i32(tmp2, s->pc);
             store_reg(s, 14, tmp2);
             gen_bx(s, tmp);
             break;
-        case 0x5: /* saturating add/subtract */
+        case 0x5:
+            ARCH(5); /* saturating add/subtract */
             rd = (insn >> 12) & 0xf;
             rn = (insn >> 16) & 0xf;
             tmp = load_reg(s, rm);
@@ -6288,16 +6290,18 @@  static void disas_arm_insn(CPUState * env, DisasContext *s)
             dead_tmp(tmp2);
             store_reg(s, rd, tmp);
             break;
-        case 7: /* bkpt */
+        case 7:
+            ARCH(5); /* bkpt */
             gen_set_condexec(s);
             gen_set_pc_im(s->pc - 4);
             gen_exception(EXCP_BKPT);
             s->is_jmp = DISAS_JUMP;
             break;
-        case 0x8: /* signed multiply */
+        case 0x8:
         case 0xa:
         case 0xc:
         case 0xe:
+            ARCH(5); /* signed multiply */
             rs = (insn >> 8) & 0xf;
             rn = (insn >> 12) & 0xf;
             rd = (insn >> 16) & 0xf;
@@ -7076,7 +7080,11 @@  static void disas_arm_insn(CPUState * env, DisasContext *s)
                             /* load */
                             tmp = gen_ld32(addr, IS_USER(s));
                             if (i == 15) {
-                                gen_bx(s, tmp);
+                                if (ENABLE_ARCH_5) {
+                                    gen_bx(s, tmp);
+                                } else {
+                                    store_reg(s, i, tmp);
+                                }
                             } else if (user) {
                                 tmp2 = tcg_const_i32(i);
                                 gen_helper_set_user_reg(tmp2, tmp);
@@ -7345,7 +7353,7 @@  static int disas_thumb2_insn(CPUState *env, DisasContext *s, uint16_t insn_hw1)
         if (insn & (1 << 22)) {
             /* Other load/store, table branch.  */
             if (insn & 0x01200000) {
-                /* Load/store doubleword.  */
+                ARCH(5); /* Load/store doubleword.  */
                 if (rn == 15) {
                     addr = new_tmp();
                     tcg_gen_movi_i32(addr, s->pc & ~3);