[Qemu-devel] Bug(?): WinXP on GNU/Linux, screen "tiling" in VESA modes

[Tero Tilus]

Hi,

This could be a bug...

  http://www.tilus.net/koti/tero/tmp/Screenshot-QEMU.png

I've got XP pro as guest and Ubuntu feisty as host.  Qemu (v 0.8.2) is
from feisty packages.  When using VESA (-std-vga) I get VGA-height (I
think) band from the top part of display repeated on the lower part
(vertical tiling) and lower part not showing.  When mouse cursor is on
upper (visible) part of screen (high enough), it is also mirrored on
lower part and when it is on lower part, it's not visible at all.  It
is as if it were "under" the repeated upper part.  Other than that,
Windows seems to work fine though.  Only I have to find "Start" button
with trial and error.  ;)

If I use VESA display I can not make the problem go away.  Changing
resolution, rebooting and using VNC changes nothing.  If I use Cirrus
emulation the problem disappears.

-- 
Tero Tilus ## 050 3635 235 ## http://www.tilus.net/koti/tero/

[Qemu-devel] qemu (0.9.0) continously segfaults when using "xvncviewer"

[Axel Kittenberger]

Hi List!

Topic says all, We just buyed a new host to run a set of virtual 
machines, and I'm experimenting with kvm/qemu.


I noticed that continous segfaults (when installing Windows 2003 host, 
with -no-acpi and no kernel acceleration) are created when using the 
"xvncviewer" coming with my Ubuntu desktop. I downloaded the binary from 
www.vnc.com. Which doesn't seem to provoke the same segfaults on qemu 
server side. Just wanted to leave you a note.


I downloaded and hand-compiled already the latest qemu release, to be 
sure not to test against an the older release in ubuntu-server which the 
hosts runs with.


Greetings, Axel Kittenberger
(I'm not subscribed to the list, so please CC me, if you have answers)

[Qemu-devel] Bug(?): WinXP on GNU/Linux, screen "tiling" in VESA modes

[Tero Tilus]

Hi,

This could be a bug...

  http://www.tilus.net/koti/tero/tmp/Screenshot-QEMU.png

I've got XP pro as guest and Ubuntu feisty as host.  Qemu (v 0.8.2) is
from feisty packages.  When using VESA (-std-vga) I get VGA-height (I
think) band from the top part of display repeated on the lower part
(vertical tiling) and lower part not showing.  When mouse cursor is on
upper (visible) part of screen (high enough), it is also mirrored on
lower part and when it is on lower part, it's not visible at all.  It
is as if it were "under" the repeated upper part.  Other than that,
Windows seems to work fine though.  Only I have to find "Start" button
with trial and error.  ;)

If I use VESA display I can not make the problem go away.  Changing
resolution, rebooting and using VNC changes nothing.  If I use Cirrus
emulation the problem disappears.

-- 
Tero Tilus ## 050 3635 235 ## http://www.tilus.net/koti/tero/

[Qemu-devel] qemu-user mmap not thread-safe?

[Alexander Graf]

Hi,

while playing around with TLS on i386 i came across this problem which
occurs even when no TLS is used at all. If two threads just malloc()
memory all the time I get a segmentation fault after a short time. Might
this be a serious bug?

If anyone more experienced in the mmap internals of qemu could take a
look at this I'd be really glad Appended is the source file as well as
the compiled i386 binary (glibc 2.3 w/o TLS) to trigger this.

The very same executable works just fine on a real pc.

Thanks a lot,

Alexander Graf


clone.tgz
Description: application/compressed-tar

Re: [Qemu-devel] qemu-user mmap not thread-safe?

[Paul Brook]

On Thursday 24 May 2007, Alexander Graf wrote:
> Hi,
>
> while playing around with TLS on i386 i came across this problem which
> occurs even when no TLS is used at all. If two threads just malloc()
> memory all the time I get a segmentation fault after a short time. Might
> this be a serious bug?

qemu is not even vaguely threadsafe.

Paul

Re : [Qemu-devel] Bug(?): WinXP on GNU/Linux, screen "tiling" in VESA modes

[Sylvain Petreolle]

Please update at least to qemu 0.9.0, and even better CVS.
 
Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Run your favorite Windows apps with free ReactOS : http://www.reactos.org
Listen to non-DRMised Music: http://www.jamendo.com






