From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmJzD-0002AU-4G for qemu-devel@nongnu.org; Fri, 29 Nov 2013 04:03:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmJz5-00053I-OO for qemu-devel@nongnu.org; Fri, 29 Nov 2013 04:03:43 -0500 Received: from [222.73.24.84] (port=13268 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmJz4-0004yf-G6 for qemu-devel@nongnu.org; Fri, 29 Nov 2013 04:03:35 -0500 Message-ID: <52985804.9080103@cn.fujitsu.com> Date: Fri, 29 Nov 2013 17:01:56 +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> <52984B0C.9030209@cn.fujitsu.com> <5298C3B30200003000077CEB@soto.provo.novell.com> In-Reply-To: <5298C3B30200003000077CEB@soto.provo.novell.com> Content-Type: text/plain; charset=UTF-8; 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: Bamvor Jian Zhang Cc: Peter Maydell , Peter Crosthwaite , hpoussin@reactos.org, afaerber@suse.de, qemu-devel Bamvor Jian Zhang wrote: > Hi, > > >>>Li Guang wrote: > =20 >> Andreas F=C3=A4rber wrote: >> =20 >>> Am 29.11.2013 01:46, schrieb Li Guang: >>> >>> =20 >>>> Andreas F=C3=A4rber wrote: >>>> >>>> =20 >>>>> Am 27.11.2013 10:22, schrieb Andreas F=C3=A4rber: >>>>> >>>>> >>>>> =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 pxa2= xx=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 i= t'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 emulat= ion >>>>>> 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 = sun6i but >>>>>> >>>>>> >>>>>> =20 >>>>> My interpolation was incorrect: A10 =3D sun4i, A13 =3D sun5i, A3x =3D= sun6i, >>>>> 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 wheth= er >>>>>> the modeling is actually correct or which changes need to be perform= ed. >>>>>> >>>>>> >>>>>> >>>>>> =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=C3=A9 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 >> >> =20 >>> 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. >>> >>> =20 >> http://en.wikipedia.org/wiki/List=5Fof=5FARM=5Fmicroprocessor=5Fcores#De= signed=5Fby=5FARM >> =20 >>> >>> =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? >> >> =20 >>>>>> 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 >> 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 >> p1 ... >> >> =20 >>> 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 "cp= u". >>> -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 o= r 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 look= ing >>>>>> 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 >>> >>> =20 >> http://download.opensuse.org/repositories/devel:/ARM:/12.3:/Contrib:/sun= xi/po >> rts/armv7hl/ >> =20 >>> >>> =20 >> >> tried to attach zImage in mail, >> but, seems failed. >> >> I will try other ways like google drive. >> =20 > you could also try the nightly build at http://dl.linux-sunxi.org/nightly= /linux-sunxi/ > =20 you mean we should directly use kernel image from there? for me, it's not OK, currently, I only add several base devices, and I didn't do BROM and PLL controller emulation, there maybe some panics for that build, we have to disable PLL config to silent kernel panics. >> >> =20 >>>>>> [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 >> >> >> >> >> >> =20 > > =20 =