Hi,
This series is a step toward having a single qemu-system-aarch64
binary for both ARM and Aarch64 variants.
First we add the TypeInfo::can_register() handler to QOM, to be
able to decide at runtime if a type can be registered. We'll
later use the target_aarch64_available() method to restrict some
QOM types to the aarch64 build.
Then few cleanups allow us to build the Raspi machines and its
components as target-agnostic. To do that, instead of embedding
a CPUState in its SoC container, we use a pointer to it. Since
the type is forward-declared by "cpu-qom.h", we can use that in
our hw/ headers. Then the correct CPU is instanciated by calling
object_new() instead of object_initialize_child().
Finally objects are moved to meson system_ss[] source set to be
built once.
Does that look reasonable to keep merging TARGET_ARM/AARCH64?
Thanks,
Phil.
Philippe Mathieu-Daudé (11):
qom: Introduce the TypeInfo::can_register() handler
target/arm: Add target_aarch64_available() helper
target/arm: Declare ARM_CPU_TYPE_NAME/SUFFIX in 'cpu-qom.h'
target/arm: Move ARM_CPU_IRQ/FIQ definitions to 'cpu-qom.h'
target/arm: Move GTIMER definitions to 'cpu-defs.h'
hw/arm/bcm2836: Simplify use of 'reset-cbar' property
hw/arm/bcm2836: Simplify access to 'start-powered-off' property
hw/arm/bcm2836: Use ARM_CPU 'mp-affinity' property
hw/arm/bcm2836: Allocate ARM CPU state with object_new()
hw/arm/raspi: Build bcm2836.o and raspi.o objects once
hw/intc/meson: Simplify how arm_gicv3_kvm.o objects are built
include/hw/arm/bcm2836.h | 4 ++--
include/qom/object.h | 4 ++++
target/arm/cpu-defs.h | 19 ++++++++++++++++
target/arm/cpu-qom.h | 11 ++++++++++
target/arm/cpu.h | 16 +-------------
hw/arm/bcm2836.c | 43 ++++++++++++++++---------------------
hw/arm/raspi.c | 8 +++----
hw/intc/arm_gicv3_its_kvm.c | 1 +
hw/intc/arm_gicv3_kvm.c | 1 +
qom/object.c | 3 +++
target/arm/cpu.c | 9 ++++++++
hw/arm/meson.build | 6 ++++--
hw/intc/meson.build | 6 ++++--
13 files changed, 80 insertions(+), 51 deletions(-)
create mode 100644 target/arm/cpu-defs.h
--
2.41.0