- Message d'origine 
De : Tero Tilus <[EMAIL PROTECTED]>
À : qemu-devel@nongnu.org
Envoyé le : Jeudi, 24 Mai 2007, 15h00mn 36s
Objet : [Qemu-devel] Bug(?): WinXP on GNU/Linux, screen "tiling" in VESA modes


Hi,

This could be a bug...

  http://www.tilus.net/koti/tero/tmp/Screenshot-QEMU.png

I've got XP pro as guest and Ubuntu feisty as host.  Qemu (v 0.8.2) is
from feisty packages.  When using VESA (-std-vga) I get VGA-height (I
think) band from the top part of display repeated on the lower part
(vertical tiling) and lower part not showing.  When mouse cursor is on
upper (visible) part of screen (high enough), it is also mirrored on
lower part and when it is on lower part, it's not visible at all.  It
is as if it were "under" the repeated upper part.  Other than that,
Windows seems to work fine though.  Only I have to find "Start" button
with trial and error.  ;)

If I use VESA display I can not make the problem go away.  Changing
resolution, rebooting and using VNC changes nothing.  If I use Cirrus
emulation the problem disappears.

-- 
Tero Tilus ## 050 3635 235 ## http://www.tilus.net/koti/tero/

[Qemu-devel] qemu ecc.h vl.c hw/ads7846.c hw/i2c.c hw/i2c.h ...

[Andrzej Zaborowski]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski  07/05/24 18:50:09

Modified files:
.  : ecc.h vl.c 
hw : ads7846.c i2c.c i2c.h ide.c max111x.c max7310.c 
 nand.c pxa2xx.c pxa2xx_dma.c pxa2xx_gpio.c 
 pxa2xx_lcd.c pxa2xx_mmci.c pxa2xx_pic.c 
 pxa2xx_timer.c spitz.c wm8750.c 

Log message:
Savevm/loadvm bits for ARM core, the PXA2xx peripherals and Spitz 
hardware.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/ecc.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.298&r2=1.299
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ads7846.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/i2c.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/i2c.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemu&r1=1.60&r2=1.61
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/max111x.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/max7310.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/nand.c?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemu&r1=1.12&r2=1.13
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_dma.c?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_gpio.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_lcd.c?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_mmci.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_pic.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_timer.c?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemu&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/wm8750.c?cvsroot=qemu&r1=1.1&r2=1.2

[Qemu-devel] qemu monitor.c vl.c

[Andrzej Zaborowski]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski  07/05/24 18:53:22

Modified files:
.  : monitor.c vl.c 

Log message:
Commit NAND image changes on "commit all" or "commit mtd".

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemu&r1=1.72&r2=1.73
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.299&r2=1.300

Re: [Qemu-devel] Timers

[Blue Swirl]

On 5/24/07, Paul Brook <[EMAIL PROTECTED]> wrote:

> > Code looks reasonable to me.  The FIXME means you're changing the timer
> > parameters after starting the timer. I didn't check whether this does
> > anything sensible (this may depend on the device), hence the message.
> > It probably needs some attention when reload == 1 && s->enabled.
> >
> > Note that save/restore is not implemented.  You may wish to implement
> > this
>
> I was thinking that it should be possible to save/restore all vm_clock
> based timers in qemu at QEMUTimer level so that hardware emulation
> doesn't have to bother restoring this. (the "ptimer" would still need
> to save its internal fields).

The problem is that the timer itself doesn't know which device it is attached
to. There's no way to ensure that the state is loaded into the correct
timers. Remember that qemu can be restarted (and all timers reallocated) in
between the save and the load.

There are already qemu_put_timer and qemu_get_timer routines.
I notice that the existing slavio_timer_{save,load} don't use these, so are
probably already broken.


