On Tue, 25 Nov 2014, Vasileios Kalintiris wrote:
> Add mips2-generic among CPU definitions for MIPS.
>
> Signed-off-by: Vasileios Kalintiris <vasileios.kalinti...@imgtec.com>
> ---
> target-mips/translate_init.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
> index 148b394..d4b1cd8 100644
> --- a/target-mips/translate_init.c
> +++ b/target-mips/translate_init.c
> @@ -108,6 +108,29 @@ struct mips_def_t {
> static const mips_def_t mips_defs[] =
> {
> {
> + /* A generic CPU providing MIPS-II features.
> + FIXME: Eventually this should be replaced by a real CPU model. */
Umm, this comment is wishful thinking I am afraid, getting a real MIPS II
processor emulated, i.e. the R6000, will be quite a challenge.
For one COP0 is completely different to anything else, in particular as
far as the MMU and the cache are concerned. Plus we don't know the
opcodes for some instructions, e.g. the R6000-specific LD and SD
operations, implemented analogously to LDC1 and SDC1; their opcodes might
be just the same as MIPS III+ LD/SD (which should be safe for user
software as in 32-bit user mode they'd trap on MIPS III+ processors such
as the R4000, etc.), but I wouldn't bet on it. Likewise all the cache
maintenance instructions.
To the best of my knowledge there wasn't any other plain MIPS II
implementation that might be easier to emulate. LSI's TinyRISC processors
were close, but lacked the LL and SC instructions (TR4101 didn't have SYNC
either). OTOH they had the MIPS16 ASE implemented; the original version
that is of course, i.e. no compact jumps, SAVE/RESTORE, etc. They had no
FPU either -- a COP1 interface was available and an FPU chip apparently
planned, but never implemented.
All the other 32-bit pieces of the era were AFAIK more of MIPS I than
MIPS II implementations. That in particular includes IDT and Toshiba
gear. Maybe I have missed something and someone can speak out who knows
better what was available around mid 1990s though.
> + .name = "mips2-generic",
> + .CP0_PRid = 0x00018000,
You need to set CP0.PRId such that CompanyID is 0, meaning a legacy
processor, or otherwise software will become confused. In the R6000 the
actual value was, according to Linux sources, 0x00000300, the same as in
the R3000A. I am not actually sure how the two quite different processors
could be told apart, perhaps poking at another CP0 register would do.
> + .CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 << CP0C0_MT),
> + .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (15 << CP0C1_MMU) |
> + (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
> + (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA) |
> + (0 << CP0C1_CA),
> + .CP0_Config2 = MIPS_CONFIG2,
> + .CP0_Config3 = MIPS_CONFIG3,
Likewise, these aren't right, there were no CP0 Config registers on the
R6000, the cache subsystem was completely different. I realise some of
these bits are fake for internal use, but the rest should best be cleared,
they can only confuse the reader.
> + .CP0_LLAddr_rw_bitmask = 0,
> + .CP0_LLAddr_shift = 4,
> + .SYNCI_Step = 32,
> + .CCRes = 2,
> + .CP0_Status_rw_bitmask = 0x30000011,
> + .CP1_fcr0 = (1 << FCR0_W) | (1 << FCR0_D) | (1 << FCR0_S),
This isn't right, for a MIPS II processor CP1.FIR will have these bits
clear and the Implementation/Revision fields set to a non-zero value to
let software probe for the presence of the FPU.
> + .SEGBITS = 32,
> + .PABITS = 32,
> + .insn_flags = CPU_MIPS2,
> + .mmu_type = MMU_TYPE_R4000,
> + },
Yeah, as I say the MMU type isn't really right. Mind that these
processors used RFE rather than ERET for exception return too, to reflect
a different exception model (the same as with MIPS I) and consequently
layout of the CP0.Status register; all of which to be taken into account
for a MIPS II processor as well.
What do you really need this processor template for and how do you
propose to use it? Is it worth including one upstream that diverges so
much from what the actual processor was like? Is it for the user
emulation mode only?
Maciej
