Shin-ichiro KAWASAKI | 1 May 2008 02:09
Picon
Gravatar

[PATCH 0/2] Improvements for SH4 System Emulation

Hi, all.

I'm looking forward to SH4 System Emulation.
I guess somebody is working on it. Can anyone tell me the progress?

Anyway, I have spent some days to investigate SH4 System Emulation,
and made tow patches which makes SH4 linux kernel to boot under some
conditions. Reviews and comments on them will be appreciated.

With these patches, kernel boot goes well and init process is started,
if the kernel is configured without PCI/Network/PATA/SuperH-SCI-SPI/USB
support. I placed the static linked hello world program at /init,
and saw 'Hello world' message printed before kenrel panic.

The init by busybox does not work well, and I have plan to work on it.
Any advice is welcome.

Regards,
Shin-ihiro Kawasaki

Shin-ichiro KAWASAKI | 1 May 2008 02:09
Picon
Gravatar

[PATCH 1/2] SH4 MMU improvements.

It does :
- adds 'ldtlb' instruction
- fixes MMUCR's LRUI field handling
- fixes TLB miss handling
- fixes ITLB miss handling
- fixes cpu_sh4_handle_mmu_fault()'s parameter 'rw' value handling
- makes PTEA register writable

Works on memory mapped TLB is left.

--- a/hw/sh7750.c 2007-12-12 10:11:42.000000000 +0900
+++ b/hw/sh7750.c 2008-04-30 09:18:26.000000000 +0900
 <at>  <at>  -360,6 +360,9  <at>  <at> 
case SH7750_PTEL_A7:
s->cpu->ptel = mem_value;
return;
+ case SH7750_PTEA_A7:
+ s->cpu->ptea = mem_value & 0x0000000f;
+ return;
case SH7750_TTB_A7:
s->cpu->ttb = mem_value;
return;
diff -ruwN a/target-sh4/cpu.h b/target-sh4/cpu.h
--- a/target-sh4/cpu.h 2007-12-02 15:18:24.000000000 +0900
+++ b/target-sh4/cpu.h 2008-04-30 09:18:26.000000000 +0900
 <at>  <at>  -163,5 +163,78  <at>  <at> 
#define MMUCR 0x1F000010
#define MMUCR_AT (1<<0)
#define MMUCR_SV (1<<8)
+#define MMUCR_URC_BITS (6)
(Continue reading)

Shin-ichiro KAWASAKI | 1 May 2008 02:09
Picon
Gravatar

[PATCH 2/2] SH4 serial controler improvements.

This patch avoids an assertion error and makes the message from
init process printed out to the console.

It does:
- makes SMR & SCR registers readable
- adds TXI interrupt handling
- fixes SCR register write mask

Patch it after patch 1/2, or you'll ses an offset warning.

diff -ruwN a/hw/sh.h b/hw/sh.h
--- a/hw/sh.h 2007-12-12 10:11:42.000000000 +0900
+++ b/hw/sh.h 2008-04-30 09:12:18.000000000 +0900
 <at>  <at>  -35,7 +35,12  <at>  <at> 
/* sh_serial.c */
#define SH_SERIAL_FEAT_SCIF (1 << 0)
void sh_serial_init (target_phys_addr_t base, int feat,
- uint32_t freq, CharDriverState *chr);
+ uint32_t freq, CharDriverState *chr,
+ struct intc_source *eri_source,
+ struct intc_source *rxi_source,
+ struct intc_source *txi_source,
+ struct intc_source *tei_source,
+ struct intc_source *bri_source);

/* tc58128.c */
int tc58128_init(struct SH7750State *s, char *zone1, char *zone2);
diff -ruwN a/hw/sh7750.c b/hw/sh7750.c
--- a/hw/sh7750.c 2008-04-30 09:11:39.000000000 +0900
+++ b/hw/sh7750.c 2008-04-30 09:12:18.000000000 +0900
(Continue reading)

Gervase Lam | 1 May 2008 03:03
Picon

Re: OpenGL in qemu

> Date: Wed, 30 Apr 2008 11:07:36 +1000
> From: Nik <qemu <at> babel.homelinux.net>
> Subject: Re: [Qemu-devel] OpenGL in qemu

> However, if I can find a solution which has a good longer-term future 
> and supports the greatest range of applications and users, then I am 
> very interested, so long as it doesn't make the implementation overly 
> complex. :o)

Fabrice made the following suggestion, which I am only just(!) beginning
to understand:

<http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00149.html>

Essentially, I think he would like to see something like the following:

(Guest driver) -> (pseudo PCI adapter emulated by QEMU)-> (Host gfx lib)

This would allow any host to benefit without having to write host
specific code to handle this.  I think that was the point Fabrice was
making.

Thanks,
Gervase.

Nik | 1 May 2008 04:26

Re: OpenGL in qemu

Gervase wrote:
> >/ Date: Wed, 30 Apr 2008 11:07:36 +1000/
> >/ From: Nik <address <at> hidden>/
> >/ Subject: Re: [Qemu-devel] OpenGL in qemu/
>
> Fabrice made the following suggestion, which I am only just(!) beginning
> to understand:
>
> <http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00149.html>
>
> Essentially, I think he would like to see something like the following:
>
> (Guest driver) -> (pseudo PCI adapter emulated by QEMU)-> (Host gfx lib)
>
> This would allow any host to benefit without having to write host
> specific code to handle this.  I think that was the point Fabrice was
> making.
>   
I had already seen references to this post, and had some questions on 
that as well.
Your diagram makes the structure clearer, thank you.

Although I suspect that the diagram is actually mroe like the following:

(Guest driver) -> (opengl library) -> (pseudo PCI adaptor) -> (Host 
opengl lib)

In this arrangement, the job of the (pseudo PCI adaptor) is to pass 
through the opengl calls and results as quickly and efficiently as 
possible, with the possibility of managing some of the memory structures 
(Continue reading)

Carlo Marcelo Arenas Belon | 1 May 2008 09:52
Picon

[PATCH v2] curses: resize terminal to fit console size

The following patch, sends a resize escape character to the terminal used
when running under curses to try to change its geometry to match the console
size (as it is done with SDL).

As suggested, I'd added a check for the type of terminal used (currently only
blacklisting "linux", eventhough from my tests it was just ignoring the escape
sequence) which will need to be expanded to all known terminals which don't
support this sequence.  As suggested as well, I'd moved the resizing to the
resize function so that it will be also called if the VGA mode is changed.

Carlo
Index: curses.c
===================================================================
--- curses.c	(revision 4290)
+++ curses.c	(working copy)
 <at>  <at>  -39,6 +39,7  <at>  <at> 

 static console_ch_t screen[160 * 100];
 static WINDOW *screenpad = NULL;
+static int term_resizable = 1;
 static int width, height, gwidth, gheight, invalidate;
 static int px, py, sminx, sminy, smaxx, smaxy;

 <at>  <at>  -98,6 +99,9  <at>  <at> 
     if (w == gwidth && h == gheight)
         return;

+    if (term_resizable && !is_graphic_console())
(Continue reading)

Dan Kenigsberg | 1 May 2008 10:48

Re: [Patch] [kinda-resend] persistent real-time-clock

On Sun, Apr 27, 2008 at 11:58:17AM -0500, Anthony Liguori wrote:
> Dan Kenigsberg wrote:
>> Real PC lets its user set the real-time-clock and store it on CMOS,
>> which advances the clock even when the PC is offline.
>>
>> These patches will allow doing the same with VM:
>> - Before shutting a VM down, use the monitor's info timeoffset to see
>>   how much (in seconds) does the rtc differ from the host clock.
>> - Store this offset somewhere.
>> - Use it next time with -startdate now+offset.
>>
>> Please tell me what do you think of it.
>>   
>
> I think a more general mechanism that stored nvram in a file would be 
> interesting.  Something like like -nvram file.ram.  This also allows a 
> guest to determine it's initial boot device and for that setting to 
> persist.

I'm not sure I understood what you suggest here.

Plainly storing the rtc state on file is not enough, as unlike with real
hardware, nothing will advance it when the power is off.

Do you suggest to set up a mechanism (in parallel to savevm/loadvm)
where each device with non-volatile memory could register to? Probably,
in most devices the SaveStateHandler could play the role of
SaveNVStateHandler, but some would have to do something else. This would
make the file.ram different than a memory dump.

(Continue reading)

Laurent Vivier | 1 May 2008 13:41

[PATCH] PMAC NVRAM cleanup

Hi,

I'm trying to boot openbios on PPC target (for the moment I'm only  
able to load yaboot).

This patch is a cleanup of PMAC nvram.

It stores nvram in a file and create valid partitions.

This doesn't break OpenHackware.

Regards,
Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

Attachment (0001-PowerMac-NVRAM-cleanup.patch): application/octet-stream, 7868 bytes

Adam Lackorzynski | 1 May 2008 14:02
Picon
Favicon

Re: Crash due to invalid env->current_tb


On Wed Apr 30, 2008 at 21:21:40 +0300, Blue Swirl wrote:
> The attached version survives quick tests for both Sparc32 and Sparc64.

Ok, I did not check for 64bit targets. So what about the following,
works for me for arm, x86-32 and x86-64.

Index: cpu-exec.c
===================================================================
--- cpu-exec.c	(revision 4276)
+++ cpu-exec.c	(working copy)
 <at>  <at>  -690,7 +691,22  <at>  <at> 
 		fp.ip = tc_ptr;
 		fp.gp = code_gen_buffer + 2 * (1 << 20);
 		(*(void (*)(void)) &fp)();
+#elif defined(__i386)
+#if (TARGET_LONG_BITS == 32)
+#define CLOBBER ,"edx"
 #else
+#define CLOBBER ,"ebx"
+#endif
+		asm volatile ("push %%ebp\n"
+		              "call *%1\n"
+			      "pop %%ebp\n"
+		              : "=A" (T0)
+			      : "a" (gen_func)
+			      : "ecx", "esi", "edi", "cc" CLOBBER
+			      );
+		T0 &= 0xffffffff;
+#undef CLOBBER
(Continue reading)

Paul Brook | 1 May 2008 14:04
Gravatar

[4291] Fix incorrect argument types.

Revision: 4291
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=4291
Author:   pbrook
Date:     2008-05-01 12:04:35 +0000 (Thu, 01 May 2008)

Log Message:
-----------
Fix incorrect argument types.

Modified Paths:
--------------
    trunk/target-arm/helper.c

Modified: trunk/target-arm/helper.c
===================================================================
--- trunk/target-arm/helper.c	2008-04-29 16:18:58 UTC (rev 4290)
+++ trunk/target-arm/helper.c	2008-05-01 12:04:35 UTC (rev 4291)
 <at>  <at>  -1985,7 +1985,7  <at>  <at> 
 #include "op_addsub.h"

 /* Unsigned saturating arithmetic.  */
-static inline uint16_t add16_usat(uint16_t a, uint8_t b)
+static inline uint16_t add16_usat(uint16_t a, uint16_t b)
 {
     uint16_t res;
     res = a + b;
 <at>  <at>  -1994,7 +1994,7  <at>  <at> 
     return res;
 }

(Continue reading)


Gmane