From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmJ7d-0005Oa-3L for qemu-devel@nongnu.org; Fri, 29 Nov 2013 03:08:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmJ7Z-0002aA-65 for qemu-devel@nongnu.org; Fri, 29 Nov 2013 03:08:20 -0500 Received: from [222.73.24.84] (port=61950 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmJ7X-0002Zw-SN for qemu-devel@nongnu.org; Fri, 29 Nov 2013 03:08:17 -0500 Message-ID: <52984B0C.9030209@cn.fujitsu.com> Date: Fri, 29 Nov 2013 16:06:36 +0800 From: Li Guang MIME-Version: 1.0 References: <1385450531-3170-1-git-send-email-lig.fnst@cn.fujitsu.com> <1385450531-3170-4-git-send-email-lig.fnst@cn.fujitsu.com> <5295B9BD.7080101@suse.de> <5295BB1E.1090600@suse.de> <5297E3F1.4060200@cn.fujitsu.com> <5298098C.1040105@suse.de> In-Reply-To: <5298098C.1040105@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 3/4] hw/arm: add sunxi machine type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Peter Maydell , Peter Crosthwaite , =?ISO-8859-1?Q?Herv=E9_Poussineau?= , qemu-devel , Bamvor Jian Zhang Andreas F=E4rber wrote: > Am 29.11.2013 01:46, schrieb Li Guang: > =20 >> Andreas F=E4rber wrote: >> =20 >>> Am 27.11.2013 10:22, schrieb Andreas F=E4rber: >>> >>> =20 >>>> Hi, >>>> >>>> Am 26.11.2013 10:22, schrieb Peter Crosthwaite: >>>> >>>> =20 >>>>> On Tue, Nov 26, 2013 at 5:22 PM, liguang >>>>> wrote: >>>>> >>>>> =20 >>>>>> Signed-off-by: liguang >>>>>> --- >>>>>> hw/arm/Makefile.objs | 1 + >>>>>> hw/arm/sunxi-soc.c | 98 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> 2 files changed, 99 insertions(+), 0 deletions(-) >>>>>> create mode 100644 hw/arm/sunxi-soc.c >>>>>> >>>>>> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs >>>>>> index 3671b42..f9f3071 100644 >>>>>> --- a/hw/arm/Makefile.objs >>>>>> +++ b/hw/arm/Makefile.objs >>>>>> @@ -5,3 +5,4 @@ obj-y +=3D tosa.o versatilepb.o vexpress.o >>>>>> xilinx=5Fzynq.o z2.o >>>>>> >>>>>> obj-y +=3D armv7m.o exynos4210.o pxa2xx.o pxa2xx=5Fgpio.o pxa2xx= =5Fpic.o >>>>>> obj-y +=3D omap1.o omap2.o strongarm.o >>>>>> +obj-y +=3D sunxi-soc.o >>>>>> diff --git a/hw/arm/sunxi-soc.c b/hw/arm/sunxi-soc.c >>>>>> new file mode 100644 >>>>>> index 0000000..b45af6d >>>>>> --- /dev/null >>>>>> +++ b/hw/arm/sunxi-soc.c >>>>>> @@ -0,0 +1,98 @@ >>>>>> +/* >>>>>> + * Allwinner sunxi series SoC emulation >>>>>> + * >>>>>> + * Copyright (C) 2013 Li Guang >>>>>> + * Written by Li Guang >>>>>> + * >>>>>> + * This program is free software; you can redistribute it and/or >>>>>> modify it >>>>>> + * under the terms of the GNU General Public License as published >>>>>> by the >>>>>> + * Free Software Foundation; either version 2 of the License, or >>>>>> + * (at your option) any later version. >>>>>> + * >>>>>> + * This program is distributed in the hope that it will be useful, >>>>>> but WITHOUT >>>>>> + * ANY WARRANTY; without even the implied warranty of >>>>>> MERCHANTABILITY or >>>>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>> License >>>>>> + * for more details. >>>>>> + */ >>>>>> + >>>>>> +#include "hw/sysbus.h" >>>>>> +#include "hw/devices.h" >>>>>> +#include "hw/boards.h" >>>>>> +#include "hw/arm/arm.h" >>>>>> +#include "hw/ptimer.h" >>>>>> +#include "hw/char/serial.h" >>>>>> +#include "hw/timer/sunxi-pit.h" >>>>>> +#include "hw/intc/sunxi-pic.h" >>>>>> + >>>>>> +#include "sysemu/sysemu.h" >>>>>> +#include "exec/address-spaces.h" >>>>>> + >>>>>> + >>>>>> +#define SUNXI=5FPIC=5FREG=5FBASE 0x01c20400 >>>>>> +#define SUNXI=5FPIT=5FREG=5FBASE 0x01c20c00 >>>>>> +#define SUNXI=5FUART0=5FREG=5FBASE 0x01c28000 >>>>>> + >>>>>> +static struct arm=5Fboot=5Finfo sunxi=5Fbinfo =3D { >>>>>> + .loader=5Fstart =3D 0x40000000, >>>>>> + .board=5Fid =3D 0x1008, >>>>>> +}; >>>>>> + >>>>>> +static void sunxi=5Finit(QEMUMachineInitArgs *args) >>>>>> >>>>>> =20 >>>>> I would check with Andreas/PMM on what the go is with SoCs regarding >>>>> container devices and boards. My (vague) understanding is that SoCs >>>>> should be container devices and boards instantiate those containers >>>>> with off-chip connectivity. This seems flat to me, with everything on >>>>> board level. >>>>> >>>>> =20 >>>> Yes, thanks, that matches what I was going to comment. But I think it's >>>> even more complicated: To my understanding, "sunxi" is the name of a >>>> community effort [1] to clean up and upstream the BSP kernels from >>>> Allwinner, so it sounds as if this was an attempt to write an emulation >>>> for that kernel family while naming everything "sunxi" when in fact the >>>> SoCs are called Axx [2] (with A1x =3D sun4i, A2x =3D sun5i, A3x =3D su= n6i but >>>> >>>> =20 >>> My interpolation was incorrect: A10 =3D sun4i, A13 =3D sun5i, A3x =3D s= un6i, >>> A20 =3D sun7i >>> >>> Andreas >>> >>> >>> =20 >>>> no literal "sunxi" AFAIK) and boards include Cubieboard, Cubieboard2, >>>> Cubieboard3/Cubietruck [3] and whatever tablets etc. are out there. >>>> (CC'ing Bamvor) >>>> >>>> That's a lesson we learned from the old "prep" machine: Please name >>>> things after real hardware, only then can it later be verified whether >>>> the modeling is actually correct or which changes need to be performed. >>>> >>>> >>>> =20 >> well, sunxi maybe be representation of Axx series, >> but, what's wrong? >> =20 > You're modeling too general IMO and thereby you're creating a > virtual-only machine (despite parallel efforts by Linaro to introduce > mach-virt for that purpose). Please model an actual piece of hardware - > SoC and board - and not something random that happens to run with the > "sunxi" kernel flavor but will leave us puzzled in the future. Should be > pretty easy to avoid. > > My example was qemu-system-ppc -M prep. Today no one knows what hardware > that was supposed to match (possibly none) because there are a number of > different PReP based machines from IBM and Motorola out there; switching > from OpenHack'Ware to OpenBIOS became difficult because among other > things we don't have a device tree dump from a physical machine to > compare to, and Herv=E9 thus set out to create new machines such as 40P > where we actually know which components the hardware contains rather > than which drivers are available in the kernel and happened to have > matching QEMU device implementations at the time. > A slightly similar problem occurred with -M pc, where we now have an > i440fx based one and the new q35 based one. It's easier to abstract > commonalities and share code between different devices/machines than > turning a generic machine/device into a less generic one, in particular > for backwards compatibility for guests, command line and QMP. > > When the difference between two devices is just a value or an offset, > then you can use static properties to set them and have the realize > function take them into account. If the composition tree differs > significantly or if you want to facilitate reuse, then different types > will be needed. Multiple machines can call a shared helper function with > some parameter; examples include PC, Versatile Express and DIGIC. > > =20 >> we can't track Axx hardware changes? why? >> =20 > Sorry, I don't get that? The Sunxi, Allwinner and Wikipedia pages all > document some key differences, in particular Cortex-A8 in A10/A13 vs. > Cortex-A7 in A20/A31. Cortex-A7 has MPCore, which drags along some key > differences that cannot easily fit in a single SunxiState SoC device. > =20 right, A10/20... seem have similar devices except CPU > At least from my understanding of Cortex-A9 and Cortex-A15 being much > closer than Cortex-A8, that is. For example, you have your own PIC for > the Cortex-A8 in this series whereas Cortex-A7 will use ARM's GIC and > may be able to reuse the "a15mpcore=5Fpriv" composite device. > http://en.wikipedia.org/wiki/List=5Fof=5FARM=5Fmicroprocessor=5Fcores#Des= igned=5Fby=5FARM > > =20 >> and also, this patch-set is also community effort just like >> sunxi in linux kernel. >> =20 > My whole point is, try to design the model forward from hardware and > less backwards from kernel. Whether it's sun4i or A10 is less relevant. > Kernels may contain bugs. Hardware doesn't change except for new revs, > but definitely not depending on who writes a kernel to run on it. :) > > =20 of course, I am aiming to emulate the real hardware, so name is not the problem, right? >>>> A practical aspect of modeling SoCs correctly is that they can more >>>> easily be reused across boards or modules, and you don't need to mess >>>> with machine-level cpu=5Fmodel if you have a fixed SoC-CPU mapping. >>>> >>>> =20 >> modeling SoC is good, but >> sorry, I can't assure that fixed mapping. >> =20 > See above. A10 / sun4i =3D> Cortex-A8, that's fixed, and then you can > properly embed the ARMCPU in an A10State/Sun4iState without pointer and > using object=5Finitialize(). > > It is your approach of a single "sunxi" machine and SunxiState that's > interfering with a fixed mapping AFAICT. Otherwise you'll need to > explain more verbose why the mapping is not assured, please. > =20 I mean, e.g. A10 and A13 are different only on HDMI-transmitter and=20 SATA-controller, but we have to have Sun4iState, and Sun5iState, I think. what I design is: we have a sunxi series as a machine, then for sunx4i, we specify -M sunxi -cpu cortex-a8 -device x1 ... for sunx5i, we specify -M sunxi -cpu cortex-a8 -device x2 ... for sunx7i, we specify -M sunxi -cpu cortex-a7 -devcie x3 ... for cubieboard, we specify -M sunxi -cpu -cortex-a8 -device x1 -device=20 p1 ... > QOM uses a strict composition model. If you choose the physical board > you have, say a Gooseberry board, then modeling should be so that we use > qemu-system-arm -M gooseberry (without -cpu cortex-a8) > and /machine has-a child "a10" > which in turn has-a child "cpu". > -M cubieboard and -M marsboard can then all reuse the allwinner-a10 SoC > device, and in the future you can then tweak CPU properties via QMP > after TypeInfo::instance=5Finit and before DeviceClass::realize. > -M cubieboard2 /machine by contrast has-a child "a20" > which has-a child "cpu[0]", > has-a child "cpu[1]". > > Like I said below, Peter Maydell should be able to guide you in more > detail for the exact naming and composition. > > =20 >>>> You may want to consult the recent DIGIC or earlier Faraday series or = my >>>> Tegra2 repository for examples of how to implement this paradigm. >>>> I believe the composition tree naming wrt "cortex" and the MPCore was >>>> still open, hopefully PMM can comment on his current preferences. >>>> >>>> And thanks for your efforts, from a distribution viewpoint I am looking >>>> forward to testing our kernels and images with this. >>>> >>>> =20 >> currently, I can only provide linux kernel build for sunxi-4i, >> where I can up-load it to? >> =20 > I recall Faraday using Google Drive, for instance. > > openSUSE seems to provide some sun4i and sun5i kernel RPMs here: > https://build.opensuse.org/project/show/devel:ARM:12.3:Contrib:sunxi > http://download.opensuse.org/repositories/devel:/ARM:/12.3:/Contrib:/sunx= i/ports/armv7hl/ > > =20 tried to attach zImage in mail, but, seems failed. I will try other ways like google drive. >>>> [1] http://linux-sunxi.org/Main=5FPage >>>> [2] http://www.allwinnertech.com/en/product/A-Serial.html >>>> >>>> =20 >> this page is can't accessed for me. >> =20 > Works for me ATM, so either a temporary problem or firewall issue... > It provides a table of the SoCs, mapping names to CPU, GPU, etc. > > Cf. http://en.wikipedia.org/wiki/Allwinner=5FTechnology#A-Series > > > =20 OK. Thanks! Li Guang =