Re: [Qemu-devel] [PATCH] pseries: Implements h_read hcall
Am 15.02.2013 11:59, schrieb Erlon Cruz:
From: Erlon Cruz erlon.c...@br.flextronics.com
This h_call is useful for DLPAR in future amongst other things. Given an index
it fetches the corresponding PTE stored in the htab.
Signed-off-by: Erlon Cruz erlon.c...@br.flextronics.com
---
hw/spapr_hcall.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 2889742..1065277 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -323,6 +323,39 @@ static target_ulong h_protect(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+target_ulong opcode, target_ulong *args)
Indentation is one-off.
Andreas
+{
+CPUPPCState *env = cpu-env;
+target_ulong flags = args[0];
+target_ulong pte_index = args[1];
+target_ulong v[4], r[4];
+uint8_t *hpte;
+int i, ridx, n_entries = 1;
+
+if ((pte_index * HASH_PTE_SIZE_64) ~env-htab_mask) {
+return H_PARAMETER;
+}
+
+if (flags H_READ_4) {
+/* Clear the two low order bits */
+pte_index = ~(3ULL);
+n_entries = 4;
+}
+
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+for (i = 0, ridx = 0; i n_entries; i++) {
+v[i] = ldq_p(hpte);
+r[i] = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
+args[ridx++] = v[i];
+args[ridx++] = r[i];
+hpte += HASH_PTE_SIZE_64;
+}
+
+return H_SUCCESS;
+}
+
static target_ulong h_set_dabr(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
{
@@ -714,6 +747,7 @@ static void hypercall_register_types(void)
spapr_register_hypercall(H_ENTER, h_enter);
spapr_register_hypercall(H_REMOVE, h_remove);
spapr_register_hypercall(H_PROTECT, h_protect);
+spapr_register_hypercall(H_READ, h_read);
/* hcall-bulk */
spapr_register_hypercall(H_BULK_REMOVE, h_bulk_remove);
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for-next v3 2/5] tmp105: Add debug output
Il 15/02/2013 14:14, Alexander Graf ha scritto: I'm assuming that changes to ppc logging go through ppc-next, changes to sparc code go through Blue etc. All those potentially conflict since they're adding to the bottom of the same text file, thus coordination. It's a long-standing criticism of our centralistic tracing infrastructure compared to the totally decentral and inhomogeneous DPRINTFs and what-nots on the other hand. I rarely found conflicts in trace-events, but in this case you would indeed have them. Trivial to solve, however. In parallel to the completely disastrous user experience when using trace points. What exactly is disastrous? We could have improvements (such as having multiple trace backends compiled in an executable, e.g. simple+stderr, or having gdb magic to enable/disable them from command breakpoints). But in general, I find trace points to be quite easy to use, and unintrusive enough to let you debug performance problems. Paolo
[Qemu-devel] [PATCH] Replace all setjmp()/longjmp() with sigsetjmp()/siglongjmp()
The setjmp() function doesn't specify whether signal masks are saved and
restored; on Linux they are not, but on BSD (including MacOSX) they are.
QEMU never wants to save and restore signal masks, because it uses threads,
and the signal-restoration may restore the whole process signal mask,
not just the mask for the thread which did the longjmp. In particular,
this resulted in a bug where ctrl-C was ignored on MacOSX because the
CPU thread did a longjmp which resulted in its signal mask being applied
to every thread, so that all threads had SIGINT and SIGTERM blocked.
The POSIX-sanctioned portable way to do a jump without affecting signal
masks is to use sigsetjmp() with a zero savemask parameter, so change
all uses of setjmp()/longjmp() accordingly.
For Windows we provide a trivial sigsetjmp/siglongjmp in terms of
setjmp/longjmp -- this is OK because no user will ever pass a non-zero
savemask (it would be a bug to do so because of the process-wide effects
described above).
The setjmp() uses in tests/tcg/test-i386.c and tests/tcg/linux-test.c
are left untouched because these are self-contained singlethreaded
test programs intended to be run under QEMU's Linux emulation, so they
have neither the portability nor the multithreading issues to deal with.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
This should have no visible effects on Linux where setjmp/longjmp
never messed with the signal state in the first place; it just makes
us behave right on the BSDs.
Stefan: I've put in the os-win32.h defines which I think are needed;
they're pretty trivial but I don't have a Win32 setup to compile with;
can I ask you to run a quick test for me, please?
I didn't feel it necessary to change every last comment that said
'longjmp' to say 'siglongjmp' where I felt the comment was talking
about 'longjmp the concept' rather than 'longjmp the specific
function implementation'.
checkpatch complains about the indent in the disassembler
sources, as usual, but is otherwise happy.
coroutine-sigaltstack.c | 26 +-
coroutine-ucontext.c | 27 ++-
cpu-exec.c| 6 +++---
disas/i386.c | 6 +++---
disas/m68k.c | 11 ++-
include/exec/cpu-defs.h | 2 +-
include/sysemu/os-win32.h | 8
monitor.c | 6 +++---
user-exec.c | 2 +-
9 files changed, 52 insertions(+), 42 deletions(-)
diff --git a/coroutine-sigaltstack.c b/coroutine-sigaltstack.c
index e37ebac..1fb41c9 100644
--- a/coroutine-sigaltstack.c
+++ b/coroutine-sigaltstack.c
@@ -45,7 +45,7 @@ static unsigned int pool_size;
typedef struct {
Coroutine base;
void *stack;
-jmp_buf env;
+sigjmp_buf env;
} CoroutineUContext;
/**
@@ -59,7 +59,7 @@ typedef struct {
CoroutineUContext leader;
/** Information for the signal handler (trampoline) */
-jmp_buf tr_reenter;
+sigjmp_buf tr_reenter;
volatile sig_atomic_t tr_called;
void *tr_handler;
} CoroutineThreadState;
@@ -115,8 +115,8 @@ static void __attribute__((constructor))
coroutine_init(void)
static void coroutine_bootstrap(CoroutineUContext *self, Coroutine *co)
{
/* Initialize longjmp environment and switch back the caller */
-if (!setjmp(self-env)) {
-longjmp(*(jmp_buf *)co-entry_arg, 1);
+if (!sigsetjmp(self-env, 0)) {
+siglongjmp(*(sigjmp_buf *)co-entry_arg, 1);
}
while (true) {
@@ -145,14 +145,14 @@ static void coroutine_trampoline(int signal)
/*
* Here we have to do a bit of a ping pong between the caller, given that
* this is a signal handler and we have to do a return soon. Then the
- * caller can reestablish everything and do a longjmp here again.
+ * caller can reestablish everything and do a siglongjmp here again.
*/
-if (!setjmp(coTS-tr_reenter)) {
+if (!sigsetjmp(coTS-tr_reenter, 0)) {
return;
}
/*
- * Ok, the caller has longjmp'ed back to us, so now prepare
+ * Ok, the caller has siglongjmp'ed back to us, so now prepare
* us for the real machine state switching. We have to jump
* into another function here to get a new stack context for
* the auto variables (which have to be auto-variables
@@ -179,7 +179,7 @@ static Coroutine *coroutine_new(void)
/* The way to manipulate stack is with the sigaltstack function. We
* prepare a stack, with it delivering a signal to ourselves and then
- * put setjmp/longjmp where needed.
+ * put sigsetjmp/siglongjmp where needed.
* This has been done keeping coroutine-ucontext as a model and with the
* pth ideas (GNU Portable Threads). See coroutine-ucontext for the basics
* of the coroutines and see pth_mctx.c (from the pth project) for the
@@ -220,7 +220,7 @@ static Coroutine *coroutine_new(void)
/*
* Now transfer control onto the signal stack and set it up.
- * It will return immediately via
Re: [Qemu-devel] [PATCH buildfix] tcg/ppc: Fix build of tcg_qemu_tb_exec()
Thanks, applied.
On Sat, Feb 16, 2013 at 10:21 PM, Andreas Färber andreas.faer...@web.de wrote:
Commit 0b0d3320db74cde233ee7855ad32a9c121d20eb4 (TCG: Final globals
clean-up) moved code_gen_prologue but forgot to update ppc code.
This broke the build on 32-bit ppc. ppc64 is unaffected.
Cc: Evgeny Voevodin evgenyvoevo...@gmail.com
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
tcg/ppc/tcg-target.h |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/tcg/ppc/tcg-target.h b/tcg/ppc/tcg-target.h
index ea26769..0fdad04 100644
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -99,6 +99,6 @@ typedef enum {
#define tcg_qemu_tb_exec(env, tb_ptr) \
((long __attribute__ ((longcall)) \
- (*)(void *, void *))code_gen_prologue)(env, tb_ptr)
+ (*)(void *, void *))tcg_ctx.code_gen_prologue)(env, tb_ptr)
#endif
--
1.7.10.4
Re: [Qemu-devel] qemu on MacOS, failing to respond to ctrl-C
On Sun, Feb 17, 2013 at 12:59 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 17 February 2013 00:19, Peter Maydell peter.mayd...@linaro.org wrote: [why doesn't MacOS QEMU exit on ctrl-C?] What seems to happen is that the other thread nips in and does the sigreturn/sigprocmask/sigaltstack stuff, and it's messing with the signal mask for the whole process. (dtruss also tell me 0x6f8c53 is the TCG CPU thread.) Found it! The culprit is the setjmp/longjmp in cpu-exec.c. On Linux these don't save and restore the process signal mask (you use sigsetjmp/siglongjmp for that). However on BSD setjmp and longjmp do save and restore the process signal mask, so when we do the longjmp in the CPU thread we end up setting the mask for every thread to the restrictive mask used by the CPU thread. Then SIGTERM and SIGINT are blocked for every thread and have no effect on QEMU. So, we can fix this MacOS issue by replacing all our current setjmp() and longjmp() with sigsetjmp(buf, 0) and siglongjmp() [which is the POSIX mandated way to say definitely don't change the signal mask, avoiding the undefined effect on the signal mask that plain longjmp has.] (I guess that might require some compat layer for win32 builds, which is trivial enough.) However, having thought about this I'm now a bit dubious about the use of longjmp in cpu_resume_from_signal() -- this is jumping out of a signal handler, so if we do nothing with the signal mask surely we'll end up running the CPU thread with that signal blocked when it was not before? I don't know why this doesn't cause issues on Linux... Long time ago, QEMU did not use any threads. They were introduced by CONFIG_IOTHREAD which then took over. -- PMM
Re: [Qemu-devel] [PATCH v2 0/3] Improve 64-bit widening multiply
Thanks, applied. On Sat, Feb 16, 2013 at 8:46 PM, Richard Henderson r...@twiddle.net wrote: Version 2 is a simple rebase and conflict fix in the tests/Makefile. r~ Richard Henderson (3): host-utils: Use __int128_t for mul[us]64 host-utils: Improve mulu64 and muls64 tests: Add unit tests for mulu64 and muls64 configure | 20 ++ include/qemu/host-utils.h | 17 - tests/Makefile| 6 ++- tests/test-mul64.c| 70 ++ util/host-utils.c | 96 --- 5 files changed, 143 insertions(+), 66 deletions(-) create mode 100644 tests/test-mul64.c -- 1.8.1.2
[Qemu-devel] Kernel kvm config
Hi, I use qem-kvm version 1.1.2 on debian testing with kernel 3.6.8. On this kernel the kvm-modules load ok: $ lsmod | grep kvm kvm_intel 114592 0 kvm 219460 1 kvm_intel My hardware should support this also : $ egrep --color vmx|svm /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow vnmi flexpriority I tried last week to upgrade to kernel 3.7.8 (trying to solve another problem), downloaded from kernel.org. As I get, during boot, an error Failed to load module kvm_intel , I checked the kernel config and to my surprise I can not select the kvm nor kvm_intel modules anymore during configuration in menuconfig on this new kernel. This is what I see: --- Virtualization │ │ │ │ M Host kernel accelerator for virtio net (EXPERIMENTAL) │ │ │ │ Linux hypervisor example code │ │ │ │ Are these modules kvm /kvm_intel no longer there/needed? Do these modules depend on another option in kernel ? I do see newest qemu version is already at 1.4. Any pointer is appreciated. Thanks and best regards, Johan
[Qemu-devel] [PATCH] vmxcap: Report APIC register emulation
From: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- scripts/kvm/vmxcap |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap index a1a44a0..bcf79f6 100755 --- a/scripts/kvm/vmxcap +++ b/scripts/kvm/vmxcap @@ -161,6 +161,7 @@ controls = [ 5: 'Enable VPID', 6: 'WBINVD exiting', 7: 'Unrestricted guest', +8: 'APIC register emulation', 9: 'Virtual interrupt delivery', 10: 'PAUSE-loop exiting', 11: 'RDRAND exiting', -- 1.7.3.4
Re: [Qemu-devel] qemu on MacOS, failing to respond to ctrl-C
On 17 February 2013 15:50, Blue Swirl blauwir...@gmail.com wrote: On Sun, Feb 17, 2013 at 12:59 AM, Peter Maydell peter.mayd...@linaro.org wrote: However, having thought about this I'm now a bit dubious about the use of longjmp in cpu_resume_from_signal() -- this is jumping out of a signal handler, so if we do nothing with the signal mask surely we'll end up running the CPU thread with that signal blocked when it was not before? I don't know why this doesn't cause issues on Linux... Long time ago, QEMU did not use any threads. They were introduced by CONFIG_IOTHREAD which then took over. Yes, but even in a single-threaded model, if you longjmp out of a signal handler for SIGSEGV or whatever then SIGSEGV is going to remain blocked by mistake... -- PMM
[Qemu-devel] [PATCH RFT v3 3/5] usb/hcd-ehci: Add Tegra2 SysBus EHCI device
From: Andreas Färber andreas.faer...@web.de
This prepares an EHCI device for the Nvidia Tegra2 SoC family.
Values based on patch by Vincent Palatin and verified against TRM v01p.
Cc: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
hw/usb/hcd-ehci-sysbus.c | 15 +++
hw/usb/hcd-ehci.h|1 +
2 Dateien geändert, 16 Zeilen hinzugefügt(+)
diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
index 92594a2..5806b0a 100644
--- a/hw/usb/hcd-ehci-sysbus.c
+++ b/hw/usb/hcd-ehci-sysbus.c
@@ -104,11 +104,26 @@ static const TypeInfo ehci_exynos4210_type_info = {
.class_init= ehci_exynos4210_class_init,
};
+static void ehci_tegra2_class_init(ObjectClass *oc, void *data)
+{
+SysBusEHCIClass *sec = SYS_BUS_EHCI_CLASS(oc);
+
+sec-capsbase = 0x100;
+sec-opregbase = 0x140;
+}
+
+static const TypeInfo ehci_tegra2_type_info = {
+.name = TYPE_TEGRA2_EHCI,
+.parent= TYPE_SYS_BUS_EHCI,
+.class_init= ehci_tegra2_class_init,
+};
+
static void ehci_sysbus_register_types(void)
{
type_register_static(ehci_type_info);
type_register_static(ehci_xlnx_type_info);
type_register_static(ehci_exynos4210_type_info);
+type_register_static(ehci_tegra2_type_info);
}
type_init(ehci_sysbus_register_types)
diff --git a/hw/usb/hcd-ehci.h b/hw/usb/hcd-ehci.h
index d0e847d..951b117 100644
--- a/hw/usb/hcd-ehci.h
+++ b/hw/usb/hcd-ehci.h
@@ -339,6 +339,7 @@ typedef struct EHCIPCIState {
#define TYPE_SYS_BUS_EHCI sysbus-ehci-usb
#define TYPE_EXYNOS4210_EHCI exynos4210-ehci-usb
+#define TYPE_TEGRA2_EHCI tegra2-ehci-usb
#define SYS_BUS_EHCI(obj) \
OBJECT_CHECK(EHCISysBusState, (obj), TYPE_SYS_BUS_EHCI)
--
1.7.10.4
[Qemu-devel] [PATCH RFT v3 0/5] usb: QOM realize support for SysBus EHCI and FUSBH200
Hello Gerd and Kuo-Jung, This series combines my revoked QOM realize patch with Kuo-Jung's series adding Faraday FUSBH200 EHCI and my Tegra2 EHCI. To facilitate adaptations for the Faraday EHCI, I am taking my QOM realize factoring further. This avoids having to introduce a class for FUSBH200 by reusing QOM instance_init infrastructure rather than realize. It simplifies overriding portscbase and portnr by setting the current values in ehci_sysbus_class_init rather than per subclass. This means less values to specify for Tegra EHCI. It also cleans up FUSBH200 code a little by introducing enum values for the register offsets (possibly to be moved to a header one day for qtest). Obviously I have no clue whether the names match any spec, please check, I made a guess based on the code comments. Only lightly tested, seeing that -device usb-ehci (PCI) doesn't segfault. Regards, Andreas v1 - v3: * Renamed realizefn - realize following a discussion with Anthony. * Rename usb_ehci_initfn - usb_ehci_realize. * Split off instance_init from initfn / realize, with Faraday in mind. * Incorporated Kuo-Jung's v1 EHCI refactoring + FUSBH200 EHCI. * Merged Kuo-Jung's v2 PCI initialization. From Kuo-Jung's FUSBH200/PORTSC v1/v2: * Moved old portscbase and portnr values into base class_init. * Moved mem_vendor field to new FUSBH200EHCIState. * Replace vendor init callback with derived instance_init. * Introduced enum for vendor registers. * Replace magic number 0x34 with formula, so that it doesn't deviate. From my Tegra2 FYI patch: * None. Cc: Gerd Hoffmann kra...@redhat.com Cc: Kuo-Jung Su dant...@faraday-tech.com Cc: Peter Crosthwaite peter.crosthwa...@xilinx.com Cc: Igor Mitsyanko i.mitsya...@samsung.com Cc: Liming Wang walimis...@gmail.com Andreas Färber (3): usb/hcd-ehci-sysbus: Convert to QOM realize usb/hcd-ehci: Split off instance_init from realize usb/hcd-ehci: Add Tegra2 SysBus EHCI device Kuo-Jung Su (2): usb/hcd-ehci: Replace PORTSC macros with variables usb/hcd-ehci: Add Faraday FUSBH200 support hw/usb/hcd-ehci-pci.c| 23 ++--- hw/usb/hcd-ehci-sysbus.c | 121 +++--- hw/usb/hcd-ehci.c| 47 +++--- hw/usb/hcd-ehci.h| 28 --- 4 Dateien geändert, 180 Zeilen hinzugefügt(+), 39 Zeilen entfernt(-) -- 1.7.10.4
[Qemu-devel] [PATCH RFT v3 5/5] usb/hcd-ehci: Add Faraday FUSBH200 support
From: Kuo-Jung Su dant...@faraday-tech.com
Add Faraday FUSBH200 support, which is slightly different from EHCI spec.
(Or maybe simply a bad/wrong implementation...)
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/usb/hcd-ehci-sysbus.c | 75 ++
hw/usb/hcd-ehci.h| 12
2 Dateien geändert, 87 Zeilen hinzugefügt(+)
diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
index 106d132..bf7788b 100644
--- a/hw/usb/hcd-ehci-sysbus.c
+++ b/hw/usb/hcd-ehci-sysbus.c
@@ -124,12 +124,87 @@ static const TypeInfo ehci_tegra2_type_info = {
.class_init= ehci_tegra2_class_init,
};
+/*
+ * Faraday FUSBH200 USB 2.0 EHCI
+ */
+
+/**
+ * FUSBH200EHCIRegs:
+ * @FUSBH200_REG_EOF_ASTR: EOF/Async. Sleep Timer Register
+ * @FUSBH200_REG_BMCSR: Bus Monitor Control/Status Register
+ */
+enum FUSBH200EHCIRegs {
+FUSBH200_REG_EOF_ASTR = 0x34,
+FUSBH200_REG_BMCSR= 0x40,
+};
+
+static uint64_t fusbh200_ehci_read(void *opaque, hwaddr addr, unsigned size)
+{
+EHCIState *s = opaque;
+hwaddr off = s-opregbase + s-portscbase + 4 * s-portnr + addr;
+
+switch (off) {
+case FUSBH200_REG_EOF_ASTR:
+return 0x0041;
+case FUSBH200_REG_BMCSR:
+/* High-Speed, VBUS valid, interrupt level-high active */
+return (2 9) | (1 8) | (1 3);
+}
+
+return 0;
+}
+
+static void fusbh200_ehci_write(void *opaque, hwaddr addr, uint64_t val,
+unsigned size)
+{
+}
+
+static const MemoryRegionOps fusbh200_ehci_mmio_ops = {
+.read = fusbh200_ehci_read,
+.write = fusbh200_ehci_write,
+.valid.min_access_size = 4,
+.valid.max_access_size = 4,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void fusbh200_ehci_init(Object *obj)
+{
+EHCISysBusState *i = SYS_BUS_EHCI(obj);
+FUSBH200EHCIState *f = FUSBH200_EHCI(obj);
+EHCIState *s = i-ehci;
+
+memory_region_init_io(f-mem_vendor, fusbh200_ehci_mmio_ops, s,
+ fusbh200, 0x4c);
+memory_region_add_subregion(s-mem,
+s-opregbase + s-portscbase + 4 * s-portnr,
+f-mem_vendor);
+}
+
+static void fusbh200_ehci_class_init(ObjectClass *oc, void *data)
+{
+SysBusEHCIClass *sec = SYS_BUS_EHCI_CLASS(oc);
+
+sec-capsbase = 0x0;
+sec-opregbase = 0x10;
+sec-portscbase = 0x20;
+sec-portnr = 1;
+}
+
+static const TypeInfo ehci_fusbh200_type_info = {
+.name = TYPE_FUSBH200_EHCI,
+.parent= TYPE_SYS_BUS_EHCI,
+.instance_size = sizeof(FUSBH200EHCIState),
+.instance_init = fusbh200_ehci_init,
+.class_init= fusbh200_ehci_class_init,
+};
+
static void ehci_sysbus_register_types(void)
{
type_register_static(ehci_type_info);
type_register_static(ehci_xlnx_type_info);
type_register_static(ehci_exynos4210_type_info);
type_register_static(ehci_tegra2_type_info);
+type_register_static(ehci_fusbh200_type_info);
}
type_init(ehci_sysbus_register_types)
diff --git a/hw/usb/hcd-ehci.h b/hw/usb/hcd-ehci.h
index 7629762..b20c20e 100644
--- a/hw/usb/hcd-ehci.h
+++ b/hw/usb/hcd-ehci.h
@@ -338,6 +338,7 @@ typedef struct EHCIPCIState {
#define TYPE_SYS_BUS_EHCI sysbus-ehci-usb
#define TYPE_EXYNOS4210_EHCI exynos4210-ehci-usb
#define TYPE_TEGRA2_EHCI tegra2-ehci-usb
+#define TYPE_FUSBH200_EHCI fusbh200-ehci-usb
#define SYS_BUS_EHCI(obj) \
OBJECT_CHECK(EHCISysBusState, (obj), TYPE_SYS_BUS_EHCI)
@@ -365,4 +366,15 @@ typedef struct SysBusEHCIClass {
uint16_t portnr;
} SysBusEHCIClass;
+#define FUSBH200_EHCI(obj) \
+OBJECT_CHECK(FUSBH200EHCIState, (obj), TYPE_FUSBH200_EHCI)
+
+typedef struct FUSBH200EHCIState {
+/* private */
+EHCISysBusState parent_obj;
+/* public */
+
+MemoryRegion mem_vendor;
+} FUSBH200EHCIState;
+
#endif
--
1.7.10.4
[Qemu-devel] [PATCH RFT v3 2/5] usb/hcd-ehci: Split off instance_init from realize
This makes the mem MemoryRegion available to derived instance_inits.
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/usb/hcd-ehci-pci.c| 19 ++-
hw/usb/hcd-ehci-sysbus.c | 16 +---
hw/usb/hcd-ehci.c| 25 +++--
hw/usb/hcd-ehci.h|1 +
4 Dateien geändert, 43 Zeilen hinzugefügt(+), 18 Zeilen entfernt(-)
diff --git a/hw/usb/hcd-ehci-pci.c b/hw/usb/hcd-ehci-pci.c
index 70fc65e..05b4a6d 100644
--- a/hw/usb/hcd-ehci-pci.c
+++ b/hw/usb/hcd-ehci-pci.c
@@ -60,20 +60,28 @@ static int usb_ehci_pci_initfn(PCIDevice *dev)
pci_conf[0x6e] = 0x00;
pci_conf[0x6f] = 0xc0; /* USBLEFCTLSTS */
-s-caps[0x09] = 0x68;/* EECP */
-
s-irq = dev-irq[3];
s-dma = pci_dma_context(dev);
-s-capsbase = 0x00;
-s-opregbase = 0x20;
-
usb_ehci_realize(s, DEVICE(dev), NULL);
pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, s-mem);
return 0;
}
+static void usb_ehci_pci_init(Object *obj)
+{
+EHCIPCIState *i = PCI_EHCI(obj);
+EHCIState *s = i-ehci;
+
+s-caps[0x09] = 0x68;/* EECP */
+
+s-capsbase = 0x00;
+s-opregbase = 0x20;
+
+usb_ehci_init(s, DEVICE(obj));
+}
+
static void usb_ehci_pci_write_config(PCIDevice *dev, uint32_t addr,
uint32_t val, int l)
{
@@ -122,6 +130,7 @@ static const TypeInfo ehci_pci_type_info = {
.name = TYPE_PCI_EHCI,
.parent = TYPE_PCI_DEVICE,
.instance_size = sizeof(EHCIPCIState),
+.instance_init = usb_ehci_pci_init,
.abstract = true,
.class_init = ehci_class_init,
};
diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
index 4be3d17..92594a2 100644
--- a/hw/usb/hcd-ehci-sysbus.c
+++ b/hw/usb/hcd-ehci-sysbus.c
@@ -36,15 +36,24 @@ static void usb_ehci_sysbus_realize(DeviceState *dev, Error
**errp)
{
SysBusDevice *d = SYS_BUS_DEVICE(dev);
EHCISysBusState *i = SYS_BUS_EHCI(dev);
-SysBusEHCIClass *sec = SYS_BUS_EHCI_GET_CLASS(dev);
+EHCIState *s = i-ehci;
+
+usb_ehci_realize(s, dev, errp);
+sysbus_init_irq(d, s-irq);
+}
+
+static void ehci_sysbus_init(Object *obj)
+{
+SysBusDevice *d = SYS_BUS_DEVICE(obj);
+EHCISysBusState *i = SYS_BUS_EHCI(obj);
+SysBusEHCIClass *sec = SYS_BUS_EHCI_GET_CLASS(obj);
EHCIState *s = i-ehci;
s-capsbase = sec-capsbase;
s-opregbase = sec-opregbase;
s-dma = dma_context_memory;
-usb_ehci_realize(s, dev, errp);
-sysbus_init_irq(d, s-irq);
+usb_ehci_init(s, DEVICE(obj));
sysbus_init_mmio(d, s-mem);
}
@@ -61,6 +70,7 @@ static const TypeInfo ehci_type_info = {
.name = TYPE_SYS_BUS_EHCI,
.parent= TYPE_SYS_BUS_DEVICE,
.instance_size = sizeof(EHCISysBusState),
+.instance_init = ehci_sysbus_init,
.abstract = true,
.class_init= ehci_sysbus_class_init,
.class_size= sizeof(SysBusEHCIClass),
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 3d20556..b233c8f 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -2505,6 +2505,21 @@ void usb_ehci_realize(EHCIState *s, DeviceState *dev,
Error **errp)
{
int i;
+for (i = 0; i NB_PORTS; i++) {
+usb_register_port(s-bus, s-ports[i], s, i, ehci_port_ops,
+ USB_SPEED_MASK_HIGH);
+s-ports[i].dev = 0;
+}
+
+s-frame_timer = qemu_new_timer_ns(vm_clock, ehci_frame_timer, s);
+s-async_bh = qemu_bh_new(ehci_frame_timer, s);
+
+qemu_register_reset(ehci_reset, s);
+qemu_add_vm_change_state_handler(usb_ehci_vm_state_change, s);
+}
+
+void usb_ehci_init(EHCIState *s, DeviceState *dev)
+{
/* 2.2 host controller interface version */
s-caps[0x00] = (uint8_t)(s-opregbase - s-capsbase);
s-caps[0x01] = 0x00;
@@ -2519,21 +2534,11 @@ void usb_ehci_realize(EHCIState *s, DeviceState *dev,
Error **errp)
s-caps[0x0b] = 0x00;
usb_bus_new(s-bus, ehci_bus_ops, dev);
-for(i = 0; i NB_PORTS; i++) {
-usb_register_port(s-bus, s-ports[i], s, i, ehci_port_ops,
- USB_SPEED_MASK_HIGH);
-s-ports[i].dev = 0;
-}
-s-frame_timer = qemu_new_timer_ns(vm_clock, ehci_frame_timer, s);
-s-async_bh = qemu_bh_new(ehci_frame_timer, s);
QTAILQ_INIT(s-aqueues);
QTAILQ_INIT(s-pqueues);
usb_packet_init(s-ipacket);
-qemu_register_reset(ehci_reset, s);
-qemu_add_vm_change_state_handler(usb_ehci_vm_state_change, s);
-
memory_region_init(s-mem, ehci, MMIO_SIZE);
memory_region_init_io(s-mem_caps, ehci_mmio_caps_ops, s,
capabilities, CAPA_SIZE);
diff --git a/hw/usb/hcd-ehci.h b/hw/usb/hcd-ehci.h
index 8105fcb..d0e847d 100644
--- a/hw/usb/hcd-ehci.h
+++ b/hw/usb/hcd-ehci.h
@@ -322,6 +322,7 @@ struct EHCIState {
extern const VMStateDescription vmstate_ehci;
+void usb_ehci_init(EHCIState *s, DeviceState *dev);
void usb_ehci_realize(EHCIState *s, DeviceState *dev, Error **errp);
[Qemu-devel] [PATCH qom-cpu v3 0/2] target-sh4: SuperHCPU subclasses
Hello Aurélien, This series introduces SuperH CPU subclasses. The first conversion to QOM patch had used a declarative approach reusing sh4_def_t as SuperHCPUInfo. This approach now uses imperative instance_init functions. To preserve -cpu ? output and case-insensitivity, distinct name and type name are used, but allowing use of the type name as done for alpha. v2 got no review feedback. v3 resolves two TODOs, fixing a potential assertion and moving CPU code out of translate.c. That way cpu_init() is easier locatable across targets and CPU init refactorings are less likely to trigger rebuild of translation. Based on my pending qom-cpu pull request. Available for testing at: git://github.com/afaerber/qemu-cpu.git qom-cpu-sh4-classes.v3 https://github.com/afaerber/qemu-cpu/commits/qom-cpu-sh4-classes.v3 Regards, Andreas v2 - v3: * Added check for new object_class_is_abstract(). * Moved superh_cpu_class_by_name() and cpu_sh4_init() to cpu.c. v2: * Fixed bug in class name comparison, spotted by Igor. * Refactored name - ObjectClass mapping into new function. * Moved realizefn patch into CPUState series, rebased. v1 - preview on GitHub: * Redone, using combination of initfn and class_init instead of SuperHCPUInfo. * Adopted naming scheme suggested by Eduardo. * Split out SuperHCPUClass field movements into separate patch. Cc: Aurélien Jarno aurel...@aurel32.net Andreas Färber (2): target-sh4: Introduce SuperHCPU subclasses target-sh4: Move PVR/PRR/CVR into SuperHCPUClass hw/sh7750.c| 10 ++- target-sh4/cpu-qom.h | 13 target-sh4/cpu.c | 180 +++- target-sh4/cpu.h |3 - target-sh4/translate.c | 84 -- 5 Dateien geändert, 199 Zeilen hinzugefügt(+), 91 Zeilen entfernt(-) -- 1.7.10.4
[Qemu-devel] [PATCH RFT v3 1/5] usb/hcd-ehci-sysbus: Convert to QOM realize
The SysBus qdev initfn merely calls SysBusDeviceClass::init, so we can
replace it with a realizefn already. This avoids getting into any initfn
ambiguity with the upcoming Faraday EHCI implementation.
Rename internal usb_ehci_initfn() to usb_ehci_realize() to allow to
return Errors from common initialization code as well.
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/usb/hcd-ehci-pci.c|2 +-
hw/usb/hcd-ehci-sysbus.c | 13 ++---
hw/usb/hcd-ehci.c|2 +-
hw/usb/hcd-ehci.h|2 +-
4 Dateien geändert, 9 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
diff --git a/hw/usb/hcd-ehci-pci.c b/hw/usb/hcd-ehci-pci.c
index 0eb7826..70fc65e 100644
--- a/hw/usb/hcd-ehci-pci.c
+++ b/hw/usb/hcd-ehci-pci.c
@@ -68,7 +68,7 @@ static int usb_ehci_pci_initfn(PCIDevice *dev)
s-capsbase = 0x00;
s-opregbase = 0x20;
-usb_ehci_initfn(s, DEVICE(dev));
+usb_ehci_realize(s, DEVICE(dev), NULL);
pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, s-mem);
return 0;
diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
index b68a66a..4be3d17 100644
--- a/hw/usb/hcd-ehci-sysbus.c
+++ b/hw/usb/hcd-ehci-sysbus.c
@@ -32,8 +32,9 @@ static Property ehci_sysbus_properties[] = {
DEFINE_PROP_END_OF_LIST(),
};
-static int usb_ehci_sysbus_initfn(SysBusDevice *dev)
+static void usb_ehci_sysbus_realize(DeviceState *dev, Error **errp)
{
+SysBusDevice *d = SYS_BUS_DEVICE(dev);
EHCISysBusState *i = SYS_BUS_EHCI(dev);
SysBusEHCIClass *sec = SYS_BUS_EHCI_GET_CLASS(dev);
EHCIState *s = i-ehci;
@@ -42,18 +43,16 @@ static int usb_ehci_sysbus_initfn(SysBusDevice *dev)
s-opregbase = sec-opregbase;
s-dma = dma_context_memory;
-usb_ehci_initfn(s, DEVICE(dev));
-sysbus_init_irq(dev, s-irq);
-sysbus_init_mmio(dev, s-mem);
-return 0;
+usb_ehci_realize(s, dev, errp);
+sysbus_init_irq(d, s-irq);
+sysbus_init_mmio(d, s-mem);
}
static void ehci_sysbus_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
-SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
-k-init = usb_ehci_sysbus_initfn;
+dc-realize = usb_ehci_sysbus_realize;
dc-vmsd = vmstate_ehci_sysbus;
dc-props = ehci_sysbus_properties;
}
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 7040659..3d20556 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -2501,7 +2501,7 @@ const VMStateDescription vmstate_ehci = {
}
};
-void usb_ehci_initfn(EHCIState *s, DeviceState *dev)
+void usb_ehci_realize(EHCIState *s, DeviceState *dev, Error **errp)
{
int i;
diff --git a/hw/usb/hcd-ehci.h b/hw/usb/hcd-ehci.h
index e95bb7e..8105fcb 100644
--- a/hw/usb/hcd-ehci.h
+++ b/hw/usb/hcd-ehci.h
@@ -322,7 +322,7 @@ struct EHCIState {
extern const VMStateDescription vmstate_ehci;
-void usb_ehci_initfn(EHCIState *s, DeviceState *dev);
+void usb_ehci_realize(EHCIState *s, DeviceState *dev, Error **errp);
#define TYPE_PCI_EHCI pci-ehci-usb
#define PCI_EHCI(obj) OBJECT_CHECK(EHCIPCIState, (obj), TYPE_PCI_EHCI)
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu v3 2/2] target-sh4: Move PVR/PRR/CVR into SuperHCPUClass
They are never changed once initialized, and moving them to the class
will allow to inspect them before instantiating.
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/sh7750.c | 10 +++---
target-sh4/cpu-qom.h |6 ++
target-sh4/cpu.c | 18 +-
target-sh4/cpu.h |3 ---
4 Dateien geändert, 22 Zeilen hinzugefügt(+), 15 Zeilen entfernt(-)
diff --git a/hw/sh7750.c b/hw/sh7750.c
index 666f865..2259b59 100644
--- a/hw/sh7750.c
+++ b/hw/sh7750.c
@@ -255,6 +255,7 @@ static uint32_t sh7750_mem_readw(void *opaque, hwaddr addr)
static uint32_t sh7750_mem_readl(void *opaque, hwaddr addr)
{
SH7750State *s = opaque;
+SuperHCPUClass *scc;
switch (addr) {
case SH7750_BCR1_A7:
@@ -288,11 +289,14 @@ static uint32_t sh7750_mem_readl(void *opaque, hwaddr
addr)
case SH7750_CCR_A7:
return s-ccr;
case 0x1f30: /* Processor version */
- return s-cpu-pvr;
+scc = SUPERH_CPU_GET_CLASS(s-cpu);
+return scc-pvr;
case 0x1f40: /* Cache version */
- return s-cpu-cvr;
+scc = SUPERH_CPU_GET_CLASS(s-cpu);
+return scc-cvr;
case 0x1f44: /* Processor revision */
- return s-cpu-prr;
+scc = SUPERH_CPU_GET_CLASS(s-cpu);
+return scc-prr;
default:
error_access(long read, addr);
abort();
diff --git a/target-sh4/cpu-qom.h b/target-sh4/cpu-qom.h
index 8326ceb..b264be7 100644
--- a/target-sh4/cpu-qom.h
+++ b/target-sh4/cpu-qom.h
@@ -40,6 +40,9 @@
* @parent_realize: The parent class' realize handler.
* @parent_reset: The parent class' reset handler.
* @name: The name.
+ * @pvr: Processor Version Register
+ * @prr: Processor Revision Register
+ * @cvr: Cache Version Register
*
* A SuperH CPU model.
*/
@@ -52,6 +55,9 @@ typedef struct SuperHCPUClass {
void (*parent_reset)(CPUState *cpu);
const char *name;
+uint32_t pvr;
+uint32_t prr;
+uint32_t cvr;
} SuperHCPUClass;
/**
diff --git a/target-sh4/cpu.c b/target-sh4/cpu.c
index fba1534..5251aa0 100644
--- a/target-sh4/cpu.c
+++ b/target-sh4/cpu.c
@@ -156,9 +156,6 @@ static void sh7750r_cpu_initfn(Object *obj)
CPUSH4State *env = cpu-env;
env-id = SH_CPU_SH7750R;
-env-pvr = 0x0005;
-env-prr = 0x0100;
-env-cvr = 0x0011;
env-features = SH_FEATURE_BCR3_AND_BCR4;
}
@@ -167,6 +164,9 @@ static void sh7750r_class_init(ObjectClass *oc, void *data)
SuperHCPUClass *scc = SUPERH_CPU_CLASS(oc);
scc-name = SH7750R;
+scc-pvr = 0x0005;
+scc-prr = 0x0100;
+scc-cvr = 0x0011;
}
static const TypeInfo sh7750r_type_info = {
@@ -182,9 +182,6 @@ static void sh7751r_cpu_initfn(Object *obj)
CPUSH4State *env = cpu-env;
env-id = SH_CPU_SH7751R;
-env-pvr = 0x04050005;
-env-prr = 0x0113;
-env-cvr = 0x0011; /* Neutered caches, should be 0x2048 */
env-features = SH_FEATURE_BCR3_AND_BCR4;
}
@@ -193,6 +190,9 @@ static void sh7751r_class_init(ObjectClass *oc, void *data)
SuperHCPUClass *scc = SUPERH_CPU_CLASS(oc);
scc-name = SH7751R;
+scc-pvr = 0x04050005;
+scc-prr = 0x0113;
+scc-cvr = 0x0011; /* Neutered caches, should be 0x2048 */
}
static const TypeInfo sh7751r_type_info = {
@@ -208,9 +208,6 @@ static void sh7785_cpu_initfn(Object *obj)
CPUSH4State *env = cpu-env;
env-id = SH_CPU_SH7785;
-env-pvr = 0x10300700;
-env-prr = 0x0200;
-env-cvr = 0x71440211;
env-features = SH_FEATURE_SH4A;
}
@@ -219,6 +216,9 @@ static void sh7785_class_init(ObjectClass *oc, void *data)
SuperHCPUClass *scc = SUPERH_CPU_CLASS(oc);
scc-name = SH7785;
+scc-pvr = 0x10300700;
+scc-prr = 0x0200;
+scc-cvr = 0x71440211;
}
static const TypeInfo sh7785_type_info = {
diff --git a/target-sh4/cpu.h b/target-sh4/cpu.h
index 49dcd9e..f805778 100644
--- a/target-sh4/cpu.h
+++ b/target-sh4/cpu.h
@@ -179,9 +179,6 @@ typedef struct CPUSH4State {
CPU_COMMON
int id;/* CPU model */
-uint32_t pvr; /* Processor Version Register */
-uint32_t prr; /* Processor Revision Register */
-uint32_t cvr; /* Cache Version Register */
void *intc_handle;
int in_sleep; /* SR_BL ignored during sleep */
--
1.7.10.4
Re: [Qemu-devel] [PATCH v3 01/20] arm: add Faraday a360 SoC platform support
Am 06.02.2013 10:45, schrieb Kuo-Jung Su:
+typedef struct FaradayMachState {
+ARMCPU *cpu;
+DeviceState *scu;
+DeviceState *ahbc;
+DeviceState *ddrc;
+DeviceState *hdma[2]; /* AHB DMA */
+DeviceState *pdma[2]; /* APB DMA */
+i2c_bus *i2c[2];
+
+MemoryRegion *as;
+MemoryRegion *ram;
+MemoryRegion *ram_alias;
+pflash_t *rom;
+MemoryRegion *sram;
+
+uint32_t ahb_slave4;/* AHB slave 4 default value */
+uint32_t ahb_slave6;/* AHB slave 6 default value */
+uint32_t ahb_remapped:1;
+uint32_t ddr_inited:1;
+} FaradayMachState;
I think you need to distinguish what's on the SoC and what's on the
evaluation board there...
For the SoC you can have a QOM type with DeviceState parent, but the
stuff on the board should stay separate. Instead of pointers you should
use the actual types (i.e., add field when you introduce the device
model). This will work out-of-the box for your own devices and will work
for ARMCPU once my pull is applied. The purpose would be container-like
grouping of devices and sharing across boards.
However, as Peter pointed out, devices should avoid fiddling with each
other's internals even if they have access to a pointer/field.
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
[Qemu-devel] [PATCH qom-cpu v3 1/2] target-sh4: Introduce SuperHCPU subclasses
Store legacy name in SuperHCPUClass for -cpu ? and for case-insensitive
class lookup.
List CPUs by iterating over TYPE_SUPERH_CPU subclasses.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-sh4/cpu-qom.h |7 ++
target-sh4/cpu.c | 180 +++-
target-sh4/translate.c | 84 --
3 Dateien geändert, 186 Zeilen hinzugefügt(+), 85 Zeilen entfernt(-)
diff --git a/target-sh4/cpu-qom.h b/target-sh4/cpu-qom.h
index d368db1..8326ceb 100644
--- a/target-sh4/cpu-qom.h
+++ b/target-sh4/cpu-qom.h
@@ -24,6 +24,10 @@
#define TYPE_SUPERH_CPU superh-cpu
+#define TYPE_SH7750R_CPU sh7750r- TYPE_SUPERH_CPU
+#define TYPE_SH7751R_CPU sh7751r- TYPE_SUPERH_CPU
+#define TYPE_SH7785_CPU sh7785- TYPE_SUPERH_CPU
+
#define SUPERH_CPU_CLASS(klass) \
OBJECT_CLASS_CHECK(SuperHCPUClass, (klass), TYPE_SUPERH_CPU)
#define SUPERH_CPU(obj) \
@@ -35,6 +39,7 @@
* SuperHCPUClass:
* @parent_realize: The parent class' realize handler.
* @parent_reset: The parent class' reset handler.
+ * @name: The name.
*
* A SuperH CPU model.
*/
@@ -45,6 +50,8 @@ typedef struct SuperHCPUClass {
DeviceRealize parent_realize;
void (*parent_reset)(CPUState *cpu);
+
+const char *name;
} SuperHCPUClass;
/**
diff --git a/target-sh4/cpu.c b/target-sh4/cpu.c
index ef0e621..fba1534 100644
--- a/target-sh4/cpu.c
+++ b/target-sh4/cpu.c
@@ -54,6 +54,180 @@ static void superh_cpu_reset(CPUState *s)
set_default_nan_mode(1, env-fp_status);
}
+typedef struct SuperHCPUListState {
+fprintf_function cpu_fprintf;
+FILE *file;
+} SuperHCPUListState;
+
+/* Sort alphabetically by type name. */
+static gint superh_cpu_list_compare(gconstpointer a, gconstpointer b)
+{
+ObjectClass *class_a = (ObjectClass *)a;
+ObjectClass *class_b = (ObjectClass *)b;
+const char *name_a, *name_b;
+
+name_a = object_class_get_name(class_a);
+name_b = object_class_get_name(class_b);
+return strcmp(name_a, name_b);
+}
+
+static void superh_cpu_list_entry(gpointer data, gpointer user_data)
+{
+ObjectClass *oc = data;
+SuperHCPUClass *scc = SUPERH_CPU_CLASS(oc);
+SuperHCPUListState *s = user_data;
+
+(*s-cpu_fprintf)(s-file, %s\n,
+ scc-name);
+}
+
+void sh4_cpu_list(FILE *f, fprintf_function cpu_fprintf)
+{
+SuperHCPUListState s = {
+.cpu_fprintf = cpu_fprintf,
+.file = f,
+};
+GSList *list;
+
+list = object_class_get_list(TYPE_SUPERH_CPU, false);
+list = g_slist_sort(list, superh_cpu_list_compare);
+g_slist_foreach(list, superh_cpu_list_entry, s);
+g_slist_free(list);
+}
+
+static gint superh_cpu_name_compare(gconstpointer a, gconstpointer b)
+{
+const SuperHCPUClass *scc = SUPERH_CPU_CLASS(a);
+const char *name = b;
+
+return strcasecmp(scc-name, name);
+}
+
+static ObjectClass *superh_cpu_class_by_name(const char *cpu_model)
+{
+ObjectClass *oc;
+GSList *list, *item;
+
+if (cpu_model == NULL) {
+return NULL;
+}
+if (strcasecmp(cpu_model, any) == 0) {
+return object_class_by_name(TYPE_SH7750R_CPU);
+}
+
+oc = object_class_by_name(cpu_model);
+if (oc != NULL object_class_dynamic_cast(oc, TYPE_SUPERH_CPU) != NULL
+ !object_class_is_abstract(oc)) {
+return oc;
+}
+
+oc = NULL;
+list = object_class_get_list(TYPE_SUPERH_CPU, false);
+item = g_slist_find_custom(list, cpu_model, superh_cpu_name_compare);
+if (item != NULL) {
+oc = item-data;
+}
+g_slist_free(list);
+return oc;
+}
+
+SuperHCPU *cpu_sh4_init(const char *cpu_model)
+{
+SuperHCPU *cpu;
+CPUSH4State *env;
+ObjectClass *oc;
+
+oc = superh_cpu_class_by_name(cpu_model);
+if (oc == NULL) {
+return NULL;
+}
+cpu = SUPERH_CPU(object_new(object_class_get_name(oc)));
+env = cpu-env;
+env-cpu_model_str = cpu_model;
+
+object_property_set_bool(OBJECT(cpu), true, realized, NULL);
+
+return cpu;
+}
+
+static void sh7750r_cpu_initfn(Object *obj)
+{
+SuperHCPU *cpu = SUPERH_CPU(obj);
+CPUSH4State *env = cpu-env;
+
+env-id = SH_CPU_SH7750R;
+env-pvr = 0x0005;
+env-prr = 0x0100;
+env-cvr = 0x0011;
+env-features = SH_FEATURE_BCR3_AND_BCR4;
+}
+
+static void sh7750r_class_init(ObjectClass *oc, void *data)
+{
+SuperHCPUClass *scc = SUPERH_CPU_CLASS(oc);
+
+scc-name = SH7750R;
+}
+
+static const TypeInfo sh7750r_type_info = {
+.name = TYPE_SH7750R_CPU,
+.parent = TYPE_SUPERH_CPU,
+.class_init = sh7750r_class_init,
+.instance_init = sh7750r_cpu_initfn,
+};
+
+static void sh7751r_cpu_initfn(Object *obj)
+{
+SuperHCPU *cpu = SUPERH_CPU(obj);
+CPUSH4State *env = cpu-env;
+
+env-id = SH_CPU_SH7751R;
+env-pvr = 0x04050005;
+env-prr = 0x0113;
+env-cvr = 0x0011; /* Neutered caches, should be 0x2048 */
+env-features = SH_FEATURE_BCR3_AND_BCR4;
+}
+
+static void
[Qemu-devel] [PATCH RFT v3 4/5] usb/hcd-ehci: Replace PORTSC macros with variables
From: Kuo-Jung Su dant...@faraday-tech.com
Replace PORTSC macros with variables which could then be
configured in ehci__class_init(...)
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/usb/hcd-ehci-pci.c|2 ++
hw/usb/hcd-ehci-sysbus.c |6 ++
hw/usb/hcd-ehci.c| 22 ++
hw/usb/hcd-ehci.h| 12 ++--
4 Dateien geändert, 28 Zeilen hinzugefügt(+), 14 Zeilen entfernt(-)
diff --git a/hw/usb/hcd-ehci-pci.c b/hw/usb/hcd-ehci-pci.c
index 05b4a6d..e534999 100644
--- a/hw/usb/hcd-ehci-pci.c
+++ b/hw/usb/hcd-ehci-pci.c
@@ -78,6 +78,8 @@ static void usb_ehci_pci_init(Object *obj)
s-capsbase = 0x00;
s-opregbase = 0x20;
+s-portscbase = 0x44;
+s-portnr = NB_PORTS;
usb_ehci_init(s, DEVICE(obj));
}
diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
index 5806b0a..106d132 100644
--- a/hw/usb/hcd-ehci-sysbus.c
+++ b/hw/usb/hcd-ehci-sysbus.c
@@ -51,6 +51,8 @@ static void ehci_sysbus_init(Object *obj)
s-capsbase = sec-capsbase;
s-opregbase = sec-opregbase;
+s-portscbase = sec-portscbase;
+s-portnr = sec-portnr;
s-dma = dma_context_memory;
usb_ehci_init(s, DEVICE(obj));
@@ -60,6 +62,10 @@ static void ehci_sysbus_init(Object *obj)
static void ehci_sysbus_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
+SysBusEHCIClass *sec = SYS_BUS_EHCI_CLASS(klass);
+
+sec-portscbase = 0x44;
+sec-portnr = NB_PORTS;
dc-realize = usb_ehci_sysbus_realize;
dc-vmsd = vmstate_ehci_sysbus;
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index b233c8f..35b4fc8 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -988,7 +988,7 @@ static uint64_t ehci_port_read(void *ptr, hwaddr addr,
uint32_t val;
val = s-portsc[addr 2];
-trace_usb_ehci_portsc_read(addr + PORTSC_BEGIN, addr 2, val);
+trace_usb_ehci_portsc_read(addr + s-portscbase, addr 2, val);
return val;
}
@@ -1029,7 +1029,7 @@ static void ehci_port_write(void *ptr, hwaddr addr,
uint32_t old = *portsc;
USBDevice *dev = s-ports[port].dev;
-trace_usb_ehci_portsc_write(addr + PORTSC_BEGIN, addr 2, val);
+trace_usb_ehci_portsc_write(addr + s-portscbase, addr 2, val);
/* Clear rwc bits */
*portsc = ~(val PORTSC_RWC_MASK);
@@ -1062,7 +1062,7 @@ static void ehci_port_write(void *ptr, hwaddr addr,
*portsc = ~PORTSC_RO_MASK;
*portsc |= val;
-trace_usb_ehci_portsc_change(addr + PORTSC_BEGIN, addr 2, *portsc, old);
+trace_usb_ehci_portsc_change(addr + s-portscbase, addr 2, *portsc,
old);
}
static void ehci_opreg_write(void *ptr, hwaddr addr,
@@ -2505,7 +2505,13 @@ void usb_ehci_realize(EHCIState *s, DeviceState *dev,
Error **errp)
{
int i;
-for (i = 0; i NB_PORTS; i++) {
+if (s-portnr NB_PORTS) {
+error_setg(errp, Too many ports! Max. port number is %d.,
+ NB_PORTS);
+return;
+}
+
+for (i = 0; i s-portnr; i++) {
usb_register_port(s-bus, s-ports[i], s, i, ehci_port_ops,
USB_SPEED_MASK_HIGH);
s-ports[i].dev = 0;
@@ -2525,7 +2531,7 @@ void usb_ehci_init(EHCIState *s, DeviceState *dev)
s-caps[0x01] = 0x00;
s-caps[0x02] = 0x00;
s-caps[0x03] = 0x01;/* HC version */
-s-caps[0x04] = NB_PORTS;/* Number of downstream ports */
+s-caps[0x04] = s-portnr; /* Number of downstream ports */
s-caps[0x05] = 0x00;/* No companion ports at present */
s-caps[0x06] = 0x00;
s-caps[0x07] = 0x00;
@@ -2543,13 +2549,13 @@ void usb_ehci_init(EHCIState *s, DeviceState *dev)
memory_region_init_io(s-mem_caps, ehci_mmio_caps_ops, s,
capabilities, CAPA_SIZE);
memory_region_init_io(s-mem_opreg, ehci_mmio_opreg_ops, s,
- operational, PORTSC_BEGIN);
+ operational, s-portscbase);
memory_region_init_io(s-mem_ports, ehci_mmio_port_ops, s,
- ports, PORTSC_END - PORTSC_BEGIN);
+ ports, 4 * s-portnr);
memory_region_add_subregion(s-mem, s-capsbase, s-mem_caps);
memory_region_add_subregion(s-mem, s-opregbase, s-mem_opreg);
-memory_region_add_subregion(s-mem, s-opregbase + PORTSC_BEGIN,
+memory_region_add_subregion(s-mem, s-opregbase + s-portscbase,
s-mem_ports);
}
diff --git a/hw/usb/hcd-ehci.h b/hw/usb/hcd-ehci.h
index 951b117..7629762 100644
--- a/hw/usb/hcd-ehci.h
+++ b/hw/usb/hcd-ehci.h
@@ -40,11 +40,7 @@
#define MMIO_SIZE0x1000
#define CAPA_SIZE0x10
-#define PORTSC 0x0044
-#define PORTSC_BEGIN PORTSC
-#define PORTSC_END (PORTSC + 4 * NB_PORTS)
-
-#define NB_PORTS 6/* Number of downstream ports */
+#define NB_PORTS 6/* Max. Number of downstream ports
Re: [Qemu-devel] [PATCH v3 04/20] arm: add Faraday FTDDRII030 support
Am 07.02.2013 18:26, schrieb Igor Mitsyanko:
On 02/06/2013 01:45 PM, Kuo-Jung Su wrote:
+static void ftddrii030_reset(DeviceState *ds)
+{
+SysBusDevice *busdev = SYS_BUS_DEVICE(ds);
+Ftddrii030State *s = FTDDRII030(FROM_SYSBUS(Ftddrii030State, busdev));
+FaradayMachState *mach = s-mach;
+
+if (!mach) {
+hw_error(ftddrii030: mach is not yet initialized!\n);
+exit(1);
+}
+
+if (mach-ddr_inited) {
+if (mach-ahb_remapped) {
This assumes that DDRII controller will be reseted before AHBC,
otherwise we'll end up with
ROM and RAM mapped at 0x0 address after reset. I do not know if we can
count on a specific device reset ordering,
maybe someone else can clarify this.
Reset handler registration happens as part of realized property setter.
For most devices that means as part of qdev_init_nofail(), so currently
the order is predictable for those. But this will change once we delay
setting realized = true to the end of machine initialization, since then
realized = true will propagate from /machine object to devices in
child property order and along busses, as drafted by Paolo.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] Replace all setjmp()/longjmp() with sigsetjmp()/siglongjmp()
On Sun, Feb 17, 2013 at 2:44 PM, Peter Maydell peter.mayd...@linaro.org wrote:
The setjmp() function doesn't specify whether signal masks are saved and
restored; on Linux they are not, but on BSD (including MacOSX) they are.
QEMU never wants to save and restore signal masks, because it uses threads,
and the signal-restoration may restore the whole process signal mask,
not just the mask for the thread which did the longjmp. In particular,
this resulted in a bug where ctrl-C was ignored on MacOSX because the
CPU thread did a longjmp which resulted in its signal mask being applied
to every thread, so that all threads had SIGINT and SIGTERM blocked.
The POSIX-sanctioned portable way to do a jump without affecting signal
masks is to use sigsetjmp() with a zero savemask parameter, so change
all uses of setjmp()/longjmp() accordingly.
For Windows we provide a trivial sigsetjmp/siglongjmp in terms of
setjmp/longjmp -- this is OK because no user will ever pass a non-zero
savemask (it would be a bug to do so because of the process-wide effects
described above).
The setjmp() uses in tests/tcg/test-i386.c and tests/tcg/linux-test.c
are left untouched because these are self-contained singlethreaded
test programs intended to be run under QEMU's Linux emulation, so they
have neither the portability nor the multithreading issues to deal with.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
This should have no visible effects on Linux where setjmp/longjmp
never messed with the signal state in the first place; it just makes
us behave right on the BSDs.
Stefan: I've put in the os-win32.h defines which I think are needed;
they're pretty trivial but I don't have a Win32 setup to compile with;
can I ask you to run a quick test for me, please?
Builds fine here on a few mingw32 setups.
I didn't feel it necessary to change every last comment that said
'longjmp' to say 'siglongjmp' where I felt the comment was talking
about 'longjmp the concept' rather than 'longjmp the specific
function implementation'.
checkpatch complains about the indent in the disassembler
sources, as usual, but is otherwise happy.
coroutine-sigaltstack.c | 26 +-
coroutine-ucontext.c | 27 ++-
cpu-exec.c| 6 +++---
disas/i386.c | 6 +++---
disas/m68k.c | 11 ++-
include/exec/cpu-defs.h | 2 +-
include/sysemu/os-win32.h | 8
monitor.c | 6 +++---
user-exec.c | 2 +-
9 files changed, 52 insertions(+), 42 deletions(-)
diff --git a/coroutine-sigaltstack.c b/coroutine-sigaltstack.c
index e37ebac..1fb41c9 100644
--- a/coroutine-sigaltstack.c
+++ b/coroutine-sigaltstack.c
@@ -45,7 +45,7 @@ static unsigned int pool_size;
typedef struct {
Coroutine base;
void *stack;
-jmp_buf env;
+sigjmp_buf env;
} CoroutineUContext;
/**
@@ -59,7 +59,7 @@ typedef struct {
CoroutineUContext leader;
/** Information for the signal handler (trampoline) */
-jmp_buf tr_reenter;
+sigjmp_buf tr_reenter;
volatile sig_atomic_t tr_called;
void *tr_handler;
} CoroutineThreadState;
@@ -115,8 +115,8 @@ static void __attribute__((constructor))
coroutine_init(void)
static void coroutine_bootstrap(CoroutineUContext *self, Coroutine *co)
{
/* Initialize longjmp environment and switch back the caller */
-if (!setjmp(self-env)) {
-longjmp(*(jmp_buf *)co-entry_arg, 1);
+if (!sigsetjmp(self-env, 0)) {
+siglongjmp(*(sigjmp_buf *)co-entry_arg, 1);
}
while (true) {
@@ -145,14 +145,14 @@ static void coroutine_trampoline(int signal)
/*
* Here we have to do a bit of a ping pong between the caller, given that
* this is a signal handler and we have to do a return soon. Then the
- * caller can reestablish everything and do a longjmp here again.
+ * caller can reestablish everything and do a siglongjmp here again.
*/
-if (!setjmp(coTS-tr_reenter)) {
+if (!sigsetjmp(coTS-tr_reenter, 0)) {
return;
}
/*
- * Ok, the caller has longjmp'ed back to us, so now prepare
+ * Ok, the caller has siglongjmp'ed back to us, so now prepare
* us for the real machine state switching. We have to jump
* into another function here to get a new stack context for
* the auto variables (which have to be auto-variables
@@ -179,7 +179,7 @@ static Coroutine *coroutine_new(void)
/* The way to manipulate stack is with the sigaltstack function. We
* prepare a stack, with it delivering a signal to ourselves and then
- * put setjmp/longjmp where needed.
+ * put sigsetjmp/siglongjmp where needed.
* This has been done keeping coroutine-ucontext as a model and with the
* pth ideas (GNU Portable Threads). See coroutine-ucontext for the
basics
* of the coroutines and
Re: [Qemu-devel] [PATCH] vnc-tls: Fix compilation with newer versions of GNU-TLS
Hi, On Thu, 2012-10-18 at 11:23 +0200, Gerd Hoffmann wrote: On 10/18/12 11:16, Andre Przywara wrote: In my installation of GNU-TLS (v3.0.23) the type gnutls_anon_server_credentials is marked deprecated, so -Werror breaks compilation. Simply replacing it with the newer ..._t version fixed the compilation on my machine (Slackware 14.0). I cannot tell how far back this new type goes, at least the header file in RHEL 5.0 (v1.4.1) seems to have it already. If someone finds a broken distribution, tell me and I insert some compat code. Acked-by: Gerd Hoffmann kra...@redhat.com is there a reason why this wasn't applied yet? Regards Tim -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany T: +49 (0) 911 74053-0 F: +49 (0) 911 74053-483 http://www.suse.de/
Re: [Qemu-devel] [PATCH 3/5] milkymist-minimac2: Just expose buffers as a sysbus mmio region
Am Freitag 15 Februar 2013, 12:45:04 schrieb Peter Maydell:
Just expose the register buffers memory as a standard sysbus mmio
region which the creator of the device can map, rather than
providing a qdev property which the creator has to set to the
base address and then doing the mapping in the device's own
init function.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Acked-by: Michael Walle mich...@walle.cc
---
hw/milkymist-hw.h |2 +-
hw/milkymist-minimac2.c |5 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/milkymist-hw.h b/hw/milkymist-hw.h
index c8bd7e9..21e202b 100644
--- a/hw/milkymist-hw.h
+++ b/hw/milkymist-hw.h
@@ -193,10 +193,10 @@ static inline DeviceState
*milkymist_minimac2_create(hwaddr base,
qemu_check_nic_model(nd_table[0], minimac2);
dev = qdev_create(NULL, milkymist-minimac2);
-qdev_prop_set_taddr(dev, buffers_base, buffers_base);
qdev_set_nic_properties(dev, nd_table[0]);
qdev_init_nofail(dev);
sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 1, buffers_base);
sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, rx_irq);
sysbus_connect_irq(SYS_BUS_DEVICE(dev), 1, tx_irq);
diff --git a/hw/milkymist-minimac2.c b/hw/milkymist-minimac2.c
index 9992dcc..b462e90 100644
--- a/hw/milkymist-minimac2.c
+++ b/hw/milkymist-minimac2.c
@@ -96,7 +96,6 @@ struct MilkymistMinimac2State {
NICState *nic;
NICConf conf;
char *phy_model;
-hwaddr buffers_base;
MemoryRegion buffers;
MemoryRegion regs_region;
@@ -475,7 +474,7 @@ static int milkymist_minimac2_init(SysBusDevice *dev)
s-rx1_buf = s-rx0_buf + MINIMAC2_BUFFER_SIZE;
s-tx_buf = s-rx1_buf + MINIMAC2_BUFFER_SIZE;
-sysbus_add_memory(dev, s-buffers_base, s-buffers);
+sysbus_init_mmio(dev, s-buffers);
qemu_macaddr_default_if_unset(s-conf.macaddr);
s-nic = qemu_new_nic(net_milkymist_minimac2_info, s-conf,
@@ -517,8 +516,6 @@ static const VMStateDescription
vmstate_milkymist_minimac2 = { };
static Property milkymist_minimac2_properties[] = {
-DEFINE_PROP_TADDR(buffers_base, MilkymistMinimac2State,
-buffers_base, 0),
DEFINE_NIC_PROPERTIES(MilkymistMinimac2State, conf),
DEFINE_PROP_STRING(phy_model, MilkymistMinimac2State, phy_model),
DEFINE_PROP_END_OF_LIST(),
Re: [Qemu-devel] [PATCH 4/5] milkymist-softusb: Don't map RAM memory regions in the device itself
Am Freitag 15 Februar 2013, 12:45:05 schrieb Peter Maydell:
Don't map the pmem and dmem RAM memory regions in the milkymist-softusb
device itself. Instead just expose them as sysbus mmio regions which
the device creator can map appropriately. This allows us to drop the
pmem_base and dmem_base properties. Instead of going via
cpu_physical_memory_read/_write when the device wants to access the
RAMs, we just keep a host pointer to the memory and use that.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Acked-by: Michael Walle mich...@walle.cc
---
hw/milkymist-hw.h |4 ++--
hw/milkymist-softusb.c | 21 +++--
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/hw/milkymist-hw.h b/hw/milkymist-hw.h
index 21e202b..47f6d50 100644
--- a/hw/milkymist-hw.h
+++ b/hw/milkymist-hw.h
@@ -210,12 +210,12 @@ static inline DeviceState
*milkymist_softusb_create(hwaddr base, DeviceState *dev;
dev = qdev_create(NULL, milkymist-softusb);
-qdev_prop_set_uint32(dev, pmem_base, pmem_base);
qdev_prop_set_uint32(dev, pmem_size, pmem_size);
-qdev_prop_set_uint32(dev, dmem_base, dmem_base);
qdev_prop_set_uint32(dev, dmem_size, dmem_size);
qdev_init_nofail(dev);
sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 1, pmem_base);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, dmem_base);
sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, irq);
return dev;
diff --git a/hw/milkymist-softusb.c b/hw/milkymist-softusb.c
index 01660be..a3e935f 100644
--- a/hw/milkymist-softusb.c
+++ b/hw/milkymist-softusb.c
@@ -54,10 +54,11 @@ struct MilkymistSoftUsbState {
MemoryRegion dmem;
qemu_irq irq;
+void *pmem_ptr;
+void *dmem_ptr;
+
/* device properties */
-uint32_t pmem_base;
uint32_t pmem_size;
-uint32_t dmem_base;
uint32_t dmem_size;
/* device registers */
@@ -134,7 +135,7 @@ static inline void
softusb_read_dmem(MilkymistSoftUsbState *s, return;
}
-cpu_physical_memory_read(s-dmem_base + offset, buf, len);
+memcpy(buf, s-dmem_ptr + offset, len);
}
static inline void softusb_write_dmem(MilkymistSoftUsbState *s,
@@ -146,7 +147,7 @@ static inline void
softusb_write_dmem(MilkymistSoftUsbState *s, return;
}
-cpu_physical_memory_write(s-dmem_base + offset, buf, len);
+memcpy(s-dmem_ptr + offset, buf, len);
}
static inline void softusb_read_pmem(MilkymistSoftUsbState *s,
@@ -158,7 +159,7 @@ static inline void
softusb_read_pmem(MilkymistSoftUsbState *s, return;
}
-cpu_physical_memory_read(s-pmem_base + offset, buf, len);
+memcpy(buf, s-pmem_ptr + offset, len);
}
static inline void softusb_write_pmem(MilkymistSoftUsbState *s,
@@ -170,7 +171,7 @@ static inline void
softusb_write_pmem(MilkymistSoftUsbState *s, return;
}
-cpu_physical_memory_write(s-pmem_base + offset, buf, len);
+memcpy(s-pmem_ptr + offset, buf, len);
}
static void softusb_mouse_changed(MilkymistSoftUsbState *s)
@@ -270,11 +271,13 @@ static int milkymist_softusb_init(SysBusDevice *dev)
memory_region_init_ram(s-pmem, milkymist-softusb.pmem,
s-pmem_size);
vmstate_register_ram_global(s-pmem);
-sysbus_add_memory(dev, s-pmem_base, s-pmem);
+s-pmem_ptr = memory_region_get_ram_ptr(s-pmem);
+sysbus_init_mmio(dev, s-pmem);
memory_region_init_ram(s-dmem, milkymist-softusb.dmem,
s-dmem_size);
vmstate_register_ram_global(s-dmem);
-sysbus_add_memory(dev, s-dmem_base, s-dmem);
+s-dmem_ptr = memory_region_get_ram_ptr(s-dmem);
+sysbus_init_mmio(dev, s-dmem);
hid_init(s-hid_kbd, HID_KEYBOARD, softusb_kbd_hid_datain);
hid_init(s-hid_mouse, HID_MOUSE, softusb_mouse_hid_datain);
@@ -298,9 +301,7 @@ static const VMStateDescription
vmstate_milkymist_softusb = { };
static Property milkymist_softusb_properties[] = {
-DEFINE_PROP_UINT32(pmem_base, MilkymistSoftUsbState, pmem_base,
0xa000), DEFINE_PROP_UINT32(pmem_size, MilkymistSoftUsbState,
pmem_size, 0x1000), -DEFINE_PROP_UINT32(dmem_base,
MilkymistSoftUsbState, dmem_base, 0xa002),
DEFINE_PROP_UINT32(dmem_size, MilkymistSoftUsbState, dmem_size,
0x2000), DEFINE_PROP_END_OF_LIST(),
};
Re: [Qemu-devel] [PATCH v3 15/20] arm: add Faraday FTMAC110 10/100Mbps ethernet support
2013/2/9 Blue Swirl blauwir...@gmail.com:
On Wed, Feb 6, 2013 at 9:45 AM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
The FTMAC110 is an Ethernet controller that provides AHB master capability
and is in full compliance with the IEEE 802.3 10/100 Mbps specifications.
Its DMA controller handles all data transfers between system memory
and on-chip memories.
It supports half-word data transfer for Linux. However it has a weird DMA
alignment issue:
(1) Tx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: O.K
(2) Rx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: Invalid (It means 0x0, 0x4, 0x8, 0xC are invalid)
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
hw/arm/Makefile.objs |1 +
hw/arm/faraday_a360.c | 10 +
hw/arm/ftmac110.c | 681
+
hw/arm/ftmac110.h | 131 ++
4 files changed, 823 insertions(+)
create mode 100644 hw/arm/ftmac110.c
create mode 100644 hw/arm/ftmac110.h
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 70d4f25..f5eeaeb 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -47,3 +47,4 @@ obj-y += ftapbbrg020.o
obj-y += ftnandc021.o
obj-y += fti2c010.o
obj-y += ftssp010.o
+obj-y += ftmac110.o
diff --git a/hw/arm/faraday_a360.c b/hw/arm/faraday_a360.c
index 52cfcec..51e8649 100644
--- a/hw/arm/faraday_a360.c
+++ b/hw/arm/faraday_a360.c
@@ -31,6 +31,7 @@ a360_device_init(A360State *s)
qemu_irq *pic;
DeviceState *ds, *fl;
SSIBus *spi;
+int done_nic = 0;
int i, nr_flash;
qemu_irq cs_line;
qemu_irq ack, req;
@@ -122,6 +123,15 @@ a360_device_init(A360State *s)
req = qdev_get_gpio_in(s-pdma[0], 2);
qdev_connect_gpio_out(s-pdma[0], 2, ack);
qdev_connect_gpio_out(ds, 1, req);
+
+/* ftmac110 */
+for (i = 0; i nb_nics; i++) {
+NICInfo *nd = nd_table[i];
+if (!done_nic (!nd-model || strcmp(nd-model, ftmac110) ==
0)) {
+ftmac110_init(nd, 0x9090, pic[25]);
+done_nic = 1;
+}
+}
}
static void
diff --git a/hw/arm/ftmac110.c b/hw/arm/ftmac110.c
new file mode 100644
index 000..d45f4ba
--- /dev/null
+++ b/hw/arm/ftmac110.c
@@ -0,0 +1,681 @@
+/*
+ * QEMU model of the FTMAC110 Controller
+ *
+ * Copyright (C) 2012 Faraday Technology
+ * Written by Dante Su dant...@faraday-tech.com
+ *
+ * This file is licensed under GNU GPL v2+.
+ */
+
+/***/
+/* FTMAC110 DMA design issue */
+/* Dante Su 2010.02.03 */
+/* */
+/* The DMA engine has a weird restriction that its Rx DMA engine */
+/* accepts only 16-bits aligned address, 32-bits aligned is still */
+/* invalid. However this restriction does not apply to Tx DMA. */
+/* Conclusion: */
+/* (1) Tx DMA Buffer Address: */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: O.K (- u-boot ZeroCopy is possible) */
+/* (2) Rx DMA Buffer Address: */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: Invalid*/
+/***/
Does this also apply to descriptors?
No, it only apply to the packet/frame buffer.
+
+#include hw/sysbus.h
+#include sysemu/sysemu.h
+#include net/net.h
+
+#include faraday.h
+#include ftmac110.h
+
+#define TYPE_FTMAC110ftmac110
+
+typedef struct Ftmac110State {
+SysBusDevice busdev;
+MemoryRegion mmio;
+
+QEMUBH *bh;
+qemu_irq irq;
+NICState *nic;
+NICConf conf;
+
+uint32_t isr;
+uint32_t ier;
+uint32_t mhash[2];
+uint32_t tx_bar;
+uint32_t rx_bar;
+uint32_t tx_idx;
+uint32_t rx_idx;
+uint32_t maccr;
+uint32_t macsr;
+uint32_t phycr;
+uint32_t phycr_rd;
+
+struct {
+uint8_t buf[2048];
+uint32_t len;
+} txbuff;
+
+uint32_t rx_pkt;
+uint32_t rx_bcst;
+uint32_t rx_mcst;
+uint16_t rx_runt;
+uint16_t rx_drop;
+uint16_t rx_crc;
+uint16_t rx_ftl;
+uint32_t tx_pkt;
+
+} Ftmac110State;
+
+#define FTMAC110(obj) \
+OBJECT_CHECK(Ftmac110State, obj, TYPE_FTMAC110)
+
+static uint8_t bitrev8(uint8_t v)
+{
+int i;
+uint8_t r = 0;
+for (i = 0; i 8; ++i) {
+
[Qemu-devel] [Bug 1127053] Re: assertion failed in exec.c while attempting to start a guest (latest commit)
Commenting out the assertion in question (which has been in the source code for the last year) seems to resolve the problem with no noticeable negative impacts, or at least this is what my tests have shown. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1127053 Title: assertion failed in exec.c while attempting to start a guest (latest commit) Status in QEMU: New Bug description: Hi team, I decided to try the latest commit on git (previously used version 1.3.0), and I got failed assertions while attempting to start my guests: eclipse ~ # qemu-kvm -enable-kvm -hda arch.img -m 4096 -smp sockets=1,cores=4 -vnc :0 -cpu host -vga std -net nic,model=e1000,macaddr=00:00:00:00:00:00 -net tap,ifname=vm0 -qmp tcp:0.0.0.0:4900,server,nowait qemu-kvm: /var/tmp/portage/app-emulation/qemu-/work/qemu-/exec.c:982: qemu_ram_set_idstr: Assertion `!new_block-idstr[0]' failed. Aborted The assertion seems valid, so whatever's causing it is probably to blame. I haven't dug around much to find out what calls the method (qemu_ram_set_idstr()), but that is probably the best place to start. The host contains a Xeon E3-1240 CPU, virtualising a bunch of guests one of which is Arch Linux 64-bit, if that helps. eclipse ~ # qemu-kvm -version QEMU emulator version 1.4.50, Copyright (c) 2003-2008 Fabrice Bellard It looks like this assertion happens if you call the executable without any parameters as well: eclipse ~ # qemu-kvm qemu-kvm: /var/tmp/portage/app-emulation/qemu-/work/qemu-/exec.c:982: qemu_ram_set_idstr: Assertion `!new_block-idstr[0]' failed. Aborted Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1127053/+subscriptions
Re: [Qemu-devel] [PATCH v3 02/20] arm: add Faraday a369 SoC platform support
2013/2/8 Igor Mitsyanko i.mitsya...@gmail.com
On 02/06/2013 01:45 PM, Kuo-Jung Su wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
The Faraday A369 EVB is a Faraday SoC platform evalution board used for
Faraday IP functional verification based on the well-known ARM AMBA 2.0
architecture.
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
hw/arm/Makefile.objs |1 +
hw/arm/faraday_a369.c| 161 +
hw/arm/faraday_a369_keypad.c | 234
++
hw/arm/faraday_a369_scu.c| 188 +
hw/arm/ftkbc010.h| 26 +
5 files changed, 610 insertions(+)
create mode 100644 hw/arm/faraday_a369.c
create mode 100644 hw/arm/faraday_a369_keypad.c
create mode 100644 hw/arm/faraday_a369_scu.c
create mode 100644 hw/arm/ftkbc010.h
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 59d7023..02d1a7b 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -34,3 +34,4 @@ obj-$(CONFIG_FDT) += ../device_tree.o
obj-y := $(addprefix ../,$(obj-y))
obj-y += faraday_a360.o faraday_a360_pmu.o
+obj-y += faraday_a369.o faraday_a369_scu.o faraday_a369_keypad.o
diff --git a/hw/arm/faraday_a369.c b/hw/arm/faraday_a369.c
new file mode 100644
index 000..e32dc7f
--- /dev/null
+++ b/hw/arm/faraday_a369.c
@@ -0,0 +1,161 @@
+/*
+ * Faraday A369 Evalution Board
+ *
+ * Copyright (c) 2012 Faraday Technology
+ * Written by Dante Su dant...@faraday-tech.com
+ *
+ * This code is licensed under GNU GPL v2+.
+ */
+
+#include hw/sysbus.h
+#include hw/arm-misc.h
+#include hw/devices.h
+#include hw/i2c.h
+#include hw/boards.h
+#include hw/flash.h
+#include hw/serial.h
+#include hw/ssi.h
+#include net/net.h
+#include sysemu/sysemu.h
+#include sysemu/blockdev.h
+#include exec/address-spaces.h
+
+#include faraday.h
+
+typedef FaradayMachStateA369State;
+
+/* Board init. */
+
+static void
+a369_device_init(A369State *s)
+{
+/* Serial (FTUART010 which is 16550A compatible) */
+if (serial_hds[0]) {
+serial_mm_init(s-as,
+ 0x92b0,
+ 2,
+ NULL,
+ 18432000 / 16,
+ serial_hds[0],
+ DEVICE_LITTLE_ENDIAN);
+}
+if (serial_hds[1]) {
+serial_mm_init(s-as,
+ 0x92c0,
+ 2,
+ NULL,
+ 18432000 / 16,
+ serial_hds[1],
+ DEVICE_LITTLE_ENDIAN);
+}
+
+/* ftscu010 */
+s-scu = sysbus_create_simple(a369.scu, 0x9200, NULL);
+
+/* ftkbc010 */
+sysbus_create_simple(a369.keypad, 0x92f0, NULL);
+}
+
+static void
+a369_board_init(QEMUMachineInitArgs *args)
+{
+DriveInfo *dinfo;
+struct arm_boot_info *bi = NULL;
+A369State *s = g_new(A369State, 1);
+
+s-as = get_system_memory();
+s-ram = g_new(MemoryRegion, 1);
+s-sram = g_new(MemoryRegion, 1);
+
+/* CPU */
+if (!args-cpu_model) {
+args-cpu_model = fa626te;
+}
+
+s-cpu = cpu_arm_init(args-cpu_model);
+if (!s-cpu) {
+args-cpu_model = arm926;
+s-cpu = cpu_arm_init(args-cpu_model);
+if (!s-cpu) {
+hw_error(a369: Unable to find CPU definition\n);
+exit(1);
+}
+}
+
+s-ahb_slave4 = 0x0008; /* ROM: base=0x, size=256MB */
+s-ahb_slave6 = 0x1009; /* RAM: base=0x1000, size=512MB */
Does this register provide information on max allowable RAM size or amount of
RAM actually accessible in a system? I mean,
should this register be modified accordingly if args-ram_size value is less
then 512MB?
Yes, the values to the registers define both the base address and max. size
to the corresponding salve devices.
Although these registers are all R/W, they should be treated as read-only to
the softwares.
Modifying the setting to slave devices would alter the system memory mapped
and might cause un-predictable issues.
P.S:
These registers are designed to be writable for Faraday internal test only.
Sometimes we'll have A36x mounted with a new external AHB daughter board
with built-in CPU and peripheral, and make A36X as an expansion bus.
Only in such case, we'll update the AHB slave settings for FPGA test.
+
+/* A369 supports upto 512MB ram space */
+if (args-ram_size 0x2000) {
+args-ram_size = 0x2000;
+}
+
+/* Use parallel NOR flash for ROM emulation */
+dinfo = drive_get_next(IF_PFLASH);
+s-rom = pflash_cfi01_register(
+0, /* base address */
+NULL,
+a369.rom,
+6144, /* 6 KB */
+dinfo ? dinfo-bdrv : NULL,
I think you should also consider a
Re: [Qemu-devel] [PATCH v3 20/20] arm: add Faraday FTSPI020 SPI flash controller support
2013/2/7 Peter Crosthwaite peter.crosthwa...@xilinx.com:
On Thu, Feb 7, 2013 at 4:59 PM, Kuo-Jung Su dant...@gmail.com wrote:
\
2013/2/7 Peter Crosthwaite peter.crosthwa...@xilinx.com:
Hi Kuo-Jung,
On Wed, Feb 6, 2013 at 7:45 PM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
The FTSPI020 is an integrated SPI Flash controller
which supports upto 4 flash chips.
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
hw/arm/Makefile.objs |1 +
hw/arm/faraday_a369.c | 12 ++
hw/arm/ftspi020.c | 345
+
hw/arm/ftspi020.h | 50 +++
4 files changed, 408 insertions(+)
create mode 100644 hw/arm/ftspi020.c
create mode 100644 hw/arm/ftspi020.h
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 508335a..7178b5d 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -52,3 +52,4 @@ obj-y += ftgmac100.o
obj-y += ftlcdc200.o
obj-y += fttsc010.o
obj-y += ftsdc010.o
+obj-y += ftspi020.o
diff --git a/hw/arm/faraday_a369.c b/hw/arm/faraday_a369.c
index 4ad48f5..132ee2f 100644
--- a/hw/arm/faraday_a369.c
+++ b/hw/arm/faraday_a369.c
@@ -203,6 +203,18 @@ a369_device_init(A369State *s)
req = qdev_get_gpio_in(s-hdma[0], 13);
qdev_connect_gpio_out(s-hdma[0], 13, ack);
qdev_connect_gpio_out(ds, 0, req);
+
+/* ftspi020: as an external AHB device */
+ds = sysbus_create_simple(ftspi020, 0xC000, pic[13]);
+spi = (SSIBus *)qdev_get_child_bus(ds, spi);
+nr_flash = 1;
+for (i = 0; i nr_flash; i++) {
+fl = ssi_create_slave_no_init(spi, m25p80);
+qdev_prop_set_string(fl, partname, w25q64);
+qdev_init_nofail(fl);
+cs_line = qdev_get_gpio_in(fl, 0);
+sysbus_connect_irq(SYS_BUS_DEVICE(ds), i + 1, cs_line);
+}
}
static void
diff --git a/hw/arm/ftspi020.c b/hw/arm/ftspi020.c
new file mode 100644
index 000..dab2f6f
--- /dev/null
+++ b/hw/arm/ftspi020.c
@@ -0,0 +1,345 @@
+/*
+ * Faraday FTSPI020 Flash Controller
+ *
+ * Copyright (c) 2012 Faraday Technology
+ * Written by Dante Su dant...@faraday-tech.com
+ *
+ * This code is licensed under GNU GPL v2+.
+ */
+
+#include hw/hw.h
+#include sysemu/sysemu.h
+#include hw/sysbus.h
+#include hw/ssi.h
+
+#include ftspi020.h
+
+#define TYPE_FTSPI020 ftspi020
+
+typedef struct Ftspi020State {
+SysBusDevice busdev;
+MemoryRegion iomem;
+qemu_irq irq;
+
+/* DMA hardware handshake */
+qemu_irq req;
+
+SSIBus *spi;
+uint8_t num_cs;
Constant. No need for it to be part of the device state, unless you
want to drive it from a property and let the machine model decide how
my cs lines you have?
Got you! I'll move these stuff to the top of faraday_a36x.c as defines.
+qemu_irq *cs_lines;
+
+int wip;/* SPI Flash Status: Write In Progress BIT shift */
+uint32_t datacnt;
+
+/* HW register caches */
+uint32_t cmd[4];
+uint32_t ctrl;
+uint32_t timing;
+uint32_t icr;
+uint32_t isr;
+uint32_t rdsr;
+} Ftspi020State;
+
+#define FTSPI020(obj) \
+OBJECT_CHECK(Ftspi020State, obj, TYPE_FTSPI020)
+
+static void ftspi020_update_irq(Ftspi020State *s)
+{
+if (s-isr) {
+qemu_set_irq(s-irq, 1);
+} else {
+qemu_set_irq(s-irq, 0);
+}
+}
+
+static void ftspi020_handle_ack(void *opaque, int line, int level)
+{
+Ftspi020State *s = FTSPI020(opaque);
+
+if (!(s-icr 0x01)) {
+return;
+}
+
+if (level) {
+qemu_set_irq(s-req, 0);
+} else if (s-datacnt 0) {
+qemu_set_irq(s-req, 1);
+}
+}
+
+static int ftspi020_do_command(Ftspi020State *s)
+{
+int cs = (s-cmd[3] 8) 0x03;
+int cmd = (s-cmd[3] 24) 0xff;
+int ilen = (s-cmd[1] 24) 0x03;
+int alen = (s-cmd[1] 0) 0x07;
+int dcyc = (s-cmd[1] 16) 0xff;
+
bitops.h has helpers that can extract fields for you without all the
stuff. Lots of magic numbers here as well, can you #define these
offsets with meaningful names?
Got you! I'll add some BIT OFFSET and MACROs for these stuff.
+/* make sure the spi flash is de-activated */
+qemu_set_irq(s-cs_lines[cs], 1);
+
+/* activate the spi flash */
+qemu_set_irq(s-cs_lines[cs], 0);
+
+/* if it's a SPI flash READ_STATUS command */
+if ((s-cmd[3] 0x06) == 0x04) {
+do {
+ssi_transfer(s-spi, cmd);
+s-rdsr = ssi_transfer(s-spi, 0x00);
+if (s-cmd[3] 0x08) {
+break;
+}
+} while (s-rdsr (1 s-wip));
+} else {
+/* otherwise */
+int i;
+
+ilen = MIN(ilen, 2);
+alen = MIN(alen, 4);
+
+/* command cycles */
+for (i = 0; i ilen; ++i) {
+ssi_transfer(s-spi, cmd);
+}
+/* address cycles */
+for (i = alen - 1; i =
[Qemu-devel] [PATCH v2][QEMU] vmxcap: Report APIC register emulation and RDTSCP control
From: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- This time I've checked twice that I'm no longer missing a field. scripts/kvm/vmxcap |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap index a1a44a0..a79f816 100755 --- a/scripts/kvm/vmxcap +++ b/scripts/kvm/vmxcap @@ -157,10 +157,12 @@ controls = [ 0: 'Virtualize APIC accesses', 1: 'Enable EPT', 2: 'Descriptor-table exiting', +3: 'Enable RDTSCP', 4: 'Virtualize x2APIC mode', 5: 'Enable VPID', 6: 'WBINVD exiting', 7: 'Unrestricted guest', +8: 'APIC register emulation', 9: 'Virtual interrupt delivery', 10: 'PAUSE-loop exiting', 11: 'RDRAND exiting', -- 1.7.3.4
Re: [Qemu-devel] [PATCH v3 15/20] arm: add Faraday FTMAC110 10/100Mbps ethernet support
2013/2/17 Peter Crosthwaite peter.crosthwa...@xilinx.com:
On Wed, Feb 6, 2013 at 7:45 PM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
The FTMAC110 is an Ethernet controller that provides AHB master capability
and is in full compliance with the IEEE 802.3 10/100 Mbps specifications.
Its DMA controller handles all data transfers between system memory
and on-chip memories.
It supports half-word data transfer for Linux. However it has a weird DMA
alignment issue:
(1) Tx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: O.K
(2) Rx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: Invalid (It means 0x0, 0x4, 0x8, 0xC are invalid)
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
hw/arm/Makefile.objs |1 +
hw/arm/faraday_a360.c | 10 +
hw/arm/ftmac110.c | 681
+
hw/arm/ftmac110.h | 131 ++
4 files changed, 823 insertions(+)
create mode 100644 hw/arm/ftmac110.c
create mode 100644 hw/arm/ftmac110.h
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 70d4f25..f5eeaeb 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -47,3 +47,4 @@ obj-y += ftapbbrg020.o
obj-y += ftnandc021.o
obj-y += fti2c010.o
obj-y += ftssp010.o
+obj-y += ftmac110.o
diff --git a/hw/arm/faraday_a360.c b/hw/arm/faraday_a360.c
index 52cfcec..51e8649 100644
--- a/hw/arm/faraday_a360.c
+++ b/hw/arm/faraday_a360.c
@@ -31,6 +31,7 @@ a360_device_init(A360State *s)
qemu_irq *pic;
DeviceState *ds, *fl;
SSIBus *spi;
+int done_nic = 0;
int i, nr_flash;
qemu_irq cs_line;
qemu_irq ack, req;
@@ -122,6 +123,15 @@ a360_device_init(A360State *s)
req = qdev_get_gpio_in(s-pdma[0], 2);
qdev_connect_gpio_out(s-pdma[0], 2, ack);
qdev_connect_gpio_out(ds, 1, req);
+
+/* ftmac110 */
+for (i = 0; i nb_nics; i++) {
+NICInfo *nd = nd_table[i];
+if (!done_nic (!nd-model || strcmp(nd-model, ftmac110) ==
0)) {
+ftmac110_init(nd, 0x9090, pic[25]);
+done_nic = 1;
+}
+}
}
static void
diff --git a/hw/arm/ftmac110.c b/hw/arm/ftmac110.c
new file mode 100644
index 000..d45f4ba
--- /dev/null
+++ b/hw/arm/ftmac110.c
@@ -0,0 +1,681 @@
+/*
+ * QEMU model of the FTMAC110 Controller
+ *
+ * Copyright (C) 2012 Faraday Technology
+ * Written by Dante Su dant...@faraday-tech.com
+ *
+ * This file is licensed under GNU GPL v2+.
+ */
+
+/***/
+/* FTMAC110 DMA design issue */
+/* Dante Su 2010.02.03 */
+/* */
+/* The DMA engine has a weird restriction that its Rx DMA engine */
+/* accepts only 16-bits aligned address, 32-bits aligned is still */
+/* invalid. However this restriction does not apply to Tx DMA. */
+/* Conclusion: */
+/* (1) Tx DMA Buffer Address: */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: O.K (- u-boot ZeroCopy is possible) */
+/* (2) Rx DMA Buffer Address: */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: Invalid*/
+/***/
+
+#include hw/sysbus.h
+#include sysemu/sysemu.h
+#include net/net.h
+
+#include faraday.h
+#include ftmac110.h
+
+#define TYPE_FTMAC110ftmac110
+
+typedef struct Ftmac110State {
+SysBusDevice busdev;
+MemoryRegion mmio;
+
+QEMUBH *bh;
+qemu_irq irq;
+NICState *nic;
+NICConf conf;
+
+uint32_t isr;
+uint32_t ier;
+uint32_t mhash[2];
+uint32_t tx_bar;
+uint32_t rx_bar;
+uint32_t tx_idx;
+uint32_t rx_idx;
+uint32_t maccr;
+uint32_t macsr;
+uint32_t phycr;
+uint32_t phycr_rd;
+
+struct {
+uint8_t buf[2048];
Magic number
Now a new macro for Max. Frame Length has been added.
+uint32_t len;
+} txbuff;
+
+uint32_t rx_pkt;
+uint32_t rx_bcst;
+uint32_t rx_mcst;
+uint16_t rx_runt;
+uint16_t rx_drop;
+uint16_t rx_crc;
+uint16_t rx_ftl;
+uint32_t tx_pkt;
+
+} Ftmac110State;
+
+#define FTMAC110(obj) \
+OBJECT_CHECK(Ftmac110State, obj, TYPE_FTMAC110)
+
+static uint8_t bitrev8(uint8_t v)
+{
+int i;
+uint8_t r = 0;
+for (i = 0; i 8; ++i) {
+
Re: [Qemu-devel] [QEMU RFC 0/2] Spying on Memory to implement ethernet can_recieve()
+Kuo-Jung Su The same issue is present in the under review Faraday ethernet device model. Regards, Peter On Mon, Jan 28, 2013 at 12:20 AM, Anthony Liguori anth...@codemonkey.ws wrote: Peter Crosthwaite peter.crosthwa...@xilinx.com writes: Hi All, Have a bit of a tricky question about ethernet controllers. We are maintaining two ethernet controllers the cadence GEM and the Xilinx AXI Ethernet both of which are scatter gather (SG) DMA capable. The issue comes about when trying to impelement the can_recieve() function for each. For the sake of background, the ethernet can_recieve() function is used by net devices to signal to the net API that it cant consume data. As QEMU network interfaces are infinately faster than real hardware you need to implement this function to insulate against mass packet droppage. The can_recieve has no real hardware analog, the network devices would just drop the packets (but the packets would be comming at a much slower rate). For most devices, the return of this function is dependant on internal state of the device. However, for SGDMA, whether or not you can receive is dependent on the state of the SGDMA buffer descriptors, which are stored in RAM. So to properly implement can_receive() we need to spy on the contents of memory, to see if the next descriptor is valid. This is not too hard. The hard part is monitoring the descriptor for change after you have returned false from can recieve() so you can tell the net layer you are now ready. Essentially, you need to watch memory and wakup when the cpu writes to the magic address. Patch 1 is a hackish first attempt at this for the cadence GEM, using the Memory API. I don't think there's anything special here. This comes down to: how can a device emulation provide flow control information to the backend? There are two ways this works today in QEMU. Most devices have some sort of mailslot register that's notified when RX buffers are added to the descriptor ring. From that, you call qemu_flush_queued_packets() to start the flow again. virtio-net is an example of this. If there is truly no notification when adding descriptors, the only option is to use a timer to periodically poll the descriptor ring. This is how our USB controllers work. Trying to write-protect memory is a losing battle. You'll end up with a timer anyway to avoid constantly taking page faults. Regards, Anthony Liguori The alternative to this is to impelement timing for the ethernet device, which is truer to the real hardware. Throttle the ethernet trasffic based on wire speed, not the state of the ethernet controller. Ive had an attempt at this for the AXI Ethernet (Patch 2) but a proper solution to this would be to implement this wire side (in the net layer) rather than device side. Peter Crosthwaite (2): cadence_gem: Throttle traffic using buffer state xilinx_axienet: Model timing. hw/cadence_gem.c| 75 - hw/xilinx_axienet.c | 16 ++-- 2 files changed, 77 insertions(+), 14 deletions(-) -- 1.7.12.1.396.g16eed7c
Re: [Qemu-devel] [PATCH v3 15/20] arm: add Faraday FTMAC110 10/100Mbps ethernet support
On Mon, Feb 18, 2013 at 5:30 PM, Kuo-Jung Su dant...@gmail.com wrote:
2013/2/17 Peter Crosthwaite peter.crosthwa...@xilinx.com:
On Wed, Feb 6, 2013 at 7:45 PM, Kuo-Jung Su dant...@gmail.com wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
The FTMAC110 is an Ethernet controller that provides AHB master capability
and is in full compliance with the IEEE 802.3 10/100 Mbps specifications.
Its DMA controller handles all data transfers between system memory
and on-chip memories.
It supports half-word data transfer for Linux. However it has a weird DMA
alignment issue:
(1) Tx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: O.K
(2) Rx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: Invalid (It means 0x0, 0x4, 0x8, 0xC are invalid)
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
hw/arm/Makefile.objs |1 +
hw/arm/faraday_a360.c | 10 +
hw/arm/ftmac110.c | 681
+
hw/arm/ftmac110.h | 131 ++
4 files changed, 823 insertions(+)
create mode 100644 hw/arm/ftmac110.c
create mode 100644 hw/arm/ftmac110.h
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 70d4f25..f5eeaeb 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -47,3 +47,4 @@ obj-y += ftapbbrg020.o
obj-y += ftnandc021.o
obj-y += fti2c010.o
obj-y += ftssp010.o
+obj-y += ftmac110.o
diff --git a/hw/arm/faraday_a360.c b/hw/arm/faraday_a360.c
index 52cfcec..51e8649 100644
--- a/hw/arm/faraday_a360.c
+++ b/hw/arm/faraday_a360.c
@@ -31,6 +31,7 @@ a360_device_init(A360State *s)
qemu_irq *pic;
DeviceState *ds, *fl;
SSIBus *spi;
+int done_nic = 0;
int i, nr_flash;
qemu_irq cs_line;
qemu_irq ack, req;
@@ -122,6 +123,15 @@ a360_device_init(A360State *s)
req = qdev_get_gpio_in(s-pdma[0], 2);
qdev_connect_gpio_out(s-pdma[0], 2, ack);
qdev_connect_gpio_out(ds, 1, req);
+
+/* ftmac110 */
+for (i = 0; i nb_nics; i++) {
+NICInfo *nd = nd_table[i];
+if (!done_nic (!nd-model || strcmp(nd-model, ftmac110) ==
0)) {
+ftmac110_init(nd, 0x9090, pic[25]);
+done_nic = 1;
+}
+}
}
static void
diff --git a/hw/arm/ftmac110.c b/hw/arm/ftmac110.c
new file mode 100644
index 000..d45f4ba
--- /dev/null
+++ b/hw/arm/ftmac110.c
@@ -0,0 +1,681 @@
+/*
+ * QEMU model of the FTMAC110 Controller
+ *
+ * Copyright (C) 2012 Faraday Technology
+ * Written by Dante Su dant...@faraday-tech.com
+ *
+ * This file is licensed under GNU GPL v2+.
+ */
+
+/***/
+/* FTMAC110 DMA design issue */
+/* Dante Su 2010.02.03 */
+/* */
+/* The DMA engine has a weird restriction that its Rx DMA engine */
+/* accepts only 16-bits aligned address, 32-bits aligned is still */
+/* invalid. However this restriction does not apply to Tx DMA. */
+/* Conclusion: */
+/* (1) Tx DMA Buffer Address: */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: O.K (- u-boot ZeroCopy is possible) */
+/* (2) Rx DMA Buffer Address: */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: Invalid*/
+/***/
+
+#include hw/sysbus.h
+#include sysemu/sysemu.h
+#include net/net.h
+
+#include faraday.h
+#include ftmac110.h
+
+#define TYPE_FTMAC110ftmac110
+
+typedef struct Ftmac110State {
+SysBusDevice busdev;
+MemoryRegion mmio;
+
+QEMUBH *bh;
+qemu_irq irq;
+NICState *nic;
+NICConf conf;
+
+uint32_t isr;
+uint32_t ier;
+uint32_t mhash[2];
+uint32_t tx_bar;
+uint32_t rx_bar;
+uint32_t tx_idx;
+uint32_t rx_idx;
+uint32_t maccr;
+uint32_t macsr;
+uint32_t phycr;
+uint32_t phycr_rd;
+
+struct {
+uint8_t buf[2048];
Magic number
Now a new macro for Max. Frame Length has been added.
+uint32_t len;
+} txbuff;
+
+uint32_t rx_pkt;
+uint32_t rx_bcst;
+uint32_t rx_mcst;
+uint16_t rx_runt;
+uint16_t rx_drop;
+uint16_t rx_crc;
+uint16_t rx_ftl;
+uint32_t tx_pkt;
+
+} Ftmac110State;
+
+#define FTMAC110(obj) \
+OBJECT_CHECK(Ftmac110State, obj, TYPE_FTMAC110)
+
+static uint8_t bitrev8(uint8_t v)
