gxemul-users Mailing List for GXemul (Page 2)
Status: Alpha
Brought to you by:
gavare
Menu
▾
▴
gxemul-users — Mailing list for user questions regarding GXemul
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(1) |
Mar
(7) |
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(4) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nigel H. <nj...@ba...> - 2014-03-31 13:50:37
|
I'm trying to build the latest version from SVN. It's build fine in the past, but I can't get it to build on my latest installation. The error message is: In file included from ../../commands_h.h:16:0, from CommandInterpreter.cc:35: ../include/commands/RedoCommand.h:58:15: error: conflicting return type specified for ‘virtual void RedoCommand::Execute(GXemul&, const std::vector<std::basic_string<char> >&)’ virtual void Execute(GXemul& gxemul, const vector<string>& arguments); ^ In file included from ../include/CommandInterpreter.h:33:0, from ../include/GXemul.h:35, from CommandInterpreter.cc:31: ../include/Command.h:92:15: error: overriding ‘virtual bool Command::Execute(GXemul&, const std::vector<std::basic_string<char> >&)’ virtual bool Execute(GXemul& gxemul, ^ In file included from ../../commands_h.h:22:0, from CommandInterpreter.cc:35: ../include/commands/UndoCommand.h:58:15: error: conflicting return type specified for ‘virtual void UndoCommand::Execute(GXemul&, const std::vector<std::basic_string<char> >&)’ virtual void Execute(GXemul& gxemul, const vector<string>& arguments); ^ In file included from ../include/CommandInterpreter.h:33:0, from ../include/GXemul.h:35, from CommandInterpreter.cc:31: ../include/Command.h:92:15: error: overriding ‘virtual bool Command::Execute(GXemul&, const std::vector<std::basic_string<char> >&)’ virtual bool Execute(GXemul& gxemul, ^ make[3]: *** [CommandInterpreter.o] Error 1 make[3]: Leaving directory `/home/njh/src/gxemul/src/main' make[2]: *** [do_main] Error 2 make[2]: Leaving directory `/home/njh/src/gxemul/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/njh/src/gxemul/src' make: *** [do_src] Error 2 -Nigel |
|
From: George K. <xke...@ne...> - 2013-04-10 02:20:36
|
In trunk (r5803), the new mode "mvme187" and the legacy mode "mvme187"
have the same name. This is the first problem. The new mode is not
complete enough to work. You need the legacy mode.
So I renamed the legacy "mvme187" to "oldmvme187".
Apply my attached patch to trunk:
$ cd gxemul
$ patch < oldmvme187.diff
Compile it again. Now you can run trunk, but you must use -e oldmvme187
and not -e mvme187.
There is a second problem. I tried to boot OpenBSD/mvme88k 5.2 and
reproduced your MODE_SENSE messages and your stuck boot. (I never got
your malloc error, perhaps because my host machine runs OpenBSD/amd64
5.2, so I have bsd libc, not glibc.)
No one has fixed the second problem.
==snip==
$ gxemul -e oldmvme187 -d vme.hd -d b:openbsd_mvme88k_5.2.iso -j
5.2/mvme88k/bsd.rd
GXemul (unknown version) Copyright (C) 2003-2012 Anders Gavare
Read the source code and/or documentation for other Copyright messages.
Simple setup...
net:
simulated network: 10.0.0.0/8 (max outgoing: TCP=100, UDP=100)
simulated gateway+nameserver: 10.0.0.254 (60:50:40:30:20:10)
simulated nameserver uses real nameserver 192.168.10.1
machine:
memory: 64 MB
cpu0: 88100
machine: MVME187
diskimage: vme.hd
SCSI DISK id 0, read/write, 2048 MB (4194304 sectors)
diskimage: openbsd_mvme88k_5.2.iso
SCSI CD-ROM id 1, read-only, 313 MB (641992 sectors) (BOOT)
ISO9660 boot:
"CDROM":5.2/mvme88k/bsd.rd
extracted 3305741 bytes into /tmp/gxemul.frsosdylKvdS
loading /tmp/gxemul.frsosdylKvdS
removing /tmp/gxemul.frsosdylKvdS
cpu0: starting at 0x00010020
NOTE: This is a LEGACY emulation mode.
-------------------------------------------------------------------------------
CPU0 is associated to 2 MC88200 CMMUs
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.2 (RAMDISK) #50: Wed Jul 25 21:24:31 GMT 2012
ro...@ar...:/usr/src/sys/arch/mvme88k/compile/RAMDISK
real mem = 67108864 (64MB)
avail mem = 59473920 (56MB)
mainbus0 at root: Motorola MVME187, 33MHz
cpu0: M88100 rev 0x3, 2 CMMU
cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
pcctwo0 at mainbus0 addr 0xfff00000: rev 0
nvram0 at pcctwo0 offset 0xc0000: MK48T08
cl0 at pcctwo0 offset 0x45000 ipl 3: console
osiop0 at pcctwo0 offset 0x47000 ipl 2: NCR53C710 rev 2, 66MHz
scsibus0 at osiop0: 8 targets, initiator 7
osiop0: target 0 ignored sync request
osiop0: target 0 now using 8 bit asynch xfers
sd0 at scsibus0 targ 0 lun 0: <GXemul, vme.hd, 0> SCSI2 0/direct fixed
sd0: 2048MB, 512 bytes/sector, 4194305 sectors
[ MODE_SENSE for page 8 is not yet implemented! ]
[ MODE_SENSE for page 8 is not yet implemented! ]
[ unknown MODE_SELECT: cmd = 15 10 00 00 63 00, data_out = 00 00 00 08
00 00 00 00 00 00 02 00 ]osiop0: target 1 ignored sync request
osiop0: target 1 now using 8 bit asynch xfers
cd0 at scsibus0 targ 1 lun 0: <GXemul, openbsd_mvme88k, 0> SCSI2 5/cdrom
removable
vme0 at pcctwo0 offset 0x40000
vme0: using BUG parameters
vme0: vme to cpu irq level 1:1
vmes0 at vme0
boot device: <unknown>
osiop0: target 0 now using 8 bit asynch xfers
root on rd0a swap on rd0b dump on rd0b
WARNING: clock gained 248 days -- CHECK AND RESET THE DATE!
==snip==
Here, the emulator is stuck. I enabled tracing (like you did with
OpenBSD 4.7 and 4.6) but got an infinite trace like yours.
--George Koehler
|
|
From: Mikael P. <mi...@it...> - 2013-04-07 18:32:51
|
Hi, I'm trying to install the latest OpenBSD/mvme88k on gxemul, but so far with little success. This longish message describes the various issues I've come across. Starting with OpenBSD 5.2 and gxemul-0.6 (r5803 from svn), following the instructions at <http://gxemul.sourceforge.net/gxemul-stable/doc/guestoses.html#openbsdmvme88kinstall>, I get: ==snip== > /tmp/install-0.6-r5803/bin/gxemul -e mvme187 -d obsd_mvme88k.img -d b:openbsd_mvme88k_5.2.iso -j 5.2/mvme88k/bsd.rd No binary specified. Usually when starting up an emulation based on a template machine, you need to supply one or more binaries. This could be an operating system kernel, a ROM image, or something similar. You can also use the -V option to start in paused mode, and load binaries interactively. (Run gxemul -h for more help on command line options.) ==snip== Adding the kernel 'bsd' to the command line yields: ==snip== > /tmp/install-0.6-r5803/bin/gxemul -e mvme187 -d obsd_mvme88k.img -d b:openbsd_mvme88k_5.2.iso -j 5.2/mvme88k/bsd.rd bsd GXemul 20130406-r5803 Copyright (C) 2003-2012 Anders Gavare mainbus0 |-- ram0 (32 MB at offset 0) |-- rom0 (4 MB at offset 0xff800000) \-- cpu0 (88100, 50 MHz) cpu0: bsd loaded a.out: entry point 0x00010020 text + data = 2334720 + 65536 bytes symbols: 92808 bytes at 0x24a000 strings: 116567 bytes at 0x260a88 7734 symbols read ------------------------------------------------------------------------------- [ cpu0: instruction translation failed at _kernelstart: ] [ <_kernelstart> ] [ 0x10020 c00003f9 br 0x11004 ; <_kernelstart+0xfe4> ] [ cpu0: only 0 steps of 100000 executed. ] [ Continuous execution aborted. ] GXemul> q ==snip== I've tried a few variations of the command line, but none worked. Next I tried gxemul-0.4.7.2: ==snip== > /tmp/install-0.4.7.2/bin/gxemul -e mvme187 -d obsd_mvme88k.img -d b:openbsd_mvme88k_5.2.iso -j 5.2/mvme88k/bsd.rd GXemul 0.4.7.2 Copyright (C) 2003-2009 Anders Gavare Read the source code and/or documentation for other Copyright messages. Simple setup... net: simulated network: 10.0.0.0/8 (max outgoing: TCP=100, UDP=100) simulated gateway+nameserver: 10.0.0.254 (60:50:40:30:20:10) simulated nameserver uses real nameserver 192.168.1.1 machine: memory: 64 MB cpu0: 88100 machine: MVME187 diskimage: obsd_mvme88k.img SCSI DISK id 0, read/write, 1855 MB (3800002 sectors) diskimage: openbsd_mvme88k_5.2.iso SCSI CD-ROM id 1, read-only, 313 MB (641992 sectors) (BOOT) ISO9660 boot: "CDROM":5.2/mvme88k/bsd.rd extracted 3305741 bytes into /tmp/gxemul.XXXXXXBYdibX loading /tmp/gxemul.XXXXXXBYdibX removing /tmp/gxemul.XXXXXXBYdibX cpu0: starting at 0x00010020 ------------------------------------------------------------------------------- CPU0 is associated to 2 MC88200 CMMUs Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.2 (RAMDISK) #50: Wed Jul 25 21:24:31 GMT 2012 ro...@ar...:/usr/src/sys/arch/mvme88k/compile/RAMDISK real mem = 67108864 (64MB) avail mem = 59473920 (56MB) mainbus0 at root: Motorola MVME187, 33MHz cpu0: M88100 rev 0x3, 2 CMMU cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache pcctwo0 at mainbus0 addr 0xfff00000: rev 0 nvram0 at pcctwo0 offset 0xc0000: MK48T08 cl0 at pcctwo0 offset 0x45000 ipl 3: console osiop0 at pcctwo0 offset 0x47000 ipl 2: NCR53C710 rev 2, 66MHz scsibus0 at osiop0: 8 targets, initiator 7 osiop0: target 0 ignored sync request osiop0: target 0 now using 8 bit asynch xfers sd0 at scsibus0 targ 0 lun 0: <GXemul, obsd_mvme88k.im, 0> SCSI2 0/direct fixed sd0: 1855MB, 512 bytes/sector, 3800003 sectors [ MODE_SENSE for page 8 is not yet implemented! ] [ MODE_SENSE for page 8 is not yet implemented! ] *** glibc detected *** /tmp/install-0.4.7.2/bin/gxemul: malloc(): memory corruption (fast): 0x000000000107bb60 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7ae16)[0x7fc03576de16] /lib64/libc.so.6(+0x7d684)[0x7fc035770684] /lib64/libc.so.6(__libc_malloc+0x63)[0x7fc0357724b3] /tmp/install-0.4.7.2/bin/gxemul[0x616216] /tmp/install-0.4.7.2/bin/gxemul[0x5ef26a] /tmp/install-0.4.7.2/bin/gxemul[0x5efb24] /tmp/install-0.4.7.2/bin/gxemul[0x4450c0] /tmp/install-0.4.7.2/bin/gxemul[0x449442] /tmp/install-0.4.7.2/bin/gxemul[0x445cc4] /tmp/install-0.4.7.2/bin/gxemul[0x61f699] /tmp/install-0.4.7.2/bin/gxemul[0x4040ad] /tmp/install-0.4.7.2/bin/gxemul[0x4028fd] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fc035714735] /tmp/install-0.4.7.2/bin/gxemul[0x402a61] ======= Memory map: ======== 00400000-0074b000 r-xp 00000000 08:05 205745 /tmp/install-0.4.7.2/bin/gxemul 0094b000-0097f000 rw-p 0034b000 08:05 205745 /tmp/install-0.4.7.2/bin/gxemul 0097f000-00a01000 rw-p 00000000 00:00 0 0105b000-01135000 rw-p 00000000 00:00 0 [heap] 7fc02dbac000-7fc02dbc1000 r-xp 00000000 08:08 131087 /usr/lib64/libgcc_s-4.7.2-20120921.so.1 7fc02dbc1000-7fc02ddc0000 ---p 00015000 08:08 131087 /usr/lib64/libgcc_s-4.7.2-20120921.so.1 7fc02ddc0000-7fc02ddc1000 rw-p 00014000 08:08 131087 /usr/lib64/libgcc_s-4.7.2-20120921.so.1 7fc02ddc1000-7fc0356f3000 rw-p 00000000 00:00 0 7fc0356f3000-7fc03589f000 r-xp 00000000 08:08 134338 /usr/lib64/libc-2.15.so 7fc03589f000-7fc035a9f000 ---p 001ac000 08:08 134338 /usr/lib64/libc-2.15.so 7fc035a9f000-7fc035aa3000 r--p 001ac000 08:08 134338 /usr/lib64/libc-2.15.so 7fc035aa3000-7fc035aa5000 rw-p 001b0000 08:08 134338 /usr/lib64/libc-2.15.so 7fc035aa5000-7fc035aaa000 rw-p 00000000 00:00 0 7fc035aaa000-7fc035ba4000 r-xp 00000000 08:08 134346 /usr/lib64/libm-2.15.so 7fc035ba4000-7fc035da3000 ---p 000fa000 08:08 134346 /usr/lib64/libm-2.15.so 7fc035da3000-7fc035da4000 r--p 000f9000 08:08 134346 /usr/lib64/libm-2.15.so 7fc035da4000-7fc035da5000 rw-p 000fa000 08:08 134346 /usr/lib64/libm-2.15.so 7fc035da5000-7fc035dc5000 r-xp 00000000 08:08 134331 /usr/lib64/ld-2.15.so 7fc035eb6000-7fc035fb9000 rw-p 00000000 00:00 0 7fc035fc0000-7fc035fc4000 rw-p 00000000 00:00 0 7fc035fc4000-7fc035fc5000 r--p 0001f000 08:08 134331 /usr/lib64/ld-2.15.so 7fc035fc5000-7fc035fc6000 rw-p 00020000 08:08 134331 /usr/lib64/ld-2.15.so 7fc035fc6000-7fc035fc7000 rw-p 00000000 00:00 0 7fffe8e8e000-7fffe8eb0000 rw-p 00000000 00:00 0 [stack] 7fffe8fcd000-7fffe8fce000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] [ unknown MODE_SELECT: cmd = 15 10 00 00 63 00, data_out = 00 00 00 08 00 00 00 00 00 00 02 00 ]Abort ==snip== The '[ MODE_SENSE' message is from gxemul's diskimage_scsicmd.c, and the backtrace is from glibc which has detected memory corruption. If I hack diskimage_scsicommand() to 'return 0' early for 'page 8' MODE_SENSE before allocating anything, I instead get: ==snip== ... sd0: 1855MB, 512 bytes/sector, 3800003 sectors [ MODE_SENSE for page 8 is NYI ] osiop TODO: error ==snip== That is, gxemul's dev_osiop.c isn't prepared to handle errors. Retrying with OpenBSD 5.1, 5.0, 4.9, or 4.8 results in the same page 8 MODE_SENSE problem. With OpenBSD 4.7 a different problem appears: ==snip== > /tmp/install-0.4.7.2/bin/gxemul-hack -e mvme187 -d obsd_mvme88k.img -d b:openbsd_mvme88k_4.7.iso -j 4.7/mvme88k/bsd.rd GXemul 0.4.7.2 Copyright (C) 2003-2009 Anders Gavare Read the source code and/or documentation for other Copyright messages. Simple setup... net: simulated network: 10.0.0.0/8 (max outgoing: TCP=100, UDP=100) simulated gateway+nameserver: 10.0.0.254 (60:50:40:30:20:10) simulated nameserver uses real nameserver 192.168.1.1 machine: memory: 64 MB cpu0: 88100 machine: MVME187 diskimage: obsd_mvme88k.img SCSI DISK id 0, read/write, 1855 MB (3800002 sectors) diskimage: openbsd_mvme88k_4.7.iso SCSI CD-ROM id 1, read-only, 288 MB (590996 sectors) (BOOT) ISO9660 boot: "CDROM":4.7/mvme88k/bsd.rd extracted 3262815 bytes into /tmp/gxemul.XXXXXX4NxcXS loading /tmp/gxemul.XXXXXX4NxcXS removing /tmp/gxemul.XXXXXX4NxcXS cpu0: starting at 0x00010020 ------------------------------------------------------------------------------- CPU0 is associated to 2 MC88200 CMMUs Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2010 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.7 (RAMDISK) #37: Sun Mar 21 20:41:11 GMT 2010 ro...@ar...:/usr/src/sys/arch/mvme88k/compile/RAMDISK real mem = 67108864 (64MB) avail mem = 56922112 (54MB) mainbus0 at root: Motorola MVME187, 33MHz cpu0: M88100 rev 0x3, 2 CMMU cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache pcctwo0 at mainbus0 addr 0xfff00000: rev 0 nvram0 at pcctwo0 offset 0xc0000: MK48T08 cl0 at pcctwo0 offset 0x45000 ipl 3: console osiop0 at pcctwo0 offset 0x47000 ipl 2: NCR53C710 rev 2, 66MHz scsibus0 at osiop0: 8 targets, initiator 7 osiop0: target 0 ignored sync request osiop0: target 0 now using 8 bit asynch xfers sd0 at scsibus0 targ 0 lun 0: <GXemul, obsd_mvme88k.im, 0> SCSI2 0/direct fixed sd0: 1855MB, 512 bytes/sec, 3800003 sec total osiop0: target 1 ignored sync request osiop0: target 1 now using 8 bit asynch xfers cd0 at scsibus0 targ 1 lun 0: <GXemul, openbsd_mvme88k, 0> SCSI2 5/cdrom removable vme0 at pcctwo0 offset 0x40000 vme0: using BUG parameters vme0: vme to cpu irq level 1:1 vmes0 at vme0 rd0: fixed, 4096 blocks boot device: <unknown> root on rd0a swap on rd0b dump on rd0b WARNING: clock gained 1112 days -- CHECK AND RESET THE DATE! ==snip== At this point the gxemul process consumes 100% CPU, but no progress in the kernel boot is being made. Breaking into the builtin debugger and enabling tracing shows: ==snip== ^C GXemul> r cpu0: pc = 0x00028924 <_sched_idle+0x13c> cpu0: r1 = 0x00028910 r2 = 0x00362710 r3 = 0x0036d0e0 cpu0: r4 = 0x00000000 r5 = 0x00008e4d r6 = 0x00362710 r7 = 0x00000001 cpu0: r8 = 0x800003f0 r9 = 0x00000001 r10 = 0x24d3f1c0 r11 = 0x00004231 cpu0: r12 = 0x000f73a0 r13 = 0x00000000 r14 = 0x00360000 r15 = 0x00360000 cpu0: r16 = 0x00000000 r17 = 0x00000000 r18 = 0x0036d0e0 r19 = 0x00360000 cpu0: r20 = 0x01aa32e0 r21 = 0x0036d0e0 r22 = 0x0036d120 r23 = 0x00000000 cpu0: r24 = 0x0036d128 r25 = 0x0036d0e0 r26 = 0x00000000 r27 = 0x00000000 cpu0: r28 = 0x00000000 r29 = 0x00000000 r30 = 0x0010bf50 r31 = 0x0291ffd0 GXemul> trace show_trace_tree = ON (was: OFF) GXemul> c <_badaddr+0x90(4,&_m88k_cpus,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_pfsr_save+0x1ec(4,0,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_getipl(&_sched_idle_cpus,&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_m187_getipl("] ",&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_interrupt(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_ext_int(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_setipl(5,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m1x7_statintr(0x291fed0,0,88,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_random(0x291fed0,0,88,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_statclock(0x291fed0,0,88,0x8e4d,&_m88k_cpus,0x165496cc,0x7ee110,0x7fffffff,..)> <_spl0(0,0,88,0x8e4d,&_m88k_cpus,0x165496cc,0x7ee110,1,..)> <_setipl(0,0,88,0x8e4d,&_m88k_cpus,0x165496cc,0x7ee110,1,..)> <_m187_setipl(0,0,88,0x8e4d,&_m88k_cpus,0x165496cc,0x7ee110,1,..)> <_setipl(0,0,88,0x8e4d,&_m88k_cpus,0,0x800003f2,0xfff4203f,..)> <_m187_setipl(0,0,88,0x8e4d,&_m88k_cpus,0,0x800003f2,0xfff4203f,..)> <_badaddr+0x90(4,&_m88k_cpus,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_pfsr_save+0x1ec(4,0,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_getipl(&_sched_idle_cpus,&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_m187_getipl("] ",&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_interrupt(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_ext_int(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_setipl(5,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m1x7_clockintr(0x291fed0,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_mtx_enter(&_pcc_mutex,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_raiseipl(5,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_m187_raiseipl(5,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_mtx_leave(&_pcc_mutex,&_m88k_cpus,&_pcc_mutex,0x8e4d,0x800003f0,5,0xaa4,0x360000,..)> <_m187_setipl(5,5,5,0x8e4d,0x800003f0,5,0xaa4,0x360000,..)> <_spl0(0,5,5,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_setipl(0,5,5,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_m187_setipl(0,5,5,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_setipl(0,5,5,0x8e4d,0x800003f0,0,0x800003f2,0xfff4203f,..)> <_m187_setipl(0,5,5,0x8e4d,0x800003f0,0,0x800003f2,0xfff4203f,..)> <_badaddr+0x90(4,&_m88k_cpus,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_pfsr_save+0x1ec(4,0,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_getipl(&_sched_idle_cpus,&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_m187_getipl("] ",&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_interrupt(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_ext_int(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_setipl(5,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m1x7_statintr(0x291fed0,0,88,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_random(0x291fed0,0,88,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_statclock(0x291fed0,0,88,0x8e4d,&_m88k_cpus,0xb783688,0x412ba8,0x7fffffff,..)> <_spl0(0,0,88,0x8e4d,&_m88k_cpus,0xb783688,0x412ba8,1,..)> <_setipl(0,0,88,0x8e4d,&_m88k_cpus,0xb783688,0x412ba8,1,..)> <_m187_setipl(0,0,88,0x8e4d,&_m88k_cpus,0xb783688,0x412ba8,1,..)> <_setipl(0,0,88,0x8e4d,&_m88k_cpus,0,0x800003f2,0xfff4203f,..)> <_m187_setipl(0,0,88,0x8e4d,&_m88k_cpus,0,0x800003f2,0xfff4203f,..)> <_badaddr+0x90(4,&_m88k_cpus,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_pfsr_save+0x1ec(4,0,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_getipl(&_sched_idle_cpus,&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_m187_getipl("] ",&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_interrupt(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_ext_int(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_setipl(5,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m1x7_clockintr(0x291fed0,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_mtx_enter(&_pcc_mutex,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_raiseipl(5,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_m187_raiseipl(5,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_mtx_leave(&_pcc_mutex,&_m88k_cpus,&_pcc_mutex,0x8e4d,0x800003f0,5,0xaa4,0x360000,..)> <_m187_setipl(5,5,5,0x8e4d,0x800003f0,5,0xaa4,0x360000,..)> <_spl0(0,5,5,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_setipl(0,5,5,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_m187_setipl(0,5,5,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_setipl(0,5,5,0x8e4d,0x800003f0,0,0x800003f2,0xfff4203f,..)> <_m187_setipl(0,5,5,0x8e4d,0x800003f0,0,0x800003f2,0xfff4203f,..)> <_badaddr+0x90(4,&_m88k_cpus,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_pfsr_save+0x1ec(4,0,0,0x8e4d,&_sched_idle_cpus,1,0x800003f0,1,..)> <_getipl(&_sched_idle_cpus,&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_m187_getipl("] ",&_m88k_cpus,0,0x8e4d,0x800003f0,1,0x800003f0,1,..)> <_interrupt(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_ext_int(0x291fed0,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m187_setipl(5,0,0,0x8e4d,0x800003f0,1,0x800003f0,0xfff4203f,..)> <_m1x7_clockintr(0x291fed0,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_mtx_enter(&_pcc_mutex,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_raiseipl(5,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_m187_raiseipl(5,0,89,0x8e4d,0x800003f0,5,0x800003f0,0xfff4203f,..)> <_mtx_leave(&_pcc_mutex,&_m88k_cpus,&_pcc_mutex,0x8e4d,0x800003f0,5,0xaa4,0x360000,..)> <_m187_setipl(5,5,5,0x8e4d,0x800003f0,5,0xaa4,0x360000,..)> ==snip== and this just goes on and on until I kill the emulator. OpenBSD 4.6 has the same problem. The good news is that OpenBSD 4.5 installs OK and appears to run fine in gxemul-0.4.7.2. However, if I try to boot the working OpenBSD 4.5 disk image with gxemul-0.6 r5803, it fails with: ==snip== > /tmp/install-0.6-r5803/bin/gxemul -e mvme187 -d obsd_mvme88k.img bsd GXemul 20130406-r5803 Copyright (C) 2003-2012 Anders Gavare mainbus0 |-- ram0 (32 MB at offset 0) |-- rom0 (4 MB at offset 0xff800000) \-- cpu0 (88100, 50 MHz) cpu0: bsd loaded a.out: entry point 0x00010020 text + data = 2150400 + 65536 bytes symbols: 84972 bytes at 0x21d000 strings: 104739 bytes at 0x231bec 7081 symbols read ------------------------------------------------------------------------------- TODO: M88K exception ### FATAL ERROR ### std::exception If you are able to reproduce this crash, please send detailed repro-steps to the author, to the gxemul-devel mailing list, or ask in #GXemul on the FreeNode IRC network. ==snip== I can't stay with OpenBSD 4.5 though, I need to run the upcoming OpenBSD 5.3 since that's when their M88K port switches from a.out to ELF and a less antique toolchain. Any help resolving these issues would be much appreciated. /Mikael |
|
From: George K. <xke...@ne...> - 2012-12-13 22:07:35
|
On 11/18/12 17:02, Nigel Horne wrote: > CommandInterpreter.cc:35:30: fatal error: ../../commands_h.h: No such > file or directory This reply is one month late, but might help the archives. If anyone gets a similar error, you probably forgot to run the configure script. See instructions in README. The configure script generates commands_h.h and a bunch of other files. --George Koehler |
|
From: Nigel H. <nj...@ba...> - 2012-11-18 23:02:37
|
The latest SVN version of Gxemul fails to compile on Debian Linux using gcc version 4.7.2: CommandInterpreter.cc:35:30: fatal error: ../../commands_h.h: No such file or directory compilation terminated. make[3]: *** [CommandInterpreter.o] Error 1 make[3]: Leaving directory `/home/njh/src/gxemul/src/main' make[2]: *** [do_main] Error 2 make[2]: Leaving directory `/home/njh/src/gxemul/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/njh/src/gxemul/src' make: *** [do_src] Error 2 -Nigel |
|
From: Anders G. <ga...@gm...> - 2011-08-20 06:11:43
|
Fre 2011-08-19 klockan 08:41 +0200 skrev Thomas Mair: > On 08/19/2011 06:48 AM, Anders Gavare wrote: > > This text output comes from the new framework, where basically nothing > > is implemented yet. To emulate MIPS machines, you need to use the old > > (legacy) framework. > That is what I suspected. If I have some spare time I would not mind to > implement some of the functionality in the new framework. Could you help > me on how the coprocessor would fit into the new framework? The new framework is more of the form of TODOs (*) and thoughts at this point, it is not really ready enough to implement specific features such as MIPS coprocessors. http://gxemul.sourceforge.net/gxemul-stable/doc/RELEASE.html Only the testm88k mode has been rewritten to use the new framework. This impacted the legacy (i.e. working) modes the least, since no-one would have used the testm88k mode for anything serious anyway. Anders * = http://gxemul.sourceforge.net/gxemul-stable/doc/TODO.html |
|
From: Thomas M. <mai...@gm...> - 2011-08-19 06:42:07
|
On 08/19/2011 06:48 AM, Anders Gavare wrote: > This text output comes from the new framework, where basically nothing > is implemented yet. To emulate MIPS machines, you need to use the old > (legacy) framework. Anders That is what I suspected. If I have some spare time I would not mind to implement some of the functionality in the new framework. Could you help me on how the coprocessor would fit into the new framework? In the meantime I will try to use the old framework. Thanks a lot Thomas |
|
From: Anders G. <ga...@gm...> - 2011-08-19 04:47:51
|
Tor 2011-08-18 klockan 23:40 +0200 skrev Thomas Mair: > GXemul> step > step 2: cpu0: 0xbfc00000 10000007 b 0xffffffffbfc00020 > => cpu0.inDelaySlot: false -> true > => cpu0.pc: 0xffffffffbfc00000 -> 0xffffffffbfc00004 .. > I hope that this information is useful for troubleshooting. This text output comes from the new framework, where basically nothing is implemented yet. To emulate MIPS machines, you need to use the old (legacy) framework. Anders |
|
From: Thomas M. <mai...@gm...> - 2011-08-18 21:40:36
|
I am running the current SVN version. The command line is the following
and the error occurs at step 4.
Maybe I did not initialize the cpu right. The first
./gxemul -V amazon.gxemul
GXemul (unknown version) Copyright (C) 2003-2011 Anders Gavare
amazon.gxemul loaded
GXemul> step
step 2: cpu0: 0xbfc00000 10000007 b 0xffffffffbfc00020
=> cpu0.inDelaySlot: false -> true
=> cpu0.pc: 0xffffffffbfc00000 -> 0xffffffffbfc00004
GXemul> step
step 3: cpu0: 0xbfc00004 00000000 (delayslot) nop
=> cpu0.inDelaySlot: true -> false
=> cpu0.pc: 0xffffffffbfc00004 -> 0xffffffffbfc00020
GXemul> step
step 4: cpu0: 0xbfc00020 40809000 unimplemented: cop0
cpu0: unimplemented opcode 0x10
cpu0: instruction translation failed
Single-stepping aborted.
GXemul> root
root
\-- mainbus0
|-- cpu0 (4KEc, 100 MHz)
\-- rom0 (16 MB at offset 0x1fc00000)
accuracy = cycle
step = 0x4
The beginning of the configuration file for the cpu is the following:
component root
{
string accuracy "cycle"
string name "root"
uint64 step 0x2
string template ""
component mainbus
{
string name "mainbus0"
uint64 step 0
string template ""
component mips_cpu
{
uint64 a0 0
uint64 a1 0
uint64 a2 0
uint64 a3 0
uint64 a4 0
uint64 a5 0
uint64 a6 0
uint64 a7 0
string abi "n64"
string architecture "MIPS"
uint64 at 0
bool bigendian true
uint64 delaySlotTarget 0xffffffffbfc00020
uint64 fp 0
double frequency 1e+08
sint32 functionCallTraceDepth 0
uint64 gp 0
bool hasUsedUnassemble false
uint64 hi 0
bool inDelaySlot false
uint64 k0 0
uint64 k1 0
uint64 lastDumpAddr 0
uint64 lastUnassembleVaddr 0
uint64 lo 0
string model "4KEc"
string name "cpu0"
sint64 nrOfTracedFunctionCalls 0
bool paused false
uint64 pc 0xffffffffbfc00000
uint64 ra 0
uint64 s0 0
uint64 s1 0
uint64 s2 0
uint64 s3 0
uint64 s4 0
uint64 s5 0
uint64 s6 0
uint64 s7 0
bool showFunctionTraceCall false
bool showFunctionTraceReturn false
uint64 sp 0xffffffffa0007f00
uint64 step 0x2
uint64 t4 0
uint64 t5 0
uint64 t6 0
uint64 t7 0
uint64 t8 0
uint64 t9 0
string template ""
uint64 v0 0
uint64 v1 0
uint64 zr 0
}
component ram
I hope that this information is useful for troubleshooting.
Thomas
On 08/17/2011 06:43 PM, Anders Gavare wrote:
> Ons 2011-08-17 klockan 10:48 +0200 skrev Thomas Mair:
>> i am trying to run an image file on a MIPS 4KEc processor. Unfortunately
>> the execution of the image stops, when trying to acess the coprocessor
>> with a mtc0 instruction. I tried to read the source code and came to the
>> conclusion that the coprocessor access is missing.
> What version of GXemul are you running, and how does the complete
> command line look when you are starting up the emulation? And what is
> the exact error?
>
> (The standard system coprocessor 0 is implemented in cpu_mips_coproc.cc,
> but maybe your command line arguments cause the coprocessor to not be
> initialized properly.)
>
>
> Anders
>
>
|
|
From: Anders G. <ga...@gm...> - 2011-08-17 16:43:20
|
Ons 2011-08-17 klockan 10:48 +0200 skrev Thomas Mair: > i am trying to run an image file on a MIPS 4KEc processor. Unfortunately > the execution of the image stops, when trying to acess the coprocessor > with a mtc0 instruction. I tried to read the source code and came to the > conclusion that the coprocessor access is missing. What version of GXemul are you running, and how does the complete command line look when you are starting up the emulation? And what is the exact error? (The standard system coprocessor 0 is implemented in cpu_mips_coproc.cc, but maybe your command line arguments cause the coprocessor to not be initialized properly.) Anders |
|
From: Thomas M. <mai...@gm...> - 2011-08-17 08:49:05
|
Hello everyone, i am trying to run an image file on a MIPS 4KEc processor. Unfortunately the execution of the image stops, when trying to acess the coprocessor with a mtc0 instruction. I tried to read the source code and came to the conclusion that the coprocessor access is missing. Is that conclusion right or am I missing something? And which is the best way to add the missing coprocessor support, to be compliant with the existing framework? Tanks a lot Thomas |
|
From: Anders G. <ga...@gm...> - 2011-02-17 19:01:36
|
Tis 2011-02-15 klockan 18:31 +0100 skrev folkert: > Hi! > > Any news on gxemul? Will it run IRIX? Hi Folkert. Sorry, not much news as of lately. IRIX status is unchanged. (If I remember correctly, some have gotten IRIX 4.x to run, with modifications... but my memory isn't very clear.) Anders |
|
From: folkert <fo...@va...> - 2011-02-15 17:49:29
|
Hi! Any news on gxemul? Will it run IRIX? Thanks, Folkert van Heusden -- MultiTail is een flexibele tool voor het volgen van logfiles en uitvoer van commando's. Filteren, van kleur voorzien, mergen, 'diff-view', etc. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com |
|
From: Anders G. <ga...@gm...> - 2011-02-13 21:04:35
|
Lör 2011-02-12 klockan 12:55 -0500 skrev Nigel Horne: > Are there any plans to release new images? I was wondering in > particular about support for newer versions of NetBSD. I have verified that NetBSD 5.1/pmax and OpenBSD 4.8/landisk work, and updated the documentation for what will become 0.6.0.1. It will hopefully be released once I have figured out if anything has changed in sourceforge, regarding how files are uploaded. Anders |
|
From: Nigel H. <nj...@ba...> - 2011-02-12 17:56:12
|
Anders, Are there any plans to release new images? I was wondering in particular about support for newer versions of NetBSD. Regards, -Nigel |
|
From: Nigel H. <nj...@ba...> - 2010-09-22 19:07:08
|
On 22/09/10 12:59, Nigel Horne wrote: > Anders, > > The latest version in SVN fails to compile for me, any advice? This is > on a Linux 64-bit host. Ignore that - I needed to rerun configure to create the file. All is well. -Nigel |
|
From: Nigel H. <nj...@ba...> - 2010-09-22 18:00:38
|
Anders, The latest version in SVN fails to compile for me, any advice? This is on a Linux 64-bit host. c++ -Wshadow -Wcast-qual -Wcast-align -Wnon-virtual-dtor -Wstrict-aliasing -Wall -Wextra -Wno-unused-parameter -g -fno-rtti -fstrict-aliasing -fomit-frame-pointer -fpeephole -O3 -DNDEBUG -O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized -Wall -pipe -mtune=native -march=native -fomit-frame-pointer -ffast-math -msse2 -msse -mmmx -mfpmath=sse -pedantic -D_FORTIFY_SOURCE=2 -Wpointer-arith -fstack-protector -Wstack-protector -Wextra -Wcast-align -Wcast-qual -Wdisabled-optimization -Wendif-labels -Wfloat-equal -Wformat-nonliteral -Winline -Wmissing-declarations -Wpointer-arith -Wundef -Wformat-security -D__STDC_FORMAT_MACROS -I../include/ -O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized -Wall -pipe -mtune=native -march=native -fomit-frame-pointer -ffast-math -msse2 -msse -mmmx -mfpmath=sse -pedantic -D_FORTIFY_SOURCE=2 -Wpointer-arith -fstack-protector -Wstack-protector -Wextra -Wcast-align -Wcast-qual -Wdisabled-optimization -Wendif-labels -Wfloat-equal -Wformat-nonliteral -Winline -Wmissing-declarations -Wpointer-arith -Wundef -Wformat-security -c -o CommandInterpreter.o CommandInterpreter.cc CommandInterpreter.cc:35:30: error: ../../commands_h.h: No such file or directory CommandInterpreter.cc:53:28: error: ../../commands.h: No such file or directory -Nigel |
|
From: Yana <op...@ya...> - 2010-08-13 03:00:09
|
Hello, I used GXemul with YanaKernel0 Prototype. http://yana.jp/ 2010/8/13, Anders Gavare <ga...@gm...>: > I do not know much about the internals of MINIX, but if it is already > more or less portably written, and if some other emulator or simulator > can be used, then yes, it is likely that GXemul can be used as well. I used MINIX with YanaKernel0 Prototype on the following computer system. + processor (GXemul(testarm,testmips)) + YanaKernel0 + MINIX kernel which depended on YanaKernel0 + MINIX tasks and MINIX processes And I want to use YanaKernel0 which was implemented by hardware. + processor which embeded YanaKernel0 (FPGA?) + MINIX kernel which depended on YanaKernel0 + MINIX tasks and MINIX processes Thanks, Yana |
|
From: Anders G. <ga...@gm...> - 2010-08-12 17:03:38
|
Hi Mohammed, Tor 2010-08-12 klockan 18:19 +0530 skrev Mohammed Rashad: > Can i use GXemul for porting MINIX OS to ARM processors? I do not know much about the internals of MINIX, but if it is already more or less portably written, and if some other emulator or simulator can be used, then yes, it is likely that GXemul can be used as well. There is no guarantee that GXemul emulates exactly any specific ARM cpu model; the cpu emulation was implemented to get some guest OSes (i.e. NetBSD) running. So you should treat GXemul as some kind of "generic lowest common denominator" emulation of the ARM ISA. You can either target the "testarm" machine, which is a basic ARM cpu plus some devices that more-or-less work like in a real machine (serial controller, interrupt controller, disk controller, ethernet controller, and a raw framebuffer), or you could port to e.g. the CATS mode (if you want VGA charcell output) or the Netwinder mode (if you want pixel-based framebuffer output). Anders |
|
From: Mohammed R. <moh...@gm...> - 2010-08-12 12:49:39
|
Can i use GXemul for porting MINIX OS to ARM processors? |
|
From: Nigel H. <nj...@ba...> - 2010-06-02 19:01:23
|
S.D., I use scp to copy files to and from the guest system - have you tried that? -Nigel |
|
From: S.D. L. <cyl...@gm...> - 2010-06-02 05:50:31
|
I follow the document to set newarchive.tar as a disk of guest os as: $ dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000 $ gxemul -X -e 3max -d nbsd_pmax.img -d newarchive.tar I do the following command to send test.c in Netbsd/pamx: # tar cvf /dev/wd1c test.c It shows: tar: ustar vol 1, 1files, 0 buyes read, 10240 bytes written in 1 secs (10240 by tes/sec) But, the newarchive.tar in Host OS (ubuntu 9.10) is still empty. It is the same situation on fransferring into guest OS. Could you help me to solve the problem? |
|
From: Anders G. <ga...@gm...> - 2010-05-11 06:25:48
|
Hi Vincent,
Tis 2010-05-11 klockan 01:20 -0400 skrev Vincent Mirian:
> Hi all,
>
> I have a few questions... :-)
>
> I would like to create execution traces of a mips processor from
> gxemul. I would like to run the simulation for a while (until a
> breakpoint let's say) and then save the _execution_ traces in a file.
I didn't quite understand which of the following two you want to do:
a) run for a while (tracing instructions), hit a breakpoint, exit
(saving the traced instruction)
or
b) run for a while without instruction trace, hit a breakpoint, turn on
instruction trace, and then continue (saving instruction trace from here
on).
Both should be possible by hacking the source code. A brutal one-off
approach could be to just hack in something in
DYNTRANS_RUN_INSTR_DEF(struct cpu *cpu) in cpu_dyntrans.cc, like
if (single_step || cpu->machine->instruction_trace
|| cpu->machine->register_dump) {
/*
* Single-step:
*/
FILE *old = stdout; // HACK!
stdout = fopen("trace-output.txt", "a"); // HACK!
struct DYNTRANS_IC *ic = cpu->cd.DYNTRANS_ARCH.next_ic;
...
/* Execute just one instruction: */
I;
n_instrs = 1;
fclose(stdout); // HACK!
stdout = old; // HACK!
} else if (cpu->machine->statistics.enabled) {
to redirect stdout to a file during single step and instruction trace.
But it would probably be horribly slow.
> Furthermore, I do not want to trace the cycle time that the processor
> is halted for memory requests.
That's easy. (Because GXemul currently does not simulate caches or
memory latencies. :-))
Anders
|
|
From: Vincent M. <vin...@ho...> - 2010-05-11 05:21:00
|
Hi all, I have a few questions... :-) I would like to create execution traces of a mips processor from gxemul. I would like to run the simulation for a while (until a breakpoint let's say) and then save the _execution_ traces in a file. Furthermore, I do not want to trace the cycle time that the processor is halted for memory requests. Any tips/suggestions on how to proceed with this? Also, does anyone know of a soft mips processor that contains atomic operations (mutex lock/unlock) in their architecture? Thank you, Vince Eco-Tip: Save trees! Do you really need to print this email? ;-) _________________________________________________________________ 30 days of prizes to be won with Hotmail. Enter Here. http://go.microsoft.com/?linkid=9729709 |
|
From: Anders G. <ga...@gm...> - 2010-04-06 19:34:08
|
Mån 2010-03-15 klockan 11:35 -0500 skrev Joel Sherrill: > Hi, > > I am the maintainer of RTEMS and would like to > be able to test our MVME2100 and MVME5500 support > on gxemul. Hi Joel. Sorry, those are not actually supported GXemul machines (see http://gxemul.sourceforge.net/gxemul-stable/doc/intro.html#emulmodes for details). They are listed when you run gxemul -H (which also lists bogus/unsupported modes), but unfortunately that's about it. > But the current svn trunk aborted with internal issues. I assume it was related to old legacy interrupt code not being updated to the (by now) other legacy interrupt code. I've checked in a bogus hack in SVN revision 5729 (*) which should at least print some initial boot messages, but again, the MVME5500 board is not really emulated. $ ./gxemul -e mvme5500 powerpc/ppc-rtems/mvme5500/hello.exe GXemul (unknown version) Copyright (C) 2003-2010 Anders Gavare Read the source code and/or documentation for other Copyright messages. Simple setup... net: simulated network: 10.0.0.0/8 (max outgoing: TCP=100, UDP=100) simulated gateway+nameserver: 10.0.0.254 (60:50:40:30:20:10) simulated nameserver uses real nameserver 192.36.120.11 machine: memory: 64 MB cpu0: PPC750 (I+D = 32+32 KB, L2 = 1024 KB) machine: MVME5500 loading /home/debug/emul/powerpc/ppc-rtems/mvme5500/hello.exe cpu0: starting at 0x00003198 NOTE: This is a LEGACY emulation mode. ------------------------------------------------------------------------------- [ using UNIMPLEMENTED spr 568 (dbat4u), pc = 0x909c ] [ using UNIMPLEMENTED spr 569 (dbat4l), pc = 0x90a0 ] [ using UNIMPLEMENTED spr 570 (dbat5u), pc = 0x90a4 ] [ using UNIMPLEMENTED spr 571 (dbat5l), pc = 0x90a8 ] [ using UNIMPLEMENTED spr 572 (dbat6u), pc = 0x90ac ] [ using UNIMPLEMENTED spr 573 (dbat6l), pc = 0x90b0 ] [ using UNIMPLEMENTED spr 574 (dbat7u), pc = 0x90b4 ] [ using UNIMPLEMENTED spr 575 (dbat7l), pc = 0x90b8 ] [ using UNIMPLEMENTED spr 560 (ibat4u), pc = 0x90bc ] [ using UNIMPLEMENTED spr 561 (dc_adr), pc = 0x90c0 ] [ using UNIMPLEMENTED spr 562 (dc_dat), pc = 0x90c4 ] [ using UNIMPLEMENTED spr 563 (ibat5l), pc = 0x90c8 ] [ using UNIMPLEMENTED spr 564 (ibat6u), pc = 0x90cc ] [ using UNIMPLEMENTED spr 565 (ibat6l), pc = 0x90d0 ] [ using UNIMPLEMENTED spr 566 (ibat7u), pc = 0x90d4 ] [ using UNIMPLEMENTED spr 567 (ibat7l), pc = 0x90d8 ] [ using UNIMPLEMENTED spr 1018 (dccr), pc = 0x9284 ] ----------------------------------------- Welcome to rtems-4.6.99.2(PowerPC/PowerPC 750/mvme5500) on MVME5500-0163 ----------------------------------------- Now BSP_mem_size = 0x1FE00000 BSP_Configuration.work_space_size = F800 > Is there someone who wouldn't mind doing the gxemul side of getting > RTEMS to run on this. A real implementation would require someone to go through all devices and CPU features that GXemul is lacking for this machine. That can take time. If there is e.g. a NetBSD port for MVME5500, then that would help a lot, many parts of GXemul are based on reverse-engineering how NetBSD uses various devices. Anders (*) http://gxemul.svn.sourceforge.net/viewvc/gxemul?view=rev&revision=5729 |
1 message has been excluded from this view by a project administrator.
