Applied on stable branch.
2008/1/13, Andrzej Zaborowski <[EMAIL PROTECTED]>:
> CVSROOT:/sources/qemu
> Module name:qemu
> Changes by: Andrzej Zaborowski 08/01/14 02:56:53
>
> Modified files:
> . : qemu-doc.texi vl.c
>
> Log message:
> Change -drive
Thank you !
Laurent
Le lundi 14 janvier 2008 à 02:56 +, Andrzej Zaborowski a écrit :
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Andrzej Zaborowski 08/01/14 02:56:53
>
> Modified files:
> . : qemu-doc.texi vl.c
>
> Log message:
> Change
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:
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 : l
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.
On 1/7/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/01/07 20:42:14
Modified files:
. : qemu-doc.texi vl.c vl.h
hw : pc.c sun4m.c
Log message:
Revert -disk p
Hi Paul,
Thanks for the explanation. I feel like fixing the alignment issue in the
qemu code is a little above my head right now. However, it turns out that
the alignment issue can be solved on the arm compiler/linker side, by
giving appropriate arguments to the linker (--ro-base 0x8034). The
> 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
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 execut
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
> execut
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" fil
>
> 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 PROTECTE
12 matches
Mail list logo
