On Tue, 2007-04-17 at 07:02 +0200, Lorenzo Campedelli wrote:
Hello,
is support for the 440GX processor foreseen anytime soon?
(I noticed it i labelled with TODO...)
Yes, once some usable PowerPC 405 board will be committed, the next step
is to implement BookE PowerPC. BookE PowerPC is the
On Mon, 2007-04-16 at 22:47 +, Thiemo Seufer wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Thiemo Seufer ths 07/04/16 22:47:54
Modified files:
hw : pckbd.c
Log message:
Support it_shift for mmapped pckbd.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/04/18 11:15:57
Modified files:
target-i386: helper.c
Log message:
Revert, this is already fixed in a better way.
CVSWeb URLs:
J. Mayer wrote:
On Mon, 2007-04-16 at 22:47 +, Thiemo Seufer wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/04/16 22:47:54
Modified files:
hw : pckbd.c
Log message:
Support it_shift for mmapped pckbd.
On Wed, 2007-04-18 at 14:06 +0100, Thiemo Seufer wrote:
J. Mayer wrote:
On Mon, 2007-04-16 at 22:47 +, Thiemo Seufer wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Thiemo Seufer ths 07/04/16 22:47:54
Modified files:
hw : pckbd.c
Hi all,
I have collected all drivers I could for GD-5446 in
http://www.claunia.com/qemu/drivers/index.html
If someone can send me drivers for other OSes and for all the other
devices of qemu (sound, net, so on), so I can upload them.
As they are old devices they are getting difficult to get
in qemu's doc, i found it support some arm integrator/cp board and arm926e
or arm1026e cpu.
but if i can choose to use arm926e cpu or arm1026e cpu ???
when i build a linux kernel image, i let it run on qemu, but i found it get
the architecture ID is 113, and 113 defined in mach-types is
On Wednesday 18 April 2007 16:19, tang peilei wrote:
in qemu's doc, i found it support some arm integrator/cp board and arm926e
or arm1026e cpu.
but if i can choose to use arm926e cpu or arm1026e cpu ???
Use the -cpu commandline option.
when i build a linux kernel image, i let it run on
If you're interressed in such a feature, you may take a look of what
I've done in hw/ppc405_uc.c. There are some device sharing the same
memory page on those microcontrollers so I introduced a fake device
called mmio that allow to register multiple devices into a single page
in Qemu. I
On Tue, 17 Apr 2007, Stuart Anderson wrote:
I've continued to work on this all week, and I still haven't managed to
solve it. I've chased down a lot of paths, but none of them have lead to
a solution. Here is a summary of the situation now.
* programs other than bash will run
* bash --version
Hi,
Aurelien's patch is still missing in CVS HEAD.
I resend it here with a small address fix.
Please add this patch to CVS. It is needed for PCI devices like
those in eepro100.c.
Thank you
Stefan
Aurelien Jarno schrieb:
I don't have such messages in the build log. I am using a 2.6.18
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/04/18 17:56:03
Modified files:
. : vl.c
Log message:
Win32 Tap inferface PPC Guest issue, by Ely Soto.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/04/18 18:11:47
Modified files:
. : vl.c
Log message:
Fix compiler warning.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.281r2=1.282
On Tue, 2007-04-17 at 16:20 -0400, Stuart Anderson wrote:
Just found a small problem w/ the termios structure as defined for PPC
linux user. It doesn't match the one in include/asm-powerpc/termbits.h.
Index: linux-user/ppc/termbits.h
On Wed, 2007-04-18 at 13:31 -0400, Stuart Anderson wrote:
On Tue, 17 Apr 2007, Stuart Anderson wrote:
I've continued to work on this all week, and I still haven't managed to
solve it. I've chased down a lot of paths, but none of them have lead to
a solution. Here is a summary of the
On Wed, 18 Apr 2007, J. Mayer wrote:
With this change, both host and target 'stty -a' give the same output.
Thanks. I'll take a better look to this patch then apply. There maybe
the same issue in the ppc64 strucutre ?
Yes, it looks like the same changes it needed in
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1 07/04/18 19:21:38
Modified files:
hw : slavio_serial.c
Log message:
Fix keyboard detection bugs
CVSWeb URLs:
Andrzej,
setting notsc makes the difference (yesterday I forgot to start
lilo after modifying /etc/lilo.conf to include notsc). Now it
work even with -kernel-kqemu. Not fully tested though, but much
better than before.
Thanks,
Werner
andrzej zaborowski wrote:
Hi,
On 17/04/07, Werner
On Wed, 18 Apr 2007, J. Mayer wrote:
You're right: I think all TLS specific code is located in the glibc.
In my last tracing through qemu.log, I did check for r2 references, and
there was one store near the beginning that looked like what glibc would
do (r2 = ptr+0x700), and the rest of the
On 16/04/07, tang peilei [EMAIL PROTECTED] wrote:
thank you for your help.
is this config you build your kernel and run in qemu ?
and can you debug yur kernel image in qemu ? i tried the gdb debug ,but it
failed.
This GDB was configured as --host=i686-pc-linux-gnu
Andrzej,
just another remark: after setting the kernel parameter to notsc
the kernel now detects the CPU correctly. Without this setting the
CPU detetion was wrong (displays the wrong CPU type, frequency, etc).
Are there any know side-effects if notsc (no time stamp counter) is
set?
Regards,
On 4/18/07, Stuart Anderson [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007, J. Mayer wrote:
You're right: I think all TLS specific code is located in the glibc.
In my last tracing through qemu.log, I did check for r2 references, and
there was one store near the beginning that looked like what
Hi,
On 18/04/07, Werner Dittmann [EMAIL PROTECTED] wrote:
Andrzej,
just another remark: after setting the kernel parameter to notsc
the kernel now detects the CPU correctly. Without this setting the
CPU detetion was wrong (displays the wrong CPU type, frequency, etc).
Are there any know
On Wed, 18 Apr 2007, Igor Kovalenko wrote:
This should be solved for x86_64 host with -mtune=nocona patch
posted a while ago.
I'll go dig that up.
The problem is with dyngen being confused by repz retq sequence.
That's what caught my attention earlier today. It was only showing up in
two
On 4/19/07, Stuart Anderson [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007, Igor Kovalenko wrote:
This should be solved for x86_64 host with -mtune=nocona patch
posted a while ago.
I'll go dig that up.
Here, http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00198.html
The problem is
On Thu, 19 Apr 2007, Igor Kovalenko wrote:
as discussed before, to do this in dyngen you need to know the context
better or you'll skip more than intended; that amounts to moving a
large bit of decoder there as far as I understand that
Yes, it was a quick hack along w/ visual inspection of
Are there no comments?
What is needed to get this fixed in QEMU CVS?
Do you need additional information?
Stefan
Here is a quick hack patch for this problem:
Index: cpu-exec.c
===
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving
On Thursday 12 April 2007 12:16 pm, eady wrote:
I'm still looking for any suggestions on how to save and restore the
target cpu state from within a custom instruction in op.c. I basically
want a custom instruction to save the cpu state to a data structure and
then continue on normally, a
On 18/04/07, Rob Landley [EMAIL PROTECTED] wrote:
On Thursday 12 April 2007 12:16 pm, eady wrote:
I'm still looking for any suggestions on how to save and restore the
target cpu state from within a custom instruction in op.c. I basically
want a custom instruction to save the cpu state to a
Inspired by Blue Swirl's statement in an earlier email that SunOS testing
can now commence against the latest SVN snapshot, i thought that i may
finally be able to contribute.
I have available:
Solaris 1.0.1 (SunOS 4.1.4)
Solaris 2.4
Solaris 2.5
Solaris 6.5 (SPARC)
Solaris 7.0 (SPARC)
Solaris
30 matches
Mail list logo
