[Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Various versions of Qemu/Kqemu available and under test: 0.8.2, 0.9.0, and CVS. Kqemu 1.3.0pre9, 1.3.0pre11 When building Qemu I use the following configure setup, using a gcc 3.4: ./configure --prefix=/usr/local/ \ --cc=/opt/gcc34/bin/gcc-3.4 --host-cc=/opt/gcc34/bin/gcc-3.4 \ --enable-alsa --enable-adlib \ --target-list=i386-softmmu x86_64-softmmu Kqemu built with standard (system) gcc. I always use qemu-system-x86_64 to start Qemu. Here the problems: Installing a 32bit Linux system (Debian, Kernel 2.6.18): - works with pure Qemu (-no-kqemu) - fails with Kqemu support enabled. The failure is a loop before or during the kernel hands over control to INIT I used gdb to get some more information about the problems using the following command: gdb qemu-system-x86_64 using a .gdbinit that sets the args, etc. When the kernel goes into the loop I interrupt with ^C several times, most of the time it was in code_gen_buffer, here in the function compute_c_subl. Because I'm _not_ sure this is the correct way to debug Qemu I cannot say if this is normal or not. At least the function always returns 1 (it seems that it is called over and over again with). The last relevant statement in this function is: cmp %eax,0x90(%r14) seta %al where the conetent of %eax is zero, the content of the memory is 0xeb3e. The return says: the memory content is bigger than 0x0 (which is true for 64bit, but also true for 32bit unsigned, compute_c_subl compares two unsigned 32bit integers). As said, take these findings with a grain of salt. My general thought about the problem: running 32bit code on a 64bit host with similar architecture as this is the case of x86 / x86_64 could easily result in problems with signedness, sign bit extension, different pointer/word/interger sizes... BTW: is there a Howto or other information how to debug Qemu when the loaded kernel loops or crashes? That would be great and would make it easier to step in here and provide some help (or is this a somewhat good kept secret :-) ? ). The next problems are fairly old, they are also reported in the Qemu user's wiki - but without an answer o solution. Installing a 64bit Linux system (openSuse 10.1, 10.2): - fails with Qemu (-no-kqemu), loops when Grub shall install the bootloader. - fails with Kqemu enabled, crashes at various addresses and prints register contents. Any hints what this could be? Solutions? Regards, Werner
[Qemu-devel] qemu hw/ppc.c target-ppc/helper.c target-ppc/op...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 07:10:48 Modified files: hw : ppc.c target-ppc : helper.c op.c op_helper.c op_helper.h translate.c translate_init.c Log message: Fix a lot of debug traces for PowerPC emulation: use logfile instead of stdout CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemur1=1.18r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.42r2=1.43 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemur1=1.32r2=1.33 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.26r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.54r2=1.55 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.10r2=1.11
[Qemu-devel] qemu/hw pflash_cfi02.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 07:14:26 Modified files: hw : pflash_cfi02.c Log message: Parallel flash bugfixes: - always need to register flash area back to IO_MEM_ROMD at reset time - disabled buffered write as it's not actually supported - don't check flash time at registration time CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pflash_cfi02.c?cvsroot=qemur1=1.4r2=1.5
[Qemu-devel] qemu/target-ppc translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 07:18:42 Modified files: target-ppc : translate.c Log message: PowerPC emulation bugfixes: - don't generate multiple exit_tb at the end of conditional branches - disable TRACE exception as it is not correct for embedded PowerPC. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.55r2=1.56
RE: [Qemu-devel] question in running linux in qemu-system-arm
or if some body had successfully install linux in qemu-arm, could you tell me your steps ?? so mybe i can find out what is wrong in my kernel image. thank you. From: tang peilei [EMAIL PROTECTED] Reply-To: qemu-devel@nongnu.org To: qemu-devel@nongnu.org Subject: [Qemu-devel] question in running linux in qemu-system-arm Date: Mon, 16 Apr 2007 04:40:47 + i had build a linux(2.6.16) with arm corss-build.The kernel config is the def config(arch/arm/ mach-integrator/Kconfig),but when i use this kernel image to run in pemu,it did not work after the message done, booting the kernel. i found it in function decompress_kernel, and it was called by head.S.and I think there is something wrong when it runs bl cache_clean_flush but i do not know what problem in it and how to deal with it. i tried to use gdb to debug it. but when i use gdb zImage or arm-elf-gdb zImage , it shows me a err message zImage is not a executeable format. who knows what should i do to resolve this problem, thanks very very much. _ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn _ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
[Qemu-devel] qemu hw/ppc.c target-ppc/cpu.h target-ppc/trans...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 07:34:39 Modified files: hw : ppc.c target-ppc : cpu.h translate_init.c helper.c Log message: Add bus model (or input pins) into PowerPC CPU flags. Add PowerPC 970 bus and exceptions model. Add code provision for PowerPC 970 instanciation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemur1=1.19r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.40r2=1.41 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.43r2=1.44
[Qemu-devel] qemu/hw ppc_chrp.c ppc_prep.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 07:41:07 Modified files: hw : ppc_chrp.c ppc_prep.c Log message: PREP and heathrow machines only support PowerPC CPU with a 6xx bus. Mac99 machine may also support PowerPC 970 CPU. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.34r2=1.35 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.35r2=1.36
[Qemu-devel] [RFC] Parallel flash support option
This patch adds a -pflash filename option to the Qemu command line.
This seems needed to instanciate parallel NOR flashes using the
pflash_cfi02 driver for embedded targets.
Please comment.
--
J. Mayer [EMAIL PROTECTED]
Never organized
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.279
diff -u -d -d -p -r1.279 vl.c
--- vl.c 6 Apr 2007 16:49:48 - 1.279
+++ vl.c 16 Apr 2007 07:42:10 -
@@ -138,6 +138,7 @@ IOPortWriteFunc *ioport_write_table[3][M
/* Note: bs_table[MAX_DISKS] is a dummy block driver if none available
to store the VM snapshots */
BlockDriverState *bs_table[MAX_DISKS + 1], *fd_table[MAX_FD];
+BlockDriverState *pflash_table[MAX_PFLASH];
BlockDriverState *sd_bdrv;
/* point to the block driver where the snapshots are managed */
BlockDriverState *bs_snapshots;
@@ -6347,6 +6348,7 @@ void help(void)
-hdc/-hdd file use 'file' as IDE hard disk 2/3 image\n
-cdrom file use 'file' as IDE cdrom image (cdrom is ide1 master)\n
-sd fileuse 'file' as SecureDigital card image\n
+ -pflash fileuse 'file' as a parallel flash image\n
-boot [a|c|d|n] boot on floppy (a), hard disk (c), CD-ROM (d), or network (n)\n
-snapshot write to temporary files instead of disk image files\n
#ifdef CONFIG_SDL
@@ -6485,6 +6487,7 @@ enum {
QEMU_OPTION_hdd,
QEMU_OPTION_cdrom,
QEMU_OPTION_sd,
+QEMU_OPTION_pflash,
QEMU_OPTION_boot,
QEMU_OPTION_snapshot,
#ifdef TARGET_I386
@@ -6564,6 +6567,7 @@ const QEMUOption qemu_options[] = {
{ hdd, HAS_ARG, QEMU_OPTION_hdd },
{ cdrom, HAS_ARG, QEMU_OPTION_cdrom },
{ sd, HAS_ARG, QEMU_OPTION_sd },
+{ pflash, HAS_ARG, QEMU_OPTION_pflash },
{ boot, HAS_ARG, QEMU_OPTION_boot },
{ snapshot, 0, QEMU_OPTION_snapshot },
#ifdef TARGET_I386
@@ -6847,10 +6854,11 @@ int main(int argc, char **argv)
int use_gdbstub;
const char *gdbstub_port;
#endif
-int i, cdrom_index;
+int i, cdrom_index, pflash_index;
int snapshot, linux_boot;
const char *initrd_filename;
const char *hd_filename[MAX_DISKS], *fd_filename[MAX_FD];
+const char *pflash_filename[MAX_PFLASH];
const char *sd_filename;
const char *kernel_filename, *kernel_cmdline;
DisplayState *ds = display_state;
@@ -6912,6 +6920,9 @@ int main(int argc, char **argv)
fd_filename[i] = NULL;
for(i = 0; i MAX_DISKS; i++)
hd_filename[i] = NULL;
+for(i = 0; i MAX_PFLASH; i++)
+pflash_filename[i] = NULL;
+pflash_index = 0;
sd_filename = NULL;
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
vga_ram_size = VGA_RAM_SIZE;
@@ -7034,6 +7045,13 @@ int main(int argc, char **argv)
case QEMU_OPTION_sd:
sd_filename = optarg;
break;
+case QEMU_OPTION_pflash:
+if (pflash_index = MAX_PFLASH) {
+fprintf(stderr, qemu: too many parallel flash images\n);
+exit(1);
+}
+pflash_filename[pflash_index++] = optarg;
+break;
case QEMU_OPTION_snapshot:
snapshot = 1;
break;
@@ -7543,6 +7562,23 @@ int main(int argc, char **argv)
}
}
+/* Open the virtual parallel flash bloc devices */
+for(i = 0; i MAX_PFLASH; i++) {
+if (pflash_filename[i]) {
+if (!pflash_table[i]) {
+char buf[64];
+snprintf(buf, sizeof(buf), fl%c, i + 'a');
+pflash_table[i] = bdrv_new(buf);
+}
+if (bdrv_open(pflash_table[i], pflash_filename[i],
+ snapshot ? BDRV_O_SNAPSHOT : 0) 0) {
+fprintf(stderr, qemu: could not open flash image '%s'\n,
+pflash_filename[i]);
+exit(1);
+}
+}
+}
+
sd_bdrv = bdrv_new (sd);
/* FIXME: This isn't really a floppy, but it's a reasonable
approximation. */
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.210
diff -u -d -d -p -r1.210 vl.h
--- vl.h 12 Apr 2007 21:11:02 - 1.210
+++ vl.h 16 Apr 2007 07:42:10 -
@@ -1432,6 +1508,8 @@ int sh7750_register_io_device(struct SH7
int tc58128_init(struct SH7750State *s, char *zone1, char *zone2);
/* NOR flash devices */
+#define MAX_PFLASH 4
+extern BlockDriverState *pflash_table[MAX_PFLASH];
typedef struct pflash_t pflash_t;
pflash_t *pflash_register (target_ulong base, ram_addr_t off,
[Qemu-devel] qemu hw/ppc_chrp.c hw/ppc_prep.c target-ppc/cpu...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 08:56:52 Modified files: hw : ppc_chrp.c ppc_prep.c target-ppc : cpu.h helper.c op_helper.c translate_init.c Log message: Add reset callbacks for PowerPC CPU. Move cpu_ppc_init, cpu_ppc_close, cpu_ppc_reset and ppc_tlb_invalidate into helper.c as they are to be called from outside of the translated code. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.35r2=1.36 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.36r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.41r2=1.42 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.44r2=1.45 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.27r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.12r2=1.13
Re: [Qemu-devel] question in running linux in qemu-system-arm
tang peilei wrote: or if some body had successfully install linux in qemu-arm, could you tell me your steps ?? so mybe i can find out what is wrong in my kernel image. thank you. I have followed these directions for installing Debian ARM in QEMU: http://www.aurel32.net/info/debian_arm_qemu.php And I have installed Armedslack (http://www.armedslack.org) using these directions as well. Regards, Sunil
[Qemu-devel] qemu/target-ppc cpu.h helper.c op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 09:21:46 Modified files: target-ppc : cpu.h helper.c op_helper.c Log message: PowerPC 4xx software driven TLB fixes + debug traces. Add code provision for more MMU models support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.42r2=1.43 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.45r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.28r2=1.29
[Qemu-devel] [PATCH] Memory-mapped interface for RTC
Hi, This patch adds a memory-mapped interface for the mc146818 (RTC) controller. Hervé mm_rtc.diff Description: Binary data
[Qemu-devel] [PATCH] [MIPS] Choose number of TLBs at runtime
Hi, This patch removes the constant MIPS_TLB_NB, and replaces it by a CPU characteristic. I kept 16 TLBs for most of CPU models, except R4000 which has 48 TLBs. Hervé variable_tlb_size.diff Description: Binary data
[Qemu-devel] [PATCH] [MIPS] Acer Pica 61 machine
Hi, This patch adds a Acer Pica 61 machine emulation to Qemu. I based my work on http://www.sensi.org/~alec/mips/acer_pica.html This machine can be used with the firmwares available at http://hpoussineau.free.fr/qemu/firmware (the PICA 61 versions). I've tested NetBSD 1.5.1, NetBSD 1.6.2, OpenBSD 2.3 and MS Windows NT 3.51, which start to boot, but all show different problems. The *BSD images are available at http://hpoussineau.free.fr/qemu Hervé pica61.diff Description: Binary data
Re: [Qemu-devel] question in running linux in qemu-system-arm
thank you very much. but i want to make the image file by myself, not using other's image file. From: Sunil Amitkumar Janki [EMAIL PROTECTED] Reply-To: qemu-devel@nongnu.org To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] question in running linux in qemu-system-arm Date: Mon, 16 Apr 2007 11:14:58 +0200 tang peilei wrote: or if some body had successfully install linux in qemu-arm, could you tell me your steps ?? so mybe i can find out what is wrong in my kernel image. thank you. I have followed these directions for installing Debian ARM in QEMU: http://www.aurel32.net/info/debian_arm_qemu.php And I have installed Armedslack (http://www.armedslack.org) using these directions as well. Regards, Sunil _ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
Re: [Qemu-devel] question in running linux in qemu-system-arm
thank you for your help. is this config you build your kernel and run in qemu ? and can you debug yur kernel image in qemu ? i tried the gdb debug ,but it failed. This GDB was configured as --host=i686-pc-linux-gnu --target=arm-elf.../root/source/test/zImage: not in executable format: File format not recognized From: Sunil Amitkumar Janki [EMAIL PROTECTED] Reply-To: qemu-devel@nongnu.org To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] question in running linux in qemu-system-arm Date: Mon, 16 Apr 2007 14:10:48 +0200 tang peilei wrote: thank you very much. but i want to make the image file by myself, not using other's image file. That's also what I do. For me these systems are only a way to get a development system running so I can recompile and optimise certain software for a specific ARM processor model. I intend to recompile Armedslack for armv5te for example for use on my PDA (Xscale PXA26x). When you have enough software of your own you can rebuild your image.I have tried to compile an ARM Versatile kernel image before but it failed a few times and compiling takes a long time in QEMU. I'll attach my probably non-functional config, which might be too large for your application. Regards, Sunil # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Wed Feb 7 16:29:09 2007 # CONFIG_ARM=y # CONFIG_GENERIC_TIME is not set CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_MTD_XIP=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=mobile-xscale CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_UTS_NS=y CONFIG_AUDIT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_PNX4008 is not set CONFIG_ARCH_PXA=y # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_OMAP is not set CONFIG_DMABOUNCE=y # # Intel PXA2xx Implementations # CONFIG_ARCH_LUBBOCK=y # CONFIG_MACH_LOGICPD_PXA270 is not set # CONFIG_MACH_MAINSTONE is not set # CONFIG_ARCH_PXA_IDP is not set # CONFIG_PXA_SHARPSL is not set # CONFIG_MACH_TRIZEPS4 is not set CONFIG_PXA25x=y # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_XSCALE=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5T=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # # Processor Features # CONFIG_ARM_THUMB=y # CONFIG_CPU_DCACHE_DISABLE is not set CONFIG_IWMMXT=y CONFIG_XSCALE_PMU=y CONFIG_SA=y CONFIG_FORCE_MAX_ZONEORDER=9 # # Bus support # # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m
Re: [Qemu-devel] question in running linux in qemu-system-arm
tang peilei wrote: thank you for your help. is this config you build your kernel and run in qemu ? and can you debug yur kernel image in qemu ? i tried the gdb debug ,but it failed. I have tried to build it a few times but it always errors out somewhere in the drivers section, probably because some drivers were not tested for ARM. But this is the closest I have got to a self-compiled kernel. You can probably get it to work by disabling some modules. This GDB was configured as --host=i686-pc-linux-gnu --target=arm-elf.../root/source/test/zImage: not in executable format: File format not recognized Unfortunately I don't cross-compile so I cannot really help you with this at the moment. Maybe it is not an ARM executable. At the moment I am building Armedslack Current X packages so I cannot build a kernel at the same time. I will try again as soon as I have finished building those. I'll probably try to set up a cross-compile environment for ARM as well. Regards, Sunil
Re: [Qemu-devel] question in running linux in qemu-system-arm
I am sorry but the kernel config I previously attached is for my PDA (Xscale). I have attached the Armedslack Current kernel config for ARM Versatile. Regard, Sunil # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20 # Mon Feb 12 20:38:46 2007 # CONFIG_ARM=y # CONFIG_GENERIC_TIME is not set CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-versatile # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set CONFIG_ARCH_VERSATILE=y # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_OMAP is not set # # Versatile platform type # CONFIG_ARCH_VERSATILE_PB=y CONFIG_MACH_VERSATILE_AB=y # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_ARM926T=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5TJ=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_COPY_V4WB=y CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # # Processor Features # # CONFIG_ARM_THUMB is not set # CONFIG_CPU_ICACHE_DISABLE is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_DCACHE_WRITETHROUGH is not set # CONFIG_CPU_CACHE_ROUND_ROBIN is not set CONFIG_ARM_VIC=y CONFIG_ICST307=y # # Bus support # CONFIG_ARM_AMBA=y CONFIG_PCI=y # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=y # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=y # # Kernel Features # # CONFIG_PREEMPT is not set # CONFIG_NO_IDLE_HZ is not set CONFIG_HZ=100 # CONFIG_AEABI is not set # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4096 # CONFIG_RESOURCES_64BIT is not set # CONFIG_LEDS is not set CONFIG_ALIGNMENT_TRAP=y # # Boot options # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE= # CONFIG_XIP_KERNEL is not set # # Floating point emulation # # # At least one emulation must be selected # CONFIG_FPE_NWFPE=y # CONFIG_FPE_NWFPE_XP is not set # CONFIG_FPE_FASTFPE is not set # CONFIG_VFP is not set # # Userspace binary
Re: [Qemu-devel] Updated OpenBIOS images
On 4/16/07, Aurelien Jarno [EMAIL PROTECTED] wrote: Is it possible (even hackish) to ignore openbios an jump directly to the kernel when using -kernel? No. The kernel queries the BIOS for hardware configuration.
Re: [Qemu-devel] Updated OpenBIOS images
On 4/16/07, Aurelien Jarno [EMAIL PROTECTED] wrote:
Blue Swirl a écrit :
The Sparc64 image can be booted using either VGA or serial. In both
cases, entering the Forth interpreter fails.
Is it possible (even hackish) to ignore openbios an jump directly to the
kernel when using -kernel?
You can try this patch. It bypasses the Forth setup and jumps to a
hard coded kernel start address.
Index: openbios-quilt/arch/sparc64/openbios.c
===
--- openbios-quilt.orig/arch/sparc64/openbios.c 2007-04-14 19:39:24.0 +
+++ openbios-quilt/arch/sparc64/openbios.c 2007-04-16 14:34:45.0 +
@@ -112,7 +112,13 @@
#ifdef CONFIG_DEBUG_BOOT
printk(done\n);
#endif
+{
+int (*entry)(const void *romvec, int p2, int p3, int p4, int p5);
+printk([sparc64] Kernel already loaded\n);
+entry = (void *) 0x404000;
+entry(0, 0, 0, 0, 0);
+}
PUSH_xt( bind_noname_func(arch_init) );
fword(PREPOST-initializer);
Re: [Qemu-devel] time inside qemu
That's true, and I don't care about it. I'd like to get a method to stop/start time inside qemu in order to simulate execution of large pieces of hw out of qemu (look at qemu-systemc project). If qemu is freeze meanwhile a systemc simulation is in progress (simulating a HW device of system), time should be freeze also. In this way, execution time of a program inside qemu should appear shorter when using accelerator HW than only SW application. I know these times are not reals, but it should be enough to estimate correctness and execution time on real platforms. Does a way to stop/start time inside qemu? Thanks, Màrius En/na Paul Brook ha escrit: On Friday 29 December 2006 17:53, Màrius Montón wrote: Hi, As I understand, OSes running inside qemu have notion of time: (its date and time works, time(1) command works, etc.). My question is about how qemu manages time. I need to stop and start again this virtual-time. qemu doesn't maintain virtual time, it just uses the real host time. I just tried with cpu_disable_ticks() and cpu_enable_ticks(). It seems to work partially: at least now system date and time are out of sync.. I suspect you'll find that for anything other than very coarse user (ie. user stop/continue) these are effectively useless. Any benchmark/performance measurements you make inside qemu are meaningless. qemu performance bears no relation whatsoever to the performance characteristics of real hardware. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Màrius Montón i Macián [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://cephis.uab.es http://www.mariusmonton.name Hardware Engineer CEPHIS Centre de Prototips i Solucions Hardware-Software Dep. Microelectrònica i Sistemes Electrònics ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534 Fax: +34 935 813 033 QC-2090D. ETSE. Campus UAB. 080193 Bellaterra begin:vcard fn;quoted-printable:M=C3=A0rius Mont=C3=B3n n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius org:CEPHIS-UAB adr:Campus de la Autonoma;;QC-2090D. ETSE;Bellaterra;Barcelona;08193;Spain email;internet:[EMAIL PROTECTED] title:System Engineer tel;work:+34935813534 url:http://cephis.uab.cat version:2.1 end:vcard
[Qemu-devel] [PATCH] savevm/loadvm/migrate: flush aio while pending BHs exist
Hello,
Sometimes (specifically when migrating/saving a guest which is doing a big IO
operation, e.g. copying a big file) there are some (aio-related) BH operations
pending. These pending BH operations are not saved as state. The ide device
does not save these operations either, which may lead to data corruption.
The patch makes sure all pending BH/aio operations are flushed.
Comments/better-alternatives are welcome.
Regards,
Uri.
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.279
diff -u -r1.279 vl.c
--- vl.c 6 Apr 2007 16:49:48 - 1.279
+++ vl.c 16 Apr 2007 14:27:00 -
@@ -5048,7 +5048,9 @@
}
/* ??? Should this occur after vm_stop? */
-qemu_aio_flush();
+do {
+ qemu_aio_flush();
+} while (qemu_bh_poll());
saved_vm_running = vm_running;
vm_stop(0);
@@ -5141,7 +5143,9 @@
}
/* Flush all IO requests so they don't interfere with the new state. */
-qemu_aio_flush();
+do {
+ qemu_aio_flush();
+} while (qemu_bh_poll());
saved_vm_running = vm_running;
vm_stop(0);
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 4/16/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote: On 4/15/07, Paul Brook [EMAIL PROTECTED] wrote: On Sunday 15 April 2007 20:11, Blue Swirl wrote: Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable assumption). The vma of .text is aligned on a 1Mb boundary. In order to allow loading via mmap, the location of .text within the file must also be aligned on a 1Mb boundary. It can't put it at address zero because the ELF headers get in the way, so the first viable location is 1Mb into the file. Nice theory (and I missed the modulo arithmetic, sorry), but on Ultrasparc the page sizes available are 8k, 64k, 4M and 256M. #define ELF_MAXPAGESIZE 0x10 BFD and GNU ld think it's 1MB. I stand corrected. Is there anything that can be done to reduce this waste?
Re: [Qemu-devel] time inside qemu
On Monday 16 April 2007 15:41, Marius Monton wrote: Any benchmark/performance measurements you make inside qemu are meaningless. qemu performance bears no relation whatsoever to the performance characteristics of real hardware. That's true, and I don't care about it. I'd like to get a method to stop/start time inside qemu in order to simulate execution of large pieces of hw out of qemu (look at qemu-systemc project). If qemu is freeze meanwhile a systemc simulation is in progress (simulating a HW device of system), time should be freeze also. In this way, execution time of a program inside qemu should appear shorter when using accelerator HW than only SW application. I know these times are not reals, but it should be enough to estimate correctness and execution time on real platforms. You're deluding yourself. I simply don't believe you can get any meaningful performance measurements out of qemu. You certainly can't use it to evaluate the correctness of time sensitive algorithms. qemu execution times can easily be orders of magnitude different from real hardware. i.e. if you have two operations that take the same amount of time to execute on real hardware, one of those operations may take many times longer than the other inside qemu. If nothing else you're entirely at the mercy of the host OS process scheduler and signal delivery. The emulated CPU may stall for an arbitrary time at any point. Paul
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
Blue Swirl wrote: On 4/16/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote: On 4/15/07, Paul Brook [EMAIL PROTECTED] wrote: On Sunday 15 April 2007 20:11, Blue Swirl wrote: Probably the linker is making sure the file offset and VMA are the same modulo the page size. But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable assumption). The vma of .text is aligned on a 1Mb boundary. In order to allow loading via mmap, the location of .text within the file must also be aligned on a 1Mb boundary. It can't put it at address zero because the ELF headers get in the way, so the first viable location is 1Mb into the file. Nice theory (and I missed the modulo arithmetic, sorry), but on Ultrasparc the page sizes available are 8k, 64k, 4M and 256M. #define ELF_MAXPAGESIZE 0x10 BFD and GNU ld think it's 1MB. I stand corrected. Is there anything that can be done to reduce this waste? See ld's -z max-page-size and -z common-page-size. Thiemo
Re: [Qemu-devel] Re: livecd
Carl Karsten wrote: Now for a bug report: [EMAIL PROTECTED]:~/qemu$ qemu -cdrom wc-2.4.iso -boot c -m 196 -serial stdio whoops - [EMAIL PROTECTED]:~/qemu$ qemu | grep -i version QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice Bellard I think I am running: qemu-snapshot-2007-04-06_05.tar.bz2 wc-2.4.iso boots just fine on 0.8.2 I'll try again with the current one. I have 2 suggestions: 1. print the version/build number when running a VM 2. add a separator between qemu's output and the -serial stdio output. (is there a better place to make suggestions?) Carl K
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 4/16/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Mon, Apr 16, 2007 at 06:01:04PM +0300, Blue Swirl wrote: I stand corrected. Is there anything that can be done to reduce this waste? For a BIOS image, you might be OK with ld -N - that should suppress the padding. Thanks, size is smaller and Qemu still accepts the image. I'll update the image and rules.
[Qemu-devel] qemu vl.h hw/pckbd.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/16 17:20:48 Modified files: . : vl.h hw : pckbd.c Log message: Memory-mapped interface for PS/2 controller, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.210r2=1.211 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.18r2=1.19
[Qemu-devel] qemu vl.h hw/mc146818rtc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/16 17:21:21 Modified files: . : vl.h hw : mc146818rtc.c Log message: Memory-mapped interface for RTC, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.211r2=1.212 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mc146818rtc.c?cvsroot=qemur1=1.8r2=1.9
Re: [Qemu-devel] qemu vl.h hw/pckbd.c
On Mon, 2007-04-16 at 17:20 +, Thiemo Seufer wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/04/16 17:20:48 Modified files: . : vl.h hw : pckbd.c Log message: Memory-mapped interface for PS/2 controller, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.210r2=1.211 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.18r2=1.19 Hi, This patch is incorrect: - it does make use of the it_shift parameter - it does not properly handle word and long accesses. The patch for the RTC is also incorrect: - it does not have a it_shift parameter - it does not handle the target endianness. I've got a correct patch for the memory mapped keyboard, as used on some PowerPC boards. I'll commit it soon. Please take a look to fix the RTC issues.
[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/04/16 17:41:15 Modified files: pc-bios: README openbios-sparc32 openbios-sparc64 Log message: Update OpenBIOS Sparc images to SVN 125 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemurev=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemurev=1.2
Re: [Qemu-devel] [PATCH] [MIPS] Acer Pica 61 machine
How is it suppossed to boot? It does not shows anything on screen, even it lacks a VGA output with default command line. El lun, 16-04-2007 a las 11:41 +0200, Hervé Poussineau escribió: Hi, This patch adds a Acer Pica 61 machine emulation to Qemu. I based my work on http://www.sensi.org/~alec/mips/acer_pica.html This machine can be used with the firmwares available at http://hpoussineau.free.fr/qemu/firmware (the PICA 61 versions). I've tested NetBSD 1.5.1, NetBSD 1.6.2, OpenBSD 2.3 and MS Windows NT 3.51, which start to boot, but all show different problems. The *BSD images are available at http://hpoussineau.free.fr/qemu Hervé
[Qemu-devel] qemu Makefile Makefile.target configure cpu-all.h
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/04/16 18:27:06 Modified files: . : Makefile Makefile.target configure cpu-all.h Log message: Sparc host update (Ben Taylor, Martin Bochnig) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.116r2=1.117 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.161r2=1.162 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.137r2=1.138 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.67r2=1.68
[Qemu-devel] qemu Makefile.target vl.h hw/ppc.c target-ppc/c...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/16 20:09:45 Modified files: . : Makefile.target vl.h hw : ppc.c target-ppc : cpu.h exec.h op.c translate_init.c Added files: hw : ppc405_uc.c Log message: Add callbacks to allow dynamic change of PowerPC clocks (to be improved) Fix embedded PowerPC watchdog and timers Fix PowerPC 405 SPR Add generic PowerPC 405 core instanciation code + resets support. Implement simple peripherals shared by most PowerPC 405 implementations PowerPC 405 EC EP microcontrollers preliminary support CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.162r2=1.163 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.213r2=1.214 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemur1=1.20r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_uc.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.43r2=1.44 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemur1=1.18r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemur1=1.33r2=1.34 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.14r2=1.15
[Qemu-devel] sizeof(target_int)
Is it possible to get size of target int? Why is only TARGET_LONG_BITS
defined?
I have need of size of target int for correct define fsid_t for linux user
mode. fsid_t is struct { int val[2]; } for linux.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
signature.asc
Description: Digital signature
Re: [Qemu-devel] time inside qemu
Hi, I just tried with cpu_disable_ticks() and cpu_enable_ticks(). It seems to work partially: at least now system date and time are out of sync.. Maybe a more accurate way to do this is mimicking stop and continue monitor commands: vm_stop(EXCP_INTERRUPT); [SystemC simulation] vm_start(); This just takes SystemC emulation time out of the equation. You cannot make any reliable performance measure of qemu's translated code, as already mentioned, but the former may be enough for your requirements. Regards, Eduardo Felipe
Re: [Qemu-devel] [PATCH] ARM XScale core features and PXA270 and PXA255 emulation.
On 3/16/07, andrzej zaborowski [EMAIL PROTECTED] wrote: Implements basic differences between XScale and plain ARM. The patch also adds the main on-chip peripherals of PXA2xx: interrupt controller, DMA, GPIO controller, SSP, I2C, I2S busses, UARTs, FIR port, RTC, Clock/Power/Memory managers. Cheers, Andrew interesting (I haven't tested it yet)... how to use this patch ? beside the -portrait extra switch, applying this patch would make arm-softmmu a pxa2xx by default ? if so, it's very interesting: I've an ipaq (H2210) and I was taking part of a port of linux on it. One big drawback then is that I burned a few SD cards to get a kernel working, but this patch could be a good fix to my problems... Do I just need the 2 emails with pxa2xx patches ? or is there more needed ? Last, but not least: do you think we could emulate a windows CE pocketpc in this way ? -- Christian
Re: [Qemu-devel] two repeatable kqemu-related crashes
On Fri, 2007-04-13 at 02:31, Don Kitchen wrote: Hi all I've found two repeatable (possibly related) ways to crash kqemu with 0.9.0 and several earlier versions also I think. It's under linux 2.6.9 fully updated CentOS 4.4 (clone of RH enterprise linux 4.4) I'm running in a similar setting without a problem. Kqemu 1.3.0pre11 + a locally cooked rpm of qemu 0.9.0 based an earlier dag package of qemu. I running WBEL 4 instead of CentOS 4, but I really doubt that is where your problem is. I'm running on x86_64 and have to admit I haven't bothered going to the very latest kernel package, still running kernel-2.6.9-34.EL. The guest I have been playing with this past week is Debian 4.0 i386. Installed and have been running since with -kernel-kqemu. The only reliable way I have to nuke the machine is boot FC5 with -kernel-kqemu and start OO.o. Without -kernel-kqemu it only kills the VM. It is something with FC5 and GCJ, been reported on the list before. Btw, OO.o as supplied with Debian 4.0 starts up without a lockup, will be throwing some documents at it later to see if it holds up. -- John M. http://www.beau.org/~jmorris This post is 100% M$Free! Geekcode 3.1:GCS C+++ UL$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r
Re: [Qemu-devel] 16-bit (and 8-bit) emulation
Windows 3.1 is not an OS. And there is no Windows for 286 protected mode. There is OS/2 and UNIXen but none works (OS/2 2.0 and later UNIXen works but they are 386 protected mode) El mar, 17-04-2007 a las 00:35 +0100, Derek Fawcus escribió: On Sun, Apr 15, 2007 at 08:55:17PM +0100, Natalia Portillo wrote: Yes but... Currently no protected mode 286 guest OS runs under qemu. Windows 3.1 Standard mode? (Delete / Rename KRNL386.EXE) DF El dom, 15-04-2007 a las 14:46 +0100, Nigel Horne escribió: Let me approach this in a different way in the hope that I'll get an answer to my question: will Qemu run a 286 guest O/S? -Nige
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi,
I have another small question. Actually, I am implementing hardware
transactional memory support in QEMU. I have implemented the following two
helper functions functions in targer-i386/helper.c
void helper_StartTransaction()
void helper_CommitTransaction();
My application looks as follows.
int main()
{
__asm_volatile(mov %al %al); //is detected in translation.c and
helper_StartTransaction is called
}
In case a transaction fails, I detect it inside the code for
helper_CommitTransaction(), now I need to jump back to the place where
On 4/8/07, Eduardo Felipe [EMAIL PROTECTED] wrote:
I recommend:
http://fabrice.bellard.free.fr/qemu/user-doc.html
Regards,
Eduardo
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Sorry for my previous incomplete email
Hi,
I have another small question. Actually, I am implementing hardware
transactional memory support in QEMU. I have implemented the following two
helper functions functions in targer-i386/helper.c
void helper_StartTransaction()
void helper_CommitTransaction();
My application looks as follows.
int main()
{
__asm_volatile(mov %al %al); //is detected in translation.c and
helper_StartTransaction is called
//add the code here
__asm_volatile(mov %bl %bl); //is detected in translation.c and
helper_CommitTransaction is called
}
In case a transaction fails, I detect it inside the code for
helper_CommitTransaction(), now I need to jump back to the start of
transaction. I do it by using setjmp inside helper_StartTransaction and
calling longjmp inside CommitTransaction, Code for the two helper functions
is as follows
void helper_StartTransaction()
{
printf(StartTransaction Called\n);
if(setjmp(env-tm_jmp))
{
printf(Transaction restart\);
}
}
void helper_CommitTransaction()
{
printf(CommitTransaction Called\n);
longjmp(env-tm_jmp, 0);
}
But this prints Transaction restart once and then the program finishes.
This means that commit transaction is not called the second time. Could you
please tell me what am I doing wrong?
Regards,
Atif
On 4/16/07, Atif Hashmi [EMAIL PROTECTED] wrote:
On 4/8/07, Eduardo Felipe [EMAIL PROTECTED] wrote:
I recommend:
http://fabrice.bellard.free.fr/qemu/user-doc.html
Regards,
Eduardo
[Qemu-devel] another lsi53c895a patch
Index: hw/lsi53c895a.c
===
RCS file: /sources/qemu/qemu/hw/lsi53c895a.c,v
retrieving revision 1.6
diff -u -p -r1.6 lsi53c895a.c
--- hw/lsi53c895a.c 7 Apr 2007 18:14:41 - 1.6
+++ hw/lsi53c895a.c 17 Apr 2007 02:12:05 -
@@ -1434,10 +1434,13 @@ static void lsi_reg_writeb(LSIState *s,
if (val LSI_ISTAT0_SRST) {
lsi_soft_reset(s);
}
+break;
case 0x16: /* MBOX0 */
s-mbox0 = val;
+break;
case 0x17: /* MBOX1 */
s-mbox1 = val;
+break;
case 0x1b: /* CTEST3 */
s-ctest3 = val 0x0f;
break;
[Qemu-devel] qemu vl.h hw/ppc405_uc.c target-ppc/translate_i...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/17 02:50:56 Modified files: . : vl.h hw : ppc405_uc.c target-ppc : translate_init.c Added files: hw : ppc405.h Log message: Move PowerPC 405 specific definitions into a separate file Preliminary code for -kernel option support for PowerPC 405 boards Fix DBSR in case of PowerPC 405 chip reset Add enums for PowerPC 405 clocks. Fix IRQ numbers (IBM reversed bits numbering...) Fix SPRG4-7 read access right Fix MSR mask in CPU definitions CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.214r2=1.215 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_uc.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.15r2=1.16
[Qemu-devel] Re: qemu vl.h hw/ppc405_uc.c target-ppc/translate_i...
Hello, is support for the 440GX processor foreseen anytime soon? (I noticed it i labelled with TODO...) Which is the most similiar PPC processor already supported? What are the differences (in term of things needed to support it)? Thanks in advance, Lorenzo
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Hi, On 16/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Various versions of Qemu/Kqemu available and under test: 0.8.2, 0.9.0, and CVS. Kqemu 1.3.0pre9, 1.3.0pre11 When building Qemu I use the following configure setup, using a gcc 3.4: ./configure --prefix=/usr/local/ \ --cc=/opt/gcc34/bin/gcc-3.4 --host-cc=/opt/gcc34/bin/gcc-3.4 \ --enable-alsa --enable-adlib \ --target-list=i386-softmmu x86_64-softmmu Kqemu built with standard (system) gcc. I always use qemu-system-x86_64 to start Qemu. Here the problems: Installing a 32bit Linux system (Debian, Kernel 2.6.18): - works with pure Qemu (-no-kqemu) - fails with Kqemu support enabled. The failure is a loop before or during the kernel hands over control to INIT Does your host happen to be dual-core? If so, please try adding notsc to the guest kernel commandline and report if it makes a difference. I used gdb to get some more information about the problems using the following command: gdb qemu-system-x86_64 using a .gdbinit that sets the args, etc. When the kernel goes into the loop I interrupt with ^C several times, most of the time it was in code_gen_buffer, here in the function compute_c_subl. Because I'm _not_ sure this is the correct way to debug Qemu I cannot say if this is normal or not. At least the function always returns 1 (it seems that it is called over and over again with). The last relevant statement in this function is: cmp %eax,0x90(%r14) seta %al where the conetent of %eax is zero, the content of the memory is 0xeb3e. The return says: the memory content is bigger than 0x0 (which is true for 64bit, but also true for 32bit unsigned, compute_c_subl compares two unsigned 32bit integers). As said, take these findings with a grain of salt. My general thought about the problem: running 32bit code on a 64bit host with similar architecture as this is the case of x86 / x86_64 could easily result in problems with signedness, sign bit extension, different pointer/word/interger sizes... BTW: is there a Howto or other information how to debug Qemu when the loaded kernel loops or crashes? That would be great and would make it easier to step in here and provide some help (or is this a somewhat good kept secret :-) ? ). Use qemu's gdb server, it's documented. The next problems are fairly old, they are also reported in the Qemu user's wiki - but without an answer o solution. Installing a 64bit Linux system (openSuse 10.1, 10.2): - fails with Qemu (-no-kqemu), loops when Grub shall install the bootloader. - fails with Kqemu enabled, crashes at various addresses and prints register contents. Any hints what this could be? Solutions? Regards, Werner Regards, Andrzej
