Re: [Qemu-devel] [PATCH v4 3/4] hw/arm: add sunxi machine type

[Bamvor Jian Zhang]

Hi, 

 >>>Li Guang <address@hidden> wrote: 
> Andreas Färber wrote: 
> > Am 29.11.2013 01:46, schrieb Li Guang: 
> >     
> >> Andreas Färber wrote: 
> >>       
> >>> Am 27.11.2013 10:22, schrieb Andreas Färber: 
> >>> 
> >>>         
> >>>> Hi, 
> >>>> 
> >>>> Am 26.11.2013 10:22, schrieb Peter Crosthwaite: 
> >>>> 
> >>>>           
> >>>>> On Tue, Nov 26, 2013 at 5:22 PM, liguang<address@hidden> 
> >>>>> wrote: 
> >>>>> 
> >>>>>             
> >>>>>> Signed-off-by: liguang<address@hidden> 
> >>>>>> --- 
> >>>>>>    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 += tosa.o versatilepb.o vexpress.o 
> >>>>>> xilinx_zynq.o z2.o 
> >>>>>> 
> >>>>>>    obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o 
> >>>>>>    obj-y += omap1.o omap2.o strongarm.o 
> >>>>>> +obj-y += 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<address@hidden> 
> >>>>>> + * 
> >>>>>> + * 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_PIC_REG_BASE 0x01c20400 
> >>>>>> +#define SUNXI_PIT_REG_BASE 0x01c20c00 
> >>>>>> +#define SUNXI_UART0_REG_BASE 0x01c28000 
> >>>>>> + 
> >>>>>> +static struct arm_boot_info sunxi_binfo = { 
> >>>>>> +    .loader_start = 0x40000000, 
> >>>>>> +    .board_id = 0x1008, 
> >>>>>> +}; 
> >>>>>> + 
> >>>>>> +static void sunxi_init(QEMUMachineInitArgs *args) 
> >>>>>> 
> >>>>>>               
> >>>>> 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. 
> >>>>> 
> >>>>>             
> >>>> 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 = sun4i, A2x = sun5i, A3x = sun6i but 
> >>>> 
> >>>>           
> >>> My interpolation was incorrect: A10 = sun4i, A13 = sun5i, A3x = sun6i, 
> >>> A20 = sun7i 
> >>> 
> >>> Andreas 
> >>> 
> >>> 
> >>>         
> >>>> 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. 
> >>>> 
> >>>> 
> >>>>           
> >> well, sunxi maybe be representation of Axx series, 
> >> but, what's wrong? 
> >>       
> > 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é 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. 
> > 
> >     
> >> we can't track Axx hardware changes? why? 
> >>       
> > 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. 
> >     
>  
> 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_priv" composite device. 
> >  
> http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores#Designed_by_ARM 
> > 
> >     
> >> and also, this patch-set is also community effort just like 
> >> sunxi in linux kernel. 
> >>       
> > 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. :) 
> > 
> >     
>  
> of course, I am aiming to emulate the real hardware, 
> so name is no
t 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_model if you have a fixed SoC-CPU mapping. 
> >>>> 
> >>>>           
> >> modeling SoC is good, but 
> >> sorry, I can't assure that fixed mapping. 
> >>       
> > See above. A10 / sun4i =>  Cortex-A8, that's fixed, and then you can 
> > properly embed the ARMCPU in an A10State/Sun4iState without pointer and 
> > using object_initialize(). 
> > 
> > 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. 
> >     
>  
> 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 ... 
>  
> > 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<allwinner-a10>  "a10" 
> >                     which in turn has-a child<cortex-a8-arm-cpu>  "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_init and before DeviceClass::realize. 
> > -M cubieboard2 /machine by contrast has-a child<allwinner-a20>  "a20" 
> >                          which has-a child<cortex-a7-arm-cpu>  "cpu[0]", 
> >                                has-a child<cortex-a7-arm-cpu>  "cpu[1]". 
> > 
> > Like I said below, Peter Maydell should be able to guide you in more 
> > detail for the exact naming and composition. 
> > 
> >     
> >>>> 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. 
> >>>> 
> >>>>           
> >> currently, I can only provide linux kernel build for sunxi-4i, 
> >> where I can up-load it to? 
> >>       
> > 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:/sunxi/po 
> rts/armv7hl/ 
> > 
> >     
>  
> tried to attach zImage in mail, 
> but, seems failed. 
>  
> I will try other ways like google drive. 
you could also try the nightly build at 
http://dl.linux-sunxi.org/nightly/linux-sunxi/
>  
> >>>> [1] http://linux-sunxi.org/Main_Page 
> >>>> [2] http://www.allwinnertech.com/en/product/A-Serial.html 
> >>>> 
> >>>>           
> >> this page is can't accessed for me. 
> >>       
> > 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_Technology#A-Series 
> > 
> > 
> >     
> OK. 
>  
> Thanks! 
> Li Guang 
>  
>  
>  
>  
>