On 19/06/2014 23:16, Aurelien Jarno wrote:
> On Wed, Jun 11, 2014 at 04:19:52PM +0100, Leon Alrae wrote:
>> Signed-off-by: Leon Alrae <leon.al...@imgtec.com>
>> ---
>> target-mips/translate_init.c | 29 +++++++++++++++++++++++++++++
>> 1 files changed, 29 insertions(+), 0 deletions(-)
>>
>> diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
>> index 29dc2ef..0adbb19 100644
>> --- a/target-mips/translate_init.c
>> +++ b/target-mips/translate_init.c
>> @@ -516,6 +516,35 @@ static const mips_def_t mips_defs[] =
>> .mmu_type = MMU_TYPE_R4000,
>> },
>> {
>> + /* A generic CPU providing MIPS64 Release 6 features.
>> + FIXME: Eventually this should be replaced by a real CPU model. */
>> + .name = "MIPS64R6-generic",
>> + .CP0_PRid = 0x00010000,
>> + .CP0_Config0 = MIPS_CONFIG0 | (0x2 << CP0C0_AR) | (0x2 << CP0C0_AT)
>> |
>> + (MMU_TYPE_R4000 << CP0C0_MT),
>> + .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (63 << CP0C1_MMU) |
>> + (2 << CP0C1_IS) | (4 << CP0C1_IL) | (3 << CP0C1_IA) |
>> + (2 << CP0C1_DS) | (4 << CP0C1_DL) | (3 << CP0C1_DA) |
>> + (0 << CP0C1_PC) | (1 << CP0C1_WR) | (1 << CP0C1_EP),
>> + .CP0_Config2 = MIPS_CONFIG2,
>> + .CP0_Config3 = MIPS_CONFIG3,
>> + .CP0_LLAddr_rw_bitmask = 0,
>> + .CP0_LLAddr_shift = 0,
>> + .SYNCI_Step = 32,
>> + .CCRes = 2,
>> + .CP0_Status_rw_bitmask = 0x30D8FFFF,
>> + .CP1_fcr0 = (1 << FCR0_F64) | (1 << FCR0_L) | (1 << FCR0_W) |
>> + (1 << FCR0_D) | (1 << FCR0_S) | (0x00 << FCR0_PRID) |
>> + (0x0 << FCR0_REV),
>> + .SEGBITS = 42,
>> + /* The architectural limit is 59, but we have hardcoded 36 bit
>> + in some places...
>> + .PABITS = 59, */ /* the architectural limit */
>> + .PABITS = 36,
>> + .insn_flags = CPU_MIPS64R6,
>> + .mmu_type = MMU_TYPE_R4000,
>> + },
>> + {
>> .name = "Loongson-2E",
>> .CP0_PRid = 0x6302,
>> /*64KB I-cache and d-cache. 4 way with 32 bit cache line size*/
>
> Sorry to say that again, but I think it should be deferred to the point
> where the MIPS R6 CPU is fully functional, so probably after the
> "implement features required in MIPS64 Release 6", and probably even
> more, as I haven't seen any patch concerning the unaligned access
> support yet.
It will take some time before MIPS R6 CPU becomes fully functional. With
the current patchset QEMU should be able to run R6 binaries in userland
emulation mode where we don't care about KScratch, TLBINV etc. Thus I
think having available MIPS R6 CPU might be handy at this point (even
though there are limitations regarding unaligned access or forbidden
slot support).
Regards,
Leon
