Hi all,
I found that Qemu ARM system simulates ARM926EJ-S and
ARM1026EJ-S processor. And I found on ARM website that
the speed of these CPUs vary from 266 to 540 MHz.
Could you tell me the exact speed of the ARM926EJ-S
and ARM1026EJ-S processor simulated by Qemu? It's very
important for me to
Hi all,
we had a problem compiling the linux kernel using for an
arm big endian target in the qemu-armeb environment.
The compilation stopped when executing the split-include utility during
the kernel compilation phase: split-include exited with an error of the
stat64 syscall, executed
Tieu Ma Dau wrote:
Hi all,
I found that Qemu ARM system simulates ARM926EJ-S and
ARM1026EJ-S processor. And I found on ARM website that
the speed of these CPUs vary from 266 to 540 MHz.
Could you tell me the exact speed of the ARM926EJ-S
and ARM1026EJ-S processor simulated by Qemu? It's very
On Tuesday 12 September 2006 08:20, Tieu Ma Dau wrote:
Hi all,
I found that Qemu ARM system simulates ARM926EJ-S and
ARM1026EJ-S processor. And I found on ARM website that
the speed of these CPUs vary from 266 to 540 MHz.
Could you tell me the exact speed of the ARM926EJ-S
and ARM1026EJ-S
Paul Brook wrote:
Modern CPUs are complicated, with many factors effecting execution speed
(pipeline interlocks, multiple levels of cache). A cycle accurate simulator
will generally be orders of magnitude slower than qemu.
Would it be feasible to just limit the number of instructions qemu
On Tuesday 12 September 2006 14:19, Markus Schiltknecht wrote:
Paul Brook wrote:
Modern CPUs are complicated, with many factors effecting execution speed
(pipeline interlocks, multiple levels of cache). A cycle accurate
simulator will generally be orders of magnitude slower than qemu.
Paul Brook wrote:
IMHO a benchmarking setup that doesn't reliably correspond to real system
performance is worse than useless.
Agreed. So let's see what's needed to get a reliably corresponding
system. I'm interested in three layers: CPU, hard disk and network.
Networking is the simplest, I
How much do misses on the branch prediction level cost? How much
pipeline interlocks? I don't think those would be _that_ dramatic. Since
today's compilers are said to be optimizing quite well...
It all depends on the code you're running. Certainly branch prediction can
have a major effect if
Now, CPUs is where I have only a vague idea of what would be needed to
simulate. I know there are up to three levels of caches and main memory,
which all have different access times. The CPU itself has a pipeline and
branch prediction and such which could invalidate the contents of
Hi,
Laurent DESNOGUES wrote:
The most complex thing to accurately simulate a modern
CPU (including ARMs) is the data cache and by far.
Hm... you have to elaborate on that one. Aren't those caches like other
caches, too? With well known algorithms like LRU?
In
comparison, getting accurate
The most complex thing to accurately simulate a modern
CPU (including ARMs) is the data cache and by far.
Hm... you have to elaborate on that one. Aren't those caches like other
caches, too? With well known algorithms like LRU?
Data caches typically do many things in one cycle; for
I am trying to install Windows Vista RC1 in QEMU (CVS snapshot from
23/08/06) on a Linux host and I am getting the STOP error A5. Someone
reported this to the list several months ago and apparently it is ACPI
related, and someone suggested an upgrade to QEMU 0.8.2. Well, this
problem is still
Laurent DESNOGUES wrote:
On top of that try to find a specification for data
side behaviour, these beasts are not documented for
two reasons:
- they are heavily optimized and so not easily
described
- they often define the efficiency of a CPU and
so are considered as secret.
That might be
On top of that try to find a specification for data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
I have at least one 450Mhz k6 in my spare bedroom. I'll by happy to
sell it to you as a platform for running debian and qemu. I'm sure it's
performance would be lower than most of the current amd processors,
though it might not be slower than some of the current intel chips,
(*grin*).
Laurent DESNOGUES [EMAIL PROTECTED] writes:
There is a company that claims to be able to accurately
simulate an at 200 Mhz (http://www.vastsystems.com). I
bet there are using statistical cycle counting and so
are probably very wrong :)
Well, their simulation speed depends on the kind of code
Hi,
I wrote a device that is connect to a host program for data exchange via socket.
The problem is that qemu do something and block the socket system call. If I capture the perror it return (in the host):
Interrupted system call
So there should be something in qemu that delete the system call.
On Tuesday 12 September 2006 23:51, Alessandro Corradi wrote:
Hi,
I wrote a device that is connect to a host program for data exchange via
socket.
The problem is that qemu do something and block the socket system call. If
I capture the perror it return (in the host):
Interrupted system call
The attached patch makes two changes needed to boot Linux on qemu with
a large (256KB) LinuxBIOS image instead of the built-in BIOS:
- Increases the space set aside for the BIOS from 256KB to 2MB; this
could of course be increased further, but 2MB seems to be the largest
EEPROM hardware
Currently qemu's i440FX PCI bridge emulation code does not set the
registers indicating the amount of RAM installed in each DIMM slot.
LinuxBIOS relies on this information to properly set up RAM before
booting Linux.
The attached patch sets a i440FX configuration register indicating the
highest
20 matches
Mail list logo
