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.mayd...@linaro.org>
> 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
>
--
Best wishes,
Kuo-Jung Su