There were bugs in the previous version, this version passes my simple
tests. I implemented save and load methods. If the 64-bit code doesn't
break ARM, it's ready for commit.
Index: qemu/hw/slavio_timer.c
===
--- qemu.orig/hw/slavio_timer.c	2007-05-24 17:12:54.0 +
+++ qemu/hw/slavio_timer.c	2007-05-24 17:54:12.0 +
@@ -48,61 +48,29 @@
  */
 
 typedef struct SLAVIO_TIMERState {
-uint32_t limit, count, counthigh;
-int64_t count_load_time;
-int64_t expire_time;
-int64_t stop_time, tick_offset;
-QEMUTimer *irq_timer;
+ptimer_state *timer;
+uint32_t count, counthigh, reached;
+uint64_t limit;
 int irq;
-int reached, stopped;
+int stopped;
 int mode; // 0 = processor, 1 = user, 2 = system
 unsigned int cpu;
 void *intctl;
 } SLAVIO_TIMERState;
 
 #define TIMER_MAXADDR 0x1f
-#define CNT_FREQ 200
 
 // Update count, set irq, update expire_time
+// Convert from ptimer countdown units
 static void slavio_timer_get_out(SLAVIO_TIMERState *s)
 {
-int out;
-int64_t diff, ticks, count;
-uint32_t limit;
-
-// There are three clock tick units: CPU ticks, register units
-// (nanoseconds), and counter ticks (500 ns).
-if (s->mode == 1 && s->stopped)
-	ticks = s->stop_time;
-else
-	ticks = qemu_get_clock(vm_clock) - s->tick_offset;
-
-out = (ticks > s->expire_time);
-if (out)
-	s->reached = 0x8000;
-// Convert register units to counter ticks
-limit = s->limit >> 9;
-
-if (!limit)
-	limit = 0x7fff >> 9;
-
-// Convert cpu ticks to counter ticks
-diff = muldiv64(ticks - s->count_load_time, CNT_FREQ, ticks_per_sec);
-
-// Calculate what the counter should be, convert to register
-// units
-count = diff % limit;
-s->count = count << 9;
-s->counthigh = count >> 22;
-
-// Expire time: CPU ticks left to next interrupt
-// Convert remaining counter ticks to CPU ticks
-s->expire_time = ticks + muldiv64(limit - count, ticks_per_sec, CNT_FREQ);
+uint64_t count;
 
-DPRINTF("irq %d limit %d reached %d d %" PRId64 " count %d s->c %x diff %" PRId64 " stopped %d mode %d\n", s->irq, limit, s->reached?1:0, (ticks-s->count_load_time), count, s->count, s->expire_time - ticks, s->stopped, s->mode);
-
-if (s->mode != 1)
-	pic_set_irq_cpu(s->intctl, s->irq, out, s->cpu);
+count = s->limit - (ptimer_get_count(s->timer) << 9);
+DPRINTF("get_out: limit %" PRIx64 " count %x%08x\n", s->limit, s->counthigh,
+s->count);
+s->count = count & 0xfe00;
+s->counthigh = count >> 32;
 }
 
 // timer callback
