| Message ID | 1359098295-10935-1-git-send-email-dantesu@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 25 January 2013 07:18, Kuo-Jung Su <dantesu@gmail.com> wrote: > From: Kuo-Jung Su <dantesu@faraday-tech.com> > > Faraday processors are a series of ARMv4/ARMv5TE clone. > > * ARMv4 series (FA526, FA626). > > All of them are now out-of-date, so I have no plan for them. > > * ARMv5TE series (FA606TE, FA626TE, FA616TE, FA726TE) > > All the single core RISC listed above are included in this patch. > And there are two Faraday CP15 extensions (AUX and I/D-Scratchpad) > have been implemented as a read/write value without any extra actions. I'm going to need pointers to the CPU documentation to be able to review this patch, though it looks mostly ok. One point: you've added new CPU state fields so you must add save and restore code for them in target-arm/machine.c (and increment CPU_SAVE_VERSION in target-arm/cpu.h.) thanks -- PMM
2013/1/25 Peter Maydell <peter.maydell@linaro.org> > On 25 January 2013 07:18, Kuo-Jung Su <dantesu@gmail.com> wrote: > > From: Kuo-Jung Su <dantesu@faraday-tech.com> > > > > Faraday processors are a series of ARMv4/ARMv5TE clone. > > > > * ARMv4 series (FA526, FA626). > > > > All of them are now out-of-date, so I have no plan for them. > > > > * ARMv5TE series (FA606TE, FA626TE, FA616TE, FA726TE) > > > > All the single core RISC listed above are included in this patch. > > And there are two Faraday CP15 extensions (AUX and I/D-Scratchpad) > > have been implemented as a read/write value without any extra > actions. > > I'm going to need pointers to the CPU documentation to be able > to review this patch, though it looks mostly ok. > > One point: you've added new CPU state fields so you must add > save and restore code for them in target-arm/machine.c > (and increment CPU_SAVE_VERSION in target-arm/cpu.h.) > > thanks > -- PMM > I'm afraid that I don't have enough permission to release full version of the cpu datasheets. However I've prepared some partial version with only CP15 and MCU descriptions at my Google Drive: https://docs.google.com/folder/d/0BwfiewvSmUgAalh5TkxyZWtlWEE/edit And thanks for the comments about target-arm/machine.c and target-arm/cpu.h. I don't even know these things shall be updated until you reminded me.
On 25 January 2013 07:18, Kuo-Jung Su <dantesu@gmail.com> wrote: > +static const ARMCPRegInfo faraday_cp_reginfo[] = { > + /* > + * Auxiliary Control Register > + * - Bit 4 STM aligned transfer for AXI > + * - Bit 3 Cache allocation configuration enable > + * - Bit 2 Static branch prediction enable > + * - Bit 1 Dynamic branch prediction enable > + * - Bit 0 Return stack enable > + */ > + { .name = "AUXCTR", .cp = 15, .crn = 1, .crm = 0, > + .opc1 = 0, .opc2 = 1, .access = PL1_RW, .resetvalue = 0x7, > + .fieldoffset = offsetof(CPUARMState, cp15.c15_aux_control) }, This is just an AUXCR in the usual encoding for one; you should use ARM_FEATURE_AUXCR (and set cpu->reset_auxcr in the cpu initfns). > + /* > + * I/D-Scratchpad Configuration Register > + * - Bits[31:10] Scratchpad base address > + * - Bits[5:2] Scratchpad size > + * - Bit 1 Scratchpad self-loading capability > + * - Bit 0 Scratchpad enable > + */ > + { .name = "IDSCFG", .cp = 15, .crn = 9, .crm = 1, > + .opc1 = 0, .opc2 = CP_ANY, .access = PL1_RW, .resetvalue = 0x0, > + .fieldoffset = offsetof(CPUARMState, cp15.c15_ids_config) }, Looking at the documentation you've provided, this encoding doesn't seem to be used on the FA606TE. It only seems to be a scratchpad register for the FA626TE. For the FA616TE and FA726TE it is a TCM config register, and for the FA606TE it doesn't exist at all. (Possibly the "scratchpad" on the 626 is actually a TCM under another name; I didn't look too closely but there seems to be some similarity...) The 726TE datasheet also talks about a c9, c1, 0, 1 encoding for the data TCM config (with c9, c1, 0, 0 being the insn TCM config). This doesn't fit with a CP_ANY value for opc2. It also sounds pretty much like the TCM registers for the ARM926, ARM946 and ARM1026, for instance. I think you need to check to what extent these registers are different between the four cores you're trying to implement, and whether any of them match up with TCM implementations in the standard ARM cores. Where there's a register set shared between ARM and Faraday implementations that probably should have an ARM_FEATURE_TCM flag. Also you should double check which if any cores really have a CP_ANY wildcard decode for opc2: I don't want us to underdecode unless we know the hardware really underdecodes [ie that working guest code fails unless we use CP_ANY]. (Some existing code in qemu uses CP_ANY because we have historically done that and don't have easy ability to check it won't break currently working guests; I would prefer us not to let in new examples without scrutiny, though.) thanks -- PMM
Hi Peter: Thanks for the comments. I'll double if the ARM_FEATURE_TCM is indetical to Faraday's I/D-scrtachpad, , add the missing MPU functions for FT606TE, and avoid using CP_ANY in next patch. Best Wishes Dante 2013/1/28 Peter Maydell <peter.maydell@linaro.org> > On 25 January 2013 07:18, Kuo-Jung Su <dantesu@gmail.com> wrote: > > +static const ARMCPRegInfo faraday_cp_reginfo[] = { > > + /* > > + * Auxiliary Control Register > > + * - Bit 4 STM aligned transfer for AXI > > + * - Bit 3 Cache allocation configuration enable > > + * - Bit 2 Static branch prediction enable > > + * - Bit 1 Dynamic branch prediction enable > > + * - Bit 0 Return stack enable > > + */ > > + { .name = "AUXCTR", .cp = 15, .crn = 1, .crm = 0, > > + .opc1 = 0, .opc2 = 1, .access = PL1_RW, .resetvalue = 0x7, > > + .fieldoffset = offsetof(CPUARMState, cp15.c15_aux_control) }, > > This is just an AUXCR in the usual encoding for one; > you should use ARM_FEATURE_AUXCR (and set cpu->reset_auxcr > in the cpu initfns). > > > + /* > > + * I/D-Scratchpad Configuration Register > > + * - Bits[31:10] Scratchpad base address > > + * - Bits[5:2] Scratchpad size > > + * - Bit 1 Scratchpad self-loading capability > > + * - Bit 0 Scratchpad enable > > + */ > > + { .name = "IDSCFG", .cp = 15, .crn = 9, .crm = 1, > > + .opc1 = 0, .opc2 = CP_ANY, .access = PL1_RW, .resetvalue = 0x0, > > + .fieldoffset = offsetof(CPUARMState, cp15.c15_ids_config) }, > > Looking at the documentation you've provided, this encoding > doesn't seem to be used on the FA606TE. > > It only seems to be a scratchpad register for the FA626TE. > For the FA616TE and FA726TE it is a TCM config register, > and for the FA606TE it doesn't exist at all. (Possibly > the "scratchpad" on the 626 is actually a TCM under another > name; I didn't look too closely but there seems to be some > similarity...) > > The 726TE datasheet also talks about a c9, c1, 0, 1 encoding > for the data TCM config (with c9, c1, 0, 0 being the insn TCM > config). This doesn't fit with a CP_ANY value for opc2. > It also sounds pretty much like the TCM registers for the > ARM926, ARM946 and ARM1026, for instance. > > I think you need to check to what extent these registers > are different between the four cores you're trying to > implement, and whether any of them match up with TCM > implementations in the standard ARM cores. Where there's > a register set shared between ARM and Faraday implementations > that probably should have an ARM_FEATURE_TCM flag. > > Also you should double check which if any cores really > have a CP_ANY wildcard decode for opc2: I don't want > us to underdecode unless we know the hardware really > underdecodes [ie that working guest code fails unless > we use CP_ANY]. (Some existing code in qemu uses CP_ANY > because we have historically done that and don't have > easy ability to check it won't break currently working > guests; I would prefer us not to let in new examples > without scrutiny, though.) > > thanks > -- PMM >
diff --git a/target-arm/cpu.c b/target-arm/cpu.c index 07588a1..5580984 100644 --- a/target-arm/cpu.c +++ b/target-arm/cpu.c @@ -214,6 +214,54 @@ static void arm926_initfn(Object *obj) cpu->reset_sctlr = 0x00090078; } +static void fa606te_initfn(Object *obj) +{ + ARMCPU *cpu = ARM_CPU(obj); + set_feature(&cpu->env, ARM_FEATURE_V5); + set_feature(&cpu->env, ARM_FEATURE_DUMMY_C15_REGS); + set_feature(&cpu->env, ARM_FEATURE_MPU); + set_feature(&cpu->env, ARM_FEATURE_FARADAY); + cpu->midr = 0x66056061; /* CR0-0 Identification Code Register (ID) */ + cpu->ctr = 0x00000000; /* CR0-1 Cache Type Register (CTR) */ + cpu->reset_sctlr = 0x00000078; /* CR1-0 Configuration Register (CFG) */ +} + +static void fa616te_initfn(Object *obj) +{ + ARMCPU *cpu = ARM_CPU(obj); + set_feature(&cpu->env, ARM_FEATURE_V5); + set_feature(&cpu->env, ARM_FEATURE_DUMMY_C15_REGS); + set_feature(&cpu->env, ARM_FEATURE_CACHE_TEST_CLEAN); + set_feature(&cpu->env, ARM_FEATURE_FARADAY); + cpu->midr = 0x66056161; /* CR0-0 Identification Code Register (ID) */ + cpu->ctr = 0x1d152152; /* CR0-1 Cache Type Register (CTR) */ + cpu->reset_sctlr = 0x00050078; /* CR1-0 Configuration Register (CFG) */ +} + +static void fa626te_initfn(Object *obj) +{ + ARMCPU *cpu = ARM_CPU(obj); + set_feature(&cpu->env, ARM_FEATURE_V5); + set_feature(&cpu->env, ARM_FEATURE_DUMMY_C15_REGS); + set_feature(&cpu->env, ARM_FEATURE_CACHE_TEST_CLEAN); + set_feature(&cpu->env, ARM_FEATURE_FARADAY); + cpu->midr = 0x66056261; /* CR0-0 Identification Code Register (ID) */ + cpu->ctr = 0x0f192192; /* CR0-1 Cache Type Register (CTR) */ + cpu->reset_sctlr = 0x00000078; /* CR1-0 Configuration Register (CFG) */ +} + +static void fa726te_initfn(Object *obj) +{ + ARMCPU *cpu = ARM_CPU(obj); + set_feature(&cpu->env, ARM_FEATURE_V5); + set_feature(&cpu->env, ARM_FEATURE_DUMMY_C15_REGS); + set_feature(&cpu->env, ARM_FEATURE_CACHE_TEST_CLEAN); + set_feature(&cpu->env, ARM_FEATURE_FARADAY); + cpu->midr = 0x66057261; /* CR0-0 Identification Code Register (ID) */ + cpu->ctr = 0x1d192192; /* CR0-1 Cache Type Register (CTR) */ + cpu->reset_sctlr = 0x00050078; /* CR1-0 Configuration Register (CFG) */ +} + static void arm946_initfn(Object *obj) { ARMCPU *cpu = ARM_CPU(obj); @@ -726,6 +774,10 @@ typedef struct ARMCPUInfo { static const ARMCPUInfo arm_cpus[] = { { .name = "arm926", .initfn = arm926_initfn }, + { .name = "fa606te", .initfn = fa606te_initfn }, + { .name = "fa616te", .initfn = fa616te_initfn }, + { .name = "fa626te", .initfn = fa626te_initfn }, + { .name = "fa726te", .initfn = fa726te_initfn }, { .name = "arm946", .initfn = arm946_initfn }, { .name = "arm1026", .initfn = arm1026_initfn }, /* What QEMU calls "arm1136-r2" is actually the 1136 r0p2, i.e. an diff --git a/target-arm/cpu.h b/target-arm/cpu.h index ffddfcb..82be02e 100644 --- a/target-arm/cpu.h +++ b/target-arm/cpu.h @@ -152,6 +152,8 @@ typedef struct CPUARMState { uint32_t c15_diagnostic; /* diagnostic register */ uint32_t c15_power_diagnostic; uint32_t c15_power_control; /* power control */ + uint32_t c15_aux_control; /* Faraday auxiliary control */ + uint32_t c15_ids_config; /* Faraday I/D scratchpad config */ } cp15; struct { @@ -391,6 +393,7 @@ enum arm_features { ARM_FEATURE_MPIDR, /* has cp15 MPIDR */ ARM_FEATURE_PXN, /* has Privileged Execute Never bit */ ARM_FEATURE_LPAE, /* has Large Physical Address Extension */ + ARM_FEATURE_FARADAY, /* Faraday extensions */ }; static inline int arm_feature(CPUARMState *env, int feature) diff --git a/target-arm/helper.c b/target-arm/helper.c index 37c34a1..44680f0 100644 --- a/target-arm/helper.c +++ b/target-arm/helper.c @@ -1015,6 +1015,31 @@ static const ARMCPRegInfo lpae_cp_reginfo[] = { REGINFO_SENTINEL }; +static const ARMCPRegInfo faraday_cp_reginfo[] = { + /* + * Auxiliary Control Register + * - Bit 4 STM aligned transfer for AXI + * - Bit 3 Cache allocation configuration enable + * - Bit 2 Static branch prediction enable + * - Bit 1 Dynamic branch prediction enable + * - Bit 0 Return stack enable + */ + { .name = "AUXCTR", .cp = 15, .crn = 1, .crm = 0, + .opc1 = 0, .opc2 = 1, .access = PL1_RW, .resetvalue = 0x7, + .fieldoffset = offsetof(CPUARMState, cp15.c15_aux_control) }, + /* + * I/D-Scratchpad Configuration Register + * - Bits[31:10] Scratchpad base address + * - Bits[5:2] Scratchpad size + * - Bit 1 Scratchpad self-loading capability + * - Bit 0 Scratchpad enable + */ + { .name = "IDSCFG", .cp = 15, .crn = 9, .crm = 1, + .opc1 = 0, .opc2 = CP_ANY, .access = PL1_RW, .resetvalue = 0x0, + .fieldoffset = offsetof(CPUARMState, cp15.c15_ids_config) }, + REGINFO_SENTINEL +}; + static int sctlr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value) { env->cp15.c1_sys = value; @@ -1163,6 +1188,9 @@ void register_cp_regs_for_features(ARMCPU *cpu) if (arm_feature(env, ARM_FEATURE_LPAE)) { define_arm_cp_regs(cpu, lpae_cp_reginfo); } + if (arm_feature(env, ARM_FEATURE_FARADAY)) { + define_arm_cp_regs(cpu, faraday_cp_reginfo); + } /* Slightly awkwardly, the OMAP and StrongARM cores need all of * cp15 crn=0 to be writes-ignored, whereas for other cores they should * be read-only (ie write causes UNDEF exception).