Re: [Qemu-devel] qemu-1.6.0 under Cygwin64 ./configure failed
Trying to buld qemu 1.6.0 with MinGW64 unger Cygwin64. Basically it works with current `configure` script but linker requres alot of libraries built for MinGW64 $ export CC=x86_64-w64-mingw32-gcc $ ./configure --target-list=arm-softmmu --disable-strip --disable-xen --disable-kvm --disable-user --disable-docs ,,, ,,, $ make ... ... LINK qemu-img.exe /usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lgthread-2.0 /usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lglib-2.0 /usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lintl /usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -liconv /usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lpcre collect2: error: ld returned 1 exit status /home/USER/qemu-1.6.0/rules.mak:60: recipe for target `qemu-img.exe' failed make: *** [qemu-img.exe] Error 1 2013/9/24 Alexander Voropay alexander.voro...@gmail.com Hi! Can anyone please correct a building qemu-1.6.0 under Cygwin64 ? ./configure reports non-working cc . The gcc is installed and working $ uname -a CYGWIN_NT-6.1 MYWIN-A2 1.7.25(0.270/5/3) 2013-08-31 20:37 x86_64 Cygwin configure.log is attached, All pre-defined macros are attached (gcc -dM -E - /dev/null) -- -=AV=-
Re: [Qemu-devel] qemu-1.6.0 under Cygwin64 ./configure failed
2013/9/24 Eric Blake ebl...@redhat.com -mno-cygwin is an obsolete command line option, formerly used for cross-compiling from cygwin to mingw. It is NOT used when building for cygwin, and these days, building for mingw should use a proper cross compiler (available from cygwin.com) rather than the -mno-cygwin crutch. To me, this means that there is some cruft in the configure file, and that no one has ever really tried to port qemu to cygwin yet. It seems, the QEMU autotool-based build system just not recognize Cygwin64. As far as I remember, I used Cygwin32 a year ago under Windows XP 32 and it worked.
Re: [Qemu-devel] Qemu and Linux 2.4
[EMAIL PROTECTED] wrote:
- QEMU malta emulation is not really complete, to put it mildly
Out of curiosity, what parts did you miss?
Like, for example, the PCI stuff. So I can use the network card.
PCI stuff in the QEMU/Malta works fine, but pseudo-bootrom
does not perform PCI enumeration and leaves uninitialized PCI BARs.
Linux MIPS/Malta 2.4 can not perform PCI enumeration too. The LANCE
Ethernet driver *requres* a pre-initialized BARs. The situation even worse,
since current Linux 2.4 can't be even built with NEW_PCI and PCI_AUTO
options at all (due to linkage error).
http://www.linux-mips.org/wiki/PCI_Subsystem
There is the same PCI problem with NetBSD/evbmips and seems VxWorks/Malta.
And yes, I am aware of YAMON.
AFAIK, YAMON may runs on the MIPS hardware only, and may not
be redistribuded in the source or binary form.
Anyway, YAMON binary does not work on the Qemu/Malta. The Galileo
chip is far more complicated then Qemu emulation. It contains four DMA
channels, four timers e.t.c. e.t.c.
I recommend to improve the Qemu Malta emulation, and make it work with
2.4 Malta kernels. (ISTR it used to work, so it shouldn't need a lot to
get there.)
I'm sure that improving the Qemu Malta emulation is a very noble goal,
but for people that need a working 2.4 kernel NOW, my patch could be
useful. Having the QEMU target in 2.6 surely helped me.
The only thing we need is a good bootrom (BIOS) for the MIPS/Malta
(Free-YAMON ;)
As a quick'n'disty solution you could initialize PCI BARs of the
device number 12 (0x0b, LANCE) with GDB:
(gdb) set variable {int}0xbbe00cf8=0x80005810 --- I/O address
(gdb) set variable {int}0xbbe00cfc=0x2001
(gdb) set variable {int}0xbbe00cf8=0x80005814 --- Mem address
(gdb) set variable {int}0xbbe00cfc=0xfc20
(gdb) set variable {int}0xbbe00cf8=0x80005804 --- Enable Mem and I/O
(gdb) set variable {int}0xbbe00cfc=0x0003
(gdb) set variable {int}0xbbe00cf8=0x8000583c IRQ=10 tied to Pin A
(gdb) set variable {int}0xbbe00cfc=0xff06010a
(gdb) cont
Continuing.
...
Linux version 2.4.35.3 ([EMAIL PROTECTED]) (gcc version 3.3.6) #2 Tue Sep 25
18:59:10 MSD 2007
...
pcnet32.c:v1.30h 06.24.2004 [EMAIL PROTECTED]
pcnet32: PCnet/PCI II 79C970A at 0x2000, 52 54 00 12 34 56 assigned IRQ 10.
eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found.
...
# lspci -v
00:0b.0 Class 0200: 1022:2000 (rev 10)
Flags: bus master, fast devsel, latency 64, IRQ 10
I/O ports at 2000 [size=32]
Memory at fc20 (32-bit, non-prefetchable) [size=32]
# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
#
# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=4.2 ms
--
-=AV=-
***
This message and any attachments (the message) are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. Orange Business Services shall not be
liable for the message if altered, changed or
falsified. If you are not the intended addressee of this message, please cancel it immediately and inform
the sender.
***
Re: [Qemu-devel] Current CVS build errors on RH9
Mulyadi Santosa [EMAIL PROTECTED] wrote: /home/wine/qemu/vl.c:59:24: linux/hpet.h: No such file or directory /home/wine/qemu/vl.c: In function `hpet_start_timer': /home/wine/qemu/vl.c:1222: storage size of `info' isn't known /home/wine/qemu/vl.c:1230: `HPET_IRQFREQ' undeclared (first use in this function) Got that messages too when I try to rebuild the CVS version about 3-4 days ago on my RH9 box. IMHO the reason is: no tg_kill syscall and hpet exists on RH 9. However, I successfully build the same CVS version on FC2. The same problem exists on the RedHat RHEL 4 (deriviated from the FC 3). -- -=AV=- *** Это сообщение и любые вложения являются конфиденциальными и предназначенными исключительно для адресатов. Любое неуполномоченное использование или распространение запрещено. Сообщения могут быть изменены. Компания Orange Business Services не несёт ответственности за изменение или фальсификацию сообщений. Если Вы не являетесь получателем данного сообщения, пожалуйста сообщите об этом отправителю и удалите это сообщение. *** This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. Orange Business Services shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ***
[Qemu-devel] [Experimental PATCH]: MIPS Malta YAMON for NetBSD
Hi! This patch add a simply YAMON services ( print() and print_count() ) to Malta pseudo-loader. This services are requred for NetBSD to run. As a result, an *unmodified* NetBSD 3.0 kernel starts to work but hangs very early on the PCNET PCI Ethernet (IRQ=0). The PCI is not initialized and NetBSD Malta does not contains a PCI fuxup routines. P.S. The Malta bootloader must acts as PCI BIOS to run NetBSD 3.0 and Linux 2.4 . $ qemu-system-mipsel -M malta -nographic -cpu 4Kc -kernel ../Malta/netbsd-MALTA Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 /proc/sys/dev/rtc/max-user-freq' as root. MIPS32/64 params: cpu arch: 32 MIPS32/64 params: TLB entries: 16 MIPS32/64 params: Icache: line = 16, total = 2048, ways = 2 sets = 64 MIPS32/64 params: Dcache: line = 16, total = 2048, ways = 2 sets = 64 picache_stride= 1024 picache_loopcount = 2 pdcache_stride= 1024 pdcache_loopcount = 2 Timer calibration: 199945600 cycles/sec [(6198300, 6298300) * 16] Loaded initial symtab at 0x802dab24, strtab at 0x802ec834, # entries 4473 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 3.0 (MALTA) #0: Sun Dec 18 23:01:15 UTC 2005 [EMAIL PROTECTED]:/home/builds/ab/netbsd-3-0-RELEASE/evbmips-mipsel/200512182024Z-obj/home/builds/ab/netbsd-3-0-RELEASE/src/sys/arch/evbmips/compile/MALTA total memory = 128 MB avail memory = 121 MB mainbus0 (root) cpu0 at mainbus0: 199.94MHz (hz cycles = 999728, delay divisor = 100) cpu0: MIPS 4Kc (0x18000) Rev. 0 with software emulated floating point cpu0: 2KB/16B 2-way set-associative L1 Instruction cache, 16 TLB entries cpu0: 2KB/16B 2-way set-associative write-back L1 Data cache gt0 at mainbus0 addr 0x1be0 pci0 at gt0 pci0: i/o space, memory space enabled Galileo (Marvell) Technology GT-64120 System Controller (miscellaneous memory, revision 0x10) at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 10 function 0 pcib0: Intel 82371AB (PIIX4) PCI-ISA Bridge, (rev . 0x00) pciide0 at pci0 dev 10 function 1 pciide0: Intel 82371SB (PIIX3) IDE Interface (rev. 0x00) pciide0: device disabled (at device) uhci0 at pci0 dev 10 function 2: Intel 82371SB (PIIX3) USB Host Controller (rev. 0x01) uhci0: can't map i/o space Intel 82371AB (PIIX4) Power Management Controller (miscellaneous bridge) at pci0 dev 10 function 3 not configured pcn0 at pci0 dev 11 function 0: AMD PCnet-PCI Ethernet pcn0: Unknown PCnet-PCI variant rev 7, Ethernet address 00:00:00:00:00:00 panic: pcib_isa_intr_string: bogus isa irq 0x0 Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x4:jr ra bdslot: nop db -- -=AV=- malta_yamon.diff Description: Binary data
[Qemu-devel] [PATCH] MIPS Malta/YAMON SP initialization
Hi! This patch adds SP initialization fot the Malta YAMON pseudo-loader. It allows to run standalone (written in C) applications: http://www.nwpi.ru/~alec/mips/yamon_test_salone.tgz $ qemu-system-mipsel -nographic -M malta -kernel yamon_test.elf Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 /proc/sys/dev/rtc/max-user-freq' as root. YAMON TEST argc = 0002 argv = 80002000 argv[] = yamon_test.elf argv[0001] = envp = 80002008 envp-name = memsize envp-val = 134217728 envp-name = modetty0 envp-val = 38400n8r memsize = 0800 -- -=AV=- malta-stack.patch Description: Binary data
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Thiemo Seufer [EMAIL PROTECTED] wrote: For the AR7 case, could you - add AR7 as a CPU type - handle the interesting cases for AR7 only, after verifying the cornercase behaviour of qemu and real hardware is consistent. AFAIK, Texas Instrument AR7 isn't a CPU. It's a SoC which combines well-known MIPS 4KEc synthesizable *core* and ADSL stuff. http://www.linux-mips.org/wiki/AR7 -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] MIPS Malta-bootloader replacement
Hi! This patch replaces hardcoded MIPS Malta bootloader with soft version. This preserves ROM area clean. Also it initializes MIPS $sp register as YAMON does. The GPR values before execution: === less /tmp/qemu.log === pc=0x80294040 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 0002 a1 80002000 a2 80002008 a3 0800 ... GPR28: gp sp 80003ff8 s8 ra CP0 Status 0x0044 Cause 0x0400 EPC0x Config0 0x8082 Config1 0x9e190c8b LLAddr 0x -- -=AV=- malta-bootloader.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu on Cygwin
Johannes Schindelin [EMAIL PROTECTED] wrote: Did anyone try the latest CVS qemu on Cygwin ? AFAICT this is due to SDL. I did not succeed in compiling any SDL related stuff in cygwin, but then, I did not really try, since the MinGW compilation is easy enough. I've successfully compiled SDL 1.2.11 on the fresh-installed Cygwin 1.5.24. The following test SDL application works: http://www.cse.nd.edu/courses/cse20211/www/code/sdl.html The SDL/test contains a bunch of SDL testing applications. Most of them works too, even sound- and OpenGL related. -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC] IRQ acknowledge on MIPS
Aurelien Jarno [EMAIL PROTECTED] wrote: Then after playing with the current code, I am sure we are missing a simple interrupt controller for the MIPS CPU. It supports 6 hardware interrupts (IP2 to IP7) and we are using two of them in the current emulation: one for the i8259a and the other for the timer. In both case the current code assert and deassert a CPU_INTERRUPT_HARD. The Galileo GT64xxx chip contains an interrupt controller too (for DMA cycle indication, built-in Timers e.t.c.). All this interrupt controllers are daisy-chained: i8259(as part of the PIIX + PCI), GT64xxx and MIPS internal. P.S. It should be good to have a well-defined modular IRQ routing architecture in the Qemu. Moreover, modern ix86 LAPIC/APIC interrupt controller even more complicated. -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Change the 82371SB PCI-to-ISA bridge into a82371EB
Aurelien Jarno [EMAIL PROTECTED] wrote: This patch changes the 82371SB PCI-to-ISA bridge into a 82371EB. Note that the ACPI controller implemented in QEMU is already a 82371EB. Shouldn't we also change all piix3 names to piix4 ? [qemu]$ find . -type f | xargs grep piix3 | wc -l 18 -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] qemu-mips: mips_bios.bin vs mipsel_bios.bin
Hi! This patch corrects mips*_bios.bin names. It allows to use arbitrary BIOS file size also. -- -=AV=- mips_bios.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] New display device for MIPS
Thiemo Seufer [EMAIL PROTECTED] wrote: AFAICS the output interferes with the serial console output. I wonder how the typical scrolling text Linux on MALTA would look like in that case. :-) What about starting with the core of the new machine description before submitting the unconnected peripherals? The Malta-LED is a part of the Malta-FPGA device wich also contains - DIP-Switch block, including BIGEND switch - NMI status register - Software reset - GPIO registers - I2C registers Is should be better to implement all this devices as one Malta FPGA driver. P.S. AFAIK, Virtio VPMM emulates Malta LED in the separate graphic window, not on the serial port. -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] MIPS timer
Hi! This patch separates MIPS CPU timer and R4K machine, please review. It's required to add a new MIPS machines. -- -=AV=- mipstimer.diff Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] MIPS: UART access w/o -kernel option
Alexander Voropay wrote: I'm still trying to run a MIPS mmon as a BIOS :) I've found one strange issue : when it runs at the KSEG0 region (0x80008000) with -kernel option it works fine. When I'm trying to run it in the MIPS BIOS region (0xbfc0) it can't output anything to the UART and Qemu segfaults on the any keypress (not my program, but whole Qemu !) I've found this bug : hw/mips_r4k.c:mips_r4k_init() Qemu/MIPS does not initialize an ISA memory region when issued without -kernel option. (I've added some debug output). Whith -kernel: cpu_register_physical_memory: start=, size=0800, offset= cpu_register_physical_memory: start=1400, size=0001, offset=0050 cpu_register_physical_memory: start=100A, size=0002, offset=0060 cpu_register_physical_memory: start=E000, size=0040, offset=0800 Without -kernel: cpu_register_physical_memory: start=, size=0800, offset= cpu_register_physical_memory: start=1FC0, size=0002, offset=08400010 Segmentation fault Could someone correct this ? The ISA region and devices initialization should be performed *before* any fileload. P.S. The MIPS initial state (PC=0xbfc0) is defined twice in the qemu: ./target-mips/translate.c:cpu_mips_init():1766 and ./hw/mips_r4k.c:mips_r4k_init() Seems, this is a bug too. -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS]
Hi! 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 [EMAIL PROTECTED] qemu/bin]$ ls qemuqemu-i386 qemu-mipsel qemu-sparcqemu-system-ppc qemu-armqemu-img qemu-ppc qemu-system-arm qemu-system-sparc qemu-armeb qemu-mips qemu-sh4 qemu-system-mips qemu-system-x86_64 Is it possible to build _both_ qemu-system-mips* for LE and BE support like userspace does ? -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] CP0 after reset bug (Was: Add MIPS ELF loader)
Alexander Voropay [EMAIL PROTECTED] wrote:
Another issue:
IN:
0xbfc00424: mtc0 zero,$13
0x0001: raise_exception 0x11
The problem is a code *before* this :
==
mfc0v0,C0_SR
and v0,SR_SR# preserve Soft Reset
or v0,SR_BEV # set Boot Exceptions
mtc0v0,C0_SR# 32 bit, kernel mode, bootstrap
mtc0zero,C0_CAUSE # -- TRAP there !!!
==
This code is a cut'n'paste from the See MIPS Run p.338
Unfortunately, this code clears CU0 bits in the CP0(SR).
It makes CP0 unusable for program and causes an exception 11 :
Coprocessor Unusable on the next CP0 access.
The Qemu has a bug there. The See MIPS Run p.51 states:
CU0 - Coprocessor 0 usable; Set 1 to be able to use some nominally
priveleged instructions in the user mode. You don't want to do this.
The CPU control instructions encoded as coprocessor 0 type are
always usable in kernel mode, regardless of the setting of this bit.
Qemu does simply check:
./target-mips/translate.c:1181
===
if (!(ctx-CP0_Status (1 CP0St_CU0))
!(ctx-hflags MIPS_HFLAG_UM)
!(ctx-hflags MIPS_HFLAG_ERL)
!(ctx-hflags MIPS_HFLAG_EXL)) {
if (loglevel CPU_LOG_TB_IN_ASM) {
fprintf(logfile, CP0 is not usable\n);
}
generate_exception_err (ctx, EXCP_CpU, 0);
return;
===
This check is not enought to emulate a Coprocessor Unusable
situation on Reset (when CPU is in the kernel mode).
--
-=AV=-
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] CP0 after reset bug (Was: Add MIPS ELF loader)
Thiemo Seufer [EMAIL PROTECTED] wrote: The Qemu has a bug there. The See MIPS Run p.51 states: A patch which doesn't negate the HFLAGS_UM check fixes this and was posted here a while ago. Thx, found. http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00148.html Is it possible to push it into the CVS ? -- -=AV=- ___ 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 [EMAIL PROTECTED] wrote: You could find my qemu.log there: http://www.nwpi.ru/~alec/mips/qemu_log.txt It goes into infinity exception loop. I'm not quite sure why but you're getting a RI exception on the address 0xbfc8 wich is the move k0, zero in the delay slot. I don't see a problem in the code, but have you tried this sequence? move k0, zero j0xbfc00400 nop Is the move implemented as addiu or as daddiu? The latter would RI. Oh! It was daddu (gcc -mips3) opcode. Thank you! Can someone add a path to make a log more readable (exception cause decode). The disassembler should be improved too, to mark a 64-bit opcodes as invalid for MIPS32... -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
move k0, zero j0xbfc00400 nop Is the move implemented as addiu or as daddiu? The latter would RI. Oh! It was daddu (gcc -mips3) opcode. Another issue: mtc0 zero, C0_CAUSE === IN: 0xbfc00424: mtc0 zero,$13 OP: 0x: save_pc 0xbfc00424 0x0001: raise_exception 0x11 0x0002: reset_T0 0x0003: exit_tb 0x0004: end 3 OUT: [size=24] 0x08a96a90: movl $0xbfc00424,0x80(%ebp) 0x08a96a9a: push $0x11 0x08a96a9f: call 0x8080fe8 0x08a96aa4: pop%eax 0x08a96aa5: xor%ebx,%ebx 0x08a96aa7: ret do_raise_exception_err: 17 0 do_interrupt enter: PC bfc00424 EPC cause -1 excp 17 do_interrupt: PC bfc00380 EPC bfc00424 cause 11 excp 17 S 0040 C 042c A D pc=0xbfc00380 HI=0x LO=0x ds 0004 0 GPR00: r0 at 0040 v0 0040 v1 GPR04: a0 a1 a2 a3 GPR08: t0 00018000 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 0x0042 Cause 0x042c EPC0xbfc00424 Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: 0xbfc00380: j 0xbfc019c0 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Dirk Behme [EMAIL PROTECTED] wrote: See a http://pastebin.com/628591 Sorry, does this link really work? I get a nearly empty page for this. Ah, pastebin keeps data only a day. I'm working on something similiar, if you want to call an embedded bootloader like uboot a BIOS ;) Anyway, I need to execute mips assembly starting from 0xbfc0 as well. I'm trying to port a mmon: http://www.brouhaha.com/~eric/software/mmon/ It's fairly simply MIPS monitor which requires only ~200 bytes and a working 16c550 UART. I think it should be possible to switch to 0xbfc0 by adjusting the addresses in hw/mips_r4k.c Things are more complicated. There should be two mode for the MIPS emulator : to run MIPS BIOS/Monitor after a full hardwere reset and to run a Linux kernel with pre-initialized hardware. MIPS Monitor should run in the BEV mode (Boot Exception Vector) to use vectors like 0xbfc00380 while Linux should use 0x8380. This state is controlled under the SR[BEV] CP0 register. GXEmul has a special -Q swith to run MIPS emulation in the BEV mode. There is another bug : for unknown reason, Qemu start BIOS execution from the 0xbfc4, not from the first address, see a hw/mips_r4k.c:221 I've just changet it to the 0xbfc0 In the current Qemu-CVS it is possible fo pass a control to the BIOS region 0xbfc0. Just omit a -kernel option and use a dummy MIPS ELF file as a parameter. This file may contain just a series of zeros (NOPs). Qemu will start execution of the binary 'mips_bios.bin' at the 0xbfc0 (except 0xbfc4 bug). Try to change the following lines in hw/mips_r4k.c: cpu_register_physical_memory(0x1fc0, ram_size, IO_MEM_RAM); This already done in the CVS hw/mips_r4k.c:215 Look at the my mmon-qemu port: http://www.nwpi.ru/~alec/mips/mmon-quemu-0.5.tgz It uses a dummy 'reset' ELF file to run a mips_bios.bin . You could find my qemu.log there: http://www.nwpi.ru/~alec/mips/qemu_log.txt It goes into infinity exception loop. The command string was $ qemu-system-mips -d out_asm,in_asm,op,int,exec,cpu -m 16 -nographic reset The mips_bios.bin is a my port of 'mmon'. P.S. JFYI: A good explanation of the MIPS reset: http://www.amd.com/files/connectivitysolutions/aufamily/au1000/Au1000Reset_rev1.2.pdf -- -=AV=- ___ 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 [EMAIL PROTECTED] wrote: cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 That comes not from the MIPS TLB mapping (which is for KSEG0/1 a fixed translation involving the high bits) but the underlying qemu softmmu support. 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 -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
