[Qemu-devel] Porting Qemu to an ARM board
Hi all, I have a board based on the IMX21 (ARM926EJ-S) and I know qemu can emulate that processor. my board has 64MB SDRAM and 64MB NAND Flash. First, I want to be able to boot Linux and I will try to emulate the rest of the peripherals later. I'm trying to figure out which files to modified and which ones to add. I 've been reading the ones regarding the one about the PXA270 as a guide. I was looking for something like an "how to port qemu to a board". Any suggestions will be welcome.. Thanks Encloy
[Qemu-devel] [PATCH] [PPC] Always enable precise emulation when softfloat is used
The patch below changes the way to enable softfloat on the PPC target. It
is now enabled when softfloat is used. The rationale behind this change
is that ones who want precise emulation prefer precision over emulation
speed.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
---
target-ppc/exec.h |4
target-ppc/op.c| 14 +++---
target-ppc/op_helper.c | 22 +++---
target-ppc/op_helper.h |6 +++---
4 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/target-ppc/exec.h b/target-ppc/exec.h
index 76fdb0b..f14f6a8 100644
--- a/target-ppc/exec.h
+++ b/target-ppc/exec.h
@@ -27,10 +27,6 @@
#include "cpu.h"
#include "exec-all.h"
-/* For normal operations, precise emulation should not be needed */
-//#define USE_PRECISE_EMULATION 1
-#define USE_PRECISE_EMULATION 0
-
register struct CPUPPCState *env asm(AREG0);
#if TARGET_LONG_BITS > HOST_LONG_BITS
/* no registers can be used */
diff --git a/target-ppc/op.c b/target-ppc/op.c
index 972b8bc..f60a6a9 100644
--- a/target-ppc/op.c
+++ b/target-ppc/op.c
@@ -1716,7 +1716,7 @@ void OPPROTO op_srli_T1_64 (void)
/* fadd - fadd. */
void OPPROTO op_fadd (void)
{
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
do_fadd();
#else
FT0 = float64_add(FT0, FT1, &env->fp_status);
@@ -1727,7 +1727,7 @@ void OPPROTO op_fadd (void)
/* fsub - fsub. */
void OPPROTO op_fsub (void)
{
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
do_fsub();
#else
FT0 = float64_sub(FT0, FT1, &env->fp_status);
@@ -1738,7 +1738,7 @@ void OPPROTO op_fsub (void)
/* fmul - fmul. */
void OPPROTO op_fmul (void)
{
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
do_fmul();
#else
FT0 = float64_mul(FT0, FT1, &env->fp_status);
@@ -1749,7 +1749,7 @@ void OPPROTO op_fmul (void)
/* fdiv - fdiv. */
void OPPROTO op_fdiv (void)
{
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
do_fdiv();
#else
FT0 = float64_div(FT0, FT1, &env->fp_status);
@@ -1796,7 +1796,7 @@ void OPPROTO op_fsel (void)
/* fmadd - fmadd. */
void OPPROTO op_fmadd (void)
{
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
do_fmadd();
#else
FT0 = float64_mul(FT0, FT1, &env->fp_status);
@@ -1808,7 +1808,7 @@ void OPPROTO op_fmadd (void)
/* fmsub - fmsub. */
void OPPROTO op_fmsub (void)
{
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
do_fmsub();
#else
FT0 = float64_mul(FT0, FT1, &env->fp_status);
@@ -1835,7 +1835,7 @@ void OPPROTO op_fnmsub (void)
/* frsp - frsp. */
void OPPROTO op_frsp (void)
{
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
do_frsp();
#else
FT0 = float64_to_float32(FT0, &env->fp_status);
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 544d906..919b481 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -922,7 +922,7 @@ void do_float_check_status (void)
}
#endif
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
void do_fadd (void)
{
if (unlikely(float64_is_signaling_nan(FT0) ||
@@ -989,7 +989,7 @@ void do_fdiv (void)
FT0 = float64_div(FT0, FT1, &env->fp_status);
}
}
-#endif /* USE_PRECISE_EMULATION */
+#endif /* CONFIG_SOFTFLOAT */
void do_fctiw (void)
{
@@ -1003,7 +1003,7 @@ void do_fctiw (void)
fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
} else {
p.ll = float64_to_int32(FT0, &env->fp_status);
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
/* XXX: higher bits are not supposed to be significant.
* to make tests easier, return the same as a real PowerPC 750
*/
@@ -1025,7 +1025,7 @@ void do_fctiwz (void)
fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
} else {
p.ll = float64_to_int32_round_to_zero(FT0, &env->fp_status);
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
/* XXX: higher bits are not supposed to be significant.
* to make tests easier, return the same as a real PowerPC 750
*/
@@ -1114,7 +1114,7 @@ void do_frim (void)
do_fri(float_round_down);
}
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
void do_fmadd (void)
{
if (unlikely(float64_is_signaling_nan(FT0) ||
@@ -1164,7 +1164,7 @@ void do_fmsub (void)
#endif
}
}
-#endif /* USE_PRECISE_EMULATION */
+#endif /* CONFIG_SOFTFLOAT */
void do_fnmadd (void)
{
@@ -1174,7 +1174,7 @@ void do_fnmadd (void)
/* sNaN operation */
fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
} else {
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
#ifdef FLOAT128
/* This is the way the PowerPC specification defines it */
float128 ft0_128, ft1_128;
@@ -1206,7 +1206,7 @@ void do_fnmsub (void)
/* sNaN operation */
fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
} else {
-#if USE_PRECISE_EMULATION
+#ifdef CONFIG_SOFTFLOAT
#ifdef FLOAT128
/* This is the way the PowerPC specification defines it */
float128 ft0_128, ft1_128;
@@ -1230
[Qemu-devel] [PATCH 2/3] [PPC] Math functions helper for CONFIG_SOFTFLOAT=yes
The patch below adds isfinite() and isnormal() functions which can
work with float64 type, used when CONFIG_SOFTFLOAT=yes.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
---
target-ppc/op_helper.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 7136e51..544d906 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -492,6 +492,27 @@ static always_inline int isinfinity (float64 d)
(u.ll & 0x000FULL) == 0;
}
+#ifdef CONFIG_SOFTFLOAT
+static always_inline int isfinite (float64 d)
+{
+CPU_DoubleU u;
+
+u.d = d;
+
+return (((u.ll >> 52) & 0x7FF) != 0x7FF);
+}
+
+static always_inline int isnormal (float64 d)
+{
+CPU_DoubleU u;
+
+u.d = d;
+
+uint32_t exp = (u.ll >> 52) & 0x7FF;
+return ((0 < exp) && (exp < 0x7FF));
+}
+#endif
+
void do_compute_fprf (int set_fprf)
{
int isneg;
--
1.5.3.8
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] [PATCH 1/3] [PPC] Use float32/64 instead of float/double
The patch below uses the float32 and float64 types instead of the float
and double types in the PPC code. This doesn't change anything when
using softfloat-native as the types are the same, but that helps
compiling the PPC target with softfloat.
It also defines a new union CPU_FloatU in addition to CPU_DoubleU, and
use them instead of identical unions that are defined in numerous
places.
---
cpu-all.h |5 +
target-ppc/op.c| 85 +++--
target-ppc/op_helper.c | 418 +++-
target-ppc/op_helper.h | 104 ---
target-ppc/op_helper_mem.h | 18 +--
target-ppc/op_mem.h| 69 +++-
6 files changed, 241 insertions(+), 458 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 7a7e655..2a2b197 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -116,6 +116,11 @@ static inline void tswap64s(uint64_t *s)
#define bswaptls(s) bswap64s(s)
#endif
+typedef union {
+float32 f;
+uint32_t l;
+} CPU_FloatU;
+
/* NOTE: arm FPA is horrible as double 32 bit words are stored in big
endian ! */
typedef union {
diff --git a/target-ppc/op.c b/target-ppc/op.c
index 6cda0f0..972b8bc 100644
--- a/target-ppc/op.c
+++ b/target-ppc/op.c
@@ -580,47 +580,28 @@ void OPPROTO op_float_check_status (void)
}
#endif
-#if defined(WORDS_BIGENDIAN)
-#define WORD0 0
-#define WORD1 1
-#else
-#define WORD0 1
-#define WORD1 0
-#endif
void OPPROTO op_load_fpscr_FT0 (void)
{
/* The 32 MSB of the target fpr are undefined.
* They'll be zero...
*/
-union {
-float64 d;
-struct {
-uint32_t u[2];
-} s;
-} u;
-
-u.s.u[WORD0] = 0;
-u.s.u[WORD1] = env->fpscr;
+CPU_DoubleU u;
+
+u.l.upper = 0;
+u.l.lower = env->fpscr;
FT0 = u.d;
RETURN();
}
void OPPROTO op_set_FT0 (void)
{
-union {
-float64 d;
-struct {
-uint32_t u[2];
-} s;
-} u;
+CPU_DoubleU u;
-u.s.u[WORD0] = 0;
-u.s.u[WORD1] = PARAM1;
+u.l.upper = 0;
+u.l.lower = PARAM1;
FT0 = u.d;
RETURN();
}
-#undef WORD0
-#undef WORD1
void OPPROTO op_load_fpscr_T0 (void)
{
@@ -3226,27 +3207,21 @@ void OPPROTO op_efststeq (void)
void OPPROTO op_efdsub (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_sub(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_sub(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
void OPPROTO op_efdadd (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_add(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_add(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
@@ -3282,27 +3257,21 @@ void OPPROTO op_efdneg (void)
void OPPROTO op_efddiv (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_div(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_div(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
void OPPROTO op_efdmul (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_mul(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_mul(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 38467c4..7136e51 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -455,53 +455,41 @@ void do_popcntb_64 (void)
/*/
/* Floating point operations helpers */
-static always_inline int fpisneg (float64 f)
+static always_inline int fpisneg (float64 d)
{
-union {
-float64 f;
-uint64_t u;
-} u;
+CPU_DoubleU u;
-u.f = f;
+u.d = d;
-return u.u >> 63 != 0;
+return u.ll >> 63 != 0;
}
-static always_inline int isden (float f)
+static always_inline int isden (float64 d)
{
-union {
-float64 f;
-uint64_t u;
-} u;
+CPU_DoubleU u;
-u.f = f;
+u.d = d;
-return ((u.u >> 52) & 0x7FF) == 0;
+return ((u.ll >> 52) & 0x7FF) == 0;
}
-static always_inline int iszero (float64 f)
+static always_inline int iszero (float64 d)
{
-union {
-float64 f;
-uint64_t u;
-} u;
+CPU_DoubleU u;
-u.f = f;
+u.d = d;
-return (u.u & ~0x8000ULL) == 0;
+return (u.ll & ~0x8000ULL) == 0;
}
-s
[Qemu-devel] Re: [RESEND] TCG breakage if TARGET_LONG_BITS > HOST_LONG_BITS
Alexander Graf wrote: > This is a resend of a mail I sent to the list on 2008/02/06. I felt it > rather disturbing, yet normal that nobody cared about Mac OS X host > support, but this concerns all x86 host OSs, so I believe this deserves > some discussion. > > Hi, > > I've been trying to get the new TCG approach running on an i386 host. It > works when I use gcc3 (miraculously as I will explain later), but fails > on gcc4. > > On boot the very first instruction that gets issued is the ljmp to the > bios: > [...] > 1. Why is gcc3 generating code, that does not use ebx? > 2. Why does movi_i64 generate code that only accesses registers? I have > not been able to find any branch in the tcg code generator for movi_ixx > that generates movs to memory addresses. > > The whole issue could be easily fixed by using registers, but putting > the call into inline assembly, telling gcc that this call clobbers all > the registers. I do not know if this is the expected behavior though, so > I think I'd rather ask before doing any patches. The fact that it works in some cases is a miracle. The right solution is to use a global TB prologue and epilogue which saves and restores callee saved registers (it is in the tcg TODO list). A temporary solution before that would be to mark ebx, esi and edi as reserved registers if TARGET_LONG_BITS > HOST_LONG_BITS. Fabrice.
[Qemu-devel] qemu gdbstub.c linux-user/main.c linux-user/sig...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 08/02/12 21:01:26 Modified files: . : gdbstub.c linux-user : main.c signal.c syscall.c linux-user/mips: target_signal.h linux-user/mips64: target_signal.h linux-user/mipsn32: target_signal.h target-mips: cpu.h op.c op_helper.c op_template.c translate.c Log message: Make MIPS MT implementation more cache friendly. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemu&r1=1.73&r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.160&r2=1.161 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemu&r1=1.55&r2=1.56 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.163&r2=1.164 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mips/target_signal.h?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mips64/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mipsn32/target_signal.h?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.56&r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.91&r2=1.92 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.77&r2=1.78 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_template.c?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.121&r2=1.122
[Qemu-devel] [PATCH] possible mmap regression
Hi, I don't know what I'm doing but this seems to fix the weird issue I was having. http://article.gmane.org/gmane.comp.emulators.qemu/23314 I've found out that this happens on linux 2.6.23, but not 2.6.24. Cheers. -- Felipe Contreras diff --git a/linux-user/mmap.c b/linux-user/mmap.c index 6292826..3050ad9 100644 --- a/linux-user/mmap.c +++ b/linux-user/mmap.c @@ -251,7 +251,7 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, especially important if qemu_host_page_size > qemu_real_host_page_size */ p = mmap(g2h(mmap_start), - host_len, prot, flags | MAP_FIXED, fd, host_offset); + host_len, prot, flags, fd, host_offset); if (p == MAP_FAILED) return -1; /* update start so that it points to the file position at 'offset' */
Re: [Qemu-devel] [PATCH] simplify storing temporaries in env structure regardless of host/target long size
On Feb 12, 2008 10:12 PM, Blue Swirl <[EMAIL PROTECTED]> wrote: > On 2/12/08, Igor Kovalenko <[EMAIL PROTECTED]> wrote: > > This patch separates decision about storing temporaries in env > > structure from target long size by introducing a macro > > QEMU_TEMPORARY_IN_ENV > > Makes it a bit easier to work around register allocation problems. > > By default there is no change to generated code. > > I'd move env->t0/t1/t2 to CPU_COMMON and the T0/T1/T2 logic to > hostregs_helper.h. > I don't think the hostregs_helper.h is supposed to be used for that. It knows nothing about env. -- Kind regards, Igor V. Kovalenko
Re: [Qemu-devel] [PATCH] simplify storing temporaries in env structure regardless of host/target long size
On 2/12/08, Igor Kovalenko <[EMAIL PROTECTED]> wrote: > This patch separates decision about storing temporaries in env > structure from target long size by introducing a macro > QEMU_TEMPORARY_IN_ENV > Makes it a bit easier to work around register allocation problems. > By default there is no change to generated code. I'd move env->t0/t1/t2 to CPU_COMMON and the T0/T1/T2 logic to hostregs_helper.h.
[Qemu-devel] [PATCH] simplify storing temporaries in env structure regardless of host/target long size
This patch separates decision about storing temporaries in env structure from target long size by introducing a macro QEMU_TEMPORARY_IN_ENV Makes it a bit easier to work around register allocation problems. By default there is no change to generated code. -- Kind regards, Igor V. Kovalenko qemu-temporary-in-env-macro.patch Description: Binary data
Re: [Qemu-devel] [PATCH] Fix multiple floppy controller issues
On 2/12/08, Hervé Poussineau <[EMAIL PROTECTED]> wrote: > Hi, > > Attached patch fixes some issues in the floppy disk controller: > - Enhance reset support (external and software) > - Use MAX_FD constant when possible > - Support up to 4 drives if MAX_FD is set to 4 > - Fix DOR register, which should be writable at any time > - Let MSR return 0x20 when non-DMA transfer is happening > - Don't assume caller wants to read whole track at once > - Add seek to next sector when in non-DMA mode > > Credits to Stuart Brady to help me to debug some issues... It's good to see someone working on FDC issues. As you may know, floppy on Sparc is still broken. Maybe you could spot the problem in the following logs (from splack-24oct2k3.iso, your patch applied, DEBUG_FLOPPY enabled): # network Network support for NFS install, 19-May-2001 [EMAIL PROTECTED] Please insert the network supplemental diskette (network.dsk), and hit [enter] to continue. FLOPPY: write reg2: 0x0c FLOPPY: digital output register set to 0x0c FLOPPY: write reg2: 0x0c FLOPPY: digital output register set to 0x0c FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg2: 0x1c FLOPPY: digital output register set to 0x1c FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: revalidate FLOPPY: 1.44 MB 3"1/2 floppy disk (2 h 80 t 18 s) ro FLOPPY: Floppy digital input register: 0x80 FLOPPY: read reg7: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg7: 0x00 FLOPPY: read reg7: 0x00 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x12 FLOPPY: PERPENDICULAR_MODE command FLOPPY: fdctrl_write_data: 12 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x00 FLOPPY: fdctrl_write_data: 00 FLOPPY: treat PERPENDICULAR_MODE command FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x13 FLOPPY: CONFIGURE command FLOPPY: fdctrl_write_data: 13 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x00 FLOPPY: fdctrl_write_data: 00 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x1a FLOPPY: fdctrl_write_data: 1a FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x00 FLOPPY: fdctrl_write_data: 00 FLOPPY: treat CONFIGURE command FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x03 FLOPPY: SPECIFY command FLOPPY: fdctrl_write_data: 03 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0xc1 FLOPPY: fdctrl_write_data: c1 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x11 FLOPPY: fdctrl_write_data: 11 FLOPPY: treat SPECIFY command FLOPPY: read reg7: 0x00 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x07 FLOPPY: RECALIBRATE command FLOPPY: fdctrl_write_data: 07 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x00 FLOPPY: fdctrl_write_data: 00 FLOPPY: treat RECALIBRATE command FLOPPY: recalibrate FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 mount: block device /dev/fd0 is write-protected, mounting read-only FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg4: 0x80 FLOPPY: select rate register set to 0x80 FLOPPY: reset controller FLOPPY: Reset interrupt FLOPPY: recalibrate FLOPPY: recalibrate FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg4: 0x80 FLOPPY: select rate register set to 0x80 FLOPPY: reset controller FLOPPY: Reset interrupt FLOPPY: recalibrate FLOPPY: recalibrate FLOPPY: Set interrupt status to 0xc0 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x08 FLOPPY: SENSE_INTERRUPT_STATUS command (c0) FLOPPY: Reset interrupt FLOPPY: main status register: 0xd0 FLOPPY: read reg4: 0xd0 FLOPPY: data register: 0x20 FLOPPY: read reg5: 0x20 FLOPPY: main status register: 0xd0 FLOPPY: read reg4: 0xd0 FLOPPY: Reset interrupt FLOPPY: data register: 0x00 FLOPPY: read reg5: 0x00 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: read reg7: 0x00 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: read reg7: 0x00 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x12 FLOPPY: PERPENDICULAR_MODE command FLOPPY: fdctrl_write_data: 12 FLOPPY: main status register: 0x80 FLOPPY: read reg4: 0x80 FLOPPY: write reg5: 0x00 FLOPPY: fdctrl_write_data: 00 FLOPPY: treat PERPENDICULAR_MODE comman
[Qemu-devel] [PATCH] Fix floppy controller issues v2
Hi,
Attached patch fixes some issues in the floppy disk controller:
- Enhance reset support (external and software)
- Use MAX_FD constant when possible
- Support up to 4 drives if MAX_FD is set to 4
- Fix DOR register, which should be writable at any time
- Let MSR return 0x20 when non-DMA transfer is happening
- Don't assume caller wants to read whole track at once
- Add seek to next sector when in non-DMA mode
- Fix non-DMA write, which was stopping after only 1 byte
Credits to Stuart Brady to help me to debug some issues...
Hervé
Index: fdc.c
===
RCS file: /sources/qemu/qemu/hw/fdc.c,v
retrieving revision 1.37
diff -u -r1.37 fdc.c
--- fdc.c 1 Jan 2008 17:06:38 - 1.37
+++ fdc.c 12 Feb 2008 17:52:03 -
@@ -306,10 +306,9 @@
drv->drflags &= ~FDRIVE_MOTOR_ON;
}
-/* Re-initialise a drives (motor off, repositioned) */
+/* Re-initialise a drive (repositioned) */
static void fd_reset (fdrive_t *drv)
{
-fd_stop(drv);
fd_recalibrate(drv);
}
@@ -402,7 +401,7 @@
/* Sun4m quirks? */
int sun4m;
/* Floppy drives */
-fdrive_t drives[2];
+fdrive_t drives[MAX_FD];
};
static uint32_t fdctrl_read (void *opaque, uint32_t reg)
@@ -622,20 +621,16 @@
fdctrl->dma_chann = dma_chann;
fdctrl->io_base = io_base;
fdctrl->config = 0x60; /* Implicit seek, polling & FIFO enabled */
-if (fdctrl->dma_chann != -1) {
-fdctrl->dma_en = 1;
+if (fdctrl->dma_chann != -1)
DMA_register_channel(dma_chann, &fdctrl_transfer_handler, fdctrl);
-} else {
-fdctrl->dma_en = 0;
-}
-for (i = 0; i < 2; i++) {
+for (i = 0; i < MAX_FD; i++) {
fd_init(&fdctrl->drives[i], fds[i]);
}
fdctrl_reset(fdctrl, 0);
fdctrl->state = FD_CTRL_ACTIVE;
register_savevm("fdc", io_base, 1, fdc_save, fdc_load, fdctrl);
qemu_register_reset(fdctrl_external_reset, fdctrl);
-for (i = 0; i < 2; i++) {
+for (i = 0; i < MAX_FD; i++) {
fd_revalidate(&fdctrl->drives[i]);
}
@@ -735,6 +730,7 @@
fdctrl_reset_fifo(fdctrl);
if (do_irq)
fdctrl_raise_irq(fdctrl, 0xc0);
+fdctrl->dma_en = (fdctrl->dma_chann != -1) ? 1 : 0;
}
static inline fdrive_t *drv0 (fdctrl_t *fdctrl)
@@ -744,12 +740,41 @@
static inline fdrive_t *drv1 (fdctrl_t *fdctrl)
{
-return &fdctrl->drives[1 - fdctrl->bootsel];
+if (fdctrl->bootsel < 1)
+return &fdctrl->drives[1];
+else
+return &fdctrl->drives[0];
+}
+
+#if MAX_FD >= 4
+static inline fdrive_t *drv2 (fdctrl_t *fdctrl)
+{
+if (fdctrl->bootsel < 2)
+return &fdctrl->drives[2];
+else
+return &fdctrl->drives[1];
}
+static inline fdrive_t *drv3 (fdctrl_t *fdctrl)
+{
+if (fdctrl->bootsel < 3)
+return &fdctrl->drives[3];
+else
+return &fdctrl->drives[2];
+}
+#endif
+
static fdrive_t *get_cur_drv (fdctrl_t *fdctrl)
{
-return fdctrl->cur_drv == 0 ? drv0(fdctrl) : drv1(fdctrl);
+switch (fdctrl->cur_drv) {
+case 0: return drv0(fdctrl);
+case 1: return drv1(fdctrl);
+#if MAX_FD >= 4
+case 2: return drv2(fdctrl);
+case 3: return drv3(fdctrl);
+#endif
+default: return NULL;
+}
}
/* Status B register : 0x01 (read-only) */
@@ -765,9 +790,15 @@
uint32_t retval = 0;
/* Drive motors state indicators */
-if (drv0(fdctrl)->drflags & FDRIVE_MOTOR_ON)
-retval |= 1 << 5;
+#if MAX_FD >= 4
+if (drv3(fdctrl)->drflags & FDRIVE_MOTOR_ON)
+retval |= 1 << 7;
+if (drv2(fdctrl)->drflags & FDRIVE_MOTOR_ON)
+retval |= 1 << 6;
+#endif
if (drv1(fdctrl)->drflags & FDRIVE_MOTOR_ON)
+retval |= 1 << 5;
+if (drv0(fdctrl)->drflags & FDRIVE_MOTOR_ON)
retval |= 1 << 4;
/* DMA enable */
retval |= fdctrl->dma_en << 3;
@@ -782,15 +813,18 @@
static void fdctrl_write_dor (fdctrl_t *fdctrl, uint32_t value)
{
-/* Reset mode */
-if (fdctrl->state & FD_CTRL_RESET) {
-if (!(value & 0x04)) {
-FLOPPY_DPRINTF("Floppy controller in RESET state !\n");
-return;
-}
-}
FLOPPY_DPRINTF("digital output register set to 0x%02x\n", value);
/* Drive motors state indicators */
+#if MAX_FD >= 4
+if (value & 0x80)
+fd_start(drv3(fdctrl));
+else
+fd_stop(drv3(fdctrl));
+if (value & 0x40)
+fd_start(drv2(fdctrl));
+else
+fd_stop(drv2(fdctrl));
+#endif
if (value & 0x20)
fd_start(drv1(fdctrl));
else
@@ -818,7 +852,11 @@
}
}
/* Selected drive */
+#if MAX_FD >= 4
+fdctrl->cur_drv = value & 3;
+#else
fdctrl->cur_drv = value & 1;
+#endif
}
/* Tape drive register : 0x03 */
@@ -843,7 +881,11 @@
}
FLOPPY_DPRINTF("tape drive register set to 0x%02x\n", value);
/* Disk boot selection indicator */
+#if MAX_FD >= 4
+fdctrl->bootsel = (value >> 2) & 3;
+#else
fdctrl->b
[Qemu-devel] [PATCH] Fix multiple floppy controller issues
Hi,
Attached patch fixes some issues in the floppy disk controller:
- Enhance reset support (external and software)
- Use MAX_FD constant when possible
- Support up to 4 drives if MAX_FD is set to 4
- Fix DOR register, which should be writable at any time
- Let MSR return 0x20 when non-DMA transfer is happening
- Don't assume caller wants to read whole track at once
- Add seek to next sector when in non-DMA mode
Credits to Stuart Brady to help me to debug some issues...
Hervé
Index: fdc.c
===
RCS file: /sources/qemu/qemu/hw/fdc.c,v
retrieving revision 1.37
diff -u -r1.37 fdc.c
--- fdc.c 1 Jan 2008 17:06:38 - 1.37
+++ fdc.c 12 Feb 2008 17:02:17 -
@@ -306,10 +306,9 @@
drv->drflags &= ~FDRIVE_MOTOR_ON;
}
-/* Re-initialise a drives (motor off, repositioned) */
+/* Re-initialise a drive (repositioned) */
static void fd_reset (fdrive_t *drv)
{
-fd_stop(drv);
fd_recalibrate(drv);
}
@@ -402,7 +401,7 @@
/* Sun4m quirks? */
int sun4m;
/* Floppy drives */
-fdrive_t drives[2];
+fdrive_t drives[MAX_FD];
};
static uint32_t fdctrl_read (void *opaque, uint32_t reg)
@@ -622,20 +621,16 @@
fdctrl->dma_chann = dma_chann;
fdctrl->io_base = io_base;
fdctrl->config = 0x60; /* Implicit seek, polling & FIFO enabled */
-if (fdctrl->dma_chann != -1) {
-fdctrl->dma_en = 1;
+if (fdctrl->dma_chann != -1)
DMA_register_channel(dma_chann, &fdctrl_transfer_handler, fdctrl);
-} else {
-fdctrl->dma_en = 0;
-}
-for (i = 0; i < 2; i++) {
+for (i = 0; i < MAX_FD; i++) {
fd_init(&fdctrl->drives[i], fds[i]);
}
fdctrl_reset(fdctrl, 0);
fdctrl->state = FD_CTRL_ACTIVE;
register_savevm("fdc", io_base, 1, fdc_save, fdc_load, fdctrl);
qemu_register_reset(fdctrl_external_reset, fdctrl);
-for (i = 0; i < 2; i++) {
+for (i = 0; i < MAX_FD; i++) {
fd_revalidate(&fdctrl->drives[i]);
}
@@ -735,6 +730,7 @@
fdctrl_reset_fifo(fdctrl);
if (do_irq)
fdctrl_raise_irq(fdctrl, 0xc0);
+fdctrl->dma_en = (fdctrl->dma_chann != -1) ? 1 : 0;
}
static inline fdrive_t *drv0 (fdctrl_t *fdctrl)
@@ -744,12 +740,41 @@
static inline fdrive_t *drv1 (fdctrl_t *fdctrl)
{
-return &fdctrl->drives[1 - fdctrl->bootsel];
+if (fdctrl->bootsel < 1)
+return &fdctrl->drives[1];
+else
+return &fdctrl->drives[0];
+}
+
+#if MAX_FD >= 4
+static inline fdrive_t *drv2 (fdctrl_t *fdctrl)
+{
+if (fdctrl->bootsel < 2)
+return &fdctrl->drives[2];
+else
+return &fdctrl->drives[1];
}
+static inline fdrive_t *drv3 (fdctrl_t *fdctrl)
+{
+if (fdctrl->bootsel < 3)
+return &fdctrl->drives[3];
+else
+return &fdctrl->drives[2];
+}
+#endif
+
static fdrive_t *get_cur_drv (fdctrl_t *fdctrl)
{
-return fdctrl->cur_drv == 0 ? drv0(fdctrl) : drv1(fdctrl);
+switch (fdctrl->cur_drv) {
+case 0: return drv0(fdctrl);
+case 1: return drv1(fdctrl);
+#if MAX_FD >= 4
+case 2: return drv2(fdctrl);
+case 3: return drv3(fdctrl);
+#endif
+default: return NULL;
+}
}
/* Status B register : 0x01 (read-only) */
@@ -765,9 +790,15 @@
uint32_t retval = 0;
/* Drive motors state indicators */
-if (drv0(fdctrl)->drflags & FDRIVE_MOTOR_ON)
-retval |= 1 << 5;
+#if MAX_FD >= 4
+if (drv3(fdctrl)->drflags & FDRIVE_MOTOR_ON)
+retval |= 1 << 7;
+if (drv2(fdctrl)->drflags & FDRIVE_MOTOR_ON)
+retval |= 1 << 6;
+#endif
if (drv1(fdctrl)->drflags & FDRIVE_MOTOR_ON)
+retval |= 1 << 5;
+if (drv0(fdctrl)->drflags & FDRIVE_MOTOR_ON)
retval |= 1 << 4;
/* DMA enable */
retval |= fdctrl->dma_en << 3;
@@ -782,15 +813,18 @@
static void fdctrl_write_dor (fdctrl_t *fdctrl, uint32_t value)
{
-/* Reset mode */
-if (fdctrl->state & FD_CTRL_RESET) {
-if (!(value & 0x04)) {
-FLOPPY_DPRINTF("Floppy controller in RESET state !\n");
-return;
-}
-}
FLOPPY_DPRINTF("digital output register set to 0x%02x\n", value);
/* Drive motors state indicators */
+#if MAX_FD >= 4
+if (value & 0x80)
+fd_start(drv3(fdctrl));
+else
+fd_stop(drv3(fdctrl));
+if (value & 0x40)
+fd_start(drv2(fdctrl));
+else
+fd_stop(drv2(fdctrl));
+#endif
if (value & 0x20)
fd_start(drv1(fdctrl));
else
@@ -818,7 +852,11 @@
}
}
/* Selected drive */
+#if MAX_FD >= 4
+fdctrl->cur_drv = value & 3;
+#else
fdctrl->cur_drv = value & 1;
+#endif
}
/* Tape drive register : 0x03 */
@@ -843,7 +881,11 @@
}
FLOPPY_DPRINTF("tape drive register set to 0x%02x\n", value);
/* Disk boot selection indicator */
+#if MAX_FD >= 4
+fdctrl->bootsel = (value >> 2) & 3;
+#else
fdctrl->bootsel = (value >> 2) & 1;
+#endif
/* Tape indicators
[Qemu-devel] helper.c chokes up when using -march
When I try to compile qemu on MinGW gcc 3.4.5 using -march=i686 or higher, or
use -msse, the helper.c file on the i386 (but not the x86_64 target, for some
odd reason) spits out
C:/msys/1.0/home/Owner/SoureCode/qemu/target-i386/helper.c: In function
`svm_check_intercept_param':
C:/msys/1.0/home/Owner/SoureCode/qemu/target-i386/helper.c:4375: error: unable
to find a register to spill in class `GENERAL_REGS'
C:/msys/1.0/home/Owner/SoureCode/qemu/target-i386/helper.c:4375: error: this is
the insn:
(insn:HI 353 352 354 39
C:/msys/1.0/home/Owner/SoureCode/qemu/target-i386/helper.c:4368 (parallel [
(set (reg:DI 167 [ .intercept ])
(lshiftrt:DI (reg:DI 167 [ .intercept ])
(subreg:QI (reg:SI 166) 0)))
(clobber (scratch:SI))
(clobber (reg:CC 17 flags))
]) 309 {lshrdi3_1} (insn_list 351 (insn_list 352 (nil)))
(expr_list:REG_DEAD (reg:SI 166)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (scratch:SI)
(nil)
A similar error happens on ppc with op_helper, but it seems to be a problem
with a header file (it also doesn't choke up when compiling the 64-bit
target... odd):
./softmmu_template.h: In function `__stq_mmu':
./softmmu_template.h:260: error: unable to find a register to spill in class
`GENERAL_REGS'
./softmmu_template.h:260: error: this is the insn:
(insn:HI 254 249 255 13 ../softmmu_template.h:289 (parallel [
(set (reg:DI 0 ax [171])
(lshiftrt:DI (reg/v:DI 59 [ val ])
(subreg:QI (reg:SI 194) 0)))
(clobber (scratch:SI))
(clobber (reg:CC 17 flags))
]) 309 {lshrdi3_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (scratch:SI)
(nil
./softmmu_template.h:260: confused by earlier errors, bailing out
make: *** [op_helper.o] Error 1
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> If you mean the one at repo.or.cz and the one at kernel.dk, no. They
> contain exactly the same history.
You're right. I hadn't checked. My own mirror generated with
git-cvsimport is incompatible with both of course, but those two are
in fact compatible.
How is that achieved ? Is one of them a mirror of the other ? Who
runs them ? (Why do I have to asking about this on a mailing list
when there ought to be a web page telling me?)
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi,
On Tue, 12 Feb 2008, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled
> do?"):
> > On Tue, 12 Feb 2008, Ian Jackson wrote:
> > > At the very least we need one drcs branch containing only changes
> > > from the upstream cvs. It has to be incrementally updated,
> > > automatically and frequently, and generally be well maintained.
> >
> > FWIW on this very list, there have been enough hints where you can
> > find such a thing, and it is not even private.
>
> I've seen two people mention git mirror urls.
>
> They contain different incompatible histories because they're
> generated separately.
If you mean the one at repo.or.cz and the one at kernel.dk, no. They
contain exactly the same history.
> The problem isn't that we don't have a git mirror of cvs. The problem
> is that we need to have exactly _one_.
I do not begin to understand why.
Ciao,
Dscho
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> On Tue, 12 Feb 2008, Ian Jackson wrote:
> > At the very least we need one drcs branch containing only changes from
> > the upstream cvs. It has to be incrementally updated, automatically
> > and frequently, and generally be well maintained.
>
> FWIW on this very list, there have been enough hints where you can find
> such a thing, and it is not even private.
I've seen two people mention git mirror urls.
They contain different incompatible histories because they're
generated separately. The problem isn't that we don't have a git
mirror of cvs. The problem is that we need to have exactly _one_.
And if we're going to have exactly one then it has to be reliable.
That doesn't mean some mirror url found in a search engine.
It means a site whose operators we know, and whose operators have
shown some evidence of a commitment to keep it working, and whom we
can contact them if it breaks. It means that the the update frequency
is published. It means someone who has some connection with the qemu
community so that we can expect them to care about it.
If we have that then everyone can expect to pull from it and not
commit to a workflow that might suddenly become untenable.
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Tue, 12 Feb 2008, Ian Jackson wrote: > * In the meantime, or if upstream decide not to, what is the best way >for non-upstream contributors to collaborate with each other ? > > [...] > > What should those of us who want to collaborate using a drcs (so that we > can share our work-in-progress patches and generally avoid blocking on > upstream) do in the meantime ? > > Having a private mirror of a drcs is all well and good but no-one can > pull from anyone else because each cvs/svn->drcs conversion yields an > incompatible history. > > At the very least we need one drcs branch containing only changes from > the upstream cvs. It has to be incrementally updated, automatically > and frequently, and generally be well maintained. FWIW on this very list, there have been enough hints where you can find such a thing, and it is not even private. Ciao, Dscho
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
> If people don't like using environmental variables, I can accept that. > Let's not pretend though that the reason is that we're protecting the > end users :-) It's more protecting me from end users :-) I should have said part of the reason. I'll admit a large part is personal preference. Paul
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, Am 12.02.2008 um 12:15 schrieb Johannes Schindelin: On Tue, 12 Feb 2008, Paul Brook wrote: Any news on the possible cvs->svn migration? To be perfectly honest, IMO there is little point moving an existing project from CVS to SVN. I disagree. CVS has several fairly fundamental flaws (no global revision IDs, unable to move files, and more subtle problems with branches/tags). SVN fixes these, and in most cases works as a direct drop-in replacement for CVS. Granted, SVN is better than CVS. But they did not even begin to tackle the fundamental shortcomings. While I can see that distributed revision control systems do enable some interesting possibilities, there's certainly no clear winner. There might not be a clear winner, but that's only because they are about equally "good". Using this argument to choose an inferiour system, such as svn, which is not only slower, bigger, has a lousy tagging/annotating/merging support, but actively discourages good workflows, is, uhm, not so wise. Currently SVN is much more widely supported than Git, which seem to be the only two alternative options here at Savannah. All of them seem to have have fairly serious issues with either usability, portability, scalability, and/or require learning a whole new workflow. Note that he said 'either'. Usability: uhm, no. There are enough short tutorials to show that Hg and Git are pretty easy to learn. Portability: uhm, no. Hg never had an issue there, Git no longer does. Mercurial has a hard dependency on Python; Git only an optional dependency on Tcl/Tk for their GUI. SVN tarballs don't need either (only SVN from SVN needs Perl+Python). Whole new workflow: uhm, no. You do not _need_ to use the bells and whistles of Hg or Git, if you really are that resistant. Johannes, just navigating around your Git repository is "hard" for someone not comfortable with git. The git pull etc. part is easy compared to that. The Subversion URLs make it much more obvious to find branches; something that's really missing in our CVS and recently forced to fork a stable branch elsewhere. But if you have 5 options, 2 of them just shine, and the other 3 are bad, do you really pick a bad apple, because "there is no best"? This is pointless and untrue. I agree with Paul that SVN is better than CVS and so did you above; so there's no black-and-white or 2:3 really. And may I add that for SVN there's apparently also an SVK in addition to the already mentioned git/hg interoperability. (haven't used it personally though) The really interesting question I see is whether a move from CVS to SVN here at Savannah would allow the CVS history to be imported using said heuristics. If no, then I assume it's out of the question anyway. Andreas
Re: [Qemu-devel] What does code_copy_enabled do?
It seems to me that there are two questions here: * Should the CVS for the upstream repository be replaced with something else ? * In the meantime, or if upstream decide not to, what is the best way for non-upstream contributors to collaborate with each other ? The answer to the first question is unambiguously `yes', I think. There are approximately five serious contenders for the replacement: svn, darcs, hg, git, bzr. Switching now to any of the drcs's would be unlikely to be regretted in the medium to long term. I haven't used darcs, but I'm in a perhaps slightly unusual position of having used all of hg, git, bzr and cvs. (I've touched svn too but haven't done anything at all complicated with it, like branching.) I think that for cvs refugees, the right answer is bzr. [1][2] bzr is strictly better than cvs in almost every respect. In particular, refugees from cvs and svn will find it easy to get to grips with. To a large extent you can just say `bzr whatever' instead of `cvs whatever', confident that it will do the right thing - and guessing is safe because even if that was the wrong rune it generally won't do something crazy and make a hideous mess. The areas where bzr is comparatively weak (performance, advanced forms of merging, lightweight branching, etc.) are already worse in cvs. On the other hand, git's and hg's weaknesses are clear regressions from cvs. git's user interface is frankly appalling. It's very functional and some day I hope to see a wrapper which makes git look more like the way everyone expects an rcs to work, and avoids blowing off one's leg. In the meantime I do use it myself but I'm wary of pushing it. hg is much better. OTOH it does have one severe problem: it expects you to check in before merging, which is the opposite of what cvs users expect. A cvs refugee, or anyone working on a project whose leaders don't like merge changesets (yes, they exist) will notice new changes upstream and decide to merge them into their current tree with `hg pull -u', which is the equivalent of `cvs update'. However, that rune's handling of merge conflicts is catastrophically bad and likely to lead to the working tree being effectively destroyed, possibly losing a great deal of work. As I've said, I think there is no point switching from cvs to svn. It's true that cvs's lack of the concept of a changeset is a serious problem and makes mirroring a cvs repository something of a challenge. However, there is already software to reconstruct changesets from cvs logs, and provided the cvs users use cvs in a sane and predictable way (which current qemu upstream do) those conversion tools do work. svn's support for branches is even worse than that of cvs's; this is frankly astonishing given how painful branches are to work with in cvs and how long this has been known to be a serious problem. But really my point is that change is painful so if we're going to try to switch to a new revision control system, with all of the learning, messing about with new software, cursing, and so on, we should try to get as much benefit as we can for our effort. Anyone who switches to svn now will, I think, regret it in another few years. The pressure to switch to a drcs will not go away. On to the second question: What should those of us who want to collaborate using a drcs (so that we can share our work-in-progress patches and generally avoid blocking on upstream) do in the meantime ? Having a private mirror of a drcs is all well and good but no-one can pull from anyone else because each cvs/svn->drcs conversion yields an incompatible history. At the very least we need one drcs branch containing only changes from the upstream cvs. It has to be incrementally updated, automatically and frequently, and generally be well maintained. Most of the potential users seem to be fans of git which is fine by me. If there is someone who knows git better than me and would like to provide a properly supported regularly updated git mirror of the upstream cvs then I would be happy to use and pull from it. Otherwise I would be quite happy to maintain such a thing on www.xen.org (the website for the Open Source Xen). Ian. (I hope the Reply-To munging hasn't caused anyone to be dropped from the CC; I've done a quick check but please forgive me if I missed one.) [1] Full disclosure: Not everyone may be aware that I spent a couple of years working for Canonical as an Ubuntu developer; I left in November. I didn't work on bzr. IMO my recommendation of bzr is best regarded as despite my relationship with Canonical, rather than because of it. [2] Some people think that bzr has some kind of dependency on Launchpad. This is not the case. If it did I wouldn't be recommending it.
Re: [Qemu-devel] What does code_copy_enabled do?
> : > > Any news on the possible cvs->svn migration? > : > > : > To be perfectly honest, IMO there is little point moving an existing > : > project from CVS to SVN. > : > : I disagree. CVS has several fairly fundamental flaws (no global revision > : IDs, unable to move files, and more subtle problems with branches/tags). > : SVN fixes these, and in most cases works as a direct drop-in replacement > : for CVS. > > FreeBSD is moving from CVS to SVN for these reasons. Just to second "M. Warner Losh": we moved Valgrind from CVS to SVN about 3.5 years ago and it was an excellent thing to do. It is not true to say there is no advantage over CVS -- the global revision IDs, the ability to rename files, and a simpler branching/tagging model are all big advantages. And the fact that it is more-or-less conceptually a drop-in replacement makes it easy for people to make the migration. Sure, Valgrind is a tiny project compared to FreeBSD. But we gain those advantages nonetheless. J
[Qemu-devel] [RESEND] TCG breakage if TARGET_LONG_BITS > HOST_LONG_BITS
This is a resend of a mail I sent to the list on 2008/02/06. I felt it rather disturbing, yet normal that nobody cared about Mac OS X host support, but this concerns all x86 host OSs, so I believe this deserves some discussion. Hi, I've been trying to get the new TCG approach running on an i386 host. It works when I use gcc3 (miraculously as I will explain later), but fails on gcc4. On boot the very first instruction that gets issued is the ljmp to the bios: IN: 0xfff0: ljmp $0xf000,$0xe05b This translates to OP: movi_i32 T0_0,$0xf000 movi_i32 T0_1,$0x0 movi_i32 T1_0,$0xe05b movi_i32 T1_1,$0x0 [...] and results in OUT: [size=83] 0x08e38f40: mov$0xf000,%eax 0x08e38f45: xor%edx,%edx 0x08e38f47: mov$0xe05b,%ecx 0x08e38f4c: xor%ebx,%ebx [...] This is perfectly fine if you assume, that these registers get clobbered and save/restore them or define them as global register variables. Unfortunately on TARGET_LONG_BITS==64 this does not happen, as T0 and T1 are supposed to be in memory, not in registers. As can be seen in the gcc4 generated assembly, gcc thinks that ebx is just fine after the function call: 0x80e1449 : mov%ebp,%ebx 0x80e144b : mov%esi,0x510(%ebp) 0x80e1451 : call *%eax 0x80e1453 : mov%eax,%edx 0x80e1455 : sar$0x1f,%edx 0x80e1458 : mov%eax,(%ebx) and qemu segfaults here. So basically there are two things puzzling me here. 1. Why is gcc3 generating code, that does not use ebx? 2. Why does movi_i64 generate code that only accesses registers? I have not been able to find any branch in the tcg code generator for movi_ixx that generates movs to memory addresses. The whole issue could be easily fixed by using registers, but putting the call into inline assembly, telling gcc that this call clobbers all the registers. I do not know if this is the expected behavior though, so I think I'd rather ask before doing any patches. I hope this helps, Alex
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, I did not really want to continue this discussion, but then, I really cannot let certain statements slip by. *sigh* On Tue, 12 Feb 2008, Paul Brook wrote: > > > Any news on the possible cvs->svn migration? > > > > To be perfectly honest, IMO there is little point moving an existing > > project from CVS to SVN. > > I disagree. CVS has several fairly fundamental flaws (no global > revision IDs, unable to move files, and more subtle problems with > branches/tags). SVN fixes these, and in most cases works as a direct > drop-in replacement for CVS. Granted, SVN is better than CVS. But they did not even begin to tackle the fundamental shortcomings. > While I can see that distributed revision control systems do enable some > interesting possibilities, there's certainly no clear winner. There might not be a clear winner, but that's only because they are about equally "good". Using this argument to choose an inferiour system, such as svn, which is not only slower, bigger, has a lousy tagging/annotating/merging support, but actively discourages good workflows, is, uhm, not so wise. > All of them seem to have have fairly serious issues with either > usability, portability, scalability, and/or require learning a whole new > workflow. Usability: uhm, no. There are enough short tutorials to show that Hg and Git are pretty easy to learn. Portability: uhm, no. Hg never had an issue there, Git no longer does. Scalability: I do beg your pardon? Hg might not be as scalable as Git, but SVN and CVS positively *suck* in that respect. Whole new workflow: uhm, no. You do not _need_ to use the bells and whistles of Hg or Git, if you really are that resistant. You can just update & add & commit as before (with Git, you just need to substitute "pull" for "update"). The only difference is that you push to the "official" server from time to time. > I'm sure advocates of each system will claim that their system is the > "best", but I remain unconvinced. I'm sure you remain unconvinced, if only to make a point. As for "best": I would not claim that either Hg or Git are "best". My preference is clear. But if you have 5 options, 2 of them just shine, and the other 3 are bad, do you really pick a bad apple, because "there is no best"? > SVN may not have the bells and whistles of some of the more exotic > systems. However it is is well tested proven technology, and IMO > universally better than CVS. It is well tested and proven, granted. As a version control system. But in terms of a source code management tool, it just leaves to be desired. Ciao, Dscho
[Qemu-devel] Re: Something fishy on linux-user/mmap.c
On Feb 11, 2008 11:18 PM, Felipe Contreras <[EMAIL PROTECTED]> wrote: > Hi, > > There's something wrong with the commit > edbcc0b2eb1d4caee5f293e5c79f81023f3394e2. Err, by that I meant: http://repo.or.cz/w/qemu.git?a=commitdiff;h=edbcc0b2eb1d4caee5f293e5c79f81023f3394e2 Sorry, I'm spoiled by git. Best regards. -- Felipe Contreras
