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
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 :
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:
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 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
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
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,
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
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
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
10 matches
Mail list logo