@@ -110,17 +78,17 @@
 {
 SLAVIO_TIMERState *s = opaque;
 
-if (!s->irq_timer)
-return;
 slavio_timer_get_out(s);
+DPRINTF("callback: count %x%08x\n", s->counthigh, s->count);
+s->reached = 0x8000;
 if (s->mode != 1)
-	qemu_mod_timer(s->irq_timer, s->expire_time);
+	pic_set_irq_cpu(s->intctl, s->irq, 1, s->cpu);
 }
 
 static uint32_t slavio_timer_mem_readl(void *opaque, target_phys_addr_t addr)
 {
 SLAVIO_TIMERState *s = opaque;
-uint32_t saddr;
+uint32_t saddr, ret;
 
 saddr = (addr & TIMER_MAXADDR) >> 2;
 switch (saddr) {
@@ -131,60 +99,69 @@
 	// clear irq
 	pic_set_irq_cpu(s->intctl, s->irq, 0, s->cpu);
 	s->reached = 0;
-	return s->limit;
+ret = s->limit & 0x7fff;
 	}
 	else {
 	slavio_timer_get_out(s);
-	return s->counthigh & 0x7fff;
+ret = s->counthigh & 0x7fff;
 	}
+break;
 case 1:
 	// read counter and reached bit (system mode) or read lsbits
 	// of counter (user mode)
 	slavio_timer_get_out(s);
 	if (s->mode != 1)
-	return (s->count & 0x7fff) | s->reached;
+ret = (s->count & 0x7fff) | s->reached;
 	else
-	return s->count;
+   

Re: [Qemu-devel] Timers

[Paul Brook]

> There were bugs in the previous version, this version passes my simple
> tests. I implemented save and load methods. If the 64-bit code doesn't
> break ARM, it's ready for commit.

Works for me on arm.

Paul

[Qemu-devel] qemu Makefile.target vl.h hw/ptimer.c hw/slavio...

[Blue Swirl]

CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/05/24 19:48:41

Modified files:
.  : Makefile.target vl.h 
hw : ptimer.c slavio_timer.c 

Log message:
Change ptimer API to use 64-bit values, add save and load methods
Use ptimers for Sparc32 Slavio

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.175&r2=1.176
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.238&r2=1.239
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ptimer.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_timer.c?cvsroot=qemu&r1=1.10&r2=1.11

Re: [Qemu-devel] Porting QEMU to PalmOS

[Jonathan Kalbfeld]

One definite plus with having QEMU for PalmOS is the ability to run things
like OpenVPN (even if slow) and connect to a VPN back-end.

As is, I use OpenVPN tunnels to link up my QEMU machines on Solaris.

jonathan

On 5/23/07, Wolfgang Schildbach <[EMAIL PROTECTED]>
wrote:


Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical
feature of position independent code.

- Wolfgang

[EMAIL PROTECTED]
wrote on 23.05.2007 13:20:22:

> Hi Johannes,
>
>thanks for your quick response.
> I thought QEMU was already compiled and run on an ARM machine?
> If so, how come that noone else had such problem (I searched for it
> on google),
> and PXA255 is a standard ARM CPU with a few additional instructions.
> And how to make them not come from GOT, those vars are declared as
extern,
> so they are globals?
>
> BR,
>Voda.

> - Original Message 
> From: Johannes Schindelin <[EMAIL PROTECTED]>
> To: sinisa marovic <[EMAIL PROTECTED]>
> Cc: qemu-devel@nongnu.org
> Sent: Wednesday, May 23, 2007 12:48:59 PM
> Subject: Re: [Qemu-devel] Porting QEMU to PalmOS

> Hi,
>
> On Wed, 23 May 2007, sinisa marovic wrote:
>
> > Relocation types that fail are 25 and 26, which are R_ARM_GOTPC and
> > R_ARM_GOT32 respectively. Their names are:
> >
> > _GLOBAL_OFFSET_TABLE_
> > cc_table
> > __op_param1
> > __op_param2
> > __op_param3
> >
> > Is there a way to fix this?
>
> The GOT is an offset table. Many CPUs have fixed-size instruction sets,
> which means that you cannot easily jump to an absolute address, since
the
> address alone would already fill up the size.
>
> Of course, this is a no-no for QEmu, since the _same_ function snippet
> will be reused _multiple_ times. So, the address must not come from a
GOT,
> but be inserted directly into the code.
>
> I do not remember off-hand how I managed to do this a couple of years
ago,
> when I worked on a MIPS host, but there _are_ gcc options to avoid a
GOT.
>
> Hth,
> Dscho
>
>
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A.







--
--
Jonathan Kalbfeld
+1 323 620 6682

[Qemu-devel] ANN: DetaolB version 0.2 is available at sourceforge.net

[Christian MICHON]

Hi lists,

DetaolB is a small live x86 distro, entirely uclibc/busybox based,
to be run either on real hardware or inside qemu. With a modified
kernel, it can also run in colinux and will soon self-build this way.

it's (at least today) at the bleeding edge of uclibc and linux kernel.
there are also some goodies like ldd and tinycc ( a tcc fork that
can compile using uclibc ).

for your bookmarks: http://detaolb.sourceforge.net

there you can find links to the iso file releases. patches will be
available on sf.net soon too, but it's mostly an assembly work,
so do not expect fantastic new linux features.

I also created a separate mailing list for this distro, to avoid
noise on the mailing lists of qemu-devel and uclibc. Future
announces for DetaolB will not bother these 2 ML, and will
be done only at this list:

https://lists.sourceforge.net/lists/listinfo/detaolb-devel

the reason for the name "DetaolB" is not difficult to figure out...
(read reverse!)

the reason for this project is to have the smallest and quickest iso
around (less than 1.4M), while still being useful and packed with
goodies. aufs and squashfs are already in: we're talking about
nice expandability here!

Fabrice: you can include it in your qemu homepage if you want to.

--
Christian

Re: [Qemu-devel] Porting QEMU to PalmOS

[sinisa marovic]

I'm afraid I will have to dissapoint you: it will be only isapc with no
networking or other fancy devices. Main goal is the ability to run dos games.
I do not know how familiar are you with PalmOS developer support. It
is poor, gcc lack many important functions that have to be written from
scratch. When I ported dosbox (which is written in c++) I realized that
there is no support for vectors, iterators, namespaces etc, so I had to
write many operators myself. The biggest problem with QEMU is that
it uses signals a lot, and, guess what, PalmOS has no support for signals
_at_ _all_. I found a way to get things going without them for now, but
this has it's drawbacks. I will have to think about something better later on.

- Original Message 
From: Jonathan Kalbfeld <[EMAIL PROTECTED]>
To: qemu-devel@nongnu.org
Sent: Thursday, May 24, 2007 11:18:48 PM
Subject: Re: [Qemu-devel] Porting QEMU to PalmOS

One definite plus with having QEMU for PalmOS is the ability to run things like 
OpenVPN (even if slow) and connect to a VPN back-end.

As is, I use OpenVPN tunnels to link up my QEMU machines on Solaris.

jonathan 


On 5/23/07, Wolfgang Schildbach <[EMAIL PROTECTED]> wrote: 
Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical
feature of position independent code. 

- Wolfgang

[EMAIL PROTECTED]
wrote on 23.05.2007 13:20:22:

> Hi Johannes,
>
>thanks for your quick response.
> I thought QEMU was already compiled and run on an ARM machine?
> If so, how come that noone else had such problem (I searched for it
> on google),
> and PXA255 is a standard ARM CPU with a few additional instructions. 
> And how to make them not come from GOT, those vars are declared as
extern,
> so they are globals?
>
> BR,
>Voda.

> - Original Message 
> From: Johannes Schindelin < [EMAIL PROTECTED]>
> To: sinisa marovic <[EMAIL PROTECTED]>
> Cc: qemu-devel@nongnu.org
> Sent: Wednesday, May 23, 2007 12:48:59 PM
> Subject: Re: [Qemu-devel] Porting QEMU to PalmOS

> Hi,
>
> On Wed, 23 May 2007, sinisa marovic wrote:
>
> > Relocation types that fail are 25 and 26, which are R_ARM_GOTPC and 
> > R_ARM_GOT32 respectively. Their names are:
> >
> > _GLOBAL_OFFSET_TABLE_
> > cc_table
> > __op_param1
> > __op_param2
> > __op_param3
> >
> > Is there a way to fix this? 
>
> The GOT is an offset table. Many CPUs have fixed-size instruction sets,
> which means that you cannot easily jump to an absolute address, since
the
> address alone would already fill up the size. 
>
> Of course, this is a no-no for QEmu, since the _same_ function snippet
> will be reused _multiple_ times. So, the address must not come from a
GOT,
> but be inserted directly into the code. 
>
> I do not remember off-hand how I managed to do this a couple of years
ago,
> when I worked on a MIPS host, but there _are_ gcc options to avoid a
GOT.
>
> Hth,
> Dscho
> 
>
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A.







-- 
--
Jonathan Kalbfeld
+1 323 620 6682


 

Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

Re: [Qemu-devel] Porting QEMU to PalmOS

[sinisa marovic]

It sure is.
I use prc-tools. It is free, and, well, it's gcc. There is also developer suite 
called CodeWarrior,
but that is for wimps ;) (expensive too). I can give you some guidelines off 
the mailing list
(I do not think others are interested in coding for palm).


