On 03/13/2012 09:58 PM, Andreas Färber wrote:
Am 13.03.2012 13:31, schrieb Igor Mitsyanko:
On 03/10/2012 08:53 PM, Andreas Färber wrote:
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
new file mode 100644
index 0000000..dabc094
--- /dev/null
+++ b/target-arm/cpu.c
[...]
+static void cpu_register(const ARMCPUInfo *info)
+{
+ TypeInfo type = {
+ .name = info->name,
+ .parent = TYPE_ARM_CPU,
+ .instance_size = sizeof(ARMCPU),
+ .class_size = sizeof(ARMCPUClass),
+ .class_init = arm_cpu_class_init,
+ .class_data = (void *)info,
+ };
Are non-initialized members guaranteed to be zero here?
I thought so for the C99-style struct initialization... I never ran into
crashes while testing. Do we need static to be safe?
+ type_register_static(&type);
+}
+
Probably should be type_register() here in case these two will actually
differ in the future.
My thinking was we don't need it here because the data (esp. strings)
are not dynamically allocated. By comparison, I used type_register() for
-cpudef in target-i386, I believe.
But I really guess it's a bug that they're just an alias right now! ;)
Object.h states we need to use type_register_static() only when TypeInfo
exists for the lifetime of
Type. As I understand this, TypeInfo must have *static const* storage
qualifier when used with type_register_static() and can have automatic
storage qualifier when used with type_register().
Maybe in the future type_register_static() will just copy a pointer to
string variables of passed
TypeInfo instead of g_strdup() them, then your code wouldn't work as
expected.
If this information is of any help, we've got no problems when emulating
ARM-based Exynos boards in QEMU with this whole patchset applied.
Thanks a lot for testing!
Have you thought about how to QOM'ify your boards? Mid-term I'd like to
see an "exynos4210" object with the CPUs on it - maybe "cpu[0]" and
"cpu[1]" child properties? Or "core[x]"? I had played with the sh7750 a
bit on my branch but like the arm926 it's a single-core.
Andreas
Yes, we've done some work on this, but we are waiting to see how you
want to proceed with SoC
QOM type, and if you're going to introduce it at all. Personally I have
no idea what members and
methods a general SoC type could have.
And another question, should we somehow exploit a fact that majority of
peripheral devices on
SoCs share i/o ports with each other and only a handful of them are
actually active at the same
time. Currently we instantiate all SoC devices even if half of them are
not used in emulated configuration. Maybe we should dynamically
create/destroy devices depending on runtime GPIO
configuration, or make all devices a board's child instead of SoC's
child. Not sure that it's worth an effort though.
As for CPU's object, Peter's idea with CortexA9 and core1, core2 childs
looks good to me.
--
Mitsyanko Igor
ASWG, Moscow R&D center, Samsung Electronics
email: i.mitsya...@samsung.com
