On 25 January 2013 07:18, Kuo-Jung Su <dant...@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
