qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v4 3/4] hw/arm: add sunxi machine type
Date: Wed, 27 Nov 2013 10:27:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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.
> 
> 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.
> 
> 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.
> 
> Regards,
> Andreas
> 
> [1] http://linux-sunxi.org/Main_Page
> [2] http://www.allwinnertech.com/en/product/A-Serial.html
> [3] http://cubieboard.org/
> 


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]