- Original Message 
From: Jonathan Kalbfeld <[EMAIL PROTECTED]>
To: qemu-devel@nongnu.org
Sent: Friday, May 25, 2007 1:33:26 AM
Subject: Re: [Qemu-devel] Porting QEMU to PalmOS

Still sounds fantistically fun.

Maybe you can point me in the right direction to write PalmOS programs (.prc's 
right?).

I have some goofy ideas for things to write for my Treo.

jonathan


On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote:
I'm afraid I will have to dissapoint you: it will be only isapc with no
networking or other fancy devices. Main goal is the ability to run dos games.
I do not know how familiar are you with PalmOS developer support. It
is poor, gcc lack many important functions that have to be written from
scratch. When I ported dosbox (which is written in c++) I realized that
there is no support for vectors, iterators, namespaces etc, so I had to
write many operators myself. The biggest problem with QEMU is that
it uses signals a lot, and, guess what, PalmOS has no support for signals
_at_ _all_. I found a way to get things going without them for now, but
this has it's drawbacks. I will have to think about something better later on.
 
- Original Message 
From: Jonathan Kalbfeld < [EMAIL PROTECTED]>
To: qemu-devel@nongnu.org
Sent: Thursday, May 24, 2007 11:18:48 PM 
Subject: Re: [Qemu-devel] Porting QEMU to PalmOS

