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 fini
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 i
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
imp
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
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
sim
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
> 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
> pi
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; f
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 occur
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 t
> > 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*).
--ric
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
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 ca
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 sys
How far away is QEMU from being able to run Windows on a MIPS (IRIX)
machine? I looked through the code and I'm not sure what is missing. I
see several files related to mips. Are these all for emulating mips?
Mathew
___
Qemu-devel mailing list
Qemu
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 currentl
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 R
21 matches
Mail list logo
