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: Li Guang
Subject: Re: [Qemu-devel] [PATCH v4 3/4] hw/arm: add sunxi machine type
Date: Fri, 29 Nov 2013 16:06:36 +0800
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.16) Gecko/20120421 Iceape/2.0.11 
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 not 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/ports/armv7hl/



tried to attach zImage in mail,
but, seems failed.

I will try other ways like google drive.


[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
reply via email to
[Prev in Thread] Current Thread [Next in Thread]