Make ARM-MIDR a property and use in Zynq

Convert the MIDR register to a property. This allows boards to later set a custom MIDR value. This has been done in such a way to maintain compatibility with all existing CPUs and boards

Signed-off-by Alistair Francis <[email protected]>

---
I originally added the properties to the cpu->midr variable in a similar method to how Peter Crosthwaite did in his 'Fix Support for ARM CBAR and reset-hivecs' series.
V2: Use dc->props to avoid using qdev_*

 target-arm/cpu.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

target-arm/cpu.c +2 -0

index 408d207..52f7f06 100644
@@ -253,6 +253,7 @@ static void arm_cpu_post_init(Object *obj)
 {
     ARMCPU *cpu = ARM_CPU(obj);
     Error *err = NULL;
+    uint32_t temp = cpu->midr;
 
     if (arm_feature(&cpu->env, ARM_FEATURE_CBAR)) {
         qdev_property_add_static(DEVICE(obj), &arm_cpu_reset_cbar_property,

@@ -265,6 +266,17 @@ static void arm_cpu_post_init(Object *obj)
                                  &err);
         assert_no_error(err);
     }
+

target-arm/cpu.c +1 -1

 }
 
 static void arm_cpu_finalizefn(Object *obj)

@@ -984,6 +996,7 @@ static const ARMCPUInfo arm_cpus[] = {
 
 static Property arm_cpu_properties[] = {
     DEFINE_PROP_BOOL("start-powered-off", ARMCPU, start_powered_off, false),
+    DEFINE_PROP_UINT32("midr", ARMCPU, midr, 0),
     DEFINE_PROP_END_OF_LIST()
 };
 
--

1.7.1

Do you even need this now? The normal arrayified dc->props properties are added at device::init time. As TYPE_DEVICE is a parent class, its init function is called before CPUs (normal inits are called in parent->child order, the post_inits are reverse). This means the cpu::init fns should correctly set the device-specific default after device::init, trampling the bogus default defined in the property array.

All of this however assumes that MIDR is unconditionally existent for all ARMCPU. Peter, are you able to confirm that thats ok before we commit to this implementation over the conditional post_init approach?

Quoted 11 lines · Peter Crosthwaite

Do you even need this now? The normal arrayified dc->props properties are added at device::init time. As TYPE_DEVICE is a parent class, its init function is called before CPUs (normal inits are called in parent->child order, the post_inits are reverse). This means the cpu::init fns should correctly set the device-specific default after device::init, trampling the bogus default defined in the property array.

All of this however assumes that MIDR is unconditionally existent for all ARMCPU. Peter, are you able to confirm that thats ok before we commit to this implementation over the conditional post_init approach?

IIRC ARMv4 and earlier didn't define the MIDR, but we don't actually emulate any of those. In general, my intent with all these constant fields in the ARMCPU struct was that we'd end up making them just properties available on all ARMCPU objects, and if the particular subtype of ARMCPU happened not to have FP and so didn't need the reset_fpsid, for example, it would just ignore whatever value you set the property to. I don't think we need to tie ourselves in knots to restrict the properties to particular CPUs if it is too implementationally awkward (though it would be nice if we can tie them to ARM_FEATURE_* bits for more or less free).

thanks
-- PMM

Quoted 11 lines · Peter Maydell

IIRC ARMv4 and earlier didn't define the MIDR, but we don't actually emulate any of those. In general, my intent with all these constant fields in the ARMCPU struct was that we'd end up making them just properties available on all ARMCPU objects, and if the particular subtype of ARMCPU happened not to have FP and so didn't need the reset_fpsid, for example, it would just ignore whatever value you set the property to. I don't think we need to tie ourselves in knots to restrict the properties to particular CPUs if it is too implementationally awkward (though it would be nice if we can tie them to ARM_FEATURE_* bits for more or less free).

ARM_FEATURE_V5 exists. Will that do the job? That will exclude just the V4T AFAICT. Worth bothering?

Quoted 14 lines · Peter Crosthwaite

Quoted 11 lines · Peter Maydell

IIRC ARMv4 and earlier didn't define the MIDR, but we don't actually emulate any of those. In general, my intent with all these constant fields in the ARMCPU struct was that we'd end up making them just properties available on all ARMCPU objects, and if the particular subtype of ARMCPU happened not to have FP and so didn't need the reset_fpsid, for example, it would just ignore whatever value you set the property to. I don't think we need to tie ourselves in knots to restrict the properties to particular CPUs if it is too implementationally awkward (though it would be nice if we can tie them to ARM_FEATURE_* bits for more or less free).

Quoted 2 lines

ARM_FEATURE_V5 exists. Will that do the job? That will exclude just the V4T AFAICT. Worth bothering?

Probably not for MIDR, I think, though maybe for some of the others we might like to.

thanks
-- PMM