CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/24 03:13:04
Modified files:
. : Makefile.target
hw : arm-misc.h armv7m_nvic.c stellaris.c
Added files:
hw : stellaris_enet.c
Log message:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/24 03:09:07
Modified files:
hw : arm-misc.h arm_gic.c armv7m_nvic.c stellaris.c
Log message:
ARMv7-M SysTick fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm-mis
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/11/24 02:56:36
Modified files:
hw : ppc.c ppc405_uc.c ppc4xx_devs.c ppc_chrp.c
ppc_oldworld.c ppc_prep.c
Log message:
More PowerPC debug print fixes - hardwa
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/11/24 02:03:56
Modified files:
target-ppc : cpu.h exec.h helper.c op_helper.c translate.c
Log message:
Fix incorrect debug prints (reported by Paul Brook).
Remove obsolete / duplicate
On Sat, 2007-11-24 at 02:32 +0100, J. Mayer wrote:
> On Sat, 2007-11-24 at 00:52 +, Paul Brook wrote:
> > > > By your own admission, we can get away with not calculating the
> > > > high 32 bit of the register. If follows that the high bits are
> > > > completely
> > > > meaningless.
> > >
>
On Sat, 2007-11-24 at 00:52 +, Paul Brook wrote:
> > > By your own admission, we can get away with not calculating the
> > > high 32 bit of the register. If follows that the high bits are completely
> > > meaningless.
> >
> > Not completelly. There are even some way to do 64 bits computations
> Well, I admit I've invented the term "ppc32", but there are dozens of
> 32-bit PowerPC chips. I'd be amazed if they do 64-bit computations or have
> 64-bit GPRs.
Indeed not. Valgrind implements the 32-bit PPC user-space instruction set
quite adequately using 32-bit computations throughout. No
> > By your own admission, we can get away with not calculating the
> > high 32 bit of the register. If follows that the high bits are completely
> > meaningless.
>
> Not completelly. There are even some way to do 64 bits computations when
> running in 32 bits mode... Some may see this as an archi
J. Mayer wrote:
[snip]
> > Showing more than 32 bits of register
> > is completely bogus.
>
> No. It's showing the full CPU state, which can be more than what the
> application (or the OS, when running virtualized on a real CPU) could
> see. The OS cannot see the whole CPU state, but Qemu must i
> There is a chance that when using "unix" or "dynticks" clock, the
> signal arrives when no cpu is executing.
I've seen similar stalls, but not managed to track down the source. Your
analysis seems correct.
> + /* cause an interrupt in the first cpu that tries to start running */
> + if
On Fri, 2007-11-23 at 22:23 +, Paul Brook wrote:
> > > I think what you mean is that they work the way that ppc64 is defined, to
> > > remain compatible with ppc32. IMHO this is entirely irrelevant as we're
> > > emulating a ppc32. You could replace the high bits with garbage and
> > > nothin
Paul Brook wrote:
> > > I think what you mean is that they work the way that ppc64 is defined, to
> > > remain compatible with ppc32. IMHO this is entirely irrelevant as we're
> > > emulating a ppc32. You could replace the high bits with garbage and
> > > nothing would ever be able to tell the dif
Hi,
There is a chance that when using "unix" or "dynticks" clock, the
signal arrives when no cpu is executing. The probability is high when
using dynticks and a timer is scheduled to expire very soon so that a
signal is delivered very soon after a previous signal. When that
happens cpu_single_env
> > I think what you mean is that they work the way that ppc64 is defined, to
> > remain compatible with ppc32. IMHO this is entirely irrelevant as we're
> > emulating a ppc32. You could replace the high bits with garbage and
> > nothing would ever be able to tell the difference.
>
> PowerPC is a
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/11/23 22:16:59
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Revert foolish patch.
CVSWeb URLs:
http://cvs.savannah.gnu.org/vi
On Fri, 2007-11-23 at 21:36 +, Paul Brook wrote:
> > Then I took a closer look to the code, to ensure I was not wrong.
> > The PowerPC 32 on 64 bits hosts is implemented the same way that the
> > specification says a PowerPC in 32 bits mode should be. Then higher bits
> > are not garbage. They
> Then I took a closer look to the code, to ensure I was not wrong.
> The PowerPC 32 on 64 bits hosts is implemented the same way that the
> specification says a PowerPC in 32 bits mode should be. Then higher bits
> are not garbage. They are what the PowerPC specification say they should
> be (apar
On Fri, 2007-11-23 at 19:10 +, Paul Brook wrote:
> > > The old code before the patch is obviously broken. It's mixing 64-bit
> > > (ppc_gpr_t) and 32-bit (target_ulong) values.
> >
> > It seems you do not understand that what was done was correct. It's not
> > mixing two different types. GPR a
On Fri, 2007-11-23 at 19:10 +, Paul Brook wrote:
> > > The old code before the patch is obviously broken. It's mixing 64-bit
> > > (ppc_gpr_t) and 32-bit (target_ulong) values.
> >
> > It seems you do not understand that what was done was correct. It's not
> > mixing two different types. GPR a
> > The old code before the patch is obviously broken. It's mixing 64-bit
> > (ppc_gpr_t) and 32-bit (target_ulong) values.
>
> It seems you do not understand that what was done was correct. It's not
> mixing two different types. GPR are of ppc_gpr_t type and should be
> displayed this way.
> It's
On Fri, 2007-11-23 at 19:42 +0100, Jocelyn Mayer wrote:
> On Fri, 2007-11-23 at 18:22 +, Paul Brook wrote:
> > > Furthermore this patch was made in a brainless way, it will be reverted
> > > asap.
> > > If you think there is a bug in someone else code, submit it a patch, if
> > > it's cleaver
On Fri, 2007-11-23 at 18:22 +, Paul Brook wrote:
> > Furthermore this patch was made in a brainless way, it will be reverted
> > asap.
> > If you think there is a bug in someone else code, submit it a patch, if
> > it's cleaver and addresses a real bug (which is not the case here) it
> > will
> Furthermore this patch was made in a brainless way, it will be reverted
> asap.
> If you think there is a bug in someone else code, submit it a patch, if
> it's cleaver and addresses a real bug (which is not the case here) it
> will be accepted and merged.
The old code before the patch is obviou
On Fri, 2007-11-23 at 17:33 +, Paul Brook wrote:
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Paul Brook 07/11/23 17:33:13
>
> Modified files:
> hw : ppc_oldworld.c
> target-ppc : cpu.h helper.c op_helper.c
>
> Log message:
> Fix
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/23 17:33:13
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Fix ppc32 register dumps on 64-bit hosts.
CVSWeb URLs:
http://cv
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/23 16:54:00
Modified files:
. : exec.c
Log message:
Fix va_list reuse in cpu_abort.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.115&r2=1.116
andrzej zaborowski wrote:
On 21/11/2007, dara burke <[EMAIL PROTECTED]> wrote:
Hi Guys,
I've been looking around for a solution to this problem that I've been
having with qemu on ubuntu Gutsy. It seemed to work fine on Feisty, but I
haven't been able to find anyone else with a similar compla
Bugs item #1837091, was opened at 2007-11-23 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1837091&group_id=180599
Please note that this message will contain a full copy
On Fri, Nov 23, 2007 at 02:48:34PM +0100, andrzej zaborowski wrote:
> > If that's really the case, I'm curious why it's distributed in its
> > binary form rather than being built at runtime.
> build-time?
Yes, my mistake :)
> Perhaps because the (cross-)compiler used to build the BIOS is not
> pr
Soren Hansen wrote:
> On Thu, Nov 22, 2007 at 01:47:22PM -0500, Markus Schulz wrote:
> > Thank you for your response; I think the file can be found here:
> > http://cvs.savannah.nongnu.org/viewvc/qemu/pc-bios/?root=qemu
>
> > As far as I understand Qemu uses the BIOS from the Bochs project and
> >
On 23/11/2007, Soren Hansen <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 22, 2007 at 01:47:22PM -0500, Markus Schulz wrote:
> > Thank you for your response; I think the file can be found here:
> > http://cvs.savannah.nongnu.org/viewvc/qemu/pc-bios/?root=qemu
>
> > As far as I understand Qemu uses the B
Hi,
I would like to modify Qemu code so that I can log guest memory
reads on certain area of memory. Guest is PPC PREP and area I like to
monitor is Residual data area. How should I do this? Where to start?
Tero
On Thu, Nov 22, 2007 at 01:47:22PM -0500, Markus Schulz wrote:
> Thank you for your response; I think the file can be found here:
> http://cvs.savannah.nongnu.org/viewvc/qemu/pc-bios/?root=qemu
> As far as I understand Qemu uses the BIOS from the Bochs project and
> the diff is applied for Qemu an
33 matches
Mail list logo
