On Fri, Nov 29, 2013 at 10:46 AM, Li Guang <lig.f...@cn.fujitsu.com> wrote:
> 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<lig.f...@cn.fujitsu.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Signed-off-by: liguang<lig.f...@cn.fujitsu.com>
>>>>> ---
>>>>> 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<lig.f...@cn.fujitsu.com>
>>>>> + *
>>>>> + * 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?
> we can't track Axx hardware changes? why?
> and also, this patch-set is also community effort just like
> sunxi in linux kernel.
>
>
>>> 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.
>
How does such variation occur, is it between different SoCs or board
configurable (tieoffs, bootrom etc)?
Regards,
Peter
