Re: [Qemu-devel] qemu qemu-doc.texi vl.c
Thank you ! Laurent Le lundi 14 janvier 2008 à 02:56 +, Andrzej Zaborowski a écrit : CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 08/01/14 02:56:53 Modified files: . : qemu-doc.texi vl.c Log message: Change -drive parsing so that paths don't have to be double-escaped (Laurent Vivier, Johannes Schindelin) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.176r2=1.177 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.395r2=1.396 -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/mc146818rtc.c
Hi, the change from mc146818rtc.c might be needed for other timer implementations, too (because not all systems emulated by QEMU use mc146818rtc.c). A list of candidates is here (fgrep gmtime, fgrep gettime): hw/m48t59.c:gmtime_r (t, tm); hw/omap.c:s-convert = rtc_utc ? gmtime_r : localtime_r; hw/pl031.c:tm = gmtime(ti); hw/pxa2xx.c:tm = gmtime(ti); hw/etraxfs_timer.c: gettimeofday(now, NULL); hw/omap.c needs additional changes for Windows, because gmtime_r is missing there. Maybe all those locations should use a central function (to be written). Stefan Fabrice Bellard schrieb: CVSROOT: /sources/qemu Module name: qemu Changes by: Fabrice Bellard bellard 07/11/07 16:24:34 Modified files: . : qemu-doc.texi vl.c vl.h hw : mc146818rtc.c Log message: added -startdate option CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.163r2=1.164 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.353r2=1.354 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.287r2=1.288 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mc146818rtc.c?cvsroot=qemur1=1.12r2=1.13
Re: [Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/mc146818rtc.c
Stefan Weil wrote: Hi, the change from mc146818rtc.c might be needed for other timer implementations, too (because not all systems emulated by QEMU use mc146818rtc.c). A list of candidates is here (fgrep gmtime, fgrep gettime): hw/m48t59.c:gmtime_r (t, tm); hw/omap.c:s-convert = rtc_utc ? gmtime_r : localtime_r; hw/pl031.c:tm = gmtime(ti); hw/pxa2xx.c:tm = gmtime(ti); hw/etraxfs_timer.c: gettimeofday(now, NULL); hw/omap.c needs additional changes for Windows, because gmtime_r is missing there. Maybe all those locations should use a central function (to be written). Right. There should be at least a function which returns the current time with the rtc_utc flag handling. Fabrice.
Re: [Qemu-devel] qemu qemu-doc.texi hw/vga.c
On 6/10/07, Blue Swirl [EMAIL PROTECTED] wrote: Modified files: . : qemu-doc.texi hw : vga.c Log message: Fix patch splitting lossage in vga.c Sorry, I forgot that I was editing the doc.
Re: [Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/pc.c hw/sun4m.c
On 1/7/07, Thiemo Seufer [EMAIL PROTECTED] wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/01/07 20:42:14
Modified files:
. : qemu-doc.texi vl.c vl.h
hw : pc.c sun4m.c
Log message:
Revert -disk patch, as requested by Fabrice. The general idea of
this
patch is sound, but the implementation is just too ugly.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.120r2=1.121
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.233r2=1.234
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.165r2=1.166
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.65r2=1.66
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.22r2=1.23
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
That sun4m.c change breaks disk/cdrom attachment to esp scsi.
Please see the patch to make it work again.
--
Kind regards,
Igor V. Kovalenko
Index: hw/sun4m.c
===
RCS file: /cvsroot/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.23
diff -u -r1.23 sun4m.c
--- hw/sun4m.c 7 Jan 2007 20:42:14 - 1.23
+++ hw/sun4m.c 9 Jan 2007 21:23:53 -
@@ -262,6 +262,13 @@
slavio_serial_init(PHYS_JJ_SER, PHYS_JJ_SER_IRQ, serial_hds[1], serial_hds[0]);
fdctrl_init(PHYS_JJ_FLOPPY_IRQ, 0, 1, PHYS_JJ_FDC, fd_table);
main_esp = esp_init(bs_table, PHYS_JJ_ESP, dma);
+
+for (i = 0; i MAX_DISKS; i++) {
+if (bs_table[i]) {
+esp_scsi_attach(main_esp, bs_table[i], i);
+}
+}
+
slavio_misc = slavio_misc_init(PHYS_JJ_SLAVIO, PHYS_JJ_ME_IRQ);
cs_init(PHYS_JJ_CS, PHYS_JJ_CS_IRQ, slavio_intctl);
sparc32_dma_set_reset_data(dma, main_esp, main_lance);
___
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
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
Re: [Qemu-devel] qemu ./qemu-doc.texi ./vl.c slirp/bootp.c slirp...
From: Paul Brook [EMAIL PROTECTED]
Date: 2006/04/16 Sun AM 07:06:58 EDT
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] qemu ./qemu-doc.texi ./vl.c slirp/bootp.c slirp...
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook [EMAIL PROTECTED] 06/04/16 11:06:58
Modified files:
. : qemu-doc.texi vl.c
slirp : bootp.c libslirp.h slirp.c
Log message:
Set slirp client hostname.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.82tr2=1.83r1=textr2=text
@item -net user[,vlan=n] @item -net user[,vlan=n][,hostname=name]
Use the user mode network stack which requires no administrator Use
the user mode network stack which requires no administrator
priviledge to run. priviledge to run. @option{hotname=name} can be used
to specify the client
hostname reported by the builtin DHCP server.
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.170tr2=1.171r1=textr2=text
looking at this, there's a typo (hotsname, vs hostname)
and since you pointed it out to me, there is also the
[dns=a.b.c.d] option that isn't listed.
Thanks for all your support (and putting up with my tpyos)
Regards,
Ben
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
