ARM CP14 trivial support
PATCH 1/1 ARM CP14 trivial support
Hi,
Continuing the patch series aiming at supporting Simtec's development boards and other Samsung SoC based systems, attached is a patch which provides trivial coprocessor 14 support.
Regards,
Daniel.
Signature · 2 lines
Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
ARM9 CP14 support
The ARM coprocessor number 14, in part, is responsible for describing CPU features. It is also the interface to the JTAG DCC channel which some systems use to control early-boot-time debugging. All this patch does is provide enough support that reading/writing cp14 won't fault the emulation.
translate.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
=== modified file 'target-arm/translate.c'
translate.c +16 -1
@@ -2643,6 +2643,19 @@return 0 ; } +static int disas_cp14_insn (CPUState *env,DisasContext *s,uint32_t insn) +{ +uint32_t rd = (insn >>12 ) &0xf ; +if (insn & (1 <<20 )) { +gen_op_movl_T0_im (0 ); +gen_movl_reg_T0 (s, rd); + }else { +/* Nothing to do on writes to cp14 */ + } +gen_lookup_tb (s); +return 0 ; +} +#define VFP_REG_SHR (x, n) (((n) > 0) ? (x) >> (n) : (x) << -(n))#define VFP_SREG (insn, bigbit, smallbit) \ ((VFP_REG_SHR(insn, bigbit - 1) & 0x1e) | (((insn) >> (smallbit)) & 1))
@@ -5567,7 +5580,9 @@return 1 ;case 10 :case 11 : -return disas_vfp_insn (env, s, insn); +return disas_vfp_insn (env, s, insn); +case 14 : +return disas_cp14_insn (env, s, insn);case 15 :return disas_cp15_insn (env, s, insn);default :
Quoted 5 lines · Daniel Silverstone
Hi,
Continuing the patch series aiming at supporting Simtec's development boards and other Samsung SoC based systems, attached is a patch which provides trivial coprocessor 14 support.
I dislike code that blindly ignores everything. Functions should be explicitly not implemented (with comments saying exactly what we're not implementing), or fail loudly when used.
The cp14 interface is also used for other debug monitor hardware (breakpoints, watchpoints, etc.) and possibly Jazelle DBX. Ignoring those commands is bad. IIRC cp14 interfaces are device specific (at least before ARMv6), so you need to figure out which cores your hacks apply to. There are definitely several different DDC interfaces.
Paul
2008/10/13 Daniel Silverstone <[email protected]>:
Quoted 3 lines
Continuing the patch series aiming at supporting Simtec's development boards and other Samsung SoC based systems, attached is a patch which provides trivial coprocessor 14 support.
+ case 14:
+ return disas_cp14_insn (env, s, insn);
This will break PXA emulation or anything that already emulates cp14.
Cheers
Quoted 9 lines · andrzej zaborowski
2008/10/13 Daniel Silverstone <[email protected]>:
Quoted 3 lines
Continuing the patch series aiming at supporting Simtec's development boards and other Samsung SoC based systems, attached is a patch which provides trivial coprocessor 14 support.
translate.c +2
-0+case 14 : +return disas_cp14_insn (env, s, insn);This will break PXA emulation or anything that already emulates cp14.
Anything that emulates cp14 should really be doing it here. The pxa coprocessor bits are IMHO a hack.
Paul
2008/10/13 Paul Brook <[email protected]>:
Quoted 6 lines · andrzej zaborowski
Quoted 5 lines
2008/10/13 Daniel Silverstone <[email protected]>:
Quoted 3 lines
Continuing the patch series aiming at supporting Simtec's development boards and other Samsung SoC based systems, attached is a patch which provides trivial coprocessor 14 support.
Quoted 7 lines
Quoted 4 lines
translate.c +2
-0+case 14 : +return disas_cp14_insn (env, s, insn);This will break PXA emulation or anything that already emulates cp14.
Anything that emulates cp14 should really be doing it here. The pxa coprocessor bits are IMHO a hack.
Coprocessor io has similar potential to mmio or x86 port io. You said it's device specific. If in a SoC a peripheral is attached through it, probably the whole peripheral shouldn't be in target-arm/ ?
Regards
Quoted 3 lines
Coprocessor io has similar potential to mmio or x86 port io. You said it's device specific. If in a SoC a peripheral is attached through it, probably the whole peripheral shouldn't be in target-arm/ ?
I disbelieve that any chips use the came coprocessor ID for both core and SoC functionality.
Paul
2008/10/13 Paul Brook <[email protected]>:
Quoted 6 lines
Quoted 3 lines
Coprocessor io has similar potential to mmio or x86 port io. You said it's device specific. If in a SoC a peripheral is attached through it, probably the whole peripheral shouldn't be in target-arm/ ?
I disbelieve that any chips use the came coprocessor ID for both core and SoC functionality.
I'm talking about coprocessor used for SoC only functionality.
Regards