From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnrDS-0002jS-Qz for qemu-devel@nongnu.org; Tue, 03 Dec 2013 09:44:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnrDN-0006oB-8n for qemu-devel@nongnu.org; Tue, 03 Dec 2013 09:44:46 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36275 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnrDM-0006o5-V2 for qemu-devel@nongnu.org; Tue, 03 Dec 2013 09:44:41 -0500 Message-ID: <529DEE54.20405@suse.de> Date: Tue, 03 Dec 2013 15:44:36 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1386061881-12720-1-git-send-email-lig.fnst@cn.fujitsu.com> <1386061881-12720-6-git-send-email-lig.fnst@cn.fujitsu.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 5/5] hw/arm: add cubieboard support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , liguang Cc: Peter Maydell , "qemu-devel@nongnu.org Developers" Am 03.12.2013 13:01, schrieb Peter Crosthwaite: > On Tue, Dec 3, 2013 at 7:11 PM, liguang wrote= : >> Signed-off-by: liguang >> --- >> hw/arm/Makefile.objs | 2 +- >> hw/arm/cubieboard.c | 33 +++++++++++++++++++++++++++++++++ >> 2 files changed, 34 insertions(+), 1 deletions(-) >> create mode 100644 hw/arm/cubieboard.c >> >> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs >> index b9e5983..8be8d8e 100644 >> --- a/hw/arm/Makefile.objs >> +++ b/hw/arm/Makefile.objs >> @@ -4,4 +4,4 @@ obj-y +=3D omap_sx1.o palm.o realview.o spitz.o stella= ris.o >> obj-y +=3D tosa.o versatilepb.o vexpress.o xilinx_zynq.o z2.o >> >> obj-y +=3D armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o >> -obj-y +=3D omap1.o omap2.o strongarm.o allwinner-a10.o >> +obj-y +=3D omap1.o omap2.o strongarm.o allwinner-a10.o cubieboard.o >> diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c >> new file mode 100644 >> index 0000000..a5be21c >> --- /dev/null >> +++ b/hw/arm/cubieboard.c >> @@ -0,0 +1,33 @@ >> +#include "hw/sysbus.h" >> +#include "hw/devices.h" >> +#include "hw/boards.h" >> +#include "hw/arm/allwinner-a10.h" >> + >> + >> +static struct arm_boot_info cubieboard_binfo =3D { >> + .loader_start =3D A10_SDRAM_BASE, >> + .board_id =3D 0x1008, >> +}; >> + >> +static void cubieboard_init(QEMUMachineInitArgs *args) >> +{ >> + A10State *s =3D a10_init(get_system_memory(), args->ram_size); >> + >> + cubieboard_binfo.ram_size =3D args->ram_size; >> + cubieboard_binfo.kernel_filename =3D args->kernel_filename; >> + cubieboard_binfo.kernel_cmdline =3D args->kernel_cmdline; >=20 > I cant help but think that serial attachment needs to happen on the > board level. but im not sure how this can be made to work with the > un-qomified serial_mm_init, so no block from me unless Andreas has a > better idea. I don't have an immediate solution, same problem in Tegra2 code. If someone is willing to convert serial_mm into QOM-friendly form that would be nice but I will be unavailable for review the next ~two weeks. What I do wonder here is why this is calling a new a10_init() rather than object_new() and related QOM APIs. get_system_memory() can without problems be called inside the device. If RAM is really on the SoC (it is for Tegra2/3) then it could become a property of the device with MemoryRegion initialization in realize - that is still unclean in my code IIRC. >> + arm_load_kernel(s->cpu, &cubieboard_binfo); >> +} [...] >> +machine_init(cubieboard_machine_init); No semicolon here please, it's a function. Regards, Andreas --=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