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

[Li Guang <lig.fnst@cn.fujitsu.com>]

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.fnst@cn.fujitsu.com>  wrote:
>>>        
>>>> Signed-off-by: liguang<lig.fnst@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.fnst@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.

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

>> Regards,
>> Andreas
>>
>> [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.

Thanks for your comment!

Li Guang

>> [3] http://cubieboard.org/
>>
>>      
>
>