diff options
| author | Helge Deller <deller@gmx.de> | 2020-08-30 15:35:07 +0200 |
|---|---|---|
| committer | Helge Deller <deller@gmx.de> | 2020-09-02 23:16:57 +0200 |
| commit | 3b65b742543bc6c2ad35e3b42401a26b48a87f26 (patch) | |
| tree | eabd17f33430196feff6f40704dc5462d82088c6 /target/hppa | |
| parent | b28c4a64973418a34cc0373a7462c64297aff623 (diff) | |
| download | qemu-3b65b742543bc6c2ad35e3b42401a26b48a87f26.zip qemu-3b65b742543bc6c2ad35e3b42401a26b48a87f26.tar.gz qemu-3b65b742543bc6c2ad35e3b42401a26b48a87f26.tar.bz2 | |
target/hppa: Fix boot with old Linux installation CDs
The current qemu hppa emulation emulates a PA1.1 CPU, which can only execute
the 32-bit instruction set. For unknown 64-bit instructions, a instruction trap
is sent to the virtual CPU.
This behaviour is correct in the sense that we emulate what the PA1.1
specification says.
But when trying to boot older Linux installation images, e.g.
ftp://parisc.parisc-linux.org/debian-cd/debian-5.0/lenny-5.0.10-hppa-iso-cd/cdimage.debian.org/debian-5010-hppa-netinst.iso
one finds that qemu fails to boot those images.
The problem is, that in the Linux kernel (e.g. 2.6.26) of those old images
64-bit instructions were used by mistake in the fault handlers. The relevant
instructions (the ",*" indicates that it's a 64-bit instruction) I see are:
0: 09 3e 04 29 sub,* sp,r9,r9
0: 08 3d 06 3d add,* ret1,r1,ret1
0: 0a 09 02 61 or,* r9,r16,r1
0: 0a ba 00 3a andcm,* r26,r21,r26
0: 08 33 02 33 and,* r19,r1,r19
The interesting part is, that real physical 32-bit machines (like the 700/64
and B160L - which is the one we emulate) do boot those images and thus seem to
simply ignore the 64-bit flag on those instructions.
The patch below modifies the qemu instruction decoder to ignore the 64-bit flag
too - which is what real 32-bit hardware seems to do. With this modification
qemu now successfully boots those older images too.
I suggest to apply the patch below - even if it does not reflect what the SPEC
says. Instead it increases the compatibility to really existing hardware and
seem to not create problems if we add real PA2.0 support anytime later.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Diffstat (limited to 'target/hppa')
| -rw-r--r-- | target/hppa/insns.decode | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/target/hppa/insns.decode b/target/hppa/insns.decode index f0dd71d..dceaad6 100644 --- a/target/hppa/insns.decode +++ b/target/hppa/insns.decode @@ -149,9 +149,9 @@ lci 000001 ----- ----- -- 01001100 0 t:5 # Arith/Log #### -andcm 000010 ..... ..... .... 000000 0 ..... @rrr_cf -and 000010 ..... ..... .... 001000 0 ..... @rrr_cf -or 000010 ..... ..... .... 001001 0 ..... @rrr_cf +andcm 000010 ..... ..... .... 000000 - ..... @rrr_cf +and 000010 ..... ..... .... 001000 - ..... @rrr_cf +or 000010 ..... ..... .... 001001 - ..... @rrr_cf xor 000010 ..... ..... .... 001010 0 ..... @rrr_cf uxor 000010 ..... ..... .... 001110 0 ..... @rrr_cf ds 000010 ..... ..... .... 010001 0 ..... @rrr_cf @@ -161,13 +161,13 @@ uaddcm_tc 000010 ..... ..... .... 100111 0 ..... @rrr_cf dcor 000010 ..... 00000 .... 101110 0 ..... @rr_cf dcor_i 000010 ..... 00000 .... 101111 0 ..... @rr_cf -add 000010 ..... ..... .... 0110.. 0 ..... @rrr_cf_sh +add 000010 ..... ..... .... 0110.. - ..... @rrr_cf_sh add_l 000010 ..... ..... .... 1010.. 0 ..... @rrr_cf_sh add_tsv 000010 ..... ..... .... 1110.. 0 ..... @rrr_cf_sh add_c 000010 ..... ..... .... 011100 0 ..... @rrr_cf_sh0 add_c_tsv 000010 ..... ..... .... 111100 0 ..... @rrr_cf_sh0 -sub 000010 ..... ..... .... 010000 0 ..... @rrr_cf +sub 000010 ..... ..... .... 010000 - ..... @rrr_cf sub_tsv 000010 ..... ..... .... 110000 0 ..... @rrr_cf sub_tc 000010 ..... ..... .... 010011 0 ..... @rrr_cf sub_tsv_tc 000010 ..... ..... .... 110011 0 ..... @rrr_cf |