One definite plus with having QEMU for PalmOS is the ability to run things like 
OpenVPN (even if slow) and connect to a VPN back-end.

As is, I use OpenVPN tunnels to link up my QEMU machines on Solaris. 

jonathan 


On 5/23/07, Wolfgang Schildbach < [EMAIL PROTECTED]> wrote: 
Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical
feature of position independent code. 

- Wolfgang

[EMAIL PROTECTED] 
wrote on 23.05.2007 13:20:22:

> Hi Johannes,
>
>thanks for your quick response.
> I thought QEMU was already compiled and run on an ARM machine?
> If so, how come that noone else had such problem (I searched for it 
> on google),
> and PXA255 is a standard ARM CPU with a few additional instructions. 
> And how to make them not come from GOT, those vars are declared as
extern,
> so they are globals?
> 
> BR,
>Voda.

> - Original Message 
> From: Johannes Schindelin < [EMAIL PROTECTED] >
> To: sinisa marovic <[EMAIL PROTECTED]>
> Cc: qemu-devel@nongnu.org
> Sent: Wednesday, May 23, 2007 12:48:59 PM
> Subject: Re: [Qemu-devel] Porting QEMU to PalmOS

> Hi,
>
> On Wed, 23 May 2007, sinisa marovic wrote:
>
> > Relocation types that fail are 25 and 26, which are R_ARM_GOTPC and 
> > R_ARM_GOT32 respectively. Their names are:
> >
> > _GLOBAL_OFFSET_TABLE_
> > cc_table
> > __op_param1
> > __op_param2
> > __op_param3
> >
> > Is there a way to fix this? 
>
> The GOT is an offset table. Many CPUs have fixed-size instruction sets,
> which means that you cannot easily jump to an absolute address, since
the
> address alone would already fill up the size. 
>
> Of course, this is a no-no for QEmu, since the _same_ function snippet 
> will be reused _multiple_ times. So, the address must not come from a
GOT,
> but be inserted directly into the code. 
>
> I do not remember off-hand how I managed to do this a couple of years 
ago,
> when I worked on a MIPS host, but there _are_ gcc options to avoid a
GOT.
>
> Hth,
> Dscho
> 
>
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A. 







-- 
--
Jonathan Kalbfeld
+1 323 620 6682





Get the free Yahoo! toolbar and rest assured with the added security of spyware 
protection. 



-- 
--
Jonathan Kalbfeld
+1 323 620 6682


 

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

Re: [Qemu-devel] Porting QEMU to PalmOS

[Jonathan Kalbfeld]

Still sounds fantistically fun.

