> > There's no point passing round both a pic callback and an object when we
> > can embed the callback in the object.
>
> I don't think that adding a callback is bad. It can be useful to use the
> device with another CPU or IRQ controller for example.
It means all the device emulation code has go
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard06/07/19 18:06:16
Modified files:
. : usb-linux.c vl.c
hw : usb-hid.c usb-hub.c usb-msd.c usb.c usb.h
Log message:
usb destroy API change (Lonnie Mendez)
C
Paul Brook wrote:
On Tuesday 18 July 2006 18:03, Thorsten Zitterell wrote:
I am working on a Gumstix system [1] emulation for QEMU which is based
on a Intel XScale processor. The board has an expansion card for network
support which is a smc91x compatible NIC. However, the irq line is not
direc
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard06/07/19 17:54:57
Modified files:
. : usb-linux.c
Log message:
Linux compilation fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/usb-linux.c?cvsroot=qemu&r1=1.6&r2=1.
IN:
0x40002bac: rd %psr, %l3
##
This last instruction seems to be completely legal, so I don't really
know what's happening...
User mode emulator does not allow supervisor mode instructions at all. Try
the system emulator (qemu-system-sp
Hi,I think you got it right. I compiled a small test program on linux/x86 using a cross compiler that generates sparc binaries.Then I tried to emulate it (still on linux/x86) using$ qemu-sparc -d in_asm program
and it starts emulating but then fails:Unhandled trap: 0x2pc: 40002bac npc: 40002bb0Gen
Hi -
I'm having a bit of trouble getting gdb to do what I was hoping it would
with qemu. Following the instructions in the docs:
#1) I launch qemu with -S -s flags ( since I want to trace the bootloader
code )
It says: Waiting gdb connection on port 1234 - which is correct, and it
opens the
