[Qemu-devel] Creating a simple
Hi all,
I'm trying to write a simple virtual hardware for QEMU. This hw must only return the value 0 every time I read at 0x6f8 address.
It looks like simple but I'm not sure... this is what I do...
I wrote a file in hw dir called hwfitt.c and implements hwfitt_ioport_read and *hwfitt_init functions.
In hwfitt_ioport_read must be a function that implements the hardware read control right?
I take for instance parallel.c code and I write hwfitt function call in
files where parallel's function are called (pc.c vl.c vl.h) and
modified make file. I didn't implement hwupdate_update_irq as in
parallel code. Is an error?
This is my hwfitt.c code. Can you support me?
Thanks
Alessandro
#include vl.h
#define HW_STS_READY 0x10
#define HW_STS_BUSY 0x80
#define HW_CTR_INIT 0x01
struct HwFittState {
uint8_t data;
uint8_t status;
uint8_t control;
int irq;
int irq_pending;
CharDriverState *chr;
int hw_driver;
};
/*static void hwupdate_update_irq(ParallelState *s)
{
if (s-irq_pending)
pic_set_irq(s-irq, 1);
else
pic_set_irq(s-irq, 0);
}*/
static uint32_t hwfitt_ioport_read(void *opaque, uint32_t addr) {
HwFittState *s = opaque;
uint32_t ret= 0xff;
addr = 7;
switch(addr) {
case 0:
if(s-hw_driver) {
s-data="">
}
ret = s-data;
break;
case 1:
if(s-hw_driver) {
ret=s-status;
}
break;
case 2:
if(s-hw_driver) {
s-control=0x10;
}
ret = s-control;
break;
}
#ifdef DEBUG_PARALLEL
printf(hwfitt: read addr=0x%02x val=0x%02x\n, addr, ret);
#endif
return ret;
}
HwFittState *hwfitt_init(int base, int irq, CharDriverState *chr){
HwFittState *s;
s=qemu_mallocz(sizeof(HwFittState));
s-chr = chr;
s-hw_driver = 1;
s-irq = irq;
s-data = "">
s-status = HW_STS_READY;
s-status |= HW_STS_BUSY;
s-control = HW_CTR_INIT;
register_ioport_read(base, 8, 1, hwfitt_ioport_read, s);
return s;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu qemu-doc.texi
Hi Paul, Does this mean that qemu-arm should be able to run the binaries that are produced by RVCT? I am trying to run a simple helloworld, compiled and linked with rvct2.2 (armcc -g -o hello hello.c) into a ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped file, but qemu-arm fails with an error loading ./hello. On a related note, how do I go about debugging qemu (namely the part that loads executables)? Since qemu appears as a shared object, this is not so straightforward. When I start gdb on arm-user, set a breakpoint at main() and type run, I get cannot insert breakpoint 1. Error accessing memory address 0x1cfb2: Input/output error. The same program may be running in another process. (This is with gdb 5.2, but 6.3 is not much different) - Wolfgang [EMAIL PROTECTED] wrote on 11.06.2006 18:28:41: CVSROOT: /sources/qemu Module name: qemu Changes by: Paul Brook pbrook 06/06/11 16:28:41 Modified files: . : qemu-doc.texi Log message: Document new arm-user features. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi? cvsroot=qemur1=1.90r2=1.91 Patches: Index: qemu-doc.texi === RCS file: /sources/qemu/qemu/qemu-doc.texi,v retrieving revision 1.90 retrieving revision 1.91 diff -u -b -r1.90 -r1.91 --- qemu-doc.texi 26 May 2006 00:49:52 - 1.90 +++ qemu-doc.texi 11 Jun 2006 16:28:41 - 1.91 @@ -1531,6 +1531,7 @@ * Quick Start:: * Wine launch:: * Command line options:: +* Other binaries:: @end menu @node Quick Start @@ -1637,6 +1638,15 @@ Act as if the host page size was 'pagesize' bytes @end table [EMAIL PROTECTED] Other binaries [EMAIL PROTECTED] Other binaries + [EMAIL PROTECTED] is also capable of running ARM Angel semihosted ELF +binaries (as implemented by the arm-elf and arm-eabi Newlib/GDB +configurations), and arm-uclinux bFLT format binaries. + +The binary format is detected automatically. + @node compilation @chapter Compilation from the sources ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu qemu-doc.texi
On Monday 12 June 2006 15:09, Wolfgang Schildbach wrote: Hi Paul, Does this mean that qemu-arm should be able to run the binaries that are produced by RVCT? I am trying to run a simple helloworld, compiled and linked with rvct2.2 (armcc -g -o hello hello.c) into a ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped file, but qemu-arm fails with an error loading ./hello. Yes it should be able to run RVCT binaries. The problem is that the qemu loader assumes the LMA and file offsets be page aligned (ie. be the same modulo the page size). This is part of the ABI for linux executables so that the binary can be mmapped directly into memory. RVCT does not enforce this alignment by default. On a related note, how do I go about debugging qemu (namely the part that loads executables)? Since qemu appears as a shared object, this is not so straightforward. When I start gdb on arm-user, set a breakpoint at main() and type run, I get Configure with --static. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] mips target
Hi, I need to start qemu with mips target, and I'm building a linux image for mips. But when I try: qemu-system-mips myimage.img I get this : mips_r4k_init: load BIOS '/usr/local/share/qemu/mips_bios.bin' size 131072 qemu: fatal: Trying to execute code outside RAM or ROM at 0xbfc2 pc=0xbfc2 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 0x EPC 0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x Aborted Is it a bug or a image problem? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: floppy controller missing in acpi tables
On Tue, 16 May 2006, Ben Taylor wrote: (ITU), such as the DiskUpdate on tools.de/solaris/itu/DU.zip which has a modifed RTL8029 driver that works with Qemu on SolarisX86. Obviosly, if you boot a Solaris 10/x86 install with -B acpi-user-options=0x0, you will not see the floppy. (I see that a patch is in the works for OpenSolaris, so eventually this will be fixed for good on Solaris). Excellent, thanks Ben and Juergen. FWIW, the RTL8139 NIC in current Qemu /ought/ to work with the 'rtls' driver included with Solaris. I havn't managed to test this yet as Qemu CVS /seems/ still to have timeout issues with Solaris NV 39 (booting from the install CD at least). Also, there was an AMD PCNet patch for Qemu (by Anthony Curtis). Which (possibly) Xen are using, but it is not included with Qemu. Solaris has a driver for this, based on the newer 'GLDv2' NIC driver framework. I tried quickly (ie i spent 5 minutes on it) porting Anthony's patch to the updated VLAN-client framework in Qemu, it gets recognised by the Solaris miniroot, but I must have missed something / made a mistake as Qemu crashes. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Power is poison. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu qemu-doc.texi
Thanks much Paul -- that did the trick! (Well, almost.) For the benefit of other ADS/RVCT users that try this, here is what I did: - figured out the file offset of the executable region in the axf file (readelf -l foo.axf|grep LOAD). For me, the offset appears to always be 0x34, and the executable region starts at 0x8000. - linked the application with armlink --ro-base 0x8034. This will move the executable region to a new start which is page-aligned to the actual file offset. - finally (this took me a little to figure out), I made sure that the executable has execute permissions: chmod u+rx foo.axf. With these changes, I could execute ARM/RealView Developer Suite generated executables directly. This is excellent -- thanks much to all who contributed to make this possible! The one remaining issue is that command line parameters are not properly transfered over to the ARM executable. This surprises me a little, since this does work for arm-userspace-linux, and the mechanisms loading the image appear quite similar. Where would I (start to) look for the reasons behind this? Is this something that needs to be fixed on the ARM side (i.e. fix the location where the ARM code looks for the environment)? - Wolfgang Paul Brook [EMAIL PROTECTED] wrote on 12.06.2006 16:18:34: On Monday 12 June 2006 15:09, Wolfgang Schildbach wrote: Hi Paul, Does this mean that qemu-arm should be able to run the binaries that are produced by RVCT? I am trying to run a simple helloworld, compiled and linked with rvct2.2 (armcc -g -o hello hello.c) into a ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped file, but qemu-arm fails with an error loading ./hello. Yes it should be able to run RVCT binaries. The problem is that the qemu loader assumes the LMA and file offsets be page aligned (ie. be the same modulo the page size). This is part of the ABI for linux executables so that the binary can be mmapped directly into memory. RVCT does not enforce this alignment by default. On a related note, how do I go about debugging qemu (namely the part that loads executables)? Since qemu appears as a shared object, this is not so straightforward. When I start gdb on arm-user, set a breakpoint at main() and type run, I get Configure with --static. Paul -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu qemu-doc.texi
Where would I (start to) look for the reasons behind this? Is this something that needs to be fixed on the ARM side (i.e. fix the location where the ARM code looks for the environment)? Look at the code in load_elf_binary that uses target_mmap to map the loadable segments into memory. The page size I'm referring to below is the target page size (4k for qemu-arm). target_mmap is more-or-less a wrapper around normal mmap that deals with the corner cases and differences in page size when host != target. There are two issues: - mmap requires the file offset be a multiple of the page size. This is relatively easy to fix. If the file data is misaligned create an anonymous mapping and pread the data. - The code assumes the VMA of the segments after roundind to a page boundary do not overlap. ie. a single memory page will contain data from no more than one segment. Fixing this is more complicated and probably involves merging the regions used by sections with overlapping pages. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Support Questions
Wanted to know about individuals that provides support and custom development for QEUM. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista
interestingly enough, qemu-img is compiled with large file support, yet on win32/mingw (gcc 3.4.5) qemu-img cannot manage images bigger than 2Gb anyone ever succeded this on win32 host ? large file support using mingw ? On 6/9/06, Paul Brook [EMAIL PROTECTED] wrote: On Friday 09 June 2006 21:41, Christian MICHON wrote: ok, I'll try that. But I also suspect a win32/mingw limitation on files bigger than 2Gb, since gcc -dumpspecs does not show anything related to -m64, which I'd expect to have to add to CFLAGS to be able to use iso or qcow images bigger than 2Gb. -m64 has nothing to do with large file support. Paul -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista
I'm sure you're doing something bad. I used qemu-img and qemu with mingw32 and files not just bigger than 2Gb but bigger than 6Gb even. El 12/06/2006, a las 20:33, Christian MICHON escribió: interestingly enough, qemu-img is compiled with large file support, yet on win32/mingw (gcc 3.4.5) qemu-img cannot manage images bigger than 2Gb anyone ever succeded this on win32 host ? large file support using mingw ? On 6/9/06, Paul Brook [EMAIL PROTECTED] wrote: On Friday 09 June 2006 21:41, Christian MICHON wrote: ok, I'll try that. But I also suspect a win32/mingw limitation on files bigger than 2Gb, since gcc -dumpspecs does not show anything related to -m64, which I'd expect to have to add to CFLAGS to be able to use iso or qcow images bigger than 2Gb. -m64 has nothing to do with large file support. Paul -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Support Questions
Well, Fabrice Bellard is main developer, and KQEMU whole developer. Paul Brook maintains ARM system, and QVM86 whole developer. Jocelyn Mayer (away) maintains PPC system. Blue Swirl maintains Sparc system. A couple of collaborators do development taks. I maintain the OS compatibility list and do extensive operating system compatibility testing. Just, for what you want that information? El 12/06/2006, a las 20:32, Joe Lee escribió: Wanted to know about individuals that provides support and custom development for QEUM. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista
I don't mind learning. Which version of msys/mingw/gcc/binutils do you have ? On 6/12/06, Natalia Portillo [EMAIL PROTECTED] wrote: I'm sure you're doing something bad. I used qemu-img and qemu with mingw32 and files not just bigger than 2Gb but bigger than 6Gb even. -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista
qemu-img.exe create -f raw test.raw 2G should take a couple of minutes to run, yet completes in less than 1s and test.raw is 0 bytes long. On 6/12/06, Natalia Portillo [EMAIL PROTECTED] wrote: I'm sure you're doing something bad. I used qemu-img and qemu with mingw32 and files not just bigger than 2Gb but bigger than 6Gb even. El 12/06/2006, a las 20:33, Christian MICHON escribió: interestingly enough, qemu-img is compiled with large file support, yet on win32/mingw (gcc 3.4.5) qemu-img cannot manage images bigger than 2Gb anyone ever succeded this on win32 host ? large file support using mingw ? On 6/9/06, Paul Brook [EMAIL PROTECTED] wrote: On Friday 09 June 2006 21:41, Christian MICHON wrote: ok, I'll try that. But I also suspect a win32/mingw limitation on files bigger than 2Gb, since gcc -dumpspecs does not show anything related to -m64, which I'd expect to have to add to CFLAGS to be able to use iso or qcow images bigger than 2Gb. -m64 has nothing to do with large file support. Paul -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-win32-imgover4g.patch apparently fixes this. maybe Natalia mentionned no problem on qcow images, not raw. On 6/12/06, Christian MICHON [EMAIL PROTECTED] wrote: qemu-img.exe create -f raw test.raw 2G should take a couple of minutes to run, yet completes in less than 1s and test.raw is 0 bytes long. On 6/12/06, Natalia Portillo [EMAIL PROTECTED] wrote: I'm sure you're doing something bad. I used qemu-img and qemu with mingw32 and files not just bigger than 2Gb but bigger than 6Gb even. El 12/06/2006, a las 20:33, Christian MICHON escribió: interestingly enough, qemu-img is compiled with large file support, yet on win32/mingw (gcc 3.4.5) qemu-img cannot manage images bigger than 2Gb anyone ever succeded this on win32 host ? large file support using mingw ? On 6/9/06, Paul Brook [EMAIL PROTECTED] wrote: On Friday 09 June 2006 21:41, Christian MICHON wrote: ok, I'll try that. But I also suspect a win32/mingw limitation on files bigger than 2Gb, since gcc -dumpspecs does not show anything related to -m64, which I'd expect to have to add to CFLAGS to be able to use iso or qcow images bigger than 2Gb. -m64 has nothing to do with large file support. Paul -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Support Questions
Hi, On Mon, 12 Jun 2006, Natalia Portillo wrote: Fabrice Bellard is main developer, and KQEMU whole developer. Paul Brook maintains ARM system, and QVM86 whole developer. ... and has commit rights to QEmu's main repository. Jocelyn Mayer (away) maintains PPC system. Blue Swirl maintains Sparc system. A couple of collaborators do development taks. I maintain the OS compatibility list and do extensive operating system compatibility testing. ... and of course, you can always ask the question on this list (which is the Open Source way anyway), and if there are too few, or none, to answer the question, you can add some digit with a dollar sign after it to entice people to help you ;-) Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: floppy controller missing in acpi tables
Paul Jakma [EMAIL PROTECTED] wrote: On Tue, 16 May 2006, Ben Taylor wrote: (ITU), such as the DiskUpdate on tools.de/solaris/itu/DU.zip which has a modifed RTL8029 driver that works with Qemu on SolarisX86. Obviosly, if you boot a Solaris 10/x86 install with -B acpi-user-options=0x0, you will not see the floppy. (I see that a patch is in the works for OpenSolaris, so eventually this will be fixed for good on Solaris). Excellent, thanks Ben and Juergen. FWIW, the RTL8139 NIC in current Qemu /ought/ to work with the 'rtls' driver included with Solaris. I havn't managed to test this yet as Qemu CVS /seems/ still to have timeout issues with Solaris NV 39 (booting from the install CD at least). You have to turn off atapi-cd-dma-enabled at the initial solaris grub boot prompt like: hit e on the primary solaris install add ,-B atapi-cd-dma-enabled=0 to the line then hit b to boot. That should get you a working install. Also, there was an AMD PCNet patch for Qemu (by Anthony Curtis). Which (possibly) Xen are using, but it is not included with Qemu. Solaris has a driver for this, based on the newer 'GLDv2' NIC driver framework. I tried quickly (ie i spent 5 minutes on it) porting Anthony's patch to the updated VLAN-client framework in Qemu, it gets recognised by the Solaris miniroot, but I must have missed something / made a mistake as Qemu crashes. Just use the ITU from Juergen. I've installed solaris express b39 and used the ni driver from the ITU and ti works like a champ. (Juergen modified Murayama's ni (ne2000) driver to work correctly with qemu). Ben regards, -- Paul Jakma[EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Power is poison. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