Maybe you can point me in the right direction to write PalmOS programs
(.prc's right?).

I have some goofy ideas for things to write for my Treo.

jonathan

On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote:


I'm afraid I will have to dissapoint you: it will be only isapc with no
networking or other fancy devices. Main goal is the ability to run dos
games.
I do not know how familiar are you with PalmOS developer support. It
is poor, gcc lack many important functions that have to be written from
scratch. When I ported dosbox (which is written in c++) I realized that
there is no support for vectors, iterators, namespaces etc, so I had to
write many operators myself. The biggest problem with QEMU is that
it uses signals a lot, and, guess what, PalmOS has no support for signals
_at_ _all_. I found a way to get things going without them for now, but
this has it's drawbacks. I will have to think about something better later
on.

- Original Message 
From: Jonathan Kalbfeld <[EMAIL PROTECTED]>
To: qemu-devel@nongnu.org
Sent: Thursday, May 24, 2007 11:18:48 PM
Subject: Re: [Qemu-devel] Porting QEMU to PalmOS

One definite plus with having QEMU for PalmOS is the ability to run things
like OpenVPN (even if slow) and connect to a VPN back-end.

As is, I use OpenVPN tunnels to link up my QEMU machines on Solaris.

jonathan

On 5/23/07, Wolfgang Schildbach <
[EMAIL PROTECTED]> wrote:
>
> Try compiling as position-dependent (i.e. not PIC) code. GOT is a
> typical
> feature of position independent code.
>
> - Wolfgang
>
> [EMAIL PROTECTED]
> wrote on 23.05.2007 13:20:22:
>
> > Hi Johannes,
> >
> >thanks for your quick response.
> > I thought QEMU was already compiled and run on an ARM machine?
> > If so, how come that noone else had such problem (I searched for it
> > on google),
> > and PXA255 is a standard ARM CPU with a few additional instructions.
> > And how to make them not come from GOT, those vars are declared as
> extern,
> > so they are globals?
> >
> > BR,
> >Voda.
>
> > - Original Message 
> > From: Johannes Schindelin < [EMAIL PROTECTED]>
> > To: sinisa marovic <[EMAIL PROTECTED]>
> > Cc: qemu-devel@nongnu.org
> > Sent: Wednesday, May 23, 2007 12:48:59 PM
> > Subject: Re: [Qemu-devel] Porting QEMU to PalmOS
>
> > Hi,
> >
> > On Wed, 23 May 2007, sinisa marovic wrote:
> >
> > > Relocation types that fail are 25 and 26, which are R_ARM_GOTPC and
> > > R_ARM_GOT32 respectively. Their names are:
> > >
> > > _GLOBAL_OFFSET_TABLE_
> > > cc_table
> > > __op_param1
> > > __op_param2
> > > __op_param3
> > >
> > > Is there a way to fix this?
> >
> > The GOT is an offset table. Many CPUs have fixed-size instruction
> sets,
> > which means that you cannot easily jump to an absolute address, since
> the
> > address alone would already fill up the size.
> >
> > Of course, this is a no-no for QEmu, since the _same_ function snippet
> > will be reused _multiple_ times. So, the address must not come from a
> GOT,
> > but be inserted directly into the code.
> >
> > I do not remember off-hand how I managed to do this a couple of years
> ago,
> > when I worked on a MIPS host, but there _are_ gcc options to avoid a
> GOT.
> >
> > Hth,
> > Dscho
> >
> >
> > Food fight? Enjoy some healthy debate
> > in the Yahoo! Answers Food & Drink Q&A.
>
>
>
>


--
--
Jonathan Kalbfeld
+1 323 620 6682


--
Get the free Yahoo! 
toolbarand
 rest assured with the added security of spyware protection.





--
--
Jonathan Kalbfeld
+1 323 620 6682

[Qemu-devel] ehci usb in qemu

[Marty Leisner]

I've heard about ehci  usb support -- I just downloaded the latest cvs 
version and there's no ehci there (but I've seen patches with ehci symbols 
at the end of last year).

Mark Burkley talked about a patch -- what's it status?

What I'm looking to do is be able to reverse engineer windows usb devices in 
qemu...

I'm not totally thrilled with wireshark (and linux 2.6.21.x) which has a binary
tracing API -- I'm thinking of adding usb tracing hooks into qemu (the content 
of the
packets are already in user spacewhy stick then into the kernel to monitor 
them?

marty

Re: [Qemu-devel] Porting QEMU to PalmOS

[Jason Brand]

Palm API reference:
http://www.access-company.com/developers/documents/docs/palmos/PalmOSReference/ReferenceTOC.html

You'll need to install (with ports, apt-get, or what have you):
m68k-palmos-gcc
m68k-palmos-gdb (not required, but very useful)
m86k-palmos-binutils
palmos sdk
pilrc

PalmOS has its own C library, which makes it painfully frustrating to
code for at times.  The API reference is invaluable.

Good luck.

On Thu, May 24, 2007 at 04:33:26PM -0700, Jonathan Kalbfeld wrote:
>  Still sounds fantistically fun.
> 
>  Maybe you can point me in the right direction to write PalmOS programs
>  (.prc's right?).
> 
>  I have some goofy ideas for things to write for my Treo.
> 
>  jonathan
> 
>  On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote:
> >
> > I'm afraid I will have to dissapoint you: it will be only isapc with no
> > networking or other fancy devices. Main goal is the ability to run dos
> > games.
> > I do not know how familiar are you with PalmOS developer support. It
> > is poor, gcc lack many important functions that have to be written from
> > scratch. When I ported dosbox (which is written in c++) I realized that
> > there is no support for vectors, iterators, namespaces etc, so I had to
> > write many operators myself. The biggest problem with QEMU is that
> > it uses signals a lot, and, guess what, PalmOS has no support for signals
> > _at_ _all_. I found a way to get things going without them for now, but
> > this has it's drawbacks. I will have to think about something better later
> > on.
> >
> > - Original Message 
> > From: Jonathan Kalbfeld <[EMAIL PROTECTED]>
> > To: qemu-devel@nongnu.org
> > Sent: Thursday, May 24, 2007 11:18:48 PM
> > Subject: Re: [Qemu-devel] Porting QEMU to PalmOS
> >
> > One definite plus with having QEMU for PalmOS is the ability to run things
> > like OpenVPN (even if slow) and connect to a VPN back-end.
> >
> > As is, I use OpenVPN tunnels to link up my QEMU machines on Solaris.
> >
> > jonathan
> >
> > On 5/23/07, Wolfgang Schildbach <
> > [EMAIL PROTECTED]> wrote:
> > >
> > > Try compiling as position-dependent (i.e. not PIC) code. GOT is a
> > > typical
> > > feature of position independent code.
> > >
> > > - Wolfgang
> > >
> > > [EMAIL PROTECTED]
> > > wrote on 23.05.2007 13:20:22:
> > >
> > > > Hi Johannes,
> > > >
> > > >thanks for your quick response.
> > > > I thought QEMU was already compiled and run on an ARM machine?
> > > > If so, how come that noone else had such problem (I searched for it
> > > > on google),
> > > > and PXA255 is a standard ARM CPU with a few additional instructions.
> > > > And how to make them not come from GOT, those vars are declared as
> > > extern,
> > > > so they are globals?
> > > >
> > > > BR,
> > > >Voda.
> > >
> > > > - Original Message 
> > > > From: Johannes Schindelin < [EMAIL PROTECTED]>
> > > > To: sinisa marovic <[EMAIL PROTECTED]>
> > > > Cc: qemu-devel@nongnu.org
> > > > Sent: Wednesday, May 23, 2007 12:48:59 PM
> > > > Subject: Re: [Qemu-devel] Porting QEMU to PalmOS
> > >
> > > > Hi,
> > > >
> > > > On Wed, 23 May 2007, sinisa marovic wrote:
> > > >
> > > > > Relocation types that fail are 25 and 26, which are R_ARM_GOTPC and
> > > > > R_ARM_GOT32 respectively. Their names are:
> > > > >
> > > > > _GLOBAL_OFFSET_TABLE_
> > > > > cc_table
> > > > > __op_param1
> > > > > __op_param2
> > > > > __op_param3
> > > > >
> > > > > Is there a way to fix this?
> > > >
> > > > The GOT is an offset table. Many CPUs have fixed-size instruction
> > > sets,
> > > > which means that you cannot easily jump to an absolute address, since
> > > the
> > > > address alone would already fill up the size.
> > > >
> > > > Of course, this is a no-no for QEmu, since the _same_ function snippet
> > > > will be reused _multiple_ times. So, the address must not come from a
> > > GOT,
> > > > but be inserted directly into the code.
> > > >
> > > > I do not remember off-hand how I managed to do this a couple of years
> > > ago,
> > > > when I worked on a MIPS host, but there _are_ gcc options to avoid a
> > > GOT.
> > > >
> > > > Hth,
> > > > Dscho
> > > >
> > > >
> > > > Food fight? Enjoy some healthy debate
> > > > in the Yahoo! Answers Food & Drink Q&A.
> > >
> > >
> > >
> > >
> >
> >
> > --
> > --
> > Jonathan Kalbfeld
> > +1 323 620 6682
> >
> >
> > --
> > Get the free Yahoo! 
> > toolbarand
> >  
> > rest assured with the added security of spyware protection.
> >
> 
> 
> 
>  -- 
>  --
>  Jonathan Kalbfeld
>  +1 323 620 6682


pgpSH8Pul5NJ5.pgp
Description: PGP signature