Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible

2007-03-16 Thread J M Cerqueira Esteves
herbie hancock wrote:
 Hello, i had also a reproducible disk crash:
 info of the last good image, size is about 3,5GB
 
 I never experienced such a bad problem with qemu before, maybe it is a 
 problem with qcow2 format ?

After the problems with qcow2 images which I reported here a few weeks
ago, I've only been using qcow images (under QEMU 0.9.0), without such
surprises.  So it seems qemu has some bug related to qcow2 images,
maybe manifesting itself only after they get larger than 4GB...


Best regards
  J Esteves


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] Redundant repz prefixes in generated amd64 code

2007-03-16 Thread Julian Seward

I'm seeing redundant repz (0xF3) prefixes in generated code, typically
just before jumps:

code_gen_buffer+415:  repz mov $0xe07f,%eax
code_gen_buffer+421:  mov%eax,0x20(%rbp)
code_gen_buffer+424:  lea-25168302(%rip),%ebx  # 0xaf0420 tbs+96
code_gen_buffer+430:  retq
code_gen_buffer+431:  mov-25168245(%rip),%eax  # 0xaf0460 tbs+160
code_gen_buffer+437:  jmpq   *%rax
code_gen_buffer+439:  repz mov $0xe092,%eax
code_gen_buffer+445:  mov%eax,0x20(%rbp)
code_gen_buffer+448:  lea-25168325(%rip),%ebx   # 0xaf0421 tbs+97
code_gen_buffer+454:  retq

I assume these are something to do with translation chaining/unchaining but
have been unable to figure out where they come from.  I know they get executed
are so are not data - valgrind barfs on them.

This is on a 64-bit host (Core 2) with qemu-0.9.0 compiled from source by
gcc-3.4.6, running an x86 (32-bit) guest.

At a guess I'd say the mov $imm,%eax is (created by? to do with?) 
gen_jmp_im in target-i386/translate.c, but I don't see how the F3 
got in on the act.  Grepping the source for 0xF3 turns up nothing 
plausible.  Any ideas where it comes from and how to get rid of it?

J


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

2007-03-16 Thread Paul Brook
On Friday 16 March 2007 14:15, Julian Seward wrote:
 I'm seeing redundant repz (0xF3) prefixes in generated code, typically
 just before jumps:

 code_gen_buffer+415:  repz mov $0xe07f,%eax
 code_gen_buffer+421:  mov%eax,0x20(%rbp)
 code_gen_buffer+424:  lea-25168302(%rip),%ebx  # 0xaf0420 tbs+96
 code_gen_buffer+430:  retq
 code_gen_buffer+431:  mov-25168245(%rip),%eax  # 0xaf0460 tbs+160
 code_gen_buffer+437:  jmpq   *%rax
 code_gen_buffer+439:  repz mov $0xe092,%eax
 code_gen_buffer+445:  mov%eax,0x20(%rbp)
 code_gen_buffer+448:  lea-25168325(%rip),%ebx   # 0xaf0421 tbs+97
 code_gen_buffer+454:  retq

 I assume these are something to do with translation chaining/unchaining but
 have been unable to figure out where they come from.

8b50 op_goto_tb1:
8b50:   8b 05 00 00 00 00   mov0(%rip),%eax 
8b52: R_X86_64_PC32 __op_param1+0x3c
8b56:   ff e0   jmpq   *%rax
8b58:   f3 c3   repz retq

qemu only strips the final ret off.
The prefixed ret is to avoid prefetch stalls on amd cpus.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

2007-03-16 Thread Julian Seward
On Friday 16 March 2007 14:28, Paul Brook wrote:
 On Friday 16 March 2007 14:15, Julian Seward wrote:
  I'm seeing redundant repz (0xF3) prefixes in generated code, typically
  just before jumps:
 
  code_gen_buffer+415:  repz mov $0xe07f,%eax
  code_gen_buffer+421:  mov%eax,0x20(%rbp)
  code_gen_buffer+424:  lea-25168302(%rip),%ebx  # 0xaf0420 tbs+96
  code_gen_buffer+430:  retq
  code_gen_buffer+431:  mov-25168245(%rip),%eax  # 0xaf0460 tbs+160
  code_gen_buffer+437:  jmpq   *%rax
  code_gen_buffer+439:  repz mov $0xe092,%eax
  code_gen_buffer+445:  mov%eax,0x20(%rbp)
  code_gen_buffer+448:  lea-25168325(%rip),%ebx   # 0xaf0421 tbs+97
  code_gen_buffer+454:  retq
 
  I assume these are something to do with translation chaining/unchaining
  but have been unable to figure out where they come from.

 8b50 op_goto_tb1:
 8b50:   8b 05 00 00 00 00   mov0(%rip),%eax
 8b52: R_X86_64_PC32 __op_param1+0x3c
 8b56:   ff e0   jmpq   *%rax
 8b58:   f3 c3   repz retq

 qemu only strips the final ret off.
 The prefixed ret is to avoid prefetch stalls on amd cpus.

So the implication of this is that the generated code just happens to
work only because the dangling F3 never ends up in front of some other
instruction which it would change the meaning of?

J


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [PATCH] Typo : fix recv and recvfrom syscalls in user emulation

2007-03-16 Thread Kirill A. Shutemov
On [Fri, 16.03.2007 13:46], Raphaël Rigo wrote:
 Trivial patch following
 
 Regards,
 Raphaël Rigo
 
 ===
 RCS file: /sources/qemu/qemu/linux-user/syscall.c,v
 retrieving revision 1.89
 diff -u -r1.89 syscall.c
 --- linux-user/syscall.c2 Mar 2007 20:47:59 -   1.89
 +++ linux-user/syscall.c16 Mar 2007 12:43:15 -
 @@ -2914,12 +2914,12 @@
  #endif
  #ifdef TARGET_NR_recv
  case TARGET_NR_recv:
 -ret = do_recvfrom(arg1, arg1, arg3, arg4, 0, 0);
 +ret = do_recvfrom(arg1, arg2, arg3, arg4, 0, 0);
  break;
  #endif
  #ifdef TARGET_NR_recvfrom
  case TARGET_NR_recvfrom:
 -ret = do_recvfrom(arg1, arg1, arg3, arg4, arg5, arg6);
 +ret = do_recvfrom(arg1, arg2, arg3, arg4, arg5, arg6);
  break;
  #endif
  #ifdef TARGET_NR_recvmsg

I have posted same patch(and a few other) more then week ago, but it
hasn't commit yet.


signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible

2007-03-16 Thread Ben Taylor

 J M Cerqueira Esteves [EMAIL PROTECTED] wrote: 
 herbie hancock wrote:
  Hello, i had also a reproducible disk crash:
  info of the last good image, size is about 3,5GB
  
  I never experienced such a bad problem with qemu before, maybe it is a 
  problem with qcow2 format ?
 
 After the problems with qcow2 images which I reported here a few weeks
 ago, I've only been using qcow images (under QEMU 0.9.0), without such
 surprises.  So it seems qemu has some bug related to qcow2 images,
 maybe manifesting itself only after they get larger than 4GB...

I suspect I saw problems with qcow2 images as well.  I was able to suspend
a Solaris Nevada B58 install and use savevm about 30% into the install and
restart it later.  As the image completd, the file system went all to hell
with corruption that was impossible to fix.  At the time, I attributed it to
the Solaris install (thinking it might have something to do with the
cmpxchg8b bug that was later fixed), but I suspect with the multiple
reports I've seen, I'm now thinking I saw the same thing.

I'm testing conversion of a qcow image to a qcow2 image.  We'll see how
that goes

Ben


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] SSE 'maxps' instruction bug?

2007-03-16 Thread Rob Landley
On Tuesday 13 March 2007 10:21 pm, Julian Seward wrote:
 
  0.9.0, or that the compiler/host combination used to build the qemu
  binary Julian is running generated bad code for the float compares.
 
 I used gcc 3.4.6 bootstrapped as normal ('make bootstrap; make install')
 on a 64-bit machine.  If it is qemu generating bad code due to variations
 in gcc behaviour, that's another argument in favour of scrapping the gcc 
 3.X based backend and using a self contained, handwritten insn selector
 and register allocator.

Are you referring to https://nowt.dyndns.org/ or something else?

Rob
-- 
Vista: Windows Millenium Second Edition


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] SSE 'maxps' instruction bug?

2007-03-16 Thread Julian Seward
On Friday 16 March 2007 18:07, Rob Landley wrote:
 On Tuesday 13 March 2007 10:21 pm, Julian Seward wrote:
   0.9.0, or that the compiler/host combination used to build the qemu
   binary Julian is running generated bad code for the float compares.
 
  I used gcc 3.4.6 bootstrapped as normal ('make bootstrap; make install')
  on a 64-bit machine.  If it is qemu generating bad code due to variations
  in gcc behaviour, that's another argument in favour of scrapping the gcc
  3.X based backend and using a self contained, handwritten insn selector
  and register allocator.

 Are you referring to https://nowt.dyndns.org/ or something else?

I was referring to an idea, of which the nowt thing is an implementation.
I'm not aware of any other such backends to qemu.

J


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

2007-03-16 Thread Paul Brook
  8b50 op_goto_tb1:
  8b50:   8b 05 00 00 00 00   mov0(%rip),%eax
  8b52: R_X86_64_PC32 __op_param1+0x3c
  8b56:   ff e0   jmpq   *%rax
  8b58:   f3 c3   repz retq
 
  qemu only strips the final ret off.
  The prefixed ret is to avoid prefetch stalls on amd cpus.

 So the implication of this is that the generated code just happens to
 work only because the dangling F3 never ends up in front of some other
 instruction which it would change the meaning of?

Correct.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible

2007-03-16 Thread Julian Seward

I ran QEMU on Valgrind for several hours last night, including a couple
of boot-shutdown cycles of RedHat8, and lots of file copying/deletion 
in the guest to get the qcow2 image up to 8GB and generally cause a lot
of disk IO.  I got no memory errors whatsoever from Valgrind and got no
filesystem corruption, so I guess I didn't trigger the bug.

Really the first thing to do is establish a reliable way to reproduce it.

J


On Friday 16 March 2007 17:00, Ben Taylor wrote:
  J M Cerqueira Esteves [EMAIL PROTECTED] wrote:
  herbie hancock wrote:
   Hello, i had also a reproducible disk crash:
   info of the last good image, size is about 3,5GB
  
   I never experienced such a bad problem with qemu before, maybe it is a
   problem with qcow2 format ?
 
  After the problems with qcow2 images which I reported here a few weeks
  ago, I've only been using qcow images (under QEMU 0.9.0), without such
  surprises.  So it seems qemu has some bug related to qcow2 images,
  maybe manifesting itself only after they get larger than 4GB...

 I suspect I saw problems with qcow2 images as well.  I was able to suspend
 a Solaris Nevada B58 install and use savevm about 30% into the install and
 restart it later.  As the image completd, the file system went all to hell
 with corruption that was impossible to fix.  At the time, I attributed it
 to the Solaris install (thinking it might have something to do with the
 cmpxchg8b bug that was later fixed), but I suspect with the multiple
 reports I've seen, I'm now thinking I saw the same thing.

 I'm testing conversion of a qcow image to a qcow2 image.  We'll see how
 that goes

 Ben


 ___
 Qemu-devel mailing list
 Qemu-devel@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

2007-03-16 Thread Igor Kovalenko

On 3/16/07, Julian Seward [EMAIL PROTECTED] wrote:


I'm seeing redundant repz (0xF3) prefixes in generated code, typically
just before jumps:

code_gen_buffer+415:  repz mov $0xe07f,%eax
code_gen_buffer+421:  mov%eax,0x20(%rbp)
code_gen_buffer+424:  lea-25168302(%rip),%ebx  # 0xaf0420 tbs+96
code_gen_buffer+430:  retq
code_gen_buffer+431:  mov-25168245(%rip),%eax  # 0xaf0460 tbs+160
code_gen_buffer+437:  jmpq   *%rax
code_gen_buffer+439:  repz mov $0xe092,%eax
code_gen_buffer+445:  mov%eax,0x20(%rbp)
code_gen_buffer+448:  lea-25168325(%rip),%ebx   # 0xaf0421 tbs+97
code_gen_buffer+454:  retq

I assume these are something to do with translation chaining/unchaining but
have been unable to figure out where they come from.  I know they get executed
are so are not data - valgrind barfs on them.

This is on a 64-bit host (Core 2) with qemu-0.9.0 compiled from source by
gcc-3.4.6, running an x86 (32-bit) guest.

At a guess I'd say the mov $imm,%eax is (created by? to do with?)
gen_jmp_im in target-i386/translate.c, but I don't see how the F3
got in on the act.  Grepping the source for 0xF3 turns up nothing
plausible.  Any ideas where it comes from and how to get rid of it?



Try -mtune=nocona something like the following

Index: Makefile.target
===
RCS file: /cvsroot/qemu/qemu/Makefile.target,v
retrieving revision 1.147
diff -u -r1.147 Makefile.target
--- Makefile.target 28 Feb 2007 21:36:41 -  1.147
+++ Makefile.target 16 Mar 2007 19:29:04 -
@@ -99,6 +99,7 @@
endif

ifeq ($(ARCH),x86_64)
+OP_CFLAGS+= -mtune=nocona -W -Wall -O4
BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
endif


--
Kind regards,
Igor V. Kovalenko


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] SSE 'maxps' instruction bug?

2007-03-16 Thread Rob Landley
On Friday 16 March 2007 2:10 pm, Julian Seward wrote:
 On Friday 16 March 2007 18:07, Rob Landley wrote:
  On Tuesday 13 March 2007 10:21 pm, Julian Seward wrote:
0.9.0, or that the compiler/host combination used to build the qemu
binary Julian is running generated bad code for the float compares.
  
   I used gcc 3.4.6 bootstrapped as normal ('make bootstrap; make install')
   on a 64-bit machine.  If it is qemu generating bad code due to 
variations
   in gcc behaviour, that's another argument in favour of scrapping the gcc
   3.X based backend and using a self contained, handwritten insn selector
   and register allocator.
 
  Are you referring to https://nowt.dyndns.org/ or something else?
 
 I was referring to an idea, of which the nowt thing is an implementation.
 I'm not aware of any other such backends to qemu.

That's Paul Brook's QOPS thing that gets discussed here from time to time.  
There are vague plans to switch over to that soonish.

Rob
-- 
Vista: Windows Millenium Second Edition


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register

2007-03-16 Thread Lauro Ramos Venancio
I'm sending a new version of the patch that uses Base Restored data
abort model.

Lauro
diff -ru qemu-0.9.0.orig/target-arm/translate.c qemu-0.9.0/target-arm/translate.c
--- qemu-0.9.0.orig/target-arm/translate.c	2007-03-16 11:41:28.0 -0300
+++ qemu-0.9.0/target-arm/translate.c	2007-03-16 14:59:40.0 -0300
@@ -1556,7 +1556,6 @@
 gen_ldst(ldsw, s);
 break;
 }
-gen_movl_reg_T0(s, rd);
 } else if (sh  2) {
 /* doubleword */
 if (sh  1) {
@@ -1572,7 +1571,7 @@
 gen_movl_reg_T0(s, rd);
 gen_op_addl_T1_im(4);
 gen_ldst(ldl, s);
-gen_movl_reg_T0(s, rd + 1);
+++rd;
 }
 address_offset = -4;
 } else {
@@ -1588,6 +1587,12 @@
 gen_op_addl_T1_im(address_offset);
 gen_movl_reg_T1(s, rn);
 }
+
+if ((insn  (1  20)) ||
+((!(insn  (1  20)))((sh  3) == 2))) {
+/* load */
+gen_movl_reg_T0(s, rd);
+}
 }
 break;
 case 0x4:
@@ -1630,10 +1635,6 @@
 gen_op_ldl_kernel();
 }
 #endif
-if (rd == 15)
-gen_bx(s);
-else
-gen_movl_reg_T0(s, rd);
 } else {
 /* store */
 gen_movl_T0_reg(s, rd);
@@ -1662,6 +1663,13 @@
 } else if (insn  (1  21))
 gen_movl_reg_T1(s, rn); {
 }
+if (insn  (1  20)) {
+/* load */
+if (rd == 15)
+gen_bx(s);
+else
+gen_movl_reg_T0(s, rd);
+}
 break;
 case 0x08:
 case 0x09:
Only in qemu-0.9.0/target-arm: translate.c~
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [PATCH] Hitachi DSCM microdrive. PCMCIA bus support.

2007-03-16 Thread andrzej zaborowski

This emulates a hard drive present in various PDAs, that connects over
PCMCIA and understands the CF-ATA command set. The drives series has
names DSCM1.

For this I add a simple API for PCMCIA cards and host slots. The
monitor command info pcmcia lists sockets and cards that sit in
them.

I wasn't sure if I should put the code in a file separate from ide.c. Ideas?

Cheers,
Andrew
From bea09ad38e0d32bf187defa37ff8fb1ef2297745 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 15:00:05 +0100
Subject: [PATCH] Hitachi DSCM microdrive. PCMCIA bus support.

---
 hw/ide.c  |  743 -
 monitor.c |2 +
 vl.c  |   42 
 vl.h  |   51 +
 4 files changed, 834 insertions(+), 4 deletions(-)

diff --git a/hw/ide.c b/hw/ide.c
index 9e5451f..1c81c98 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -2,6 +2,7 @@
  * QEMU IDE disk and CD-ROM Emulator
  * 
  * Copyright (c) 2003 Fabrice Bellard
+ * Copyright (c) 2006 Openedhand Ltd.
  * 
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the Software), to 
deal
@@ -131,6 +132,7 @@
 #define WIN_SPECIFY0x91 /* set drive geometry translation 
*/
 #define WIN_DOWNLOAD_MICROCODE 0x92
 #define WIN_STANDBYNOW20x94
+#define CFA_IDLEIMMEDIATE  0x95 /* force drive to become ready */
 #define WIN_STANDBY2   0x96
 #define WIN_SETIDLE2   0x97
 #define WIN_CHECKPOWERMODE20x98
@@ -142,7 +144,8 @@
 #define WIN_PIDENTIFY  0xA1 /* identify ATAPI device   */
 #define WIN_QUEUED_SERVICE 0xA2
 #define WIN_SMART  0xB0 /* self-monitoring and reporting */
-#define CFA_ERASE_SECTORS  0xC0
+#define CFA_ACCESS_METADATA_STORAGE0xB8
+#define CFA_ERASE_SECTORS  0xC0 /* microdrives implement as NOP */
 #define WIN_MULTREAD   0xC4 /* read sectors using multiple 
mode*/
 #define WIN_MULTWRITE  0xC5 /* write sectors using multiple 
mode */
 #define WIN_SETMULT0xC6 /* enable/disable multiple mode */
@@ -176,11 +179,13 @@
 #define WIN_IDENTIFY_DMA   0xEE /* same as WIN_IDENTIFY, but DMA */
 #define WIN_SETFEATURES0xEF /* set special drive 
features */
 #define EXABYTE_ENABLE_NEST0xF0
+#define IBM_SENSE_CONDITION0xF0 /* measure disk temperature */
 #define WIN_SECURITY_SET_PASS  0xF1
 #define WIN_SECURITY_UNLOCK0xF2
 #define WIN_SECURITY_ERASE_PREPARE 0xF3
 #define WIN_SECURITY_ERASE_UNIT0xF4
 #define WIN_SECURITY_FREEZE_LOCK   0xF5
+#define CFA_WEAR_LEVEL 0xF5 /* microdrives implement as NOP */
 #define WIN_SECURITY_DISABLE   0xF6
 #define WIN_READ_NATIVE_MAX0xF8 /* return the native maximum 
address */
 #define WIN_SET_MAX0xF9
@@ -282,6 +287,12 @@
 #define ASC_MEDIUM_NOT_PRESENT   0x3a
 #define ASC_SAVING_PARAMETERS_NOT_SUPPORTED  0x39
 
+#define CFA_NO_ERROR0x00
+#define CFA_MISC_ERROR  0x09
+#define CFA_INVALID_COMMAND 0x20
+#define CFA_INVALID_ADDRESS 0x21
+#define CFA_ADDRESS_OVERFLOW0x2f
+
 #define SENSE_NONE0
 #define SENSE_NOT_READY   2
 #define SENSE_ILLEGAL_REQUEST 5
@@ -295,6 +306,7 @@ typedef void EndTransferFunc(struct IDEState *);
 typedef struct IDEState {
 /* ide config */
 int is_cdrom;
+int is_cf;
 int cylinders, heads, sectors;
 int64_t nb_sectors;
 int mult_sectors;
@@ -349,6 +361,12 @@ typedef struct IDEState {
 uint8_t io_buffer[MAX_MULT_SECTORS*512 + 4];
 QEMUTimer *sector_write_timer; /* only used for win2k instal hack */
 uint32_t irq_count; /* counts IRQs when using win2k install hack */
+/* CF-ATA extended error */
+uint8_t ext_error;
+/* CF-ATA metadata storage */
+uint32_t mdata_size;
+uint8_t *mdata_storage;
+int media_changed;
 } IDEState;
 
 #define BM_STATUS_DMAING 0x01
@@ -544,6 +562,74 @@ static void ide_atapi_identify(IDEState *s)
 s-identify_set = 1;
 }
 
+static void ide_cfata_identify(IDEState *s)
+{
+uint16_t *p;
+uint32_t cur_sec;
+char buf[20];
+
+p = (uint16_t *) s-identify_data;
+if (s-identify_set)
+goto fill_buffer;
+
+memset(p, 0, sizeof(s-identify_data));
+
+cur_sec = s-cylinders * s-heads * s-sectors;
+
+put_le16(p + 0, 0x848a);   /* CF Storage Card signature */
+put_le16(p + 1, s-cylinders); /* Default cylinders */
+put_le16(p + 3, s-heads); /* Default heads */
+put_le16(p + 6, s-sectors);   /* Default sectors per track */
+put_le16(p + 7, s-nb_sectors  16);  /* Sectors per card */
+put_le16(p + 8, s-nb_sectors);/* Sectors per 

[Qemu-devel] [PATCH] Maxim MAX7310 GPIO expander. I2C bus support.

2007-03-16 Thread andrzej zaborowski

Adds an 8-port GPIO expansion chip that connects over I2C and a simple
I2C bus api.

Cheers,
Andrew
From 0babece5fd378a12a71c43791c76308751c6dc96 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 15:11:23 +0100
Subject: [PATCH] Maxim MAX7310 GPIO expander. I2C bus support.

---
 hw/i2c.h |  160 
 hw/max7310.c |  176 ++
 vl.h |4 +
 3 files changed, 340 insertions(+), 0 deletions(-)

diff --git a/hw/i2c.h b/hw/i2c.h
new file mode 100644
index 000..d866f28
--- /dev/null
+++ b/hw/i2c.h
@@ -0,0 +1,160 @@
+/*
+ * Simplified I2C(tm) bus / SMBus(tm).
+ *
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This file is licensed under GNU GPL v2.
+ */
+
+#define I2C_MAX_MSG4096
+
+struct i2c_slave_s {
+uint8_t address;
+int (*tx)(void *opaque, uint8_t *data, int len);
+void (*start)(void *opaque, int dir);
+void (*stop)(void *opaque);
+void *opaque;
+};
+
+struct i2c_bus_s {
+struct i2c_slave_s *slave[0x80];
+uint8_t current;
+int dir;
+};
+
+/* I2C master - drives the clock signal on a bus.  There can be multiple
+ * masters on one bus.  */
+struct i2c_master_s {
+struct i2c_bus_s *bus;
+uint8_t message[I2C_MAX_MSG];
+int message_len;
+int ack;
+
+uint8_t data;
+};
+
+static inline int i2c_bus_start(struct i2c_bus_s *bus, uint8_t byte)
+{
+struct i2c_slave_s *slave;
+
+bus-current = byte  1;
+bus-dir = byte  1;
+slave = bus-slave[bus-current];
+
+return !slave;
+}
+
+static inline int i2c_start_submit(struct i2c_bus_s *bus)
+{
+struct i2c_slave_s *slave = bus-slave[bus-current];
+if (!slave)
+return 1;
+
+if (slave-start)
+slave-start(slave-opaque, bus-dir);
+return 0;
+}
+
+static inline int i2c_stop_submit(struct i2c_bus_s *bus)
+{
+struct i2c_slave_s *slave = bus-slave[bus-current];
+if (!slave)
+return 1;
+
+if (slave-stop)
+slave-stop(slave-opaque);
+return 0;
+}
+
+static inline int i2c_msg_submit(struct i2c_bus_s *bus,
+uint8_t message[], int len)
+{
+struct i2c_slave_s *slave = bus-slave[bus-current];
+if (!slave)
+return 1;
+
+return slave-tx ? slave-tx(slave-opaque, message, len) : 1;
+}
+
+static inline void i2c_master_submit(struct i2c_master_s *master,
+int start, int stop)
+{
+int ret = 0;
+
+if (!master-bus) {
+master-ack = 0;
+return;
+}
+
+if (start) {
+if (master-message_len)
+if (!master-bus-dir) {   /* Master -- Slave */
+i2c_start_submit(master-bus);
+ret = i2c_msg_submit(master-bus,
+master-message, master-message_len);
+master-message_len = 0;
+}
+
+ret = i2c_bus_start(master-bus, master-data);
+master-message_len = 0;
+
+if (master-bus-dir) {/* Master -- Slave */
+i2c_start_submit(master-bus);
+master-message_len = 1;
+if (stop)
+i2c_msg_submit(master-bus, master-message, 0);
+}
+} else if (stop  2) {
+if (!master-bus-dir) {   /* Master -- Slave */
+if (master-message_len  I2C_MAX_MSG)
+master-message[master-message_len ++] = master-data;
+} else {   /* Master -- Slave */
+ret = i2c_msg_submit(master-bus,
+master-message, master-message_len);
+master-data = master-message[0];
+}
+}
+
+if (stop) {
+if (!master-bus-dir) {   /* Master -- Slave */
+i2c_start_submit(master-bus);
+ret = i2c_msg_submit(master-bus,
+master-message, master-message_len);
+master-message_len = 0;
+}
+
+i2c_stop_submit(master-bus);
+}
+
+master-ack = !ret;
+}
+
+/* Call with zero `addr' to detach.  */
+static inline void i2c_slave_attach(struct i2c_bus_s *bus, uint8_t addr,
+struct i2c_slave_s *dev)
+{
+if (addr = 0x80)
+cpu_abort(cpu_single_env, bad I2C address);
+
+if (dev-address)
+bus-slave[dev-address] = 0;
+
+dev-address = addr;
+
+if (dev-address)
+bus-slave[dev-address] = dev;
+}
+
+static inline void i2c_master_attach(struct i2c_bus_s *bus,
+struct i2c_master_s *dev)
+{
+dev-bus = bus;
+}
+
+/* max7310.c */
+struct i2c_slave_s *max7310_init(void);
+void max7310_reset(struct i2c_slave_s *i2c);
+void max7310_gpio_set(struct i2c_slave_s *i2c, int line, int level);
+void max7310_gpio_handler_set(struct i2c_slave_s *i2c, int line,
+gpio_handler_t handler, void *opaque);
diff --git a/hw/max7310.c b/hw/max7310.c
new file mode 100644
index 

Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

2007-03-16 Thread Julian Seward
On Friday 16 March 2007 18:40, Anthony Liguori wrote:
 Hi Julian,

 Julian Seward wrote:
  Here is a somewhat revised version of a patch I first made nearly
  three years ago.  The original thread is
 
  http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00263.html
 
  It still uses a shadow frame buffer.  Fabrice mentioned this is not
  necessary

 I thought about this a little and here's what I came up with.

 I think we could change vga_draw_line* so that as part of the drawing
 process, it compared the newly generated pixel with the previous pixel
 value and returned back the min, max x-coordinate that changed.

 Since we tend to only extend the vertical dirty range by a couple
 pixels, this should be a relatively cheap way of reducing the size of
 the update region.

Sounds plausible - having said that, I have no familiarity with the VGA
code.  Also sounds like a cleaner solution than mine.

Is there something which guarantees that the vertical dirty range only
overshoots by some small number of pixels?  (thinking more about it ..
it doesn't matter - finding min/max that changed for each line will also
make it possible to identify the vertical limits of the change).

Will this work also for the CL542x adaptor?  (Does that fall in the category
of vga?)  My current hack works for with/without -std-vga and I think 
that's because it lives underneath both, in the connection to SDL.

J


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [PATCH] Remove repeated code, enable encrypted SD and USB sticks.

2007-03-16 Thread andrzej zaborowski

Move the code that asks user for password for encrypted images, to one
places instead of having one copy in vl.c and a second one in
monitor.c. Make qemu use it for USB-mass-storage and SD cards too.

I posted this change earlier but without SD support.

Apply this on top of [PATCH] SecureDigital card emulation.

Cheers,
Andrew
From e8e50499eb4d1e2cda3cad3265cf8f925dfe520d Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 16:05:46 +0100
Subject: [PATCH] Remove repeated code, enable encrypted SD and USB sticks.

---
 hw/sd.c  |2 ++
 hw/usb-msd.c |2 ++
 monitor.c|   12 +---
 vl.c |   33 +
 vl.h |2 ++
 5 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/hw/sd.c b/hw/sd.c
index 37accde..f91054a 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -416,6 +416,8 @@ struct sd_state_s *sd_init()
 snapshot ? BDRV_O_SNAPSHOT : 0)  0)
 fprintf(stderr, %s: Couldn't open %s\n,
 __FUNCTION__, sd_filename);
+else
+qemu_key_check(bs, sd_filename);
 }
 
 sd = (struct sd_state_s *) qemu_mallocz(sizeof(struct sd_state_s));
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 4530a1c..46aa234 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -522,6 +522,8 @@ USBDevice *usb_msd_init(const char *filename)
 bdrv = bdrv_new(usb);
 if (bdrv_open(bdrv, filename, 0)  0)
 goto fail;
+if (qemu_key_check(bdrv, filename))
+goto fail;
 s-bs = bdrv;
 
 s-dev.speed = USB_SPEED_FULL;
diff --git a/monitor.c b/monitor.c
index 943b25b..3f31904 100644
--- a/monitor.c
+++ b/monitor.c
@@ -380,8 +380,6 @@ static void do_eject(int force, const char *filename)
 static void do_change(const char *device, const char *filename)
 {
 BlockDriverState *bs;
-int i;
-char password[256];
 
 bs = bdrv_find(device);
 if (!bs) {
@@ -391,15 +389,7 @@ static void do_change(const char *device, const char 
*filename)
 if (eject_device(bs, 0)  0)
 return;
 bdrv_open(bs, filename, 0);
-if (bdrv_is_encrypted(bs)) {
-term_printf(%s is encrypted.\n, device);
-for(i = 0; i  3; i++) {
-monitor_readline(Password: , 1, password, sizeof(password));
-if (bdrv_set_key(bs, password) == 0)
-break;
-term_printf(invalid password\n);
-}
-}
+qemu_key_check(bs, filename);
 }
 
 static void do_screen_dump(const char *filename)
diff --git a/vl.c b/vl.c
index e5b53d2..a22ef95 100644
--- a/vl.c
+++ b/vl.c
@@ -6705,6 +6705,24 @@ static uint8_t *signal_stack;
 
 /* password input */
 
+int qemu_key_check(BlockDriverState *bs, const char *name)
+{
+char password[256];
+int i;
+
+if (!bdrv_is_encrypted(bs))
+return 0;
+
+term_printf(%s is encrypted.\n, name);
+for(i = 0; i  3; i++) {
+monitor_readline(Password: , 1, password, sizeof(password));
+if (bdrv_set_key(bs, password) == 0)
+return 0;
+term_printf(invalid password\n);
+}
+return -EPERM;
+}
+
 static BlockDriverState *get_bdrv(int index)
 {
 BlockDriverState *bs;
@@ -6722,21 +6740,12 @@ static BlockDriverState *get_bdrv(int index)
 static void read_passwords(void)
 {
 BlockDriverState *bs;
-int i, j;
-char password[256];
+int i;
 
 for(i = 0; i  6; i++) {
 bs = get_bdrv(i);
-if (bs  bdrv_is_encrypted(bs)) {
-term_printf(%s is encrypted.\n, bdrv_get_device_name(bs));
-for(j = 0; j  3; j++) {
-monitor_readline(Password: , 
- 1, password, sizeof(password));
-if (bdrv_set_key(bs, password) == 0)
-break;
-term_printf(invalid password\n);
-}
-}
+if (bs)
+qemu_key_check(bs, bdrv_get_device_name(bs));
 }
 }
 
diff --git a/vl.h b/vl.h
index cfafc08..453e78d 100644
--- a/vl.h
+++ b/vl.h
@@ -632,6 +632,8 @@ void qemu_aio_wait_start(void);
 void qemu_aio_wait(void);
 void qemu_aio_wait_end(void);
 
+int qemu_key_check(BlockDriverState *bs, const char *name);
+
 /* Ensure contents are flushed to disk.  */
 void bdrv_flush(BlockDriverState *bs);
 
-- 
1.4.4.3

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

2007-03-16 Thread Anthony Liguori

Julian Seward wrote:

On Friday 16 March 2007 18:40, Anthony Liguori wrote:
  

Hi Julian,

Julian Seward wrote:


Here is a somewhat revised version of a patch I first made nearly
three years ago.  The original thread is

http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00263.html

It still uses a shadow frame buffer.  Fabrice mentioned this is not
necessary
  

I thought about this a little and here's what I came up with.

I think we could change vga_draw_line* so that as part of the drawing
process, it compared the newly generated pixel with the previous pixel
value and returned back the min, max x-coordinate that changed.

Since we tend to only extend the vertical dirty range by a couple
pixels, this should be a relatively cheap way of reducing the size of
the update region.



Sounds plausible - having said that, I have no familiarity with the VGA
code.  Also sounds like a cleaner solution than mine.

Is there something which guarantees that the vertical dirty range only
overshoots by some small number of pixels?


Even at a relatively low resolution (640 x 480 @ 16 bit), a page will 
span only three rows so one dirty page cannot dirty more than 5 vertical 
pixels.



  (thinking more about it ..
it doesn't matter - finding min/max that changed for each line will also
make it possible to identify the vertical limits of the change).
  


This is also true.


Will this work also for the CL542x adaptor?  (Does that fall in the category
of vga?)  My current hack works for with/without -std-vga and I think 
that's because it lives underneath both, in the connection to SDL.
  


Each adapter will have to do it's own minimization but that's sort of 
the write thing anyway IMHO.  How granular each update is really only 
depends on the adapter.  For instance, the VMware adapter really 
shouldn't need to do any minimization at all.


Regards,

Anthony Liguori


J

  




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [PATCH] NAND Flash memory emulation. ECC calculation helpers.

2007-03-16 Thread andrzej zaborowski

NAND chip that understands the basic NAND command set (most chips have
some own custom commands but operating systems don't use them). It can
emulate mostly all of the chips supported by Linux given the
manufacturer id and chip id, including large page devices. The table
of IDs is taken from Linux. I added a -mtdblock filename switch for
pointing qemu to the image to use. If no image is given nand.c will
store data only in memory and discard it on quit.

The patch also has a routine that calculates the ECC checksums that
most NAND controllers use (but not the chip itself).

Cheers,
Andrew
From 99122604f6cd1ffdb71b9d89faf1c0df99db2938 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 16:41:18 +0100
Subject: [PATCH] NAND Flash memory emulation. ECC calculation helpers.

---
 ecc.h |   77 
 hw/nand.c |  613 +
 vl.c  |7 +
 vl.h  |   22 +++
 4 files changed, 719 insertions(+), 0 deletions(-)

diff --git a/ecc.h b/ecc.h
new file mode 100644
index 000..11e6d01
--- /dev/null
+++ b/ecc.h
@@ -0,0 +1,77 @@
+/*
+ * Calculate Error-correcting Codes. Used by NAND Flash controllers
+ * (not by NAND chips).
+ *
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+struct ecc_state_s {
+uint8_t cp;/* Column parity */
+uint16_t lp[2];/* Line parity */
+uint16_t count;
+};
+
+/*
+ * Pre-calculated 256-way 1 byte column parity.  Table borrowed from Linux.
+ */
+static const uint8_t nand_ecc_precalc_table[] = {
+0x00, 0x55, 0x56, 0x03, 0x59, 0x0c, 0x0f, 0x5a,
+0x5a, 0x0f, 0x0c, 0x59, 0x03, 0x56, 0x55, 0x00,
+0x65, 0x30, 0x33, 0x66, 0x3c, 0x69, 0x6a, 0x3f,
+0x3f, 0x6a, 0x69, 0x3c, 0x66, 0x33, 0x30, 0x65,
+0x66, 0x33, 0x30, 0x65, 0x3f, 0x6a, 0x69, 0x3c,
+0x3c, 0x69, 0x6a, 0x3f, 0x65, 0x30, 0x33, 0x66,
+0x03, 0x56, 0x55, 0x00, 0x5a, 0x0f, 0x0c, 0x59,
+0x59, 0x0c, 0x0f, 0x5a, 0x00, 0x55, 0x56, 0x03,
+0x69, 0x3c, 0x3f, 0x6a, 0x30, 0x65, 0x66, 0x33,
+0x33, 0x66, 0x65, 0x30, 0x6a, 0x3f, 0x3c, 0x69,
+0x0c, 0x59, 0x5a, 0x0f, 0x55, 0x00, 0x03, 0x56,
+0x56, 0x03, 0x00, 0x55, 0x0f, 0x5a, 0x59, 0x0c,
+0x0f, 0x5a, 0x59, 0x0c, 0x56, 0x03, 0x00, 0x55,
+0x55, 0x00, 0x03, 0x56, 0x0c, 0x59, 0x5a, 0x0f,
+0x6a, 0x3f, 0x3c, 0x69, 0x33, 0x66, 0x65, 0x30,
+0x30, 0x65, 0x66, 0x33, 0x69, 0x3c, 0x3f, 0x6a,
+0x6a, 0x3f, 0x3c, 0x69, 0x33, 0x66, 0x65, 0x30,
+0x30, 0x65, 0x66, 0x33, 0x69, 0x3c, 0x3f, 0x6a,
+0x0f, 0x5a, 0x59, 0x0c, 0x56, 0x03, 0x00, 0x55,
+0x55, 0x00, 0x03, 0x56, 0x0c, 0x59, 0x5a, 0x0f,
+0x0c, 0x59, 0x5a, 0x0f, 0x55, 0x00, 0x03, 0x56,
+0x56, 0x03, 0x00, 0x55, 0x0f, 0x5a, 0x59, 0x0c,
+0x69, 0x3c, 0x3f, 0x6a, 0x30, 0x65, 0x66, 0x33,
+0x33, 0x66, 0x65, 0x30, 0x6a, 0x3f, 0x3c, 0x69,
+0x03, 0x56, 0x55, 0x00, 0x5a, 0x0f, 0x0c, 0x59,
+0x59, 0x0c, 0x0f, 0x5a, 0x00, 0x55, 0x56, 0x03,
+0x66, 0x33, 0x30, 0x65, 0x3f, 0x6a, 0x69, 0x3c,
+0x3c, 0x69, 0x6a, 0x3f, 0x65, 0x30, 0x33, 0x66,
+0x65, 0x30, 0x33, 0x66, 0x3c, 0x69, 0x6a, 0x3f,
+0x3f, 0x6a, 0x69, 0x3c, 0x66, 0x33, 0x30, 0x65,
+0x00, 0x55, 0x56, 0x03, 0x59, 0x0c, 0x0f, 0x5a,
+0x5a, 0x0f, 0x0c, 0x59, 0x03, 0x56, 0x55, 0x00,
+};
+
+/* Update ECC parity count.  */
+static inline uint8_t ecc_digest(struct ecc_state_s *s, uint8_t sample)
+{
+uint8_t idx = nand_ecc_precalc_table[sample];
+
+s-cp ^= idx  0x3f;
+if (idx  0x40) {
+s-lp[0] ^= ~s-count;
+s-lp[1] ^= s-count;
+}
+s-count ++;
+
+return sample;
+}
+
+/* Reinitialise the counters.  */
+static inline void ecc_reset(struct ecc_state_s *s)
+{
+s-lp[0] = 0x;
+s-lp[1] = 0x;
+s-cp = 0x00;
+s-count = 0;
+}
diff --git a/hw/nand.c b/hw/nand.c
new file mode 100644
index 000..029a29f
--- /dev/null
+++ b/hw/nand.c
@@ -0,0 +1,613 @@
+/*
+ * Flash NAND memory emulation.  Based on 16M x 8 Bit NAND Flash
+ * Memory datasheet for the KM29U128AT / K9F2808U0A chips from
+ * Samsung Electronic.
+ *
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#ifndef NAND_IO
+
+# include vl.h
+
+# define NAND_CMD_READ00x00
+# define NAND_CMD_READ10x01
+# define NAND_CMD_READ20x50
+# define NAND_CMD_LPREAD2  0x30
+# define NAND_CMD_NOSERIALREAD20x35
+# define NAND_CMD_RANDOMREAD1  0x05
+# define NAND_CMD_RANDOMREAD2  0xe0
+# define NAND_CMD_READID   0x90
+# define NAND_CMD_RESET0xff
+# define NAND_CMD_PAGEPROGRAM1 0x80
+# define NAND_CMD_PAGEPROGRAM2 0x10
+# define NAND_CMD_CACHEPROGRAM20x15
+# define NAND_CMD_BLOCKERASE1  0x60
+# define NAND_CMD_BLOCKERASE2  0xd0
+# define NAND_CMD_READSTATUS   0x70
+# define NAND_CMD_COPYBACKPRG1 0x85
+
+# define 

[Qemu-devel] [PATCH] Wolfson Microsystems WM8750 audio CODEC (i2c chip).

2007-03-16 Thread andrzej zaborowski

An audio codec used in various embedded devices, has both inputs and
outputs. Mainline linux contains the driver for it in the recently
added ASOC framework. It connects to a processor through I2C (control)
and I2S (audio data).

Cheers,
Andrew
From 18bd82a9a6929fa2de39e78f4792879afb8ae087 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 16:47:16 +0100
Subject: [PATCH] Wolfson Microsystems WM8750 audio CODEC (i2c chip).

---
 hw/i2c.h|8 +
 hw/wm8750.c |  524 +++
 2 files changed, 532 insertions(+), 0 deletions(-)

diff --git a/hw/i2c.h b/hw/i2c.h
index d866f28..73e00ed 100644
--- a/hw/i2c.h
+++ b/hw/i2c.h
@@ -158,3 +158,11 @@ void max7310_reset(struct i2c_slave_s *i2c);
 void max7310_gpio_set(struct i2c_slave_s *i2c, int line, int level);
 void max7310_gpio_handler_set(struct i2c_slave_s *i2c, int line,
 gpio_handler_t handler, void *opaque);
+
+/* wm8750.c */
+struct i2c_slave_s *wm8750_init(AudioState *audio);
+void wm8750_reset(struct i2c_slave_s *i2c);
+void wm8750_data_req_set(struct i2c_slave_s *i2c,
+void (*data_req)(void *, int, int), void *opaque);
+void wm8750_dac_dat(void *opaque, uint32_t sample);
+uint32_t wm8750_adc_dat(void *opaque);
diff --git a/hw/wm8750.c b/hw/wm8750.c
new file mode 100644
index 000..baff1de
--- /dev/null
+++ b/hw/wm8750.c
@@ -0,0 +1,524 @@
+/*
+ * WM8750 audio CODEC.
+ *
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This file is licensed under GNU GPL.
+ */
+
+#include vl.h
+
+#define IN_PORT_N  3
+#define OUT_PORT_N 3
+
+#define CODEC  wm8750
+
+struct wm_rate_s;
+struct wm8750_s {
+int i2c_dir;
+struct i2c_slave_s i2c;
+QEMUSoundCard card;
+SWVoiceIn *adc_voice[IN_PORT_N];
+SWVoiceOut *dac_voice[OUT_PORT_N];
+int enable;
+void (*data_req)(void *, int, int);
+void *opaque;
+uint8_t data_in[4096];
+uint8_t data_out[4096];
+int idx_in, req_in;
+int idx_out, req_out;
+
+SWVoiceOut **out[2];
+uint8_t outvol[7], outmute[2];
+SWVoiceIn **in[2];
+uint8_t invol[4], inmute[2];
+
+uint8_t diff[2], pol, ds, monomix[2], alc, mute;
+uint8_t path[4], mpath[2], power, format;
+uint32_t inmask, outmask;
+const struct wm_rate_s *rate;
+};
+
+static inline void wm8750_in_load(struct wm8750_s *s)
+{
+int acquired;
+if (s-idx_in + s-req_in = sizeof(s-data_in))
+return;
+s-idx_in = audio_MAX(0, (int) sizeof(s-data_in) - s-req_in);
+acquired = AUD_read(*s-in[0], s-data_in + s-idx_in,
+sizeof(s-data_in) - s-idx_in);
+}
+
+static inline void wm8750_out_flush(struct wm8750_s *s)
+{
+int sent;
+if (!s-idx_out)
+return;
+sent = AUD_write(*s-out[0], s-data_out, s-idx_out);
+s-idx_out = 0;
+}
+
+static void wm8750_audio_in_cb(void *opaque, int avail_b)
+{
+struct wm8750_s *s = (struct wm8750_s *) opaque;
+s-req_in = avail_b;
+s-data_req(s-opaque, s-req_out  2, avail_b  2);
+
+#if 0
+wm8750_in_load(s);
+#endif
+}
+
+static void wm8750_audio_out_cb(void *opaque, int free_b)
+{
+struct wm8750_s *s = (struct wm8750_s *) opaque;
+wm8750_out_flush(s);
+
+s-req_out = free_b;
+s-data_req(s-opaque, free_b  2, s-req_in  2);
+}
+
+struct wm_rate_s {
+int adc;
+int adc_hz;
+int dac;
+int dac_hz;
+};
+
+static const struct wm_rate_s wm_rate_table[] = {
+{  256, 48000,  256, 48000 },  /* SR: 0 */
+{  384, 48000,  384, 48000 },  /* SR: 1 */
+{  256, 48000, 1536,  8000 },  /* SR: 00010 */
+{  384, 48000, 2304,  8000 },  /* SR: 00011 */
+{ 1536,  8000,  256, 48000 },  /* SR: 00100 */
+{ 2304,  8000,  384, 48000 },  /* SR: 00101 */
+{ 1536,  8000, 1536,  8000 },  /* SR: 00110 */
+{ 2304,  8000, 2304,  8000 },  /* SR: 00111 */
+{ 1024, 12000, 1024, 12000 },  /* SR: 01000 */
+{ 1526, 12000, 1536, 12000 },  /* SR: 01001 */
+{  768, 16000,  768, 16000 },  /* SR: 01010 */
+{ 1152, 16000, 1152, 16000 },  /* SR: 01011 */
+{  384, 32000,  384, 32000 },  /* SR: 01100 */
+{  576, 32000,  576, 32000 },  /* SR: 01101 */
+{  128, 96000,  128, 96000 },  /* SR: 01110 */
+{  192, 96000,  192, 96000 },  /* SR: 0 */
+{  256, 44100,  256, 44100 },  /* SR: 1 */
+{  384, 44100,  384, 44100 },  /* SR: 10001 */
+{  256, 44100, 1408,  8018 },  /* SR: 10010 */
+{  384, 44100, 2112,  8018 },  /* SR: 10011 */
+{ 1408,  8018,  256, 44100 },  /* SR: 10100 */
+{ 2112,  8018,  384, 44100 },  /* SR: 10101 */
+{ 1408,  8018, 1408,  8018 },  /* SR: 10110 */
+{ 2112,  8018, 2112,  8018 },  /* SR: 10111 */
+{ 1024, 11025, 1024, 11025 },  /* SR: 11000 */
+{ 1536, 11025, 1536, 11025 },  /* SR: 11001 */
+{  512, 22050,  512, 

[Qemu-devel] [PATCH] Texas Instruments ADS7846 ADC chip.

2007-03-16 Thread andrzej zaborowski

This is an ADC chip with eight inputs usually used for power
management (battery current measurements) on small systems and a
touchscreen controller. This chip or similar ones (7845 etc) are seen
a lot in all kinds of PDAs.

Cheers,
Andrew
From f6be7abd757e49e67b81847634c1075e222be0bc Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 16:53:08 +0100
Subject: [PATCH] Texas Instruments ADS7846 ADC chip.

---
 hw/ads7846.c |  134 ++
 vl.h |8 
 2 files changed, 142 insertions(+), 0 deletions(-)

diff --git a/hw/ads7846.c b/hw/ads7846.c
new file mode 100644
index 000..3297b7b
--- /dev/null
+++ b/hw/ads7846.c
@@ -0,0 +1,134 @@
+/*
+ * TI ADS7846 chip emulation.
+ *
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include vl.h
+
+struct ads7846_state_s {
+void (*interrupt)(void *opaque, int level);
+void *opaque;
+
+int input[8];
+int pressure;
+int noise;
+
+int cycle;
+int output;
+};
+
+/* Control-byte bitfields */
+#define CB_PD0 (1  0)
+#define CB_PD1 (1  1)
+#define CB_SER (1  2)
+#define CB_MODE(1  3)
+#define CB_A0  (1  4)
+#define CB_A1  (1  5)
+#define CB_A2  (1  6)
+#define CB_START   (1  7)
+
+#define X_AXIS_DMAX3680
+#define X_AXIS_MIN 150
+#define Y_AXIS_DMAX3640
+#define Y_AXIS_MIN 190
+
+#define ADS_VBAT   2000
+#define ADS_VAUX   2000
+#define ADS_TEMP0  2000
+#define ADS_TEMP1  3000
+#define ADS_XPOS(x, y) (X_AXIS_MIN + ((X_AXIS_DMAX * (x))  15))
+#define ADS_YPOS(x, y) (Y_AXIS_MIN + ((Y_AXIS_DMAX * (y))  15))
+#define ADS_Z1POS(x, y)600
+#define ADS_Z2POS(x, y)(600 + 6000 / ADS_XPOS(x, y))
+
+static void ads7846_int_update(struct ads7846_state_s *s)
+{
+if (s-interrupt)
+s-interrupt(s-opaque, s-pressure == 0);
+}
+
+uint32_t ads7846_read(void *opaque)
+{
+struct ads7846_state_s *s = (struct ads7846_state_s *) opaque;
+
+return s-output;
+}
+
+void ads7846_write(void *opaque, uint32_t value)
+{
+struct ads7846_state_s *s = (struct ads7846_state_s *) opaque;
+
+switch (s-cycle ++) {
+case 0:
+if (!(value  CB_START)) {
+s-cycle = 0;
+break;
+}
+
+s-output = s-input[(value  4)  7];
+
+/* Imitate the ADC noise, some drivers expect this.  */
+s-noise = (s-noise + 3)  7;
+switch ((value  4)  7) {
+case 1: s-output += s-noise ^ 2; break;
+case 3: s-output += s-noise ^ 0; break;
+case 4: s-output += s-noise ^ 7; break;
+case 5: s-output += s-noise ^ 5; break;
+}
+
+if (value  CB_MODE)
+s-output = 4;   /* 8 bits instead of 12 */
+
+break;
+case 1:
+s-cycle = 0;
+break;
+}
+}
+
+static void ads7846_ts_event(void *opaque,
+int x, int y, int z, int buttons_state)
+{
+struct ads7846_state_s *s = opaque;
+
+if (buttons_state) {
+s-input[1] = ADS_YPOS(x, y);
+s-input[3] = ADS_Z1POS(x, y);
+s-input[4] = ADS_Z2POS(x, y);
+s-input[5] = ADS_XPOS(x, y);
+}
+
+if (s-pressure == !buttons_state) {
+s-pressure = !!buttons_state;
+
+ ads7846_int_update(s);
+}
+}
+
+struct ads7846_state_s *ads7846_init(
+void (*penirq)(void *opaque, int level), void *opaque)
+{
+struct ads7846_state_s *s;
+s = (struct ads7846_state_s *)
+qemu_mallocz(sizeof(struct ads7846_state_s));
+memset(s, 0, sizeof(struct ads7846_state_s));
+
+s-interrupt = penirq;
+s-opaque = opaque;
+
+s-input[0] = ADS_TEMP0;   /* TEMP0 */
+s-input[2] = ADS_VBAT;/* VBAT */
+s-input[6] = ADS_VAUX;/* VAUX */
+s-input[7] = ADS_TEMP1;   /* TEMP1 */
+
+/* We want absolute coordinates */
+qemu_add_mouse_event_handler(ads7846_ts_event, s, 1,
+QEMU ADS7846-driven Touchscreen);
+
+ads7846_int_update(s);
+return s;
+}
diff --git a/vl.h b/vl.h
index 7c88c72..2f2e340 100644
--- a/vl.h
+++ b/vl.h
@@ -1414,6 +1414,14 @@ uint8_t nand_getio(struct nand_flash_s *s);
 
 #include ecc.h
 
+
+/* ads7846.c */
+struct ads7846_state_s;
+uint32_t ads7846_read(void *opaque);
+void ads7846_write(void *opaque, uint32_t value);
+struct ads7846_state_s *ads7846_init(
+void (*penirq)(void *opaque, int level), void *opaque);
+
 /* PCMCIA/Cardbus */
 
 struct pcmcia_socket_s {
-- 
1.4.4.3

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

2007-03-16 Thread Paul Brook
  Will this work also for the CL542x adaptor?  (Does that fall in the
  category of vga?)  My current hack works for with/without -std-vga and I
  think that's because it lives underneath both, in the connection to
  SDL.

 Each adapter will have to do it's own minimization but that's sort of
 the write thing anyway IMHO.  How granular each update is really only
 depends on the adapter.  For instance, the VMware adapter really
 shouldn't need to do any minimization at all.

It would be nice if we could share the framebuffer blitting routines. We've 
currently got 3 different implementations (vga/cirrus, tcx and pl110) of 
basically the same framebuffer rendering routines.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] PATCH] Maxim MAX1110/1111 ADC chip

2007-03-16 Thread andrzej zaborowski

Another ADC chip, also with 8 inputs. Also has drivers in mainline Linux.

Cheers,
Andrew
From 9209db09c9b8e04becf100bd242cb38ca7ad3ca6 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 16:54:17 +0100
Subject: [PATCH] Maxim MAX1110/ ADC chip.

---
 hw/max111x.c |  138 ++
 vl.h |7 +++
 2 files changed, 145 insertions(+), 0 deletions(-)

diff --git a/hw/max111x.c b/hw/max111x.c
new file mode 100644
index 000..685b80a
--- /dev/null
+++ b/hw/max111x.c
@@ -0,0 +1,138 @@
+/*
+ * MAX1110/ ADC chip emulation.
+ *
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This code is licensed under the GPLv2.
+ */
+
+#include vl.h
+
+struct max111x_s {
+void (*interrupt)(void *opaque);
+void *opaque;
+uint8_t tb1, rb2, rb3;
+int cycle;
+
+int input[8];
+int inputs, com;
+};
+
+/* Control-byte bitfields */
+#define CB_PD0 (1  0)
+#define CB_PD1 (1  1)
+#define CB_SGL (1  2)
+#define CB_UNI (1  3)
+#define CB_SEL0(1  4)
+#define CB_SEL1(1  5)
+#define CB_SEL2(1  6)
+#define CB_START   (1  7)
+
+#define CHANNEL_NUM(v, b0, b1, b2) \
+   v)  (2 + (b0)))  4) |\
+(((v)  (3 + (b1)))  2) |\
+(((v)  (4 + (b2)))  1))
+
+uint32_t max111x_read(void *opaque)
+{
+struct max111x_s *s = (struct max111x_s *) opaque;
+
+if (!s-tb1)
+return 0;
+
+switch (s-cycle ++) {
+case 1:
+return s-rb2;
+case 2:
+return s-rb3;
+}
+
+return 0;
+}
+
+/* Interpret a control-byte */
+void max111x_write(void *opaque, uint32_t value)
+{
+struct max111x_s *s = (struct max111x_s *) opaque;
+int measure, chan;
+
+/* Ignore the value if START bit is zero */
+if (!(value  CB_START))
+return;
+
+s-cycle = 0;
+
+if (!(value  CB_PD1)) {
+s-tb1 = 0;
+return;
+}
+
+s-tb1 = value;
+
+if (s-inputs == 8)
+chan = CHANNEL_NUM(value, 1, 0, 2);
+else
+chan = CHANNEL_NUM(value  ~CB_SEL0, 0, 1, 2);
+
+if (value  CB_SGL)
+measure = s-input[chan] - s-com;
+else
+measure = s-input[chan] - s-input[chan ^ 1];
+
+if (!(value  CB_UNI))
+measure ^= 0x80;
+
+s-rb2 = (measure  2)  0x3f;
+s-rb3 = (measure  6)  0xc0;
+
+if (s-interrupt)
+s-interrupt(s-opaque);
+}
+
+struct max111x_s *max111x_init(void (*cb)(void *opaque), void *opaque)
+{
+struct max111x_s *s;
+s = (struct max111x_s *)
+qemu_mallocz(sizeof(struct max111x_s));
+memset(s, 0, sizeof(struct max111x_s));
+
+s-interrupt = cb;
+s-opaque = opaque;
+
+/* TODO: add a user interface for setting these */
+s-input[0] = 0xf0;
+s-input[1] = 0xe0;
+s-input[2] = 0xd0;
+s-input[3] = 0xc0;
+s-input[4] = 0xb0;
+s-input[5] = 0xa0;
+s-input[6] = 0x90;
+s-input[7] = 0x80;
+s-com = 0;
+return s;
+}
+
+struct max111x_s *max1110_init(void (*cb)(void *opaque), void *opaque)
+{
+struct max111x_s *s = max111x_init(cb, opaque);
+s-inputs = 8;
+return s;
+}
+
+struct max111x_s *max_init(void (*cb)(void *opaque), void *opaque)
+{
+struct max111x_s *s = max111x_init(cb, opaque);
+s-inputs = 4;
+return s;
+}
+
+void max111x_set_input(struct max111x_s *s, int line, uint8_t value)
+{
+if (line = s-inputs) {
+printf(%s: There's no input %i\n, __FUNCTION__, line);
+return;
+}
+
+s-input[line] = value;
+}
diff --git a/vl.h b/vl.h
index 2f2e340..a619ee6 100644
--- a/vl.h
+++ b/vl.h
@@ -1414,6 +1414,13 @@ uint8_t nand_getio(struct nand_flash_s *s);
 
 #include ecc.h
 
+/* max111x.c */
+struct max111x_s;
+uint32_t max111x_read(void *opaque);
+void max111x_write(void *opaque, uint32_t value);
+struct max111x_s *max1110_init(void (*cb)(void *opaque), void *opaque);
+struct max111x_s *max_init(void (*cb)(void *opaque), void *opaque);
+void max111x_set_input(struct max111x_s *s, int line, uint8_t value);
 
 /* ads7846.c */
 struct ads7846_state_s;
-- 
1.4.4.3

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [PATCH] iwMMXt instruction set for the PXA270.

2007-03-16 Thread Paul Brook
 The iwMMXt has 16+ of its own registers, Does someone know if there's
 any standard way for gdb to read their values so they can be printed
 when you do info registers? It may be worth adding proper piece in
 gdbstub.c then.

Yes, recent gdb has remote protocol bits for this. The same mechanisms can be 
used to expose system registers.

http://sourceware.org/gdb/current/onlinedocs/gdb_35.html

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [PATCH] iwMMXt instruction set for the PXA270.

2007-03-16 Thread Lennert Buytenhek
On Fri, Mar 16, 2007 at 10:24:28PM +0100, andrzej zaborowski wrote:

 The iwMMXt has 16+ of its own registers, Does someone know if there's
 any standard way for gdb to read their values so they can be printed
 when you do info registers?

You mean something like PTRACE_GETWMMXREGS ?


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [PATCH] Spitz PDA, example PXA board.

2007-03-16 Thread andrzej zaborowski

This patch adds a full PXA270-based machine. In fact four different,
but similar models of the same series. Use -M spitz, -M akita, -M
borzoi or -M terrier with qemu-system-arm to select them. The board
contains a PXA processor with all its on-chip peripherals plus several
other chips including the ADS7846, MAX, MAX7310, WM8750, the
microdrive, NAND flash, SD slot, one usable PCMCIA socket,
touchscreen, a keypad.

There is no way to pass a kernel command line to a Linux kernel
running on this device because its stock bootloader is quite dumb. So
-append doesn't work. The machine is also supported by OpenBSD and
NetBSD but only Linux has been tested.

Cheers,
Andrew
From c0ef3c129e69d3fde7632a2e7ac1c679eb4401ee Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 17:17:27 +0100
Subject: [PATCH] Spitz PDA, example PXA board

---
 Makefile.target |   14 +-
 hw/spitz.c  | 1157 +++
 keymaps/spitz   |   26 ++
 qemu-doc.texi   |   31 ++
 vl.c|6 +
 vl.h|6 +
 6 files changed, 1235 insertions(+), 5 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 8eaa8dd..9b08ef3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -329,7 +329,7 @@ VL_OBJS+=tap-win32.o
 endif
 
 SOUND_HW = sb16.o es1370.o
-AUDIODRV = audio.o noaudio.o wavaudio.o
+AUDIODRV = audio.o noaudio.o wavaudio.o mixeng.o
 ifdef CONFIG_SDL
 AUDIODRV += sdlaudio.o
 endif
@@ -370,16 +370,16 @@ ifeq ($(TARGET_BASE_ARCH), i386)
 # Hardware support
 VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o $(AUDIODRV)
 VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
-VL_OBJS+= cirrus_vga.o mixeng.o apic.o parallel.o acpi.o piix_pci.o
+VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
 VL_OBJS+= usb-uhci.o smbus_eeprom.o
-CPPFLAGS += -DHAS_AUDIO
+CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
 endif
 ifeq ($(TARGET_BASE_ARCH), ppc)
 VL_OBJS+= ppc.o ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o $(AUDIODRV)
 VL_OBJS+= mc146818rtc.o serial.o i8259.o i8254.o fdc.o m48t59.o
-VL_OBJS+= ppc_prep.o ppc_chrp.o cuda.o adb.o openpic.o heathrow_pic.o mixeng.o
+VL_OBJS+= ppc_prep.o ppc_chrp.o cuda.o adb.o openpic.o heathrow_pic.o
 VL_OBJS+= grackle_pci.o prep_pci.o unin_pci.o
-CPPFLAGS += -DHAS_AUDIO
+CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
 endif
 ifeq ($(TARGET_ARCH), mips)
 VL_OBJS+= mips_r4k.o mips_malta.o mips_timer.o mips_int.o dma.o vga.o serial.o 
i8254.o i8259.o
@@ -404,6 +404,10 @@ VL_OBJS+= arm_boot.o pl011.o pl050.o pl080.o pl110.o 
pl190.o
 VL_OBJS+= versatile_pci.o
 VL_OBJS+= arm_gic.o realview.o arm_sysctl.o
 VL_OBJS+= arm-semi.o
+VL_OBJS+= pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o
+VL_OBJS+= pxa2xx_lcd.o pxa2xx_mmci.o pxa2xx_pcmcia.o max111x.o max7310.o
+VL_OBJS+= spitz.o ads7846.o sd.o ide.o serial.o nand.o $(AUDIODRV) wm8750.o 
+CPPFLAGS += -DHAS_AUDIO -DHIGH_LATENCY
 endif
 ifeq ($(TARGET_BASE_ARCH), sh4)
 VL_OBJS+= shix.o sh7750.o sh7750_regnames.o tc58128.o
diff --git a/hw/spitz.c b/hw/spitz.c
new file mode 100644
index 000..7ce6497
--- /dev/null
+++ b/hw/spitz.c
@@ -0,0 +1,1157 @@
+/*
+ * PXA270-based Clamshell PDA platforms.
+ *
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Written by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include vl.h
+
+#define spitz_printf(format, ...)  \
+fprintf(stderr, %s:  format, __FUNCTION__, ##__VA_ARGS__)
+#undef REG_FMT
+#define REG_FMT0x%02lx
+
+/* Spitz Flash */
+#define FLASH_BASE 0x0c00
+#define FLASH_ECCLPLB  0x00/* Line parity 7 - 0 bit */
+#define FLASH_ECCLPUB  0x04/* Line parity 15 - 8 bit */
+#define FLASH_ECCCP0x08/* Column parity 5 - 0 bit */
+#define FLASH_ECCCNTR  0x0c/* ECC byte counter */
+#define FLASH_ECCCLRR  0x10/* Clear ECC */
+#define FLASH_FLASHIO  0x14/* Flash I/O */
+#define FLASH_FLASHCTL 0x18/* Flash Control */
+
+#define FLASHCTL_CE0   (1  0)
+#define FLASHCTL_CLE   (1  1)
+#define FLASHCTL_ALE   (1  2)
+#define FLASHCTL_WP(1  3)
+#define FLASHCTL_CE1   (1  4)
+#define FLASHCTL_RYBY  (1  5)
+#define FLASHCTL_NCE   (FLASHCTL_CE0 | FLASHCTL_CE1)
+
+struct sl_nand_s {
+target_phys_addr_t target_base;
+struct nand_flash_s *nand;
+uint8_t ctl;
+struct ecc_state_s ecc;
+};
+
+static uint32_t sl_readb(void *opaque, target_phys_addr_t addr)
+{
+struct sl_nand_s *s = (struct sl_nand_s *) opaque;
+int ryby;
+addr -= s-target_base;
+
+switch (addr) {
+#define BSHR(byte, from, to)   ((s-ecc.lp[byte]  (from - to))  (1  to))
+case FLASH_ECCLPLB:
+return BSHR(0, 4, 0) | BSHR(0, 5, 2) | BSHR(0, 6, 4) | BSHR(0, 7, 6) |
+BSHR(1, 4, 1) | BSHR(1, 5, 3) | BSHR(1, 6, 5) | BSHR(1, 7, 7);
+
+#define BSHL(byte, from, to)   

[Qemu-devel] [PATCH] Account for RAM not mapped at 0x0 in arm_boot.c.

2007-03-16 Thread andrzej zaborowski

The second shortest bootloader (hw/arm_boot.c) assumes that the RAM is
mapped at address 0 in the machine (which is false for probably more
than half of the registered ARM machines), so this adds an additional
argument to arm_load_kernel() that should receive the RAM start
address. It will offset the addresses passed in r1 and r2 and in ATAGS
by this value.

Cheers,
Andrew
From 18cc65714e1de31a0060ee81292d75cd0874a849 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 17:23:12 +0100
Subject: [PATCH] Account for RAM not mapped at 0x0 in arm_boot.c.

---
 hw/arm_boot.c |   19 ++-
 hw/integratorcp.c |2 +-
 hw/realview.c |2 +-
 hw/spitz.c|2 +-
 hw/versatilepb.c  |2 +-
 target-arm/cpu.h  |3 ++-
 vl.h  |2 +-
 7 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index dfc00db..91bd783 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -32,11 +32,12 @@ static void main_cpu_reset(void *opaque)
 if (env-kernel_filename)
 arm_load_kernel(env, env-ram_size, env-kernel_filename, 
 env-kernel_cmdline, env-initrd_filename, 
-env-board_id);
+env-board_id, env-loader_start);
 }
 
 static void set_kernel_args(uint32_t ram_size, int initrd_size,
-const char *kernel_cmdline)
+const char *kernel_cmdline,
+target_phys_addr_t loader_start)
 {
 uint32_t *p;
 
@@ -51,12 +52,12 @@ static void set_kernel_args(uint32_t ram_size, int 
initrd_size,
 stl_raw(p++, 4);
 stl_raw(p++, 0x54410002);
 stl_raw(p++, ram_size);
-stl_raw(p++, 0);
+stl_raw(p++, loader_start);
 if (initrd_size) {
 /* ATAG_INITRD2 */
 stl_raw(p++, 4);
 stl_raw(p++, 0x54420005);
-stl_raw(p++, INITRD_LOAD_ADDR);
+stl_raw(p++, loader_start + INITRD_LOAD_ADDR);
 stl_raw(p++, initrd_size);
 }
 if (kernel_cmdline  *kernel_cmdline) {
@@ -77,7 +78,7 @@ static void set_kernel_args(uint32_t ram_size, int 
initrd_size,
 
 void arm_load_kernel(CPUState *env, int ram_size, const char *kernel_filename,
  const char *kernel_cmdline, const char *initrd_filename,
- int board_id)
+ int board_id, target_phys_addr_t loader_start)
 {
 int kernel_size;
 int initrd_size;
@@ -98,6 +99,7 @@ void arm_load_kernel(CPUState *env, int ram_size, const char 
*kernel_filename,
 env-kernel_cmdline = kernel_cmdline;
 env-initrd_filename = initrd_filename;
 env-board_id = board_id;
+env-loader_start = loader_start;
 qemu_register_reset(main_cpu_reset, env);
 }
 /* Assume that raw images are linux kernels, and ELF images are not.  */
@@ -109,7 +111,7 @@ void arm_load_kernel(CPUState *env, int ram_size, const 
char *kernel_filename,
 if (kernel_size  0) {
 kernel_size = load_image(kernel_filename,
  phys_ram_base + KERNEL_LOAD_ADDR);
-entry = KERNEL_LOAD_ADDR;
+entry = loader_start + KERNEL_LOAD_ADDR;
 is_linux = 1;
 }
 if (kernel_size  0) {
@@ -134,11 +136,10 @@ void arm_load_kernel(CPUState *env, int ram_size, const 
char *kernel_filename,
 }
 bootloader[1] |= board_id  0xff;
 bootloader[2] |= (board_id  8)  0xff;
-bootloader[5] = KERNEL_ARGS_ADDR;
+bootloader[5] = loader_start + KERNEL_ARGS_ADDR;
 bootloader[6] = entry;
 for (n = 0; n  sizeof(bootloader) / 4; n++)
 stl_raw(phys_ram_base + (n * 4), bootloader[n]);
-set_kernel_args(ram_size, initrd_size, kernel_cmdline);
+set_kernel_args(ram_size, initrd_size, kernel_cmdline, loader_start);
 }
 }
-
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index 5e4c636..cb9469c 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -512,7 +512,7 @@ static void integratorcp_init(int ram_size, int 
vga_ram_size, int boot_device,
 pl110_init(ds, 0xc000, pic, 22, 0);
 
 arm_load_kernel(env, ram_size, kernel_filename, kernel_cmdline,
-initrd_filename, 0x113);
+initrd_filename, 0x113, 0x0);
 }
 
 QEMUMachine integratorcp_machine = {
diff --git a/hw/realview.c b/hw/realview.c
index a5607e7..ca3c0f0 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -129,7 +129,7 @@ static void realview_init(int ram_size, int vga_ram_size, 
int boot_device,
 /* 0x6c00 PCI mem 2.  */
 
 arm_load_kernel(env, ram_size, kernel_filename, kernel_cmdline,
-initrd_filename, 0x33b);
+initrd_filename, 0x33b, 0x0);
 }
 
 QEMUMachine realview_machine = {
diff --git a/hw/spitz.c b/hw/spitz.c
index 7ce6497..a434721 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -1092,7 +1092,7 @@ static void spitz_common_init(int ram_size, int 

Re: [Qemu-devel] [PATCH] Spitz PDA, example PXA board.

2007-03-16 Thread Hetz Ben Hamo

Just a tiny question:

With all those patches and devices that you added, is it possible to
boot/use any Windows CE variant?

Thanks,
Hetz

On 3/16/07, andrzej zaborowski [EMAIL PROTECTED] wrote:

This patch adds a full PXA270-based machine. In fact four different,
but similar models of the same series. Use -M spitz, -M akita, -M
borzoi or -M terrier with qemu-system-arm to select them. The board
contains a PXA processor with all its on-chip peripherals plus several
other chips including the ADS7846, MAX, MAX7310, WM8750, the
microdrive, NAND flash, SD slot, one usable PCMCIA socket,
touchscreen, a keypad.

There is no way to pass a kernel command line to a Linux kernel
running on this device because its stock bootloader is quite dumb. So
-append doesn't work. The machine is also supported by OpenBSD and
NetBSD but only Linux has been tested.

Cheers,
Andrew

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel






--
Skepticism is the lazy person's default position.
Visit my blog (hebrew) for things that (sometimes) matter:
http://wp.dad-answers.com


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [PATCH] PXA-specific ARM hacks.

2007-03-16 Thread andrzej zaborowski

This patch contains some ugly but very useful chnages:
- in cpu-exec.c, halt the arm CPU on CPU_INTERRUPT_HALT like in other
architectures.
- wake the cpu up on CPU_INTERRUPT_EXITTB - this serves waking the
CPU up without asserting IRQ or FIQ, which is possible on PXA. Would
it be better to add a separate interrupt type instead?
- in target-arm/translate.c, don't terminate the TB after a CP15
write. The purpose of this is to imitate the real processor's
instruction cache (to some degree). OSes should never need rely on the
cache prefetch but unfortunately Linux for pxa does when it's waking
up from sleep or deep idle, when enabling the MMU (simplifies things a
lot for Linux).

Cheers,
Andrew
From 7ba76bd146394be87dc6480a172386a9e5e73877 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 17:25:41 +0100
Subject: [PATCH] PXA-specific ARM hacks.

---
 cpu-all.h  |3 ++-
 cpu-exec.c |   10 --
 target-arm/translate.c |2 ++
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index 9b617fc..177bcba 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -763,7 +763,8 @@ void cpu_dump_statistics (CPUState *env, FILE *f,
   int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
   int flags);
 
-void cpu_abort(CPUState *env, const char *fmt, ...);
+void cpu_abort(CPUState *env, const char *fmt, ...)
+__attribute__ ((__format__ (__printf__, 2, 3)));
 extern CPUState *first_cpu;
 extern CPUState *cpu_single_env;
 extern int code_copy_enabled;
diff --git a/cpu-exec.c b/cpu-exec.c
index 48c2a93..2e99de2 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -276,8 +276,8 @@ int cpu_exec(CPUState *env1)
 if (env1-halted) {
 /* An interrupt wakes the CPU even if the I and F CPSR bits are
set.  */
-if (env1-interrupt_request
- (CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD)) {
+if (env1-interrupt_request 
+(CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD | CPU_INTERRUPT_EXITTB)) {
 env1-halted = 0;
 } else {
 return EXCP_HALTED;
@@ -528,6 +528,12 @@ int cpu_exec(CPUState *env1)
 env-exception_index = EXCP_IRQ;
 do_interrupt(env);
 }
+if (interrupt_request  CPU_INTERRUPT_HALT) {
+env-interrupt_request = ~CPU_INTERRUPT_HALT;
+env-halted = 1;
+env-exception_index = EXCP_HLT;
+cpu_loop_exit();
+}
 #elif defined(TARGET_SH4)
/* X */
 #endif
diff --git a/target-arm/translate.c b/target-arm/translate.c
index e5032c5..c476e06 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -1536,7 +1536,9 @@ static int disas_cp15_insn(DisasContext *s, uint32_t insn)
 gen_movl_T0_reg(s, rd);
 gen_op_movl_cp15_T0(insn);
 }
+#if 0
 gen_lookup_tb(s);
+#endif
 return 0;
 }
 
-- 
1.4.4.3

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [PATCH] -show-cursor switch to inhibit SDL hiding cursor.

2007-03-16 Thread andrzej zaborowski

Systems with touchscreens usually don't display a cursor (in fact they
can't know where the stylus is if it's not touching the screen in this
moment) so it makes sense to not hide the host's mouse cursor even
when grabbed. Only SDL.

Cheers,
Andrew
From e0111f822059b9905e842bb1d29e7c6fa8c65a8e Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 17:28:44 +0100
Subject: [PATCH] -show-cursor switch to inhibit SDL hiding cursor.

---
 sdl.c |6 ++
 vl.c  |6 ++
 vl.h  |1 +
 3 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/sdl.c b/sdl.c
index 0cb2241..1330df4 100644
--- a/sdl.c
+++ b/sdl.c
@@ -228,6 +228,9 @@ static void sdl_update_caption(void)
 
 static void sdl_hide_cursor(void)
 {
+if (!cursor_hide)
+return;
+
 if (kbd_mouse_is_absolute()) {
 SDL_ShowCursor(1);
 SDL_SetCursor(sdl_cursor_hidden);
@@ -238,6 +241,9 @@ static void sdl_hide_cursor(void)
 
 static void sdl_show_cursor(void)
 {
+if (!cursor_hide)
+return;
+
 if (!kbd_mouse_is_absolute()) {
 SDL_ShowCursor(1);
 SDL_SetCursor(sdl_cursor_normal);
diff --git a/vl.c b/vl.c
index 94260b4..292c677 100644
--- a/vl.c
+++ b/vl.c
@@ -184,6 +184,7 @@ const char *vnc_display;
 int acpi_enabled = 1;
 int fd_bootchk = 1;
 int no_reboot = 0;
+int cursor_hide = 1;
 int snapshot = 0;
 const char *sd_filename = 0;
 const char *mtd_filename = 0;
@@ -6613,6 +6614,7 @@ enum {
 QEMU_OPTION_vnc,
 QEMU_OPTION_no_acpi,
 QEMU_OPTION_no_reboot,
+QEMU_OPTION_show_cursor,
 QEMU_OPTION_daemonize,
 QEMU_OPTION_option_rom,
 QEMU_OPTION_semihosting
@@ -6704,6 +6706,7 @@ const QEMUOption qemu_options[] = {
 { cirrusvga, 0, QEMU_OPTION_cirrusvga },
 { no-acpi, 0, QEMU_OPTION_no_acpi },
 { no-reboot, 0, QEMU_OPTION_no_reboot },
+{ show-cursor, 0, QEMU_OPTION_show_cursor },
 { daemonize, 0, QEMU_OPTION_daemonize },
 { option-rom, HAS_ARG, QEMU_OPTION_option_rom },
 #if defined(TARGET_ARM)
@@ -7413,6 +7416,9 @@ int main(int argc, char **argv)
 case QEMU_OPTION_no_reboot:
 no_reboot = 1;
 break;
+case QEMU_OPTION_show_cursor:
+cursor_hide = 0;
+break;
case QEMU_OPTION_daemonize:
daemonize = 1;
break;
diff --git a/vl.h b/vl.h
index 3eb204a..2211d1d 100644
--- a/vl.h
+++ b/vl.h
@@ -156,6 +156,7 @@ extern int kqemu_allowed;
 extern int win2k_install_hack;
 extern int usb_enabled;
 extern int smp_cpus;
+extern int cursor_hide;
 extern int snapshot;
 extern const char *sd_filename;
 extern const char *mtd_filename;
-- 
1.4.4.3

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [PATCH] NAND image conversion utility for the Spitz machines.

2007-03-16 Thread andrzej zaborowski

This is a small program that converts NAND Flash images from raw to
the format used by hw/nand.c. I don't know if it should be included in
qemu (it's handy for me to have it included). What it does:
- takes on standard input flash rootfs partition images generated
from some OpenEmbedded-based build systems (i.e. Poky or OpenZaurus)
- offsets the image to the rootfs partition's start,
- inserts proper jffs2 markers in the Out-Of-Band areas in the flash
so that Linux doesn't protest. Also inserts empty block jffs2 markers
and ECC where necessary.

Cheers,
Andrew
From a6fb0b70ec61a3d37293a895f8d31262a12cbcb8 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 17:36:30 +0100
Subject: [PATCH] NAND Flash image conversion utility for the Spitz machines.

---
 Makefile|   15 +++-
 raw2flash.c |  370 +++
 2 files changed, 384 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index b6d7b1f..daac31a 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,7 @@ BASE_CFLAGS += -mcpu=ultrasparc
 endif
 CPPFLAGS += -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
 LIBS=
-TOOLS=qemu-img$(EXESUF)
+TOOLS=qemu-img$(EXESUF) raw2flash$(EXESUF) flash2raw$(EXESUF)
 ifdef CONFIG_STATIC
 BASE_LDFLAGS += -static
 endif
@@ -23,6 +23,7 @@ DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1
 else
 DOCS=
 endif
+MODELS=spitz akita borzoi terrier
 
 ifndef CONFIG_DARWIN
 ifndef CONFIG_WIN32
@@ -43,6 +44,13 @@ qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c 
block-cow.c block-qco
 dyngen$(EXESUF): dyngen.c
$(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^
 
+raw2flash$(EXESUF) flash2raw$(EXESUF): raw2flash.c
+   $(CC) -D$@ $(CFLAGS) $(LDFLAGS) $(DEFINES) -o $@ $^
+   for m in $(MODELS); do \
+   [ -e [EMAIL PROTECTED](EXESUF) ] || \
+   ln -s $@ [EMAIL PROTECTED](EXESUF) ; \
+   done
+
 clean:
 # avoid old build problems by removing potentially incorrect old files
rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h 
opc-arm.h gen-op-arm.h 
@@ -89,6 +97,11 @@ endif
for d in $(TARGET_DIRS); do \
$(MAKE) -C $$d $@ || exit 1 ; \
 done
+   for m in $(MODELS); do \
+   for n in *.$$m; do \
+   $(INSTALL) $$n $(DESTDIR)$(bindir); \
+   done; \
+   done
 
 # various test targets
 test speed test2: all
diff --git a/raw2flash.c b/raw2flash.c
new file mode 100644
index 000..19faf62
--- /dev/null
+++ b/raw2flash.c
@@ -0,0 +1,370 @@
+/*
+ * Copyright (c) 2006 OpenedHand Ltd.
+ *
+ * This file is licensed under GNU GPL v2.
+ */
+#include string.h
+#include unistd.h
+#include stdint.h
+#include stdio.h
+#include sys/types.h
+#include stdlib.h
+
+#define TFR(_) _
+#define VERBOSE
+#define PBAR_LEN   40
+
+#define PARTITION_START0x0070
+
+static const int ecc_pos8[] = {
+   0x0, 0x1, 0x2,
+};
+
+static const int ecc_pos16[] = {
+   0x0, 0x1, 0x2, 0x3, 0x6, 0x7,
+};
+
+static const int ecc_pos64[] = {
+   0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
+   0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+   0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
+};
+
+static const int ecc_akita[] = {
+   0x05, 0x01, 0x02, 0x03, 0x06, 0x07, 0x15, 0x11,
+   0x12, 0x13, 0x16, 0x17, 0x25, 0x21, 0x22, 0x23,
+   0x26, 0x27, 0x35, 0x31, 0x32, 0x33, 0x36, 0x37,
+};
+
+struct jffs_marker_s {
+   int pos;
+   uint8_t value;
+};
+
+static const struct jffs_marker_s free_pos8[] = {
+   { 0x03, 0xff }, { 0x04, 0xff }, { 0x06, 0x85 }, { 0x07, 0x19 },
+   { -1 },
+};
+
+static const struct jffs_marker_s free_pos16[] = {
+   { 0x08, 0x85 }, { 0x09, 0x19 }, { 0x0a, 0x03 }, { 0x0b, 0x20 },
+   { 0x0c, 0x08 }, { 0x0d, 0x00 }, { 0x0e, 0x00 }, { 0x0f, 0x00 },
+   { -1 },
+};
+
+static const struct jffs_marker_s free_pos64[] = {
+   { 0x02, 0xff }, { 0x03, 0xff }, { 0x04, 0xff }, { 0x05, 0xff },
+   { 0x06, 0xff }, { 0x07, 0xff }, { 0x08, 0xff }, { 0x09, 0xff },
+   { 0x0a, 0xff }, { 0x0b, 0xff }, { 0x0c, 0xff }, { 0x0d, 0xff },
+   { 0x0e, 0xff }, { 0x0f, 0xff }, { 0x10, 0x85 }, { 0x11, 0x19 },
+   { 0x12, 0x03 }, { 0x13, 0x20 }, { 0x14, 0x08 }, { 0x15, 0x00 },
+   { 0x16, 0x00 }, { 0x17, 0x00 }, { 0x18, 0xff }, { 0x19, 0xff },
+   { 0x1a, 0xff }, { 0x1b, 0xff }, { 0x1c, 0xff }, { 0x1d, 0xff },
+   { 0x1e, 0xff }, { 0x1f, 0xff }, { 0x20, 0xff }, { 0x21, 0xff },
+   { 0x22, 0xff }, { 0x23, 0xff }, { 0x24, 0xff }, { 0x25, 0xff },
+   { 0x26, 0xff }, { 0x27, 0xff },
+   { -1 },
+};
+
+static const struct jffs_marker_s free_akita[] = {
+   { 0x08, 0x85 }, { 0x09, 0x19 }, { 0x0a, 0x03 }, { 0x0b, 0x20 },
+   { 0x0c, 0x08 }, { 0x0d, 0x00 }, { 0x0e, 0x00 }, { 0x0f, 0x00 },
+   { 0x10, 0xff },
+   { -1 },
+};
+
+#define LEN(array) (sizeof(array) / sizeof(*array))

[Qemu-devel] Latest SVN fails to build on Fedora Core 6

2007-03-16 Thread Nigel Horne


gcc34 -O2 -pipe -mtune=pentium4 -march=pentium4 -Wall -O2 -g 
-fno-strict-aliasing -fomit-frame-pointer -I. -I.. 
-I/home/njh/src/qemu/target-i386 -I/home/njh/src/qemu -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/njh/src/qemu/fpu 
-DHAS_AUDIO -I/home/njh/src/qemu/slirp   -c -o helper.o 
/home/njh/src/qemu/target-i386/helper.c

../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 365 349 366 13 ../softmmu_template.h:290 (parallel [
(set (reg:DI 0 ax [216])
(lshiftrt:DI (reg/v:DI 59 [ val ])
(subreg:QI (reg:SI 229) 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[1]: *** [helper.o] Error 1
make[1]: Leaving directory `/home/njh/src/qemu/i386-softmmu'
make: *** [subdir-i386-softmmu] Error 2
[EMAIL PROTECTED] qemu]$

-Nigel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] support for non aio host os's?

2007-03-16 Thread Todd T. Fries
.. so now that aio is in, and whatever existed before is out, has anybody
come up with a way to support host os's that do not have aio?

Thanks,
-- 
Todd Fries .. [EMAIL PROTECTED]

 _
| \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \  1.866.792.3418 (FAX)
| ..in support of free software solutions.  \  250797 (FWD)
| \
 \\
 
  37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [PATCH] Spitz PDA, example PXA board.

2007-03-16 Thread andrzej zaborowski

Hi,

On 16/03/07, Hetz Ben Hamo [EMAIL PROTECTED] wrote:

Just a tiny question:

With all those patches and devices that you added, is it possible to
boot/use any Windows CE variant?


Short answer is with only these patches, no. I believe Windows doesn't
run on the Spitz PDA - it comes with Linux from factory.

I don't know about Windows CE but Windows Mobile runs on a lot of PXA
based PDAs so these PXA patches can certainly be helpful for emulating
one of these PDAs and then you could perhaps run Ms Windows.

Regards,
Andrew


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

2007-03-16 Thread Julian Seward

  ifeq ($(ARCH),x86_64)
 +OP_CFLAGS+= -mtune=nocona -W -Wall -O4
  BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
  endif

That works.  Thanks.

J


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] [Bug] MIPS code fails at branch instruction

2007-03-16 Thread Stefan Weil
Hi,

QEMU MIPS emulation fails with code using illegal commands
in the delay slot of a branch.

I had an endless loop with QEMU running the firmware of a
MIPS based router.

MIPS says: branches, jumps, ... instructions should not be
placed in the delay slot of a branch or jump.

Nevertheless, some routers use this kind of code.

I wrote a test program to examine the difference between emulation
and a real MIPS CPU (see appendices).

Results are given below for real hardware, normal emulation and
emulation using single stepping.

Stefan


Compile branch test like this:
mipsel-linux-gcc -Os -g btest.c btest2.S

AR7 (MIPS 4KEc) router:
# ./a.out
0
1100
1000

qemu-system-mipsel (unmodified):
# ./a.out
0
# (program hangs)

qemu-system-mipsel (single stepping / MIPS_SINGLE_STEP in translate.c):
# ./a.out
0
1221
1221

/*

Compile branch test like this:
mipsel-linux-gcc -Os -g btest.c btest2.S

Original code failing with emulation:
218:   8d09lw  t1,0(t0)
21c:   31290001andit1,t1,0x1
220:   1120fffdbeqzt1,0x218
224:   03e8jr  ra
228:   3c088000lui t0,0x8000
22c:   3c093c1alui t1,0x3c1a

AR7 router:
# ./a.out
0
1100
1000

qemu-system-mipsel (unmodified):
# ./a.out
0
# (program hangs)

qemu-system-mipsel (unmodified):
# ./a.out
0
1221
1221

*/

#include stdio.h

extern int test1(int i);
extern int test2(int i);

int main(void)
{
  int i = 0;
  printf(%d\n, i);
  i = test1(0);
  printf(%d\n, i);
  i = test2(0);
  printf(%d\n, i);
  return 0;
}
#if 0
218:   8d09lw  t1,0(t0)
21c:   31290001andit1,t1,0x1
220:   1120fffdbeqzt1,0x218
224:   03e8jr  ra
228:   3c088000lui t0,0x8000
22c:   3c093c1alui t1,0x3c1a
230:   35299400ori t1,t1,0x9400
234:   ad09sw  t1,0(t0)
238:   3c09275alui t1,0x275a
23c:   ad090004sw  t1,4(t0)
#endif

#include asm/asm.h
#include asm/regdef.h

.text
.set noreorder
.set mips32r2

LEAF(test1)
movev0,a0
addiu   v0,v0,1000
bneza0,$L1
jr  ra
addiu   v0,v0,100
$L1:
beqza0,$L2
jr  ra
addiu   v0,v0,10
$L2:
addiu   v0,v0,1
jr  ra
nop
END(test1)

LEAF(test2)
movev0,a0
addiu   v0,v0,1000
beqza0,$L3
jr  ra
addiu   v0,v0,100
$L3:
bneza0,$L4
jr  ra
addiu   v0,v0,10
$L4:
addiu   v0,v0,1
jr  ra
nop
END(test2)


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] qemu cpu-all.h cpu-defs.h cpu-exec.c exec.c gdb...

2007-03-16 Thread Paul Brook
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/03/16 23:58:11

Modified files:
.  : cpu-all.h cpu-defs.h cpu-exec.c exec.c 
 gdbstub.c 
target-arm : translate.c 

Log message:
Watchpoint support (previous commit got eaten by Savannah server crash).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.63r2=1.64
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemur1=1.17r2=1.18
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.93r2=1.94
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.87r2=1.88
http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemur1=1.50r2=1.51
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemur1=1.45r2=1.46


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction

2007-03-16 Thread Thiemo Seufer
Stefan Weil wrote:
 Hi,
 
 QEMU MIPS emulation fails with code using illegal commands
 in the delay slot of a branch.
 
 I had an endless loop with QEMU running the firmware of a
 MIPS based router.
 
 MIPS says: branches, jumps, ... instructions should not be
 placed in the delay slot of a branch or jump.
 
 Nevertheless, some routers use this kind of code.

The architecture spec defines this as undefined behaviour. Other
implementations of MIPS CPUs show funny effects which are hard
to explain without detailed knowledge of the microarchitecture.

 I wrote a test program to examine the difference between emulation
 and a real MIPS CPU (see appendices).

I wouldn't be surprised if it starts to fail for some other combinations
like a mix of branch and branch likely instructions.

(The semantics of a branch delay slot are: The instruction in the delay
slot is executed, then the branch is executed. Now, when the instruction
in the delay slot is itself a branch, what will happen to its delay slot?)


Thiemo


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] qemu/linux-user syscall.c

2007-03-16 Thread Paul Brook
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/03/17 01:27:24

Modified files:
linux-user : syscall.c 

Log message:
Usermode recv syscall fix.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.89r2=1.90


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] Use TMPDIR environment Variable for Snapshot Mode

2007-03-16 Thread Oliver Adler
Hi Folks,
thank you VERY MUCH for bringing qemu to us.

I would like to see this little modification, honoring the
setting of the TMPDIR environment variable. Then I can use
the snapshot mode even if my /tmp directory is small in
size:

The diff is based on the qemu-0.9.0 release.

--- block.c+Sat Mar 17 02:06:26 2007
+++ block.c Fri Mar 16 23:21:21 2007
@@ -188,8 +188,13 @@
 void get_tmp_filename(char *filename, int size)
 {
 int fd;
+char *tmpdir;
 /* XXX: race condition possible */
-pstrcpy(filename, size, /tmp/vl.XX);
+tmpdir = getenv(TMPDIR);
+if (tmpdir == NULL)
+   tmpdir = /tmp;
+snprintf(filename, size, %s/vl.XX, tmpdir);
+//pstrcpy(filename, size, /tmp/vl.XX);
 fd = mkstemp(filename);
 close(fd);
 }



Thank you 


Oliver


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] qemu/target-arm translate.c

2007-03-16 Thread Paul Brook
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/03/17 01:43:01

Modified files:
target-arm : translate.c 

Log message:
ARM register index+writeback fix (Lauro Ramos Venancio).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemur1=1.46r2=1.47


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel