headers
Peter Teoh | 1 Jun 2008 02:09
Picon
Gravatar

Re: qemu - how to output the bootup message?

Oh yes....this is an impt keyword.....I found something....thanks.

On 5/31/08, Mulyadi Santosa <mulyadi.santosa <at> gmail.com> wrote:
> Hi
>
>
>  On Sat, May 31, 2008 at 3:34 PM, Peter Teoh <htmldeveloper <at> gmail.com> wrote:
>  > All the initial bootup message output in the graphical display of QEMU - how
>  > do I log all them into another file?
>
>
> maybe you need to instruct the kernel to enable serial console. Then
>  invoke qemu to use -nographic....
>
>  regards,
>
>
>  Mulyadi.
>
>
>

--

-- 
Regards,
Peter Teoh
Permalink | Reply | 0 comments |
headers
Peter Teoh | 1 Jun 2008 02:09
Picon
Gravatar

Re: Mount errors in QEMU

On 5/31/08, Mulyadi Santosa <mulyadi.santosa <at> gmail.com> wrote:
> Hi...
>
>  maybe your "root=' needs to point to the LVM volume instead of real
>  partition. ANd just make sure your kernel already included LVM
>  support...be it LVM version 1 or 2.
>
>  regards,
>
>
>  Mulyadi.
>
>

Thanks for the reply.   As shown in "df", the root is not at the vg
level, as vg is just for storing a different set of data.

But I did try anyway.   Let me try again...

Thanks Mulyadi..
>

--

-- 
Regards,
Peter Teoh
Permalink | Reply | 0 comments |
headers
Paul Brook | 1 Jun 2008 02:06
Gravatar

Re: Re: [PATCH 0/5] Debugger enhancements

> I don't think it is a good idea to say that breakpoints/watchpoints
> apply to all processors. Such behavior should be handled at a higher level.
>
> It would also be interesting if the watchpoint/breakpoint implementation
> could be used to implement CPU watchpoints and breakpoints (I am
> thinking about the x86 DRx registers here).

Watchpoints and breakpoints are architecture independent debugger features. 
The gdb break/watchpoints should be independent of any user visible debug 
hardware.

I agree it probably makes sense for both to share an implementation though.

> If this is the wanted behavior then the same system as the Self
> Modifying Code on x86 should be used. Basically it consists in doing as
> a MMU fault and single stepping one instruction after. Unfortunately I
> fear the implementation will be complicated.

FWIW I'm planning on reviving the instruction counting patches and making some 
modifications to the mmio TLB handling, which should provide infrastructure 
for doing this in a better way.

Paul
Permalink | Reply | 0 comments |
headers
Richard Sandiford | 1 Jun 2008 09:50
Picon
Picon

Re: [4622] Fix for 32-bit MIPS.

Hi Thiemo,

Thanks for applying the patches, and sorry for the fallout on 32-bit
targets from the DIV patch.

Thiemo Seufer <ths <at> networkno.de> writes:
>  <at>  <at>  -1904,15 +1904,16  <at>  <at> 
>              {
>                  TCGv r_tmp1 = tcg_temp_new(TCG_TYPE_I64);
>                  TCGv r_tmp2 = tcg_temp_new(TCG_TYPE_I64);
> +                TCGv r_tmp3 = tcg_temp_new(TCG_TYPE_I64);
>  
> -                tcg_gen_ext32s_tl(cpu_T[0], cpu_T[0]);
> -                tcg_gen_ext32s_tl(cpu_T[1], cpu_T[1]);
> -                tcg_gen_div_i64(r_tmp1, cpu_T[0], cpu_T[1]);
> -                tcg_gen_rem_i64(r_tmp2, cpu_T[0], cpu_T[1]);
> -                tcg_gen_ext32s_tl(r_tmp1, r_tmp1);
> -                tcg_gen_ext32s_tl(r_tmp2, r_tmp2);
> -                gen_store_LO(r_tmp1, 0);
> -                gen_store_HI(r_tmp2, 0);
> +                tcg_gen_ext_tl_i64(r_tmp1, cpu_T[0]);
> +                tcg_gen_ext_tl_i64(r_tmp2, cpu_T[1]);
> +                tcg_gen_div_i64(r_tmp3, r_tmp1, r_tmp2);
> +                tcg_gen_rem_i64(r_tmp2, r_tmp1, r_tmp2);
> +                tcg_gen_trunc_i64_tl(cpu_T[0], r_tmp3);
> +                tcg_gen_trunc_i64_tl(cpu_T[1], r_tmp2);
> +                gen_store_LO(cpu_T[0], 0);
> +                gen_store_HI(cpu_T[1], 0);
>              }
>              gen_set_label(l1);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Федорченко Леонид | 1 Jun 2008 08:18
Picon
Favicon

qemu & wine

In you documentation wrote "Download the binary x86 Wine install (`qemu-XXX-i386-wine.tar.gz' on the
QEMU web page)". But I can`t find it. 

  How can I run wine with qemu on ppc?
Permalink | Reply | 1 comment |
headers
Jamie Lokier | 1 Jun 2008 14:38

Re: [PATCH 0/5] Debugger enhancements

Paul Brook wrote:
> On most targets watchpoint traps occur after the instruction
> completes, so you have to defer the DEBUG exception.  Normal MMU
> faults occur before the instruction completes.

Ok.  It might be a useful architecture-independent debugging feature
to _also_ have the ability to trap a watchpoint before the memory
access though - especially writes.  Are there any tracing tools which
use the gdbstub support and could make use of that?  Can GDB make use
of that?

-- Jamie
Permalink | Reply | 1 comment |
headers
Blue Swirl | 1 Jun 2008 14:49
Picon

[4638] Fix compilation warning

Revision: 4638
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=4638
Author:   blueswir1
Date:     2008-06-01 12:49:32 +0000 (Sun, 01 Jun 2008)

Log Message:
-----------
Fix compilation warning

Modified Paths:
--------------
    trunk/hw/esp.c

Modified: trunk/hw/esp.c
===================================================================
--- trunk/hw/esp.c	2008-05-31 16:33:53 UTC (rev 4637)
+++ trunk/hw/esp.c	2008-06-01 12:49:32 UTC (rev 4638)
 <at>  <at>  -577,7 +577,7  <at>  <at> 

     qemu_put_buffer(f, s->rregs, ESP_REGS);
     qemu_put_buffer(f, s->wregs, ESP_REGS);
-    qemu_put_be32s(f, &s->ti_size);
+    qemu_put_be32s(f, (uint32_t *)&s->ti_size);
     qemu_put_be32s(f, &s->ti_rptr);
     qemu_put_be32s(f, &s->ti_wptr);
     qemu_put_buffer(f, s->ti_buf, TI_BUFSZ);
 <at>  <at>  -599,7 +599,7  <at>  <at> 

     qemu_get_buffer(f, s->rregs, ESP_REGS);
     qemu_get_buffer(f, s->wregs, ESP_REGS);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Lock | 1 Jun 2008 15:15
Picon

Re: osdep.c patch (FreeBSD hosts)

On Fri, May 30, 2008 at 01:03:05AM +0200, Juergen Lock wrote:
> On Fri, May 30, 2008 at 12:57:13AM +0200, Juergen Lock wrote:
> > On Thu, May 29, 2008 at 11:54:31PM +0200, Fabrice Bellard wrote:
> > > Is it really needed to mmap() the RAM on FreeBSD ? This is a Linux
> > > specific hack, and it may even be obsolete with recent Linux kernels.
> > > 
> > Hmm actually I don't know...  You think the...
> > 
> > > > +#else
> > > > +    ptr = mmap(NULL, 
> > > > +               size, 
> > > > +               PROT_WRITE | PROT_READ, MAP_PRIVATE|MAP_ANON, 
> > > > +               -1, 0);
> > > > +#endif
> > 
> > could be replaced by just malloc?  Or would there be align issues too?
> 
> ..and I just checked the manpage, our malloc page-aligns too (for sizes >=
> pagesize), so at least that shouldn't be an issue.

Ok and I just tested the following patch and it worked for me:

Index: qemu/osdep.c
 <at>  <at>  -83,7 +83,9  <at>  <at> 

 #if defined(USE_KQEMU)

+#ifndef __FreeBSD__
 #include <sys/vfs.h>
+#endif
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Weil | 1 Jun 2008 15:28
Picon

Re: [4496][Bug] Switch most MIPS logical and arithmetic instructions to TCG.

Since Qemu r4496, r4497, MIPS Malta no longer boots in big endian mode
(little endian still works). The Linux kernel hangs in prom_putchar.

A comparision of qemu.log shows a regression for at least rotr
(see extracts of qemu.log for r4495 and r4497). There seems to be
another regression for the code in prom_putchar.

r4497 also changes the initial values of the register HI, LO.
I patched these differences in the listings below.

Stefan

r4495 (register a2 changes correctly):

pc=0x80458760 HI=0x033d59d4 LO=0x033d5a24 ds 0090 80458740 0
GPR00: r0 00000000 at 00000008 v0 c0000000 v1 c0000000
GPR04: a0 bbe00000 a1 80480000 a2 00c00000 a3 bbe00048
GPR08: t0 bbe000f0 t1 00000020 t2 000000a0 t3 80490000
GPR12: t4 80480000 t5 80480000 t6 8042fe2e t7 ffffffff
GPR16: s0 80480000 s1 8042ffa0 s2 00000000 s3 00000000
GPR20: s4 00000000 s5 00000000 s6 80480000 s7 00000000
GPR24: t8 00000001 t9 00000006 k0 00000000 k1 00000000
GPR28: gp 8042e000 sp 8042ff08 s8 00000000 ra 80458564
CP0 Status  0x10000000 Cause   0x00000400 EPC    0x00000000
    Config0 0x80008482 Config1 0x9e190c8b LLAddr 0x804322dc
IN: prom_init
0x80458760:  ror    a2,a2,0x10

---------------- 0 00000090
OP:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Kiszka | 1 Jun 2008 15:53
Picon

Re: [PATCH 0/5] Debugger enhancements

Fabrice Bellard wrote:
> Jan Kiszka wrote:
>> Fabrice Bellard wrote:
>>> Hi,
>>>
>>> I cannot accept the patches for several reasons:
>>>
>>> 1) You mix cosmetic and functional patches.
>> Do you have specific hunks in mind? I'm a bit blind ATM, not seeing
>> where I changed coding style or naming for cosmetic reasons.
> 
> You renammed mem_write_pc and mem_write_vaddr.

mem -> iomem dated back when I was confused about plain RAM access going
through handlers that are called io_read/write. Reverted this. But write
-> access is required as I changed the semantics of these variables.

> 
> BTW, why did you add 'len' and 'type' parameters to breakpoints ?
> 
> I don't think it is a good idea to say that breakpoints/watchpoints
> apply to all processors. Such behavior should be handled at a higher level.

Yes, I agree meanwhile. Now I introduced a host-injection layer to
gdbstub that handles this. All cpu_* services are per-CPU again.

> 
> It would also be interesting if the watchpoint/breakpoint implementation
> could be used to implement CPU watchpoints and breakpoints (I am
> thinking about the x86 DRx registers here).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane