From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Usug2-0004cH-CF for qemu-devel@nongnu.org; Sat, 29 Jun 2013 08:54:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Usufz-0007xs-T5 for qemu-devel@nongnu.org; Sat, 29 Jun 2013 08:54:54 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47189 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Usufz-0007xg-Jl for qemu-devel@nongnu.org; Sat, 29 Jun 2013 08:54:51 -0400 Message-ID: <51CED912.4080905@suse.de> Date: Sat, 29 Jun 2013 14:54:42 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1372420798-4790-1-git-send-email-andre.przywara@calxeda.com> In-Reply-To: <1372420798-4790-1-git-send-email-andre.przywara@calxeda.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] highbank: add initial Calxeda Midway A15 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andre Przywara , Peter Maydell Cc: aliguori@us.ibm.com, Mitsyanko Igor , qemu-devel@nongnu.org, Rob Herring Am 28.06.2013 13:59, schrieb Andre Przywara: > From: Rob Herring >=20 > While the Calxeda Midway part is actually a bit more than a "Highbank > with A15s", for QEMU's purposes this view is sufficient. So to allow > both emulation with that chip as well as KVM guests using that model > add an A15 CPU and it's peripherals as an option. The use of: > "-M highbank -cpu cortex-a15" simply gives the new chip without the > need for a new model. >=20 > Signed-off-by: Rob Herring > Signed-off-by: Andre Przywara > --- > hw/arm/highbank.c | 19 +++++++++++++------ > 1 file changed, 13 insertions(+), 6 deletions(-) >=20 > diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c > index 4405dbd..ed864c6 100644 > --- a/hw/arm/highbank.c > +++ b/hw/arm/highbank.c > @@ -196,6 +196,7 @@ static void highbank_init(QEMUMachineInitArgs *args= ) > const char *kernel_filename =3D args->kernel_filename; > const char *kernel_cmdline =3D args->kernel_cmdline; > const char *initrd_filename =3D args->initrd_filename; > + CPUARMState *env =3D NULL; > DeviceState *dev; > SysBusDevice *busdev; > qemu_irq *irqp; > @@ -223,6 +224,8 @@ static void highbank_init(QEMUMachineInitArgs *args= ) > cpu->reset_cbar =3D GIC_BASE_ADDR; > irqp =3D arm_pic_init_cpu(cpu); > cpu_irq[n] =3D irqp[ARM_PIC_CPU_IRQ]; > + > + env =3D &cpu->env; > } > =20 > sysmem =3D get_system_memory(); > @@ -246,7 +249,16 @@ static void highbank_init(QEMUMachineInitArgs *arg= s) > } > } > =20 > - dev =3D qdev_create(NULL, "a9mpcore_priv"); > + if (arm_feature(env, ARM_FEATURE_LPAE)) { > + dev =3D qdev_create(NULL, "a15mpcore_priv"); This feels a bit fragile to me... Cortex-A7 or other cores might grow support for LPAE, too. I would suggest something along these lines: if (object_get_class(OBJECT(cpu)) =3D=3D object_class_by_name("cortex-a15= -" TYPE_ARM_CPU)) {...} In a QOM context Peter, the Samsung guys and me had been discussing how to improve CPU modelling, which I have been experimenting with some more on my Tegra branch: http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/tegra Transferred to Highbank this would result in something like this: /machine/highbank-soc - name board-specific, a DeviceState /machine/highbank-soc/cortex - a Container for ARM standard peripherals /machine/highbank-soc/cortex/cpu[0..3] - an ARMCPU core /machine/highbank-soc/foo - anything that's specific to this SoC I now wonder whether it would make sense to turn the "cortex" node into a DeviceState type "cortex-a15-arm-soc" rather than an empty Container filled by each SoC? DeviceState would help with recursive QOM realization, and we could then better embed what is now a15mpcore_priv. Certainly outside the scope of this patch, but long-term I would like to get away from the board-level CPU peripheral fiddling that is being done here and clearly separate SoC from machine via different files. Regards, Andreas > + } else { > + dev =3D qdev_create(NULL, "l2x0"); > + qdev_init_nofail(dev); > + busdev =3D SYS_BUS_DEVICE(dev); > + sysbus_mmio_map(busdev, 0, 0xfff12000); > + > + dev =3D qdev_create(NULL, "a9mpcore_priv"); > + } > qdev_prop_set_uint32(dev, "num-cpu", smp_cpus); > qdev_prop_set_uint32(dev, "num-irq", NIRQ_GIC); > qdev_init_nofail(dev); > @@ -260,11 +272,6 @@ static void highbank_init(QEMUMachineInitArgs *arg= s) > pic[n] =3D qdev_get_gpio_in(dev, n); > } > =20 > - dev =3D qdev_create(NULL, "l2x0"); > - qdev_init_nofail(dev); > - busdev =3D SYS_BUS_DEVICE(dev); > - sysbus_mmio_map(busdev, 0, 0xfff12000); > - > dev =3D qdev_create(NULL, "sp804"); > qdev_prop_set_uint32(dev, "freq0", 150000000); > qdev_prop_set_uint32(dev, "freq1", 150000000); >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg