Hi Alex, On Thu, Sep 3, 2026 at 10:48 PM Alex Bennée <[email protected]> wrote: > > Bin Meng <[email protected]> writes: > > > The Phytium E2000Q combines two FTC310 cores and two FTC664 cores. > > Its EL3 firmware accesses implementation-defined system registers > > while setting up the cores. Using generic Cortex-A72 CPUs leaves > > these registers undefined and traps firmware before it can reach > > U-Boot. > > > > Add FTC310 and FTC664 CPU types using Cortex-A72 as their common > > execution base. Provide conservative RAZ/WI and NOP stubs for the > > firmware-visible E2000 controls that have no modeled behavior. > > > > Set each CPU DT compatible string, MIDR, instruction feature fields, > > AArch32 floating-point feature fields, and CTR_EL0.L1Ip field to > > values observed on an E2000Q board. The FTC310 reports a VIPT > > instruction cache, while the FTC664 reports a PIPT instruction cache. > > > > Signed-off-by: Bin Meng <[email protected]> > > --- > > > > target/arm/tcg/cpu64.c | 81 > > ++++++++++++++++++++++++++++++++++++++++++ > > I wonder if cpu64 is the best place to model this? The alternative is to > treat it like other SoCs (e.g. the Pi's BCM SoCs). Was the reason it > ended up here because you needed access to aarch64_a72_initfn? Could you > not instantiate: > > soc_base->cpu_type = ARM_CPU_TYPE_NAME("cortex-a72"); > > and then at realize: > > object_initialize_child(OBJECT(dev), "cpu[*]", &s->cpu[n].core, > soc_base->cpu_type); > > or does that not allow for tweaking the CP regs? >
I followed your advice and that worked like a charm. Will move the Phytium-specific CPU type in the SoC/machine codes in v2. > > > 1 file changed, 81 insertions(+) > > > > diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c > > index affd87a3ae..0fd2f79bbc 100644 > > --- a/target/arm/tcg/cpu64.c > > +++ b/target/arm/tcg/cpu64.c > > @@ -336,6 +336,85 @@ static void aarch64_a72_initfn(Object *obj) > > define_cortex_a72_a57_a53_cp_reginfo(cpu); > > } > > Regards, Bin
