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

[Andreas Färber]

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.

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. :)

>>> 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.

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/ports/armv7hl/

>>> [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

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg