Re: [Qemu-devel] How to extract content of a raw image on host?
JonY wrote: Dirk Behme wrote: Hi, is there a way to extract the contents of a qemu raw image on (x86 Linux) host without starting QEMU itself? If so, any hint would be quite nice. I'm looking for anything like the reverse what http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00448.html seems to do. Extract files/directories from an existing raw image. qemu-img reports me > qemu-img info disk.img image: disk.img file format: raw virtual size: 4.3M (4515328 bytes) disk size: 4.3M but what is in it and how to access the content? Thanks, and sorry if this is a FAQ and I missed the correct search string, Dirk Hi, have you tried using a loop back mount? # mount -o loop disk.img mnt/ mount: You have to specify a file system type # mount -t raw -o loop disk.img mnt/ mount: unknown file system type „raw“ Sorry if I miss the obvious ;) Dirk
[Qemu-devel] How to extract content of a raw image on host?
Hi, is there a way to extract the contents of a qemu raw image on (x86 Linux) host without starting QEMU itself? If so, any hint would be quite nice. I'm looking for anything like the reverse what http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00448.html seems to do. Extract files/directories from an existing raw image. qemu-img reports me > qemu-img info disk.img image: disk.img file format: raw virtual size: 4.3M (4515328 bytes) disk size: 4.3M but what is in it and how to access the content? Thanks, and sorry if this is a FAQ and I missed the correct search string, Dirk
Re: [Qemu-devel] Nokia N770 and/or N800 emulation
M. Warner Losh wrote: Is anybody working on N770 and/or N800 emulation for qemu? Andrzej Zaborowski worked on OMAP310 for Palm Tungsten|E machine emulation for qemu: http://cvs.savannah.gnu.org/viewvc/qemu/hw/?root=qemu Please note that N770/800 has other OMAP processors than Tungsten. N770 has ARM9/DSP based OMAP17xx, while N800 has ARM11/DSP based OMAP24xx. I think qemu will never support DSP, and qemu doesn't support ARM11 (see qemu mail archives for details). So currently I think there are only chances for ARM9 side of N770. Best regards Dirk
Re: [Qemu-devel] QEMU wiki down?
Stefan Weil wrote: Dirk Behme schrieb: Anybody else with problems accessing QEMU wiki http://kidsquid.com/cgi-bin/moin.cgi ? Dirk Yes. Stefan Looks okay again. Thanks Dirk Btw: Our QuickStartGuide reached > 10 view counts: http://kidsquid.com/cgi-bin/moin.cgi/PageHits :) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU wiki down?
Anybody else with problems accessing QEMU wiki http://kidsquid.com/cgi-bin/moin.cgi ? Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Decode of MIPS DMFC0 and DMTC0
Hi,
looking into target-mips/translate.c, in function
decode_opc() OPC_DMFC0 and OPC_DMTC0 are mapped to gen_cp0()
if MIPS64 is enabled:
case OPC_CP0:
op1 = MASK_CP0(ctx->opcode);
switch (op1) {
case OPC_MFC0:
case OPC_MTC0:
#ifdef MIPS_HAS_MIPS64
case OPC_DMFC0:
case OPC_DMTC0:
#endif
gen_cp0(ctx, op1, rt, rd);
break;
But looking into gen_cp0() in same file, there is no case
statement for OPC_DMFC0 and OPC_DMTC0. Looks to me that this
results in a RI exception.
Do I overlook anything here or is DMFC0/DMTC0 decoding
missing in gen_cp0()?
Dirk
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] boot a preinstalled winxp on linux/x86: writing a patch...
Roberto Polli wrote: Alle 11:09, giovedì 28 dicembre 2006, Stefan Weil ha scritto: booting a preinstalled winxp fails because Windows XP crashs...and ... reboot. It won't fail if the real hardware and QEMU's virtual hardware are nearly identical. ok Especially the chipset seams to be critical. 1- so we should have one qemu "chipset emulator" for each winxp installation? 2- is this pbm equivalent to the "move my hd to another pc with different mainboard" one? 3- if I solve pbm 2, should I solve pbm 1? /dev/hda1 is the first partition which is part of /dev/hda (whole disk) yes, i mistakenly thought that part of the windows bootloader was related to the mbr Thank you very much for your explanation, these are very helpful! Do you think I should put something about this thread in the wiki? Forums are full of such these question! I think parts of this are already in Wiki: http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions#head-a1fc78523d7c7d256a29bac4577cd728be70eedd Do you think this is sufficent? If not, feel free to extend it. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH 3/6] A cumulative MIPS patchset
Thiemo Seufer wrote: Aurelien Jarno wrote: I suggest to use the patch below instead. It is based on the patch I posted [1] on the mailing list a few days ago. it moves the initialisation of the RTC date/time into hw/mc146818rtc.c, to avoid duplication of code. I guess all platform using this RTC chip will want to setup at least the date and time. I included it in my current mips patchset, available from http://people.debian.org/~ths/qemu/2006-11-26/ I saw no other comments on the list, so any chance to get this patchset applied? Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Huge TLB performance improvement
Daniel Jacobowitz wrote: This is with all of the patches I've posted to the list applied If patches settle down would be nice to get a list of patches or a summary patch to be applied in which order against which basis. Seems that I mixed up finding the correct ones in the correct order ;) Many thanks Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Broken forum links on qemu.org
Oliver Gerlich wrote: It seems the new forum location is only available from the mailing list (I didn't find any other link). Wiki [1] should have correct link to forum. Best regards Dirk [1] http://kidsquid.com/cgi-bin/moin.cgi ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Poor Qemu documentation for Windows host
Alexey Eremenko wrote: For example the documentation is very poor about running Qemu under Windows host, with it's lacking details about Windows networks. Maybe you like to check if QEMU Wiki http://kidsquid.com/cgi-bin/moin.cgi/QemuOnWindows can help you (and link at bottom of that page). I would like to state exactly which parts of Qemu or not available on Windows host system in the end-user docs, and I will send you a diff/patch. You are invited to add anything to wiki you think is missing as well. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Porting QEMU to run on Plan9
Bankim Bhavsar wrote: Is there a porting guide to port QEMU to a new host OS ? Maybe http://libvncserver.sourceforge.net/qemu/qemu-porting.html can help you. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] MIPS little endian user space emulation
Stefan Weil wrote: Dirk Behme schrieb: Hi, anybody with success using little endian MIPS user space emulation qemu-mipsel? I try to run a simple hello world example using recent QEMU snapshot. It crashes with "qemu: unhandled CPU exception 0x1a - aborting". For more details see below. Doing the same with ARM compiler and qemu-arm does work btw. My CVS snapshot works: $ mipsel-user/qemu-mipsel -L /nfsroot /nfsroot/bin/busybox ls / bin dev etc lib mnt proc sbin tmp usr Busybox statically or dynamically linked? Which toolchain? Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] MIPS little endian user space emulation
wangji wrote: Seems to me that it gets a wrong jump address via gp in t9: 0x401fa00c: lw t9,-32600(gp) ... 0x401fa01c: jalr t9 ... yes,I got similar error,but if I "static" compile then everything looks ok ! Thanks for the hint! static works for me as well. So, maybe a toolchain (glibc?) issue? qemu-0.82 ,crosstool-0.38 from my latest livecdToolkit http://mirror.opf.slu.cz/scratchbox/iso/ScratchboxMultiCpu-2.3.iso I use qemu-snapshot-2006-09-07_23 and toolchain created with crosstool-0.42 configuration cat mipsel.dat gcc-3.4.1-glibc-2.3.2.dat Regards Dirk Btw: Do you can connect and then step/continue with gdb to qemu-mipsel? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] MIPS little endian user space emulation
Hi,
anybody with success using little endian MIPS user space
emulation qemu-mipsel? I try to run a simple hello world
example using recent QEMU snapshot. It crashes with "qemu:
unhandled CPU exception 0x1a - aborting". For more details
see below. Doing the same with ARM compiler and qemu-arm
does work btw.
Seems to me that it gets a wrong jump address via gp in t9:
0x401fa00c: lw t9,-32600(gp)
...
0x401fa01c: jalr t9
Any ideas?
Many thanks
Dirk
hello_world> cat hello_world.c
#include
int main(void) {
printf("Hello world\n");
return 0;
}
hello_world> mipsel-linux-gcc hello_world.c -o hello_world
hello_world> file hello_world
hello_world: ELF 32-bit LSB MIPS-I executable, MIPS, version
1 (SYSV), for GNU/Linux 2.4.3, dynamically linked (uses
shared libs), not stripped
hello_world> ./qemu-mipsel -L
/usr/mips/mipsel-linux/mipsel-linux -d
out_asm,in_asm,op,int,exec,cpu hello_world
qemu: unhandled CPU exception 0x1a - aborting
pc=0x00012a2c HI=0x LO=0x ds 0003 0
GPR00: r0 at v0 401f60d4 v1 0008
GPR04: a0 00017864 a1 0001730c a2 00a1 a3 00016500
GPR08: t0 9000 t1 401f6000 t2 4000 t3 6fff
GPR12: t4 7053 t5 401f3c00 t6 401f3f00 t7 0063
GPR16: s0 6f72 s1 s2 s3
GPR20: s4 s5 s6 s7
GPR24: t8 6dff t9 00012a2c k0 k1
GPR28: gp 40257020 sp 401f3be8 s8 ra 401fa024
CP0 Status 0x30400014 Cause 0x EPC0x
Config0 0x8082 Config1 0x1e190c8b LLAddr 0x
CP1 FCR0 0x0110 FCR31 0x SR.FR 0
FT0: w: d: fd:0 fs:5.75452
FT1: w: d: fd:0 fs:5.75452
FT2: w: d: fd:0 fs:5.75452
f00: w: d: fd:0 fs:5.75452
...
f30: w: d: fd:0 fs:5.75452
qemu: uncaught target signal 6 (Aborted) - exiting
Exctract of end of log file:
...
pc=0x401f9c28 HI=0x LO=0x ds 0003 0
GPR00: r0 at v0 v1 0008
GPR04: a0 0008 a1 401f617c a2 401f3c38 a3 401f6000
GPR08: t0 9000 t1 401f6000 t2 4000 t3 6fff
GPR12: t4 7053 t5 401f3c20 t6 401f3f20 t7 0063
GPR16: s0 6f72 s1 s2 s3
GPR20: s4 s5 s6 s7
GPR24: t8 6dff t9 6e66 k0 k1
GPR28: gp 40257020 sp 401f3c08 s8 ra 6eff
CP0 Status 0x30400014 Cause 0x EPC0x
Config0 0x8082 Config1 0x1e190c8b LLAddr 0x
CP1 FCR0 0x0110 FCR31 0x SR.FR 0
FT0: w: d: fd:0 fs:-8.6795e-299
FT1: w: d: fd:0 fs:-8.6795e-299
FT2: w: d: fd:0 fs:-8.6795e-299
f00: w: d: fd:0 fs:-8.6795e-299
f02: w: d: fd:0 fs:-8.6795e-299
f04: w: d: fd:0 fs:-8.6795e-299
f06: w: d: fd:0 fs:-8.6795e-299
f08: w: d: fd:0 fs:-8.6795e-299
f10: w: d: fd:0 fs:-8.6795e-299
f12: w: d: fd:0 fs:-8.6795e-299
f14: w: d: fd:0 fs:-8.6795e-299
f16: w: d: fd:0 fs:-8.6795e-299
f18: w: d: fd:0 fs:-8.6795e-299
f20: w: d: fd:0 fs:-8.6795e-299
f22: w: d: fd:0 fs:-8.6795e-299
f24: w: d: fd:0 fs:-8.6795e-299
f26: w: d: fd:0 fs:-8.6795e-299
f28: w: d: fd:0 fs:-8.6795e-299
f30: w: d: fd:0 fs:-8.6795e-299
IN:
0x401f9c28: lw v0,60(a2)
0x401f9c2c: nop
0x401f9c30: bnez v0,0x401fa000
0x401f9c34: nop
OP:
0x: load_gpr_T0_gpr6
0x0001: set_T1 0x3c
0x0002: add
0x0003: lw_raw
0x0004: store_T0_gpr_gpr2
0x0005: load_gpr_T0_gpr2
0x0006: reset_T1
0x0007: ne
0x0008: set_bcond
0x0009: jnz_T2 0x0
0x000a: goto_tb1
0x000b: save_pc 0x401f9c38
0x000c: set_T0 0x800cd4a1
0x000d: exit_tb
0x000e: save_pc 0x401fa000
0x000f: set_T0 0x0
0x0010: exit_tb
0x0011: reset_T0
0x0012: exit_tb
0x0013: end
2 0003
OUT: [size=80]
0x810cd980: mov0x18(%ebp),%ebx
0x810cd983: mov$0x3c,%esi
0x810cd988: add%esi,%ebx
0x810cd98a: mov(%ebx),%ebx
0x810cd98c: mov%ebx,0x8(%ebp)
0x810cd98f: mov0x8(%ebp),%ebx
0x810cd992: xor%esi,%esi
0x810cd994: cmp%esi,%ebx
0x810cd996: setne %al
0x810cd999: xor%ebx,%ebx
0x810cd99b: mov%al,%bl
0x810cd99d: mov%ebx,%edi
0x810cd99f: test %edi,%edi
0x810cd9a1: je 0x810cd9a8
0x810cd9a3: jmp0x810cd9bd
0x810cd9a8: jmp0x83151d34
0x810cd9ad: movl $0x401f9c38,0x80(%ebp)
0x810cd9b7: mov$0x800cd4a1,%ebx
0x810cd9bc: ret
0x810cd9bd: movl $0x401fa000,0x80(%ebp)
0x810cd9c7: mov$0x0,%ebx
0x810cd9cc: ret
0x810cd9cd: xor%eb
[Qemu-devel] QEMU Wiki down?
Hi, anybody else with problems accessing QEMU Wiki? http://kidsquid.com/cgi-bin/moin.cgi Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Debugging low level ARM with GDB
Hello, I'd like to debug low level ARM bootloader U-Boot using ARM port of QEMU. I use qemu-0.8.0-i386.tar.gz for this and start QEMU with > qemu-system-arm -S -s -m 64 -net none -nographic -kernel u-boot.bin -monitor null -parallel null -serial null Waiting gdb connection on port 1234 (Note: u-boot.bin is the binary one, u-boot used below is the ELF version) In another window I start ARM gdb, but seems that I'm not able to step, disassemble etc: uboot/u-boot-1.1.4> arm-linux-gdb GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux". (gdb) file u-boot Reading symbols from uboot/u-boot-1.1.4/u-boot...done. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x in ?? () (gdb) info r r0 0x0 0 r1 0x0 0 ... r120x0 0 sp 0x0 0 lr 0x0 0 pc 0x0 0 fps0x0 0 cpsr 0x41d3 1073742291 (gdb) disassemble No function contains program counter for selected frame. (gdb) s Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) c Continuing. [pressing ctrl-c] Program received signal 0, Signal 0. 0x00018468 in ?? () (gdb) s Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) info r r0 0xfffecf00 -78080 r1 0x0 0 r2 0x100256 r3 0x0 0 ... r6 0x0 0 r7 0x4001024 r8 0x0 0 ... r110x0 0 r120x18064 98404 sp 0x0 0 lr 0x180f4 98548 pc 0x18468 99432 fps0x0 0 cpsr 0x61d3 1610613203 (gdb) What do I miss here? Seems that program did something, but I'm not able to debug it. Two additional questions: If I load the binary version of image u-boot.bin into QEMU, how does QEMU know to which start address the image was linked to? Or do I have to load the ELF file? If my program want to access the serial ports, how do I have to configure the serial driver in my program to access these ports? E.g. which base address do I have to use in the serial driver? In real HW they differ from chip to chip. Many thanks and best regards, Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
Marius Groeger wrote: I agree, though, that in your debugging, you probably examined a wrong context. The actual, current context's EXL should be correct, otherwise things wouldn't be working at all. Argh, debugging different context sounds nice ;) It's my feeling that while switching between these different context anything with hflags goes wrong. But I'm only guessing here. Let's see... Having said that, I'm currently playing with nested interrupts - let's see how that checks out... :-) Do several consecutively, non nested, interrupts (e.g. priodical timer) work for you? Cheers Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
Thiemo Seufer wrote: Dirk Behme wrote: I'm not sure, but while playing with MIPS interrupts, it seems to me that something with reset of interrupt flag MIPS_HFLAG_EXL (0x04) at exception exit (eret) is wrong. It seems to me that only one interrupt is executed because after eret, MIPS_HFLAG_EXL stays set in env->hflags. Then, at next interrupt, system correctly checks for MIPS_HFLAG_EXL, but this is still set and no further interrupt happens. This explains some weirdness I saw on my hacked up qemu when running a mips32r2-compiled Linux kernel. This was the reason why I first tried it with a small test program before using Linux ;) Debugging shows that op_eret() in MIPS op.c correctly reset this bit: env->hflags &= ~MIPS_HFLAG_EXL; But debug output at end of e.g. save_cpu_state() (debug output of ctx->hflags and ctx->saved_hflags ) or in function which tries to issue (next) timer interrupt (debug output of env->hflags) MIPS_HFLAG_EXL is still (again?) set everywhere. Looks like the correct env->hflags from op_eret() is overwritten somewhere later with wrong value. These three ctx->hflags, ctx->saved_hflags and env->hflags are confusing me ;) Where are they synchronized after eret? Or who overwrites the env->hflags correctly set by eret again? Any ideas, why eret sets env->hflags correctly and later global env->hflags has still/again wrong value? Any other hints? AFAIU qemu maintains an environment stack, I guess popping the environment restores the old flag contents. Anybody with a short explanation of the basics of this? I think this would really help debugging this issue. Many thanks Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
Hi, I'm not sure, but while playing with MIPS interrupts, it seems to me that something with reset of interrupt flag MIPS_HFLAG_EXL (0x04) at exception exit (eret) is wrong. It seems to me that only one interrupt is executed because after eret, MIPS_HFLAG_EXL stays set in env->hflags. Then, at next interrupt, system correctly checks for MIPS_HFLAG_EXL, but this is still set and no further interrupt happens. Debugging shows that op_eret() in MIPS op.c correctly reset this bit: env->hflags &= ~MIPS_HFLAG_EXL; But debug output at end of e.g. save_cpu_state() (debug output of ctx->hflags and ctx->saved_hflags ) or in function which tries to issue (next) timer interrupt (debug output of env->hflags) MIPS_HFLAG_EXL is still (again?) set everywhere. Looks like the correct env->hflags from op_eret() is overwritten somewhere later with wrong value. These three ctx->hflags, ctx->saved_hflags and env->hflags are confusing me ;) Where are they synchronized after eret? Or who overwrites the env->hflags correctly set by eret again? Any ideas, why eret sets env->hflags correctly and later global env->hflags has still/again wrong value? Any other hints? Many thanks Dirk Debug output shows something like: save_cpu_state(): ctx->hflags ctx->saved_hflags MIPS Timer #1: Status: 0x80408401, Cause: 0x8000, env->hflags: 0x save_cpu_state():ctx->hflags 0004 ctx->saved_hflags 0004 ** Interrupt handler called... ** Start of op_eret(): env->hflags 0x0204 Status 0x80408403 ** End of op_eret(): env->hflags 0x0200 Status 0x80408401 save_cpu_state():ctx->hflags 0004 ctx->saved_hflags 0004 save_cpu_state():ctx->hflags 0004 ctx->saved_hflags 0004 save_cpu_state():ctx->hflags 0004 ctx->saved_hflags 0004 ... MIPS Timer #2: Status: 0x80408401, Cause: 0x8000, env->hflags: 0x0004 MIPS Timer #3: Status: 0x80408401, Cause: 0x8000, env->hflags: 0x0004 MIPS Timer #4: Status: 0x80408401, Cause: 0x8000, env->hflags: 0x0004 MIPS Timer #5: Status: 0x80408401, Cause: 0x8000, env->hflags: 0x0004 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Interesting QEMU + OpenVPN
Jonathan Kalbfeld wrote: I have an instance of NetBSD 3.0.1 that runs inside of QEMU emulating an i386. On the parent system, whether it is Windows, Linux, Solaris, or *BSD, you can run an OpenVPN instance and set up a tunnel. On the guest system, you can then run OpenVPN and connect to the other end of the tunnel. Voila! Now, from the parent system, you can connect directly to your QEMU instance by using the tunnel. Maybe you like to add some details (something like a small "howto"?) and add a small description of this to QEMU Wiki [1]? Dirk [1] http://kidsquid.com/cgi-bin/moin.cgi ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix warnings in mips_r4k.c
Paul Brook wrote: On Monday 31 July 2006 11:20, Dirk Behme wrote: Fix warnings hw/mips_r4k.c: In function ‘mips_r4kc_init’: hw/mips_r4k.c:230: warning: pointer targets in passing argument 3 of ‘load_elf’ differ in signedness hw/mips_r4k.c:256: warning: pointer targets in passing argument 1 of ‘strcpy’ differ in signedness Compile with -Wno-pointer-sign. gcc4 isn't really supported anyway. Yes, I know ;) And yes, I know there are technical reasons for not supporting gcc4. But do you wan't to say that at places, where because of typos or lazy programming and thus no technical reason for it (e.g. passing signed where calling function wants unsigned) it is better to disable warning with -Wno-pointer-sign instead of fixing it? Note that I haven't fixed a lot of other similar warnings where there may be technical reasons for it. But in this file I thought its worth fixing and improving code quality. Regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix warnings in mips_r4k.c
Fix warnings
hw/mips_r4k.c: In function ‘mips_r4kc_init’:
hw/mips_r4k.c:230: warning: pointer targets in passing
argument 3 of ‘load_elf’ differ in signedness
hw/mips_r4k.c:256: warning: pointer targets in passing
argument 1 of ‘strcpy’ differ in signedness
--- ./hw/mips_r4k.c_orig 2006-07-31 12:11:32.0 +0200
+++ ./hw/mips_r4k.c 2006-07-31 12:14:55.0 +0200
@@ -195,7 +195,7 @@ void mips_r4kc_init (int ram_size, int v
const char *initrd_filename)
{
char buf[1024];
-int64_t entry = 0;
+uint64_t entry = 0;
unsigned long bios_offset;
int io_memory;
int ret;
@@ -253,7 +253,7 @@ void mips_r4kc_init (int ram_size, int v
}
/* Store command line. */
-strcpy (phys_ram_base + (16 << 20) - 256, kernel_cmdline);
+strcpy ((char *)phys_ram_base + (16 << 20) - 256, kernel_cmdline);
/* FIXME: little endian support */
*(int *)(phys_ram_base + (16 << 20) - 260) = tswap32 (0x12345678);
*(int *)(phys_ram_base + (16 << 20) - 264) = tswap32 (ram_size);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QuickStartGuide on QEMU Wiki
Fabrice Bellard wrote: Thank you for the advices. I modified the web site: tell me if you see other problems. Just an idea: What's about splitting KQEMU kqemu-xxx.tar.gz into two archives, one for Linux and one for Windows? If Linux is tar.gz and Windows uses .zip, people don't need a third party tool to extract tar.gz under Windows. Regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re QuickStartGuide on QEMU Wiki
Andrew Malcolmson wrote:
Here is a super short addition you might want to add to the
QuickStartGuide page,
A Wiki is something anybody can add improvements himself ;)
Create an empty 3 GB image file. You will be installing into this:
a)
{{{
qemu-img create mylinux.raw 3G
}}}
b)
Install from a downloaded iso file:
{{{
qemu -hda mylinux.raw -cdrom /dev/cdrom -boot d -net user -m 256
}}}
c)
Run the installation:
{{{
qemu -hda mylinux.raw -cdrom /dev/cdrom -boot c -net user -m 256
}}}
Mmh, sorry, but I didn't get the point here. What is the key
difference between the things above and
- your step (a) and QuickStartGuide step 2: creation of
blank disk image:
qemu-img create -f qcow c.img 3G
- your step (b) and QuickStartGuide step 3b: suppose you
have an install iso image, called my_os_install.iso. Then run:
qemu -cdrom my_os_install.iso -hda c.img -m 256 -boot d
already in QuickStartGuide?
Your step (c) is an extension of QuickStartGuide's "qemu
-hda c.img -m 256" which I think can be done by anybody who
understands the basics of QuickStartGuide on his own.
Let us keep the QuickStartGuide simple and easy and don't
explain every possible variant. For this anybody can use
http://fabrice.bellard.free.fr/qemu/qemu-doc.html
Regards
Dirk
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Updated QEMU binary with fixed invisible wall?
Hi, sorry if this is a FAQ, but while playing with installing Win under Linux (you know, the quick start guide) I found that I have the "invisible wall" mouse problem as well. I used the binary qemu-0.8.1-i386.tar.gz from QEMU's download area. Recent CVS seems to contain [1] already. Is there anywhere an updated binary version available? Regards Dirk [1] http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00112.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QuickStartGuide on QEMU Wiki
Fabrice Bellard wrote: Thank you for the advices. I modified the web site: tell me if you see other problems. Great! Many thanks! I'm not sure, but I think I can remember that in the download area there was a link to the QEMU daily snapshots (I think called "mirror"?) at http://qemu.dad-answers.com/download/qemu/ Do I overlooked anyhting or is it gone? Yes, I know, under "Links" there is a link to qemu.dad-answers.com, but there I wasn't able to find a link to the download area with the snapshots as well. Only my bookmark list helped me here ;) Best regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add special MIPS multiply instructions
This is an update of MIPS NEC VR5400 special instruction
patch [1]. It is necessary because of MIPS instruction set
configuration patch. Therefore this patch has to be applied
on top of
http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00158.html
Best regards
Dirk
[1]
http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html
--- ./target-mips/op_helper.c_orig 2006-07-22 07:32:51.0 +0200
+++ ./target-mips/op_helper.c 2006-07-22 08:01:16.0 +0200
@@ -128,6 +128,134 @@ void do_msubu (void)
tmp = ((uint64_t)T0 * (uint64_t)T1);
set_HILO(get_HILO() - tmp);
}
+
+#ifdef MIPS_USES_NEC_VR5400
+void do_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_msachi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_msacu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_msachiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulhi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulhiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulshi (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulshiu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+#endif /* MIPS_USES_NEC_VR5400 */
#endif
#if defined(CONFIG_USER_ONLY)
@@ -159,6 +287,149 @@ void do_tlbr (void)
{
cpu_abort(env, "tlbr\n");
}
+
+#ifdef MIPS_USES_NEC_VR5400
+void op_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_msachi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_msacu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_msachiu (void)
+{
+uint64_t tmp;
+
+
[Qemu-devel] QuickStartGuide on QEMU Wiki
Hi, just fyi: I tried to merge [1] and [2] and to distill a "Quick start guide" http://kidsquid.com/cgi-bin/moin.cgi/QuickStartGuide from it. Maybe someone find it useful. I do ;) Additionally, I agree to the first paragraph of [3] that it would be nice to have a link to the Wiki (and to the QuickStartGuide? ;) ) at a more prominent place on QEMU's homepage. I think this would help to avoid [4]. Fabrice, if you like it, maybe you can think about it. Regards Dirk [1] http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00094.html [2] http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00104.html [3] http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00116.html [4] http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00097.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Thiemo Seufer wrote: ... I recommend to go for a sufficiently flexible interface first, and then introduce it gradually in all appropriate places. A macro like: MIPS_OPC(ISA, ASE, CPU) which compares the arguments with the currently selected CPU emulation and throws an RI exception if the feature doesn't exist: ... case OPC_LD: MIPS_OPC(MIPS-III, 0, 0); ... break; ... ... My point is those MIPS_USES_*/MIPS_FEATURE_* should be abstracted better, that is, they should move in the implementation of the MIPS_OPC macro. I really like your proposals of MIPS_OPC() and better abstraction of MIPS_USES_*/MIPS_FEATURE_*! Do you think you can post a patch which introduces the basic parts of this functionality in the short term? Then we can use it as a starter for more improvements. This is not meant as an objection, I'm just drawing from experience with binutils, where it took some iterations (and wasted effort) to get it sufficiently right. You are right with your wasted effort argument above as well. However, my patch does not only introduce MIPS_USES_*/MIPS_FEATURE_*. It additionally introduces cpu_mips_set_model() (yes, I know, this can be improved as well, as Fabrice mentioned). So it shouldn't be to much wasted effort to keep the cpu_mips_set_model() and convert the three or four places of my MIPS_USES_*/MIPS_FEATURE_* to your MIPS_OPC abstraction (in case my patch is accepted ;) ). Btw, while talking about cpu_mips_set_model(): While thinking about it I found that we should try to keep the generic parts of cpu and model selection logic in sync with other architectures, I think at least with ARM (where possible). There will be differences in details like in instruction set splitting with your MIPS_OPC logic. But would be nice if we make generic improvements to e.g. cpu_mips_set_model() at MIPS, we make the same at ARM as well. ... Well, there is no CPU named "R4Kc". What qemu emulates today resembles mostly a 4kc, that is a MIPS32R1 CPU which has no FPU support. Yes, I understand this. But two things: First, in the current MIPS configuration FPU is enabled for "R4Kc". I think we shouldn't disable anything what is there at the moment, without giving an alternative for people using this (e.g. introducing an additional machine). And this only because there is no real world equivalent for this. Second, while I agree that there is no real world equivalent for this, I think this is one of the biggest advantages of a simulator like qemu: Your are able to configure and test machine and feature combinations which will never exist in real world really quickly. This second point is "the simulated machines should model the real world 110% exactly" vs "I don't need 100% simulation accuracy and wan't to be able to use configurations which are not possible in real world". Depends on how people will use qemu. I think while the first argument may be valid for x86 where people want to run e.g. Windows on Linux, for embedded processors like ARM or MIPS the second may be valid and interesting as well. Cheers Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Fabrice Bellard wrote:
Dirk Behme wrote:
Fabrice Bellard wrote:
Each machine can add specific support for that (for example a -cpu
option). It is likely to come at least for the PC machines.
I add suggest one more parameter to cpu_mips_set_model() to specify
optional features. A function converting a CPU "string id" into an id
+ features would be interesting too.
Fabrice, do you will accept the patch if I remove the
MIPS_FEATURE_ISAx options and convert MIPS_FEATURE_NEC_EXT to
MIPS_FEATURE_NEC_VR5400 as described in my previous mail?
Yes. Even without I can accept it as it is better than what we
previously had.
Please find as promised in attachment the updated version of
this patch. It removes MIPS_FEATURE_ISAx for the moment and
renames MIPS_FEATURE_NEC_EXT to MIPS_FEATURE_NEC_VR5400.
Best regards
Dirk
--- ./hw/mips_r4k.c_orig2006-07-08 07:16:50.0 +0200
+++ ./hw/mips_r4k.c 2006-07-08 07:16:45.0 +0200
@@ -189,10 +189,10 @@ CPUReadMemoryFunc *io_read[] = {
&io_readl,
};
-void mips_r4k_init (int ram_size, int vga_ram_size, int boot_device,
-DisplayState *ds, const char **fd_filename, int snapshot,
-const char *kernel_filename, const char *kernel_cmdline,
-const char *initrd_filename)
+void mips_r4kc_init (int ram_size, int vga_ram_size, int boot_device,
+ DisplayState *ds, const char **fd_filename, int snapshot,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename)
{
char buf[1024];
int64_t entry = 0;
@@ -203,6 +203,7 @@ void mips_r4k_init (int ram_size, int vg
long kernel_size;
env = cpu_init();
+cpu_mips_set_model(env, MIPS_R4Kc);
register_savevm("cpu", 0, 3, cpu_save, cpu_load, env);
/* allocate RAM */
@@ -284,8 +285,8 @@ void mips_r4k_init (int ram_size, int vg
}
}
-QEMUMachine mips_machine = {
-"mips",
-"mips r4k platform",
-mips_r4k_init,
+QEMUMachine mips_r4kc_machine = {
+"r4kc",
+"mips r4kc platform",
+mips_r4kc_init,
};
--- ./vl.h_orig 2006-07-08 07:16:51.0 +0200
+++ ./vl.h 2006-07-08 07:16:45.0 +0200
@@ -917,7 +917,7 @@ extern QEMUMachine core99_machine;
extern QEMUMachine heathrow_machine;
/* mips_r4k.c */
-extern QEMUMachine mips_machine;
+extern QEMUMachine mips_r4kc_machine;
/* shix.c */
extern QEMUMachine shix_machine;
--- ./target-mips/cpu.h_orig2006-07-08 07:16:50.0 +0200
+++ ./target-mips/cpu.h 2006-07-08 07:23:52.0 +0200
@@ -210,6 +210,8 @@ struct CPUMIPSState {
int bcond; /* Branch condition (if needed) */
int halted; /* TRUE if the CPU is in suspend state */
+
+uint32_t features; /* Internal CPU feature flags */
CPU_COMMON
};
@@ -275,5 +277,30 @@ enum {
int cpu_mips_exec(CPUMIPSState *s);
CPUMIPSState *cpu_mips_init(void);
uint32_t cpu_mips_get_clock (void);
+void cpu_mips_set_model(CPUMIPSState *env, uint32_t id);
+
+enum mips_features {
+MIPS_FEATURE_R4K_EXT = 0x1, /* instruction set extension for MIPS R4K */
+MIPS_FEATURE_NEC_VR5400 = 0x2, /* instruction set extension for NEC VR5400
CPUs */
+MIPS_FEATURE_FPU = 0x4, /* floating point instruction set */
+};
+
+#ifdef MIPS_USES_R4K_EXT
+#define mips_uses_r4k_ext() (env->features & MIPS_FEATURE_R4K_EXT)
+#else
+#define mips_uses_r4k_ext() 0
+#endif
+
+#ifdef MIPS_USES_NEC_VR5400
+#define mips_uses_nec_vr5400() (env->features & MIPS_FEATURE_NEC_VR5400)
+#else
+#define mips_uses_nec_vr5400() 0
+#endif
+
+#ifdef MIPS_USES_FPU
+#define mips_uses_fpu() (env->features & MIPS_FEATURE_FPU)
+#else
+#define mips_uses_fpu() 0
+#endif
#endif /* !defined (__MIPS_CPU_H__) */
--- ./target-mips/translate.c_orig 2006-07-08 07:16:50.0 +0200
+++ ./target-mips/translate.c 2006-07-08 07:22:48.0 +0200
@@ -1887,7 +1887,7 @@ static void gen_blikely(DisasContext *ct
gen_set_label(l1);
}
-static void decode_opc (DisasContext *ctx)
+static void decode_opc (CPUState *env, DisasContext *ctx)
{
int32_t offset;
int rs, rt, rd, sa;
@@ -1927,7 +1927,17 @@ static void decode_opc (DisasContext *ct
gen_arith(ctx, op1 | EXT_SPECIAL, rd, rs, rt);
break;
case 0x18 ... 0x1B: /* MULT / DIV */
-gen_muldiv(ctx, op1 | EXT_SPECIAL, rs, rt);
+ if(!sa) {
+gen_muldiv(ctx, op1 | EXT_SPECIAL, rs, rt);
+ } else {
+ if(mips_uses_nec_vr5400()) {
+ op1 = ctx->opcode & 0x7FF;
+ /* tbd: call handler for special NEC instructions */
+} else {
+ MIPS_INVAL("NEC extension");
+generate_exception(ctx, EXCP_RI);
+}
+}
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Fabrice Bellard wrote: Each machine can add specific support for that (for example a -cpu option). It is likely to come at least for the PC machines. ... I add suggest one more parameter to cpu_mips_set_model() to specify optional features. A function converting a CPU "string id" into an id + features would be interesting too. Fabrice, do you will accept the patch if I remove the MIPS_FEATURE_ISAx options and convert MIPS_FEATURE_NEC_EXT to MIPS_FEATURE_NEC_VR5400 as described in my previous mail? I consider this patch as a *first* step from hardcoded and compile time selected MIPS machine to flexible configuration as proposed by you and Thiemo. Other patches, for example with (really nice!) features above, can follow then and take this first patch as basis. With this, several small patches will improve MIPS step by step. I'd like to avoid a 'perfect, but unreadable, big & never ready' patch. And, with several small patches, more people can contribute ;) Many thanks for the comments Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Thiemo Seufer wrote:
Dirk Behme wrote:
- As I understand it, MIPS III is an extension of MIPS II,
MIPS IV is an extension of MIPS III etc. Therefore I used
definitions for ISAx which include the smaller ones as well.
Unfortunately it is not that simple. We have the upward-compatible ISAs:
Mmph ;) What do you think about this: Looking at the recent
MIPS code, we have a #define MIPS_USES_R4K_EXT and a #define
MIPS_USES_FPU, nothing else. No splitting of the different
ISAs and FPU instructions at all. And, looking at your
explanation, it seems to be really tricky to do this
splitting. So I'll remove the MIPS_FEATURE_ISAx definitions
from the patch (as mentioned, they were unused and only
example), this will change nothing compared to the existing
code.
I'd prefer to make changes and improvements in small
readable pieces without changing too much. One small
improvement after the other, not a big 'perfect', but
unreadable, patch. So the splitting of the ISA levels is
something for an other patch.
The improvement of this patch is to convert the compile time
switches MIPS_USES_R4K_EXT, MIPS_USES_FPU to compile *and*
runtime switches and to make machine runtime selectable (and
introduce MIPS_FEATURE_NEC_xxx).
+enum mips_features {
+MIPS_FEATURE_ISA1 = 0x1, /* MIPS I instruction set architecture */
+MIPS_FEATURE_ISA2 = 0x3, /* MIPS II instruction set architecture */
+MIPS_FEATURE_ISA3 = 0x7, /* MIPS III instruction set architecture */
+MIPS_FEATURE_ISA4 = 0xF, /* MIPS IV instruction set architecture */
I'll remove this.
+MIPS_FEATURE_R4K_EXT = 0x10, /* instruction set extension for MIPS R4K */
Those "extensions" seem to be unimplemented, maybe this was intended to
cover partial support for MIPS32R2, IOW, for a 4KE.
Sorry, what do you mean here? I only took the existing
#define MIPS_USES_R4K_EXT.
+MIPS_FEATURE_NEC_EXT = 0x20, /* instruction set extension for NEC CPUs */
This should name the specific CPU core (vr5400 or vr5500?). NEC built
a range of MIPS CPUs (e.g. vr41xx, or R12000) with different capabilities.
Yes, I'll change this.
However, on long term, there is a 'keep code simple' vs
'split instructions technically correct' tradeoff. Adding
later switches for e.g. vr41xx and R12000 will be okay from
clean instruction split point of view, but additional
switches will mess up the code and may be doublicate some
stuff. While one MIPS_FEATURE_NEC_EXT which contains all NEC
extensions will be simple, but wrong from instruction splitting.
But I'll convert this to MIPS_FEATURE_NEC_VR5400.
+void cpu_mips_set_model(CPUMIPSState *env, uint32_t id)
+{
+env->CP0_PRid = id;
+env->features = 0;
+switch (id) {
+case MIPS_R4Kc:
+set_feature(env, MIPS_FEATURE_ISA3);
+set_feature(env, MIPS_FEATURE_R4K_EXT);
+set_feature(env, MIPS_FEATURE_FPU);
+break;
What's the meaning of "R4Kc" here?
- R4000: We don't have 64bit (ISA III) support.
- 4kc: This one has neither ISA III nor FPU.
That's easy: I don't know ;) If you look at existing
mips-defs.h it is the name of the only hardcoded machine we
have at the moment. It enables R4K extensions and FPU. It
was my goal to change no functionality, only to make first
step to runtime selection. lI'll remove the ISA option.
Best regards
Dirk
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] MIPS instruction set configuration
Fabrice Bellard wrote:
You should add a runtime selection system : see the ARM and PowerPC
targets (I would prefer a parameter to cpu_init(). It was not done that
way on PowerPC for legacy reasons). Each machine should be able to
select the processor it needs (and allow the user to change it if
needed, but it is not the main point). There is no good reason to make
the selection at compile time because the translator can efficiently
handle any CPU differences at runtime.
Find in the attachment a first proposal for runtime
instruction set configuration for MIPS target. Please
comment, correct etc.
Some notes:
- As first step, only three options for R4K, NEC (partly,
see below) and FPU are used. The different MIPS ISA levels
aren't used at the moment and are there for future use.
Fabrice mentioned that he likes to split the different MIPS
intstruction set configurations clearly.
- As I understand it, MIPS III is an extension of MIPS II,
MIPS IV is an extension of MIPS III etc. Therefore I used
definitions for ISAx which include the smaller ones as well.
- With the
#ifdef MIPS_USES_xxx
#define mips_uses_xxx() (env->features & MIPS_FEATURE_xxx)
#else
#define mips_uses_xxx() 0
#endif
logic it should be possible to enable or disable a feature
at compile time by setting the corresponding macro *or* at
runtime by adding machines with different features to
cpu_mips_set_model().
- If mips_uses_xxx() is set to 0 at compile time, I think
gcc should optimize away the if(mips_uses_xxx()) parts in
translate.c. Therefore I think we can remove some #if
defined (MIPS_USES_xxx).
- An cpu_mips_set_model() is introduced similiar to the ARM
one. Because in mips-defs.h there was a hardcoded CPU, some
reorganization for runtime selection was necessary.
- Later, it should be possible to move more options to
runtime configuration, like endianess and the #if defined
(MIPS_CONFIGx) in cpu_mips_init(). For the moment, to keep
patch small I concentrated only on instruction set. I don't
want to mix to much instruction set configuration and
machine runtime selection for the moment.
- cpu_mips_init() moved from translate.c to helper.c and was
extended there by set_feature() and cpu_mips_set_model()
(same file location like used by ARM). Setting of FPU
options moved from cpu_mips_init() to model configuration
cpu_mips_set_model().
- My patch for NEC instruction set extension (the main
reason for the whole stuff ;) ) will be send and updated if
you like the configuration in this patch and something like
this is applied. For the moment, there's only a stub in
decode_opc() which should generate an exception.
Best regards
Dirk
--- ./target-mips/cpu.h_orig2006-07-02 14:44:59.0 +0200
+++ ./target-mips/cpu.h 2006-07-02 17:32:41.0 +0200
@@ -210,6 +210,8 @@ struct CPUMIPSState {
int bcond; /* Branch condition (if needed) */
int halted; /* TRUE if the CPU is in suspend state */
+
+uint32_t features; /* Internal CPU feature flags */
CPU_COMMON
};
@@ -275,5 +277,58 @@ enum {
int cpu_mips_exec(CPUMIPSState *s);
CPUMIPSState *cpu_mips_init(void);
uint32_t cpu_mips_get_clock (void);
+void cpu_mips_set_model(CPUMIPSState *env, uint32_t id);
+
+enum mips_features {
+MIPS_FEATURE_ISA1 = 0x1, /* MIPS I instruction set architecture */
+MIPS_FEATURE_ISA2 = 0x3, /* MIPS II instruction set architecture */
+MIPS_FEATURE_ISA3 = 0x7, /* MIPS III instruction set architecture */
+MIPS_FEATURE_ISA4 = 0xF, /* MIPS IV instruction set architecture */
+MIPS_FEATURE_R4K_EXT = 0x10, /* instruction set extension for MIPS R4K */
+MIPS_FEATURE_NEC_EXT = 0x20, /* instruction set extension for NEC CPUs */
+MIPS_FEATURE_FPU = 0x40, /* floating point instruction set */
+};
+
+#ifdef MIPS_USES_ISA1
+#define mips_uses_isa1() (env->features & MIPS_FEATURE_ISA1)
+#else
+#define mips_uses_isa1() 0
+#endif
+
+#ifdef MIPS_USES_ISA2
+#define mips_uses_isa2() (env->features & MIPS_FEATURE_ISA2)
+#else
+#define mips_uses_isa2() 0
+#endif
+
+#ifdef MIPS_USES_ISA3
+#define mips_uses_isa3() (env->features & MIPS_FEATURE_ISA3)
+#else
+#define mips_uses_isa3() 0
+#endif
+
+#ifdef MIPS_USES_ISA4
+#define mips_uses_isa4() (env->features & MIPS_FEATURE_ISA4)
+#else
+#define mips_uses_isa4() 0
+#endif
+
+#ifdef MIPS_USES_R4K_EXT
+#define mips_uses_r4k_ext() (env->features & MIPS_FEATURE_R4K_EXT)
+#else
+#define mips_uses_r4k_ext() 0
+#endif
+
+#ifdef MIPS_FEATURE_NEC_EXT
+#define mips_uses_nec_ext() (env->features & MIPS_FEATURE_NEC_EXT)
+#else
+#define mips_uses_nec_ext() 0
+#endif
+
+#ifdef MIPS_USES_FPU
+#define mips_uses_fpu() (env->features & MIPS_FEATURE_FPU)
+#else
+#define mips_uses_fpu() 0
+#endif
#endif /* !defined (__MIPS_CPU_H__) */
--- ./target-mips/helper.c_orig 2006-07-02 15:30:49.0 +0200
+++ ./target-mips/helper.c 2006-07-02 17:41:01.0 +0200
@@ -430,3 +430,69 @@ void do_interrupt (CPUState *env)
}
MIPS instruction set configuration, was: Re: [Qemu-devel] Pending MIPS patches
Fabrice Bellard wrote: 3. [PATCH] Add special MIPS multiply instructions http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html Same remark. These are NEC VR54xx specific extensions to the MIPS instruction set. They are used if you use GCC's -march=vr5400 option. See www.necelam.com/docs/files/1375_V2.pdf as well. Can you add some kind of define or dynamic processor definnition in your patch so that we can keep track of the exact instruction set ? Yes, I will update the patch. Any ideas or proposals from anybody how to do this the best way? Are there already examples from other architectures? I think a define to be able to completely select/unselect it at compile time combined with possibility for dynamic runtime selection would be the best? Regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Pending MIPS patches
Fabrice Bellard wrote: 2. [PATCH][MIPS] add "lwu" instruction http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00326.html On which MIPS CPU is it defined ? Need to track instruction sets exactly to be able to select a given MIPS CPU at compile time or dynamically. 3. [PATCH] Add special MIPS multiply instructions http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html Same remark. These are NEC VR54xx specific extensions to the MIPS instruction set. They are used if you use GCC's -march=vr5400 option. See www.necelam.com/docs/files/1375_V2.pdf as well. 9. [PATCH] Update MIPS status register with EXL and ERL bits at exception http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00329.html OK but the following lines are suspicious: Yes, I see. I mixed two fixes, let me explain below: -env->hflags = MIPS_HFLAG_ERL; +env->hflags |= MIPS_HFLAG_ERL; This is a typo fix for a missing "or" (it should be "|=" instead of only "="). hflags is used as a shadow of the status register and there not the whole value should be set, only the corresponding flag. See for example correct usage of MIPS_HFLAG_EXL or MIPS_HFLAG_ERL in helper.c or op.c of target-mips. There, they are correctly used everywhere with "|=" or "&= ~", except at this place. + env->CP0_Status &= (1 << CP0St_ERL); This is part of the "Update status register EXL and ERL flags directly, entering or leaving exception, not only hflags". So this two added lines fix the missing "or" and set the flag in the status register as well, not only in hflags. If you like you can apply the single "|=" line as a typo fix, and the rest as an additional fix to update status register as well with ERL and EXL. Regards Dirk Btw: Many thanks for commenting all patches! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Pending MIPS patches
Hi, just fyi below my list of pending MIPS patches. Not sure if all patches are ready for inclusion, but maybe they are helpful for somebody. I try to track which patches are already applied and which not. Please feel free to add, comment, discuss etc anything. Best regards Dirk Pending MIPS patches (bugs & improvements): === 1. [PATCH] Huge TLB performance improvement http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00034.html 2. [PATCH][MIPS] add "lwu" instruction http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00326.html 3. [PATCH] Add special MIPS multiply instructions http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html 4. [PATCH][MIPS] Enforce aligned pc http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00484.html 5.[PATCH 5-6/8] Mips improvements http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00314.html http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00315.html Note: Patch 7/8 was eaten by list. 6. [PATCH] Fix initial value for MIPS CP0 Config Register http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00372.html 7. [PATCH] Restructure MIPS r4k code http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00429.html Note: Pending until additional MIPS machines are added. Comment from Fabrice: I prefer to wait until there is another mips machine (e.g. Malta). Currently I see no reason to move the mips code as it is very small. 8. [PATCH] Add mips-user signal handling http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00319.html 9. [PATCH] Update MIPS status register with EXL and ERL bits at exception http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00329.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Update MIPS status register with EXL and ERL bits at exception
- Fix missing 'or' in target-mips/helper.c while update of
hflags with HFLAG_ERL
- Update status register EXL and ERL flags directly if
entering or leaving exception, not only hflags. With old
mechanism, correct status register is returned only if read
from target with mfc0 instruction. This is because value of
status register is calculated at read time using hflags.
GDB, which directly seems to read CP0_Status, doesn't get
the correct status register.
- Remove then EXL and ERL calculation based on hflags from
do_mfc0 because status register now has already the correct
value.
Signed-off-by: Dirk Behme
--- ./target-mips/op_helper.c_orig 2006-06-19 18:14:13.0 +0200
+++ ./target-mips/op_helper.c 2006-06-19 18:37:05.0 +0200
@@ -219,10 +219,6 @@ void do_mfc0 (int reg, int sel)
T0 = env->CP0_Status;
if (env->hflags & MIPS_HFLAG_UM)
T0 |= (1 << CP0St_UM);
-if (env->hflags & MIPS_HFLAG_ERL)
-T0 |= (1 << CP0St_ERL);
-if (env->hflags & MIPS_HFLAG_EXL)
-T0 |= (1 << CP0St_EXL);
rn = "Status";
break;
case 13:
--- ./target-mips/op.c_orig 2006-06-19 18:08:40.0 +0200
+++ ./target-mips/op.c 2006-06-19 18:31:40.0 +0200
@@ -1104,9 +1104,11 @@ void op_eret (void)
if (env->hflags & MIPS_HFLAG_ERL) {
env->PC = env->CP0_ErrorEPC;
env->hflags &= ~MIPS_HFLAG_ERL;
+ env->CP0_Status &= ~(1 << CP0St_ERL);
} else {
env->PC = env->CP0_EPC;
env->hflags &= ~MIPS_HFLAG_EXL;
+ env->CP0_Status &= ~(1 << CP0St_EXL);
}
env->CP0_LLAddr = 1;
}
--- ./target-mips/helper.c_orig 2006-06-19 18:09:36.0 +0200
+++ ./target-mips/helper.c 2006-06-19 18:28:23.0 +0200
@@ -332,7 +332,8 @@ void do_interrupt (CPUState *env)
} else {
env->CP0_ErrorEPC = env->PC;
}
-env->hflags = MIPS_HFLAG_ERL;
+env->hflags |= MIPS_HFLAG_ERL;
+ env->CP0_Status &= (1 << CP0St_ERL);
pc = 0xBFC0;
break;
case EXCP_MCHECK:
@@ -396,6 +397,7 @@ void do_interrupt (CPUState *env)
pc = 0x8000;
}
env->hflags |= MIPS_HFLAG_EXL;
+ env->CP0_Status |= (1 << CP0St_EXL);
pc += offset;
env->CP0_Cause = (env->CP0_Cause & ~0x7C) | (cause << 2);
if (env->hflags & MIPS_HFLAG_BMASK) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Simulation of MIPS interrupts?
Hi,
looking in cpu_exec.c at cpu_exec() there are two code
blocks which call MIPS interrupt handling code (please see
below, (a) & (b) )
When is which block called?
I ask because a simple MIPS IRQ test doesn't work for me
like I would expect. I enable interrupts in status register.
Then, using code (b), system jumps to 0xbfc00380 like
expected. My expectation would be that I now can do
everything in ISR. As long as EXL is set it locks out
interrupts globally (like done in code (b) ). Even touching
HW and raising an additional IRQ in ISR shouldn't come
through until first called ISR exits with 'eret'. This is
what is checked in code (b): As long EXL ist set,
do_interrupt() isn't called again there.
But if additional IRQ is raised while in ISR, block (a) is
called (which does no checks like code (b)), system jumps to
0xbfc00380, executes ~7-8 assembly instructions and jumps
again to 0xbfc00380 via block (a). This results in an
infinite loop. eret of first ISR is never executed:
IRQ
exec (b)
jump 0xbfc00380
do sth, issue second IRQ
IRQ
exec (a)
jump 0xbfc00380
do ~7-8 assembly instructions
exec (a)
jump 0xbfc00380
do ~7-8 assembly instructions
exec (a)
jump 0xbfc00380
do ~7-8 assembly instructions
...
Best regards
Dirk
(a)
...
#elif defined(TARGET_MIPS)
do_interrupt(env);
#elif defined(TARGET_SPARC)
...
(b)
...
#elif defined(TARGET_MIPS)
if ((interrupt_request &
CPU_INTERRUPT_HARD) &&
(env->CP0_Status & (1 << CP0St_IE)) &&
(env->CP0_Status & env->CP0_Cause &
0xFF00) &&
!(env->hflags & MIPS_HFLAG_EXL) &&
!(env->hflags & MIPS_HFLAG_ERL) &&
!(env->hflags & MIPS_HFLAG_DM)) {
/* Raise it */
env->exception_index =
EXCP_EXT_INTERRUPT;
env->error_code = 0;
do_interrupt(env);
env->interrupt_request &=
~CPU_INTERRUPT_HARD;
...
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] setting MIPS gdb breakpoints have wrong offsets
Hi, I just tried to debug some simple MIPS code using qemu-system-mipsel by setting some breakpoints. If I use gdb's break command with symbol names the breakpoints are set at offsets and therefore they are never hit. Please find an example below. I'd like to stop the program if I get an interrupt, everything looks okay. But break command sets breakpoint at 0xbfc00384 instead of 0xbfc00380. Is this a bug or feature? I use qemu-system-mipsel with some of the pending MIPS patches applied locally. If this is a bug, can anybody else reproduce this? Any idea? Best regards Dirk (gdb) info address exception Symbol "exception" is at 0xbfc00380. (gdb) list exception 158 .end cache_miss 159 160 .org 0x380 161 .ent exception 162 exception: 163 j exception_handler 164 nop 165 .end exception 166 167 / (gdb) x/2i 0xbfc00380 0xbfc00380 : b 0xbfc0046c 0xbfc00384 : nop (gdb) break exception Breakpoint 1 at 0xbfc00384: file crt0.S, line 163. (gdb) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Restructure MIPS r4k code
This patch restructures the mips_r4k.c code. Goal is to make
it easier to add additional machines in the future. Taking
ARM as example, two additional files mips_timer.c and
mips_pic.c are introduced. The corresponding code from
mips_r4k.c is moved to these files. With this, code reuse is
possible for other machines as well and unnecessary code
duplication can be avoided.
Additionally, machine is renamed from mips_machine to
mips_r4k_machine. Again, this makes it easier to add
addional mips_xxx_machines in future.
This patch has no functional changes. Only exitsting code is
moved, machine name changes and empty function
cpu_mips_irqctrl_init() is removed.
Signed-off-by: Dirk Behme
--- ./hw/mips_timer.c_orig 2006-05-24 19:31:37.0 +0200
+++ ./hw/mips_timer.c 2006-05-24 19:36:49.0 +0200
@@ -0,0 +1,75 @@
+/*
+ * MIPS timer for qemu.
+ *
+ */
+
+#include "vl.h"
+
+/* MIPS R4K timer */
+uint32_t cpu_mips_get_count (CPUState *env)
+{
+return env->CP0_Count +
+(uint32_t)muldiv64(qemu_get_clock(vm_clock),
+ 100 * 1000 * 1000, ticks_per_sec);
+}
+
+static void cpu_mips_update_count (CPUState *env, uint32_t count,
+ uint32_t compare)
+{
+uint64_t now, next;
+uint32_t tmp;
+
+tmp = count;
+if (count == compare)
+tmp++;
+now = qemu_get_clock(vm_clock);
+next = now + muldiv64(compare - tmp, ticks_per_sec, 100 * 1000 * 1000);
+if (next == now)
+ next++;
+#if 0
+if (logfile) {
+fprintf(logfile, "%s: 0x%08llx %08x %08x => 0x%08llx\n",
+__func__, now, count, compare, next - now);
+}
+#endif
+/* Store new count and compare registers */
+env->CP0_Compare = compare;
+env->CP0_Count =
+count - (uint32_t)muldiv64(now, 100 * 1000 * 1000, ticks_per_sec);
+/* Adjust timer */
+qemu_mod_timer(env->timer, next);
+}
+
+void cpu_mips_store_count (CPUState *env, uint32_t value)
+{
+cpu_mips_update_count(env, value, env->CP0_Compare);
+}
+
+void cpu_mips_store_compare (CPUState *env, uint32_t value)
+{
+cpu_mips_update_count(env, cpu_mips_get_count(env), value);
+env->CP0_Cause &= ~0x8000;
+cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
+}
+
+static void mips_timer_cb (void *opaque)
+{
+CPUState *env;
+
+env = opaque;
+#if 0
+if (logfile) {
+fprintf(logfile, "%s\n", __func__);
+}
+#endif
+cpu_mips_update_count(env, cpu_mips_get_count(env), env->CP0_Compare);
+env->CP0_Cause |= 0x8000;
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+}
+
+void cpu_mips_clock_init (CPUState *env)
+{
+env->timer = qemu_new_timer(vm_clock, &mips_timer_cb, env);
+env->CP0_Compare = 0;
+cpu_mips_update_count(env, 1, 0);
+}
--- ./hw/mips_r4k.c_orig2006-05-24 19:30:34.0 +0200
+++ ./hw/mips_r4k.c 2006-05-24 19:40:01.0 +0200
@@ -12,103 +12,9 @@
extern FILE *logfile;
-static PITState *pit;
-
-static void pic_irq_request(void *opaque, int level)
-{
-CPUState *env = first_cpu;
-if (level) {
-env->CP0_Cause |= 0x0400;
-cpu_interrupt(env, CPU_INTERRUPT_HARD);
-} else {
- env->CP0_Cause &= ~0x0400;
-cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
-}
-}
-
-void cpu_mips_irqctrl_init (void)
-{
-}
-
-/* XXX: do not use a global */
-uint32_t cpu_mips_get_random (CPUState *env)
-{
-static uint32_t seed = 0;
-uint32_t idx;
-seed = seed * 314159 + 1;
-idx = (seed >> 16) % (MIPS_TLB_NB - env->CP0_Wired) + env->CP0_Wired;
-return idx;
-}
-
-/* MIPS R4K timer */
-uint32_t cpu_mips_get_count (CPUState *env)
-{
-return env->CP0_Count +
-(uint32_t)muldiv64(qemu_get_clock(vm_clock),
- 100 * 1000 * 1000, ticks_per_sec);
-}
-
-static void cpu_mips_update_count (CPUState *env, uint32_t count,
- uint32_t compare)
-{
-uint64_t now, next;
-uint32_t tmp;
-
-tmp = count;
-if (count == compare)
-tmp++;
-now = qemu_get_clock(vm_clock);
-next = now + muldiv64(compare - tmp, ticks_per_sec, 100 * 1000 * 1000);
-if (next == now)
- next++;
-#if 0
-if (logfile) {
-fprintf(logfile, "%s: 0x%08llx %08x %08x => 0x%08llx\n",
-__func__, now, count, compare, next - now);
-}
-#endif
-/* Store new count and compare registers */
-env->CP0_Compare = compare;
-env->CP0_Count =
-count - (uint32_t)muldiv64(now, 100 * 1000 * 1000, ticks_per_sec);
-/* Adjust timer */
-qemu_mod_timer(env->timer, next);
-}
-
-void cpu_mips_store_count (CPUState *env, uint32_t value)
-{
-cpu_mips_update_count(env, value, env->CP0_Compare);
-}
-
-void cpu_mips_store_compare (CPUState *env, uint32_t value)
-{
-cpu_mips_update_count(env, cpu_mips_get_cou
Re: [Qemu-devel] [PATCH][MIPS]
Alexander Voropay wrote: The current CVS QEMU Makefile builds "qemu-system-mips" binary which really emulates a little-endian system and should be renamed to the "qemu-system-mipsel" With configure --target-list you can select mips-softmmu or mipsel-softmmu. So I think it's a good idea to extend build system to generate mips-softmmu -> qemu-system-mips (big endian) mipsel-softmmu -> qemu-system-mipsel (little endian) Has anybody a patch for this? > Is it possible to build _both_ "qemu-system-mips*" for LE and BE support > like userspace does ? I don't think so at the moment. I'm not sure what happens if both (little and big endian) targets are selected by configure. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix memory leaks in ELF loader
Fabrice Bellard wrote: Why adding several labels ? qemu_free(NULL) is perfectly valid. I would just add the missing "qemu_free(phdr)" ... Okay. Wasn't sure about this ;) Do you want a patch for "qemu_free(phdr)"? Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix overflow conditions for MIPS add/subtract
Fix overflow conditions for MIPS add/subtract as proposed by
Daniel Jacobowitz.
http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00538.html
Regards
Dirk
--- target-mips/op.c_orig 2006-04-30 09:40:46.0 +0200
+++ target-mips/op.c2006-04-30 09:41:52.0 +0200
@@ -206,7 +206,7 @@ void op_addo (void)
tmp = T0;
T0 += T1;
-if (((tmp ^ T1 ^ (-1)) & (T0 ^ T1)) >> 31) {
+if (~(T0 ^ T1) & (T0 ^ tmp) & 0x8000) {
/* operands of same sign, result different sign */
CALL_FROM_TB1(do_raise_exception_direct, EXCP_OVERFLOW);
}
@@ -225,7 +225,7 @@ void op_subo (void)
tmp = T0;
T0 = (int32_t)T0 - (int32_t)T1;
-if (((tmp ^ T1) & (tmp ^ T0)) >> 31) {
+if ((T0 ^ T1) & (T0 ^ tmp) & 0x8000) {
/* operands of different sign, first operand and result different sign
*/
CALL_FROM_TB1(do_raise_exception_direct, EXCP_OVERFLOW);
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix memory leaks in ELF loader
Fix memory leaks in ELF loader.
Regards
Dirk
--- elf_ops.h_orig 2006-05-01 09:01:47.0 +0200
+++ elf_ops.h 2006-05-01 09:09:34.0 +0200
@@ -148,7 +148,7 @@ int glue(load_elf, SZ)(int fd, int64_t v
uint8_t *data = NULL;
if (read(fd, &ehdr, sizeof(ehdr)) != sizeof(ehdr))
-goto fail;
+goto fail1;
if (must_swab) {
glue(bswap_ehdr, SZ)(&ehdr);
}
@@ -162,9 +162,9 @@ int glue(load_elf, SZ)(int fd, int64_t v
lseek(fd, ehdr.e_phoff, SEEK_SET);
phdr = qemu_mallocz(size);
if (!phdr)
-goto fail;
+goto fail2;
if (read(fd, phdr, size) != size)
-goto fail;
+goto fail2;
if (must_swab) {
for(i = 0; i < ehdr.e_phnum; i++) {
ph = &phdr[i];
@@ -181,9 +181,9 @@ int glue(load_elf, SZ)(int fd, int64_t v
data = qemu_mallocz(mem_size);
if (ph->p_filesz > 0) {
if (lseek(fd, ph->p_offset, SEEK_SET) < 0)
-goto fail;
+goto fail3;
if (read(fd, data, ph->p_filesz) != ph->p_filesz)
-goto fail;
+goto fail3;
}
addr = ph->p_vaddr + virt_to_phys_addend;
@@ -195,10 +195,13 @@ int glue(load_elf, SZ)(int fd, int64_t v
data = NULL;
}
}
+qemu_free(phdr);
return total_size;
- fail:
+ fail3:
qemu_free(data);
+ fail2:
qemu_free(phdr);
+ fail1:
return -1;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix overflow conditions for MIPS add / subtract
Daniel Jacobowitz wrote: I haven't tested the patched qemu, but I did test the expressions themselves in standalone code, and they definitely do not detect overflow. Maybe you can test Ralf's alternative proposal http://lists.gnu.org/archive/html/qemu-devel/2006-02/msg00154.html as well? Thanks Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] new MIPS instructions
Thiemo Seufer wrote: Fabrice Bellard wrote: I suggest adding a parameter to cpu_mips_init() telling the exact CPU model which is emulated. Optionnal features (such as the FPU) could be specified with an additionnal parameter. Probably with an additional switch "emulate everything we know about", which would be especially useful for usermode emulation where CPU specifics don't matter that much. Good points, but I don't know which is the best way to go ;) I think there are pros for both ways: Pro "emulate everything we know about" or "one MIPS fits all": Compile your program with a -march option you want, load the binary (or now the ELF as well ;) ) into QEMU and (if QEMU has support for the selected architecture) it will run. Without the user to select any special configuration on the command line (or tweaking inside QEMUs source code). It will run correctly without the user even to think about any special QEMU configuration. This was what I assumed before investigating why my code with a special -march option didn't work. Pro "additional parameter": FPU is a good example for this. If the processor I want to emulate has no FPU I would assume if my code uses (accidently?) FPU instructions I get exception/error/warning from QEMU. It confused me that QEMU (wrongly) executes my program with unsupported instructions (architecture) without any warning. "one MIPS fits all" is a user friendly and QEMU easy to use option, while "additional parameter" is the option for emulation accuracy. I'm not an ELF expert: Does ELF contain information about architecture compiled for? If yes, we can combine both ways above? Load ELF file, read architecture from it and let QEMU autoselect correct architecture features (or give error if not supported). Then we have emulation accuracy but don't need additional options. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add special MIPS multiply instructions
Hi,
while playing with different -march options of MIPS GCC, I
found that GCC generates some special R5400 three register
multiply assembly commands if used with -march=vr5400 (MULS,
MULHI, MACC etc.). These commands use 11 bit extended
opcodes where the lowest 6 bits are the same as for the
standard MULT/MULTU instructions (0x18 & 0x19). See for
example chapter 17.4 of
www.necelam.com/docs/files/1375_V2.pdf
Unfortunately, because QEMU uses mask 0x3F to extract
opcode, it doesn't detect these special opcodes and instead
executes the (wrong) standard ones. No exception or
warning is given. Calculation is simply wrong and program
misbehaves while working with wrong values.
Patch below adds support for these special MIPS opcodes.
Regards
Dirk
--- ./target-mips/op_helper.c_orig 2006-04-21 19:47:43.0 +0200
+++ ./target-mips/op_helper.c 2006-04-21 20:18:38.0 +0200
@@ -129,6 +129,132 @@ void do_msubu (void)
tmp = ((uint64_t)T0 * (uint64_t)T1);
set_HILO(get_HILO() - tmp);
}
+
+void do_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_msachi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_msacu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_msachiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulhi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulhiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulshi (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulshiu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
#endif
#if defined(CONFIG_USER_ONLY)
--- ./target-mips/op.c_orig 2006-04-21 19:47:43.0 +0200
+++ ./target-mips/op.c 2006-04-21 20:06:58.0 +0200
@@ -409,6 +409,146 @@ void op_msubu (void)
set_HILO(get_HILO() - tmp);
RETURN();
}
+
+void op_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+R
[Qemu-devel] MIPS patches, was: MIPS single stepping
Thiemo Seufer wrote: Stefan Weil wrote: Great, it works fine. Thanks :) FWIW, I have some rather massive MIPS update (e.g. MIPS32R2 support) in the works and hope to get it finished enough the next days to make a quilt patchset of it. I plan to integrate the other MIPS patches into it for the time being. My list of MIPS patches: MIPS Bugs: = 1. [PATCH] Fix overflow conditions for MIPS add / subtract http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00270.html *OR* [PATCH] Fix test for two's complement overflow http://lists.gnu.org/archive/html/qemu-devel/2006-02/msg00154.html (not sure which is the prefered one. Are both equal?) 2. [PATCH] MIPS CP0 not usable in kernel mode? http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00148.html 3. [PATCH] MIPS single stepping http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00336.html MIPS Improvements: == 1. [PATCH] Huge TLB performance improvement http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00034.html 2. [PATCH] Add MIPS ELF loader http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00185.html 3. [PATCH][MIPS] add "lwu" instruction http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00326.html 4. [PATCH][MIPS] add basic FPU support http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00327.html Anything missing? Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] MIPS single stepping
Hi,
patch below makes GDB single stepping for MIPS work.
For debugging (breakpoint set), in
target-mips/translate.c/gen_intermediate_code_internal()
gen_opc_pc[] isn't initialized. So in debugging case don't call
cpu_restore_state() which then accesses uninitalized
gen_opc_pc[]. do_raise_exception_direct() indirectly calls
cpu_restore_state(), do_raise_exception() doesn't.
Best regards
Dirk
--- ./target-mips/op.c_orig 2006-04-19 18:14:00.0 +0200
+++ ./target-mips/op.c 2006-04-19 18:14:29.0 +0200
@@ -604,7 +604,7 @@ void op_trap (void)
void op_debug (void)
{
- CALL_FROM_TB1(do_raise_exception_direct, EXCP_DEBUG);
+ CALL_FROM_TB1(do_raise_exception, EXCP_DEBUG);
}
void op_set_lladdr (void)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
Thiemo Seufer wrote:
Updated version, note that this is still not suitable for CVS since
x86 fails to build with it.
fyi: for me, arm-softmmu fails as well:
.../qemu/qemu-snapshot-2006-03-30_23/target-arm/op.c
gcc: unrecognized option '-preferred-stack-boundary=2'
/qemu/qemu-snapshot-2006-03-30_23/target-arm/op_mem.h: In
function ‘op_vfp_std_kernel’:
/qemu/qemu-snapshot-2006-03-30_23/target-arm/op_mem.h:66:
error: unable to find a register to spill in class
‘GENERAL_REGS’
/qemu/qemu-snapshot-2006-03-30_23/target-arm/op_mem.h:66:
error: this is the insn:
(insn:HI 44 43 45 2
/qemu/qemu-snapshot-2006-03-30_23/cpu-all.h:342 (set (mem:DI
(plus:SI (reg/v:SI 59 [ addr ])
(reg:SI 73 [ .addend ])) [0 S8 A64])
(reg:DI 63 [ .vfp.tmp0d ])) 57 {*movdi_2}
(insn_list:REG_DEP_TRUE 43 (nil))
(expr_list:REG_DEAD (reg:DI 63 [ .vfp.tmp0d ])
(expr_list:REG_DEAD (reg/v:SI 59 [ addr ])
(expr_list:REG_DEAD (reg:SI 73 [
.addend ])
(nil)
/qemu/qemu-snapshot-2006-03-30_23/target-arm/op_mem.h:66:
confused by earlier errors, bailing out
make[1]: *** [op.o] Error 1
make[1]: Leaving directory
`/qemu/qemu-snapshot-2006-03-30_23/arm-softmmu'
make: *** [all] Error 1
gcc -v
...
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
Dirk
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Alexander Voropay wrote: I'm trying to implement a mips_bios, unfortunately, quemu seems can't run a code at the 0xbfc0 region. See a http://pastebin.com/628591 The conventional 'move k0,zero' instruction (line 35) causes an general exceprion to 0xbfc00380, see line 70 Try to change the following lines in hw/mips_r4k.c: //#define KERNEL_LOAD_ADDR 0x8001 #define KERNEL_LOAD_ADDR 0xBFC0 //cpu_register_physical_memory(0, ram_size, IO_MEM_RAM); cpu_register_physical_memory(0x1fc0, ram_size, IO_MEM_RAM); //kernel_size = load_image(kernel_filename, //phys_ram_base + (kernel_base - 0x8000)); kernel_size = load_image(kernel_filename, phys_ram_base); Works for me: (gdb) p/x $pc $1 = 0xbfc0 (gdb) x/2i $pc 0xbfc0 <_start>:b 0xbfc00400 0xbfc4 <_start+4>: nop (gdb) x/2i 0x1fc0 0x1fc0: b 0x1fc00400 0x1fc4: nop (gdb) Best regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Thiemo Seufer wrote: On Tue, Mar 28, 2006 at 08:57:15AM +0200, Dirk Behme wrote: What about the patch in attachment? It first tries to load image as an ELF file. If this fails it falls back to raw image load. Additionally, it takes feature of patch above to go on even if no BIOS is found. A slightly more polished version with less noisy messages is appended. It also adjusts the ramdisk load address to physical addressing, similiar to the binary kernel load. One question I just found: If we go on if no BIOS is found/executed and we load some stuff to e.g. 0x8001, where is the default address translation made? As I understand MIPS, code in kseg0 (0x8000) and kseg1 (0xA000) should be executable without MMU/TLB setup because it is mapped by default to physical 0x0. But looks to me that I get a cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 for it. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Single stepping MIPS in GDB
Hi,
answering to myself again ;)
Now, I found where the PC is wrongly set to 0x0:
In translate-all.c, end of function cpu_restore_state() (lines
with '+' are debug output added):
#elif defined(TARGET_MIPS)
+printf("PC before: 0x%08x, j: %d, OPC_BUF_SIZE: %d\n",
env->PC, j, OPC_BUF_SIZE);
+for(c = 0; c < OPC_BUF_SIZE; c++)
+ printf("OPC %03d: 0x%08x\n", c, gen_opc_pc[c]);
env->PC = gen_opc_pc[j];
+printf("PC after: 0x%08x\n", env->PC);
env->hflags &= ~MIPS_HFLAG_BMASK;
env->hflags |= gen_opc_hflags[j];
#endif
results in the following output (0x80010400 is the correct one):
PC before: 0x80010400, j: -8185, OPC_BUF_SIZE: 512
OPC 000: 0x
OPC 001: 0x
...
OPC 510: 0x
OPC 511: 0x
PC after: 0x
If I temporarily delete the line "env->PC = gen_opc_pc[j];"
single stepping seems to work.
Seems that gen_opc_pc is all 0, and j looks strange. But I
don't know whats wrong here? ;(
Best regards
Dirk
Dirk Behme wrote:
I try to debug some low level system init code on MIPS
as well. For this, I use qemu-snapshot-2006-03-21_23 because this
already includes little endian MIPS (--target-list=mipsel-softmmu). I
can load my program to MIPS default start address 0x8001, use
mipsel-linux-gdb to attach to it and load symbols. Start address is
set correctly. But seems that I have trouble single stepping (si). I
would assume that with first si system should jump to 0x80010400
(please find some debug output below). Instead, PC is set to 0x0.
*1* Debug output for single step at startup. PC is set to 0x0 instead
to next command at 0x80010400
_start ()
at uboot/u-boot-1.1.4/cpu/mips/start.S:43
43 RVECENT(reset,0)/* U-boot entry point */
(gdb) p/x $pc
$1 = 0x8001
(gdb) x/2i $pc
0x8001 <_start>:b 0x80010400
0x80010004 <_start+4>: nop
(gdb) si
0x in ?? ()
(gdb) p/x $pc
$2 = 0x0
(gdb)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Single stepping MIPS in GDB
Hi, if nobody has an idea regarding this, any hint where to search or how to debug this the best way? What confuses me is that qemu.log correctly shows pc=0x80010400 but qemu monitor register info and GDB show pc=0. Thanks Dirk Dirk Behme wrote: Hi, now, after ARM, I try to debug some low level system init code on MIPS as well. For this, I use qemu-snapshot-2006-03-21_23 because this already includes little endian MIPS (--target-list=mipsel-softmmu). I can load my program to MIPS default start address 0x8001, use mipsel-linux-gdb to attach to it and load symbols. Start address is set correctly. But seems that I have trouble single stepping (si). I would assume that with first si system should jump to 0x80010400 (please find some debug output below). Instead, PC is set to 0x0. If I start program with 'continue' in gdb, seems that program starts to run correctly. After stop at random location with ctrl-c in gdb, the following single steps seem to fail as well (please see below as well). Any hints what I'm making wrong here? Many thanks Dirk *1* Debug output for single step at startup. PC is set to 0x0 instead to next command at 0x80010400 _start () at uboot/u-boot-1.1.4/cpu/mips/start.S:43 43 RVECENT(reset,0)/* U-boot entry point */ (gdb) p/x $pc $1 = 0x8001 (gdb) x/2i $pc 0x8001 <_start>:b 0x80010400 0x80010004 <_start+4>: nop (gdb) si 0x in ?? () (gdb) p/x $pc $2 = 0x0 (gdb) /tmp> cat qemu.log pc=0x8001 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 cpu_mips_handle_mmu_fault address=8001 ret 0 physical 0001 prot 3 pc=0x8001 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: 0x8001: b 0x80010400 0x80010004: nop OP: 0x: goto_tb0 0x0001: save_pc 0x80010400 0x0002: set_T0 0x829ce00 0x0003: exit_tb 0x0004: reset_T0 0x0005: exit_tb 0x0006: end 2 0002 OUT: [size=24] 0x08a9ce00: jmp0xa4ab0b4 0x08a9ce05: movl $0x80010400,0x80(%ebp) 0x08a9ce0f: mov$0x829ce00,%ebx 0x08a9ce14: ret 0x08a9ce15: xor%ebx,%ebx 0x08a9ce17: ret Trace 0x08a9ce00 [8001] pc=0x80010400 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x pc=0x80010400 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: OP: 0x: save_pc 0x80010400 0x0001: debug 0x0002: end 2 0002 OUT: [size=21] 0x08a9ce20: movl $0x80010400,0x80(%ebp) 0x08a9ce2a: push $0x10002 0x08a9ce2f: call 0x80866c0 0x08a9ce34: pop%eax Trace 0x08a9ce20 [80010400] search pc 1 -
[Qemu-devel] [PATCH] Add MIPS ELF loader
Hi,
ELF loader feature for MIPS in patch
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00033.html
was rejected because it breaks loading of raw kernel images:
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00082.html
What about the patch in attachment? It first tries to load
image as an ELF file. If this fails it falls back to raw
image load. Additionally, it takes feature of patch above to
go on even if no BIOS is found.
Regards
Dirk
--- ./hw/mips_r4k.c_orig2006-03-28 07:48:21.0 +0200
+++ ./hw/mips_r4k.c 2006-03-28 08:52:18.0 +0200
@@ -5,6 +5,30 @@
#define KERNEL_LOAD_ADDR 0x8001
#define INITRD_LOAD_ADDR 0x8080
+#include "disas.h"
+
+#define ELF_CLASS ELFCLASS32
+#ifdef TARGET_WORDS_BIGENDIAN
+# define ELF_DATAELFDATA2MSB
+#else
+# define ELF_DATAELFDATA2LSB
+#endif
+#define ELF_ARCHEM_MIPS
+
+#include "elf.h"
+
+#ifndef BSWAP_NEEDED
+#define bswap_ehdr32(e) do { } while (0)
+#define bswap_phdr32(e) do { } while (0)
+#define bswap_shdr32(e) do { } while (0)
+#define bswap_sym32(e) do { } while (0)
+#endif
+
+#define SZ 32
+#define elf_worduint32_t
+#define bswapSZs bswap32s
+#include "elf_ops.h"
+
extern FILE *logfile;
static PITState *pit;
@@ -101,6 +125,83 @@ void cpu_mips_clock_init (CPUState *env)
cpu_mips_update_count(env, 1, 0);
}
+static int load_mips_kernel_elf(const char *filename, elf_word *entry)
+{
+struct elf32_hdr ehdr;
+int retval, fd, i;
+Elf32_Half machine;
+
+fd = open(filename, O_RDONLY | O_BINARY);
+if (fd < 0)
+ goto error;
+
+retval = read(fd, &ehdr, sizeof(ehdr));
+if (retval < 0)
+ goto error;
+
+if (ehdr.e_ident[0] != 0x7f || ehdr.e_ident[1] != 'E'
+ || ehdr.e_ident[2] != 'L' || ehdr.e_ident[3] != 'F')
+ goto error;
+machine = tswap16(ehdr.e_machine);
+if (machine == EM_MIPS) {
+ struct elf32_phdr phdr;
+
+ bswap_ehdr32(&ehdr);
+
+ *entry = ehdr.e_entry;
+ retval = lseek(fd, ehdr.e_phoff, SEEK_SET);
+ if (retval < 0)
+ goto error;
+
+ for (i = 0; i < ehdr.e_phnum; i++) {
+ retval = read(fd, &phdr, sizeof(phdr));
+ if (retval < 0)
+ goto error;
+ bswap_phdr32(&phdr);
+ if (phdr.p_type == PT_LOAD) {
+ uint8_t *addr;
+ size_t sz = phdr.p_filesz;
+
+ if (phdr.p_vaddr < 0x8000
+ || phdr.p_memsz > 0x2000
+ || (phdr.p_vaddr < 0xa000 && (phdr.p_vaddr +
+phdr.p_memsz) >= 0xa000)
+ || (phdr.p_vaddr < 0xc000 && (phdr.p_vaddr +
+phdr.p_memsz) >= 0xc000))
+ goto error;
+ addr = (uint8_t *)(phys_ram_base + (phdr.p_vaddr & 0x1fff));
+ retval = lseek(fd, phdr.p_offset, SEEK_SET);
+ if (retval < 0)
+ goto error;
+ while (sz) {
+ retval = read(fd, addr, sz);
+ switch (retval) {
+ case -1:
+ goto error;
+ case 0: /* EOF */
+ if (sz)
+ goto error;
+ break;
+ default:
+ if (sz < retval)
+ goto error;
+ sz -= retval;
+ retval = 0;
+ break;
+ }
+ }
+ }
+ }
+ load_symbols32(&ehdr, fd);
+}
+
+close(fd);
+return retval;
+error:
+close(fd);
+return -1;
+}
+
static void io_writeb (void *opaque, target_phys_addr_t addr, uint32_t value)
{
#if 0
@@ -191,12 +292,12 @@ void mips_r4k_init (int ram_size, int vg
char buf[1024];
target_ulong kernel_base, kernel_size, initrd_base, initrd_size;
unsigned long bios_offset;
+elf_word entry = 0;
int io_memory;
int linux_boot;
int ret;
CPUState *env;
-printf("%s: start\n", __func__);
linux_boot = (kernel_filename != NULL);
env = cpu_init();
@@ -204,47 +305,59 @@ void mips_r4k_init (int ram_size, int vg
/* allocate RAM */
cpu_register_physical_memory(0, ram_size, IO_MEM_RAM);
+
+/* Try to load a BIOS image. If this fails, we continue regardless */
bios_offset = ram_size + vga_ram_size;
snprintf(buf, sizeof(buf), "%s/%s", bios_dir, BIOS_FILENAME);
-printf("%s: load BIOS '%s' size %d\n", __func__, buf, BIOS_SIZE);
ret = load_image(buf, phys_ram_base + bios_offset);
-if (ret != BIOS_SIZE) {
-fprintf(stderr, "qemu: could not load MIPS bios '%s'\n", buf);
-exit(1);
+if (ret == BIOS_SIZE) {
+ cpu_register_physical_memory((uint32_t)(0x1fc0),
+BIOS_SIZE, bios_offset | IO_MEM_ROM);
+ env->PC = 0xBFC0;
+ printf("qemu: successfully loaded BIOS '%s' size
[Qemu-devel] Single stepping MIPS in GDB
Hi, now, after ARM, I try to debug some low level system init code on MIPS as well. For this, I use qemu-snapshot-2006-03-21_23 because this already includes little endian MIPS (--target-list=mipsel-softmmu). I can load my program to MIPS default start address 0x8001, use mipsel-linux-gdb to attach to it and load symbols. Start address is set correctly. But seems that I have trouble single stepping (si). I would assume that with first si system should jump to 0x80010400 (please find some debug output below). Instead, PC is set to 0x0. If I start program with 'continue' in gdb, seems that program starts to run correctly. After stop at random location with ctrl-c in gdb, the following single steps seem to fail as well (please see below as well). Any hints what I'm making wrong here? Many thanks Dirk *1* Debug output for single step at startup. PC is set to 0x0 instead to next command at 0x80010400 _start () at uboot/u-boot-1.1.4/cpu/mips/start.S:43 43 RVECENT(reset,0)/* U-boot entry point */ (gdb) p/x $pc $1 = 0x8001 (gdb) x/2i $pc 0x8001 <_start>:b 0x80010400 0x80010004 <_start+4>: nop (gdb) si 0x in ?? () (gdb) p/x $pc $2 = 0x0 (gdb) /tmp> cat qemu.log pc=0x8001 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 cpu_mips_handle_mmu_fault address=8001 ret 0 physical 0001 prot 3 pc=0x8001 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: 0x8001: b 0x80010400 0x80010004: nop OP: 0x: goto_tb0 0x0001: save_pc 0x80010400 0x0002: set_T0 0x829ce00 0x0003: exit_tb 0x0004: reset_T0 0x0005: exit_tb 0x0006: end 2 0002 OUT: [size=24] 0x08a9ce00: jmp0xa4ab0b4 0x08a9ce05: movl $0x80010400,0x80(%ebp) 0x08a9ce0f: mov$0x829ce00,%ebx 0x08a9ce14: ret 0x08a9ce15: xor%ebx,%ebx 0x08a9ce17: ret Trace 0x08a9ce00 [8001] pc=0x80010400 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x pc=0x80010400 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: OP: 0x: save_pc 0x80010400 0x0001: debug 0x0002: end 2 0002 OUT: [size=21] 0x08a9ce20: movl $0x80010400,0x80(%ebp) 0x08a9ce2a: push $0x10002 0x08a9ce2f: call 0x80866c0 0x08a9ce34: pop%eax Trace 0x08a9ce20 [80010400] search pc 1 pc=0x80010400 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 000
Re: [Qemu-devel] Debugging low level ARM with GDB
Paul Brook wrote:
If I load the binary version of image u-boot.bin into QEMU,
how does QEMU know to which start address the image was
linked to? Or do I have to load the ELF file?
qemu assumes it's loading a raw binary kernel zImage. Currently it is loaded
at 0x1. The linux kernel don't care where they are loaded, so this may
change in the future.
If you configure u-boot for a base address of 0x1000 it will probably work.
Thanks!
I linked u-boot to 0x1 and it was loaded correctly:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x in ?? ()
(gdb) info register
r0 0x0 0
...
pc 0x0 0
fps0x0 0
cpsr 0x41d3 1073742291
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) disassemble 0x1
Dump of assembler code for function _start:
0x0001 <_start+0>: b 0x10050
...
But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
(0x1)? Adding
env->regs[15] = KERNEL_LOAD_ADDR;
in hw/integratorcp.c after load_image(kernel_filename,...)
did the job:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
_start ()
at u-boot-1.1.4/cpu/arm926ejs/start.S:54
54 b reset
(gdb) info registers
r0 0x0 0
...
lr 0x0 0
pc 0x1 65536
fps0x0 0
cpsr 0x41d3 1073742291
(gdb) disassemble
Dump of assembler code for function _start:
0x0001 <_start+0>: b 0x10050
...
and si works. Do I still miss anything here?
Then I tried the other way around: Instead of adapting
u-boot, it should be possible to adapt hw/integratorcp.c to
the address u-boot is linked to by default. This is
0x1108. For my changes see below. With this, I get
> qemu-system-arm -S -s -kernel u-boot.bin -m 64
qemu: could not load kernel 'u-boot.bin'
Any ideas? Maybe anything with phys_ram_base? Do I have to
adjust
kernel_size = load_image(kernel_filename,
phys_ram_base + KERNEL_LOAD_ADDR);
as well?
Best regards
Dirk
--- ./hw/integratorcp.c_orig2006-03-24
16:40:23.0 +0100
+++ ./hw/integratorcp.c 2006-03-24 16:39:35.0 +0100
@@ -10,7 +10,8 @@
#include
#define KERNEL_ARGS_ADDR 0x100
-#define KERNEL_LOAD_ADDR 0x0001
+//#define KERNEL_LOAD_ADDR 0x0001
+#define KERNEL_LOAD_ADDR 0x1108
#define INITRD_LOAD_ADDR 0x0080
/* Stub functions for hardware that doesn't exist. */
@@ -1188,7 +1189,7 @@ static void integratorcp_init(int ram_si
/* ??? On a real system the first 1Mb is mapped as
SSRAM or boot flash. */
/* ??? RAM shoud repeat to fill physical memory space. */
/* SDRAM at address zero*/
-cpu_register_physical_memory(0, ram_size, IO_MEM_RAM);
+cpu_register_physical_memory(KERNEL_LOAD_ADDR,
ram_size, IO_MEM_RAM);
/* And again at address 0x8000 */
cpu_register_physical_memory(0x8000, ram_size,
IO_MEM_RAM);
@@ -1223,6 +1224,7 @@ static void integratorcp_init(int ram_si
fprintf(stderr, "qemu: could not load kernel
'%s'\n", kernel_filename);
exit(1);
}
+env->regs[15] = KERNEL_LOAD_ADDR;
if (initrd_filename) {
initrd_size = load_image(initrd_filename,
phys_ram_base +
INITRD_LOAD_ADDR);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Debugging low level ARM with GDB
Paul Brook wrote: But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR (0x1)? What makes you think ti's wrong? There's a small bootloader built into qemu. Uups. Then it seems that I start things the wrong way. I start QEMU with -S -s, then I attach GDB, and GDB "complains" that PC is at 0x0 (and not 0x1). How do I have to invoke things in the correct way (and that this bootloader is used) so that system is at 0x1 if I attach GDB and can start with si debugging from there? Then I tried the other way around: Instead of adapting u-boot, it should be possible to adapt hw/integratorcp.c to the address u-boot is linked to by default. This is 0x1108. For my changes see below. With this, I get You're obviously using the wrong u-boot config then. 0x1108 isn't even a RAM address. Yes, seems that I was unclear here. Sorry. It's for an other board. Take this question as the first step for a new machine description using integrator as an example. Thanks for your help and patience! Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Debugging low level ARM with GDB
Hello, I'd like to debug low level ARM bootloader U-Boot using ARM port of QEMU. I use qemu-0.8.0-i386.tar.gz for this and start QEMU with qemu-system-arm -S -s -m 64 -net none -nographic -kernel u-boot.bin -monitor null -parallel null -serial null Waiting gdb connection on port 1234 (Note: u-boot.bin is the binary one, u-boot used below is the ELF version) In another window I start ARM gdb, but seems that I'm not able to step, disassemble etc: uboot/u-boot-1.1.4> arm-linux-gdb GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux". (gdb) file u-boot Reading symbols from uboot/u-boot-1.1.4/u-boot...done. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x in ?? () (gdb) info r r0 0x0 0 r1 0x0 0 ... r120x0 0 sp 0x0 0 lr 0x0 0 pc 0x0 0 fps0x0 0 cpsr 0x41d3 1073742291 (gdb) disassemble No function contains program counter for selected frame. (gdb) s Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) c Continuing. [pressing ctrl-c] Program received signal 0, Signal 0. 0x00018468 in ?? () (gdb) s Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) info r r0 0xfffecf00 -78080 r1 0x0 0 r2 0x100256 r3 0x0 0 ... r6 0x0 0 r7 0x4001024 r8 0x0 0 ... r110x0 0 r120x18064 98404 sp 0x0 0 lr 0x180f4 98548 pc 0x18468 99432 fps0x0 0 cpsr 0x61d3 1610613203 (gdb) What do I miss here? Seems that program did something, but I'm not able to debug it. Two additional questions: If I load the binary version of image u-boot.bin into QEMU, how does QEMU know to which start address the image was linked to? Or do I have to load the ELF file? If my program wants to access the serial ports, how do I have to configure the serial driver in my program to access these ports? E.g. which base address do I have to use in the serial driver? In real HW they differ from chip to chip. Many thanks and best regards, Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
