[Qemu-devel] Patch for OHW bootinfos

[Qemu-devel] Patch for OHW bootinfos

[Tero Kaarlela]

[-- Attachment #1.1: Type: text/plain, Size: 555 bytes --]

This patches residual data structures for OHW Prep. ftp://ftp.software.ibm.com/rs6000/technology/spec/RESIDUAL.PS has been used as reference document here. Now the Vital product data shows correctly with guest Linux lsresidual utility.(instead of segmentation fault before patching). Also memory segment info structures are correct now but data in segments not(need a dynamical way to add data into these). Also devices structures are corrected but no devices described yet(dynamical detecting of PCI devices is easy but how about ISAPNP?).


Tero 
  

[-- Attachment #1.2: Type: text/html, Size: 1170 bytes --]

[-- Attachment #2: bootinfos.diff --]
[-- Type: application/octet-stream, Size: 7277 bytes --]

--- OpenHackWare-release-0.4/src/bootinfos.c	2005-03-31 07:23:33.000000000 +0000
+++ OpenHackWare-release-0.4/src/bootinfos.c.mod	2007-07-20 17:17:55.000000000 +0000
@@ -80,7 +80,7 @@ void prepare_bootinfos (void *p, uint32_
 }
 
 /* Residual data */
-#define MAX_CPUS 16
+#define MAX_CPUS 32
 #define MAX_SEGS 64
 #define MAX_MEMS 64
 #define MAX_DEVS 256
@@ -88,20 +88,21 @@ void prepare_bootinfos (void *p, uint32_
 typedef struct vital_t {
     /* Motherboard dependents */
     uint8_t model[32];
-    uint8_t serial[64];
-    uint16_t version;
-    uint16_t revision;
-    uint32_t firmware;
+    uint8_t serial[16]; 
+    uint8_t reserved[48]; 
+    uint32_t firmwaresupplier;
+    uint32_t firmwaresupports;
     uint32_t NVRAM_size;
     uint32_t nSIMMslots;
-    uint32_t nISAslots;
-    uint32_t nPCIslots;
-    uint32_t nPCMCIAslots;
-    uint32_t nMCAslots;
-    uint32_t nEISAslots;
+    uint16_t endianswitchmethod;
+    uint16_t spreadIOmethod;
+    uint32_t smplar; 
+    uint32_t ramerrorlog;
+    uint8_t reserved5[4];
+    uint8_t reserved6[4]; 	
     uint32_t CPUHz;
     uint32_t busHz;
-    uint32_t PCIHz;
+    uint8_t reserved7[4];
     uint32_t TBdiv;
     /* CPU infos */
     uint32_t wwidth;
@@ -126,14 +127,15 @@ typedef struct vital_t {
     uint32_t ITLB_assoc;
     uint32_t DTLB_size;
     uint32_t DTLB_assoc;
-    void *ext_vital;
+    uint32_t ext_vital;
 } vital_t;
 
 typedef struct PPC_CPU_t {
     uint32_t pvr;
-    uint32_t serial;
-    uint32_t L2_size;
-    uint32_t L2_assoc;
+    uint8_t ncpu;
+    uint8_t statecpu;
+    uint16_t reserved;
+    
 } PPC_CPU_t;
 
 typedef struct map_t {
@@ -151,10 +153,14 @@ typedef struct PPC_device_t {
     uint32_t devID;
     uint32_t serial;
     uint32_t flags;
-    uint32_t type;
-    uint32_t subtype;
-    uint32_t interface;
-    uint32_t spare;
+    uint8_t type;
+    uint8_t subtype;
+    uint8_t interface;
+    uint8_t spare;
+    uint32_t busaccess;
+    uint32_t allocoffset;
+    uint32_t posoffset;
+    uint32_t compatoffset;
 } PPC_device_t;
 
 typedef struct residual_t {
@@ -162,7 +168,8 @@ typedef struct residual_t {
     uint16_t  version;
     uint16_t  revision;
     vital_t   vital;
-    uint32_t  nCPUs;
+    uint16_t  maxnCPUs;
+    uint16_t  nCPUs;
     PPC_CPU_t CPUs[MAX_CPUS];
     uint32_t  max_mem;
     uint32_t  good_mem;
@@ -179,29 +186,34 @@ void residual_build (void *p, uint32_t m
                      uint32_t load_base, uint32_t load_size,
                      uint32_t last_alloc)
 {
-    const unsigned char model[] = "Qemu\0PPC\0";
+    const unsigned char model[] = "OHW PPS Model 6050\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
+    const unsigned char serial[] = "OHW60501\0\0\0\0\0\0\0\0";
+    const unsigned char reserved[] ="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
+    const unsigned char reserved1[] = "\0\0\0\0";
     residual_t *res = p;
     int i;
-
+   
     if (res == NULL)
         return;
     res->length = sizeof(residual_t);
     res->version = 1;
     res->revision = 0;
     memcpy(res->vital.model, model, sizeof(model));
-    res->vital.version = 1;
-    res->vital.revision = 0;
-    res->vital.firmware = 0x1D1;
+    memcpy(res->vital.serial, serial, sizeof(serial));
+    memcpy(res->vital.reserved, reserved, sizeof(reserved));
+    res->vital.firmwaresupplier = 0x00;
+    res->vital.firmwaresupports = 0x1D1;
     res->vital.NVRAM_size = 0x2000;
     res->vital.nSIMMslots = 1;
-    res->vital.nISAslots = 0;
-    res->vital.nPCIslots = 0;
-    res->vital.nPCMCIAslots = 0;
-    res->vital.nMCAslots = 0;
-    res->vital.nEISAslots = 0;
+    res->vital.endianswitchmethod = 0x01;
+    res->vital.spreadIOmethod = 0x00;
+    res->vital.smplar = 0;
+    res->vital.ramerrorlog = 0;
+    memcpy(res->vital.reserved5, reserved1, sizeof(reserved1));
+    memcpy(res->vital.reserved6, reserved1, sizeof(reserved1));
     res->vital.CPUHz = 200 * 1000 * 1000;
     res->vital.busHz = 100 * 1000 * 1000;
-    res->vital.PCIHz = 33 * 1000 * 1000;
+    memcpy(res->vital.reserved7, reserved1, sizeof(reserved1));
     res->vital.TBdiv = 1000;
     res->vital.wwidth = 32;
     res->vital.page_size = 4096;
@@ -224,39 +236,46 @@ void residual_build (void *p, uint32_t m
     res->vital.ITLB_assoc = 2;
     res->vital.DTLB_size = 0;
     res->vital.DTLB_assoc = 2;
-    res->vital.ext_vital = NULL;
+    res->vital.ext_vital = 0;
+    res->maxnCPUs = 1;
     res->nCPUs = 1;
     res->CPUs[0].pvr = mfpvr();
-    res->CPUs[0].serial = 0;
-    res->CPUs[0].L2_size = 0;
-    res->CPUs[0].L2_assoc = 8;
+    res->CPUs[0].ncpu = 0;
+    res->CPUs[0].statecpu = 0;
+    res->CPUs[0].reserved = 0;
+    for(i = 1; i < 31; i++) {
+    res->CPUs[i].pvr = 0;
+    res->CPUs[i].ncpu = i;
+    res->CPUs[i].statecpu = 0xFF;
+	}
     /* Memory infos */
     res->max_mem = memsize;
     res->good_mem = memsize;
+    res->nmaps = 6;
     /* Memory mappings */
     /* First segment: firmware */
     last_alloc = (last_alloc + 4095) & ~4095;
-    res->maps[0].usage = 0x0007;
-    res->maps[0].base  = 0x00000000;
-    res->maps[0].count = last_alloc >> 12;
+    res->maps[0].usage = 0x0004;
+    res->maps[0].base  = 0x0580;			    
+    res->maps[0].count = 0x0021;
     i = 1;
     if (last_alloc != load_base) {
         /* Free memory between firmware and boot image */
         res->maps[1].usage = 0x0010;
-        res->maps[1].base = last_alloc >> 12;
-        res->maps[1].count = (load_base - last_alloc) >> 12;
+        res->maps[1].base = 0x0600;
+        res->maps[1].count = 0;
         i++;
     }
     /* Boot image */
     load_size = (load_size + 4095) & ~4095;
     res->maps[i].usage = 0x0008;
-    res->maps[i].base  = load_base >> 12;
-    res->maps[i].count = load_size >> 12;
+    res->maps[i].base  = 0x0100;
+    res->maps[i].count = 0x0100;
     i++;
     /* Free memory */
     res->maps[i].usage = 0x0010;
-    res->maps[i].base  = (load_base + load_size) >> 12;
-    res->maps[i].count = (memsize >> 12) - res->maps[i].base;
+    res->maps[i].base  = 0x0040;
+    res->maps[i].count = 0x400;
     i++;
     /* ISA IO region : 8MB */
     res->maps[i].usage = 0x0040;
@@ -273,10 +292,27 @@ void residual_build (void *p, uint32_t m
     res->maps[i].base  = 0xFFFF0000 >> 12;
     res->maps[i].count = 0x00010000 >> 12;
     i++;
-    res->nmaps = i;
+    for( i = i; i < 64; i++){
+    res->maps[i].usage = 0;
+    res->maps[i].base  = 0;
+    res->maps[i].count = 0;
+    }
     /* Memory SIMMs */
     res->nmems = 1;
     res->memories[0].size = memsize;
     /* Describe no devices */
-    res->ndevices = 0;
+    for(i = 0; i < 255; i++){
+    res->devices[i].busID = 0;
+    res->devices[i].devID = 0;
+    res->devices[i].serial = 0;
+    res->devices[i].flags = 0;
+    res->devices[i].subtype = 0;
+    res->devices[i].interface = 0;
+    res->devices[i].spare = 0;
+    res->devices[i].busaccess = 0;
+    res->devices[i].allocoffset = 0;
+    res->devices[i].posoffset = 0;
+    res->devices[i].compatoffset = 0;
+
+}
 }

[Qemu-devel] QEmu as a Device Software Optimization tool

[Paul Borman]

Greetings,

I have been working with QEmu for a few months now at Wind River.  I  
am sure many of you already know Jason Wessel and Alex deVries who  
championed QEmu as a tool for our Linux product.  It is my goal to  
demonstrate the power of QEmu for embedded software development  
(excuse me, DSO - Device Software Optimization).  I have identified  
several areas in which some work needs to be done to make QEmu more  
appropriate for embedded development.  I am interested in comments or  
pointers to existing work for several areas (I have also done work in  
many of these areas already).  I have been working mainly with  
PowerPC targets and X86 Linux as a host.

System Clock - Currently it appears to me that QEmu attempt to sync  
the "system clock" with realtime resulting in a different number of  
emulated "clock" cycles per clock interrupt.  In the embedded  
environment we are typically much more interested in a deterministic  
result from the clock.  For the PowerPC I have implemented an  
alternate implementation of the TB and Decrementer that increments  
the time base based on the number of emulated instructions that have  
been processed.  It is not perfect, but at least now the timer  
interrupt is triggered when the decrementer goes negative.  Have  
others worked on this problem?

QEmu Target Configuration - I would like to define a configuration  
file syntax (I cannot help but think back to my BSDi days and the BSD/ 
OS kernel configuration file) that would define the hardware from the  
outside.  Device drivers would either need to be already linked in,  
or be able to be dynamically loaded.  I would expect that things such  
as the memory map, type of interrupt controller, the various devices  
along with their io port and memory addresses and interrupts would be  
defined here.  Again, this would not replace the current system, but  
would essentially be a new init module.  I do not want to see any  
working configurations break.

Paravirtualization - I have written a "device driver" for QEmu that  
allows the guest system to essentially make function calls right into  
the host (dealing with data representation, etc).  A prime example  
for use of this is OpenGL.  OpenGL is pretty much done in hardware  
these days, and most embedded devices do not use X11 as a graphics  
system.  By providing an OpenGL library on the target OS that  
basically calls straight into the hosts OpenGL library it should be  
possible to greatly increase the performance of the target without  
having to try and export the real graphics hardware into QEmu.  Along  
with this I have done the necessary work to allow QEmu to use dlopen 
() to load in arbitrary shim layers to libraries.

There are other areas as well, such as deterministic execution, etc.   
If anyone else is interested in these topics, please let me know.

Paul Borman
Principal Technologist
Wind River Systems

Re: [Qemu-devel] QEmu as a Device Software Optimization tool

[Thiemo Seufer]

Paul Borman wrote:
> Greetings,
>
> I have been working with QEmu for a few months now at Wind River.  I am 
> sure many of you already know Jason Wessel and Alex deVries who championed 
> QEmu as a tool for our Linux product.  It is my goal to demonstrate the 
> power of QEmu for embedded software development (excuse me, DSO - Device 
> Software Optimization).  I have identified several areas in which some work 
> needs to be done to make QEmu more appropriate for embedded development.  I 
> am interested in comments or pointers to existing work for several areas (I 
> have also done work in many of these areas already).  I have been working 
> mainly with PowerPC targets and X86 Linux as a host.
>
> System Clock - Currently it appears to me that QEmu attempt to sync the 
> "system clock" with realtime resulting in a different number of emulated 
> "clock" cycles per clock interrupt.  In the embedded environment we are 
> typically much more interested in a deterministic result from the clock.  
> For the PowerPC I have implemented an alternate implementation of the TB 
> and Decrementer that increments the time base based on the number of 
> emulated instructions that have been processed.  It is not perfect, but at 
> least now the timer interrupt is triggered when the decrementer goes 
> negative.  Have others worked on this problem?

I think this goes in the more general area of instruction/cycle counting,
which would be also useful for basic performance analysis. IMHO the
alternatives should be switchable at runtime (from the monitor and via
command line), with host clock synchronization staying the default.

So far I haven't thought much about the other topics you raise.


Thiemo

Re: [Qemu-devel] QEmu as a Device Software Optimization tool

[Even Rouault]

On Thursday 26 July 2007 18:34:36 Paul Borman wrote:
> Paravirtualization - I have written a "device driver" for QEmu that  
> allows the guest system to essentially make function calls right into  
> the host (dealing with data representation, etc).  A prime example  
> for use of this is OpenGL.  OpenGL is pretty much done in hardware  
> these days, and most embedded devices do not use X11 as a graphics  
> system.  By providing an OpenGL library on the target OS that  
> basically calls straight into the hosts OpenGL library it should be  
> possible to greatly increase the performance of the target without  
> having to try and export the real graphics hardware into QEmu.  Along  
> with this I have done the necessary work to allow QEmu to use dlopen
> () to load in arbitrary shim layers to libraries.

As far as OpenGL is concerned, I don't know if you have already looked at it, 
but you may be interested by my OpenGL patch. Even if it uses a specific 
guest <--> host communication hack, this may save you the quite tidious 
process of serializing/deserializing OpenGL calls between guest and host.
For more details, see : http://qemu-forum.ipi.fi/viewtopic.php?t=2984

Re: [Qemu-devel] QEmu as a Device Software Optimization tool

[andrzej zaborowski]

Hi,

On 26/07/07, Paul Borman <paul.borman@windriver.com> wrote:
> QEmu Target Configuration - I would like to define a configuration
> file syntax (I cannot help but think back to my BSDi days and the BSD/
> OS kernel configuration file) that would define the hardware from the
> outside.  Device drivers would either need to be already linked in,
> or be able to be dynamically loaded.  I would expect that things such
> as the memory map, type of interrupt controller, the various devices
> along with their io port and memory addresses and interrupts would be
> defined here.  Again, this would not replace the current system, but
> would essentially be a new init module.  I do not want to see any
> working configurations break.

There is some interesting work being done on a similar project by Paul
Sokolovsky for his and Maria Zabolotnaya's Google Summer Of Project.
In their approach machine descriptions (but not only) are written in
python, which lets you hope that they can have a simple syntax,
practically like a config file, if desired, or a much more powerful
one, so it seems to be a better idea than plain config files.

Personally though I don't see much benefit to simple syntax config
files over C files, that are being used now.
Regards

[Qemu-devel] Re: QEmu as a Device Software Optimization tool

[Hollis Blanchard]

On Thu, 26 Jul 2007 21:00:31 +0200, andrzej zaborowski wrote:
> 
> There is some interesting work being done on a similar project by Paul
> Sokolovsky for his and Maria Zabolotnaya's Google Summer Of Project.
> In their approach machine descriptions (but not only) are written in
> python, which lets you hope that they can have a simple syntax,
> practically like a config file, if desired, or a much more powerful
> one, so it seems to be a better idea than plain config files.
> 
> Personally though I don't see much benefit to simple syntax config
> files over C files, that are being used now.

Really? Take a look at ppc_prep_init()...

I would love to see machine definition done in python.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [Qemu-devel] Re: QEmu as a Device Software Optimization tool

[Paul Borman]

The platform I started with was ppc_prep :-)

So, is Python already part of qemu?  Personally, I would have a goal  
that the definition of a device would be simple enough that there  
would be no reason to have anything more complicated than a simple  
text file.  While I would not suggest that the BSD config file syntax  
should be used, I do think it is instructive.

It has a section for defining macros, really, the standard name/value  
pairs

	options         KTR                     # kernel wraparound trace  
buffer support
	options "KTR_SIZE=32768"        # trace buffer in bytes (def=8K)
	options "KTR_COMPILE='~0'"      # compile in all traces
	options "KTR_MASK=0"            # but turn none of them on

Clearly there would be cleaner ways to specify this for QEmu

	set memory_size	0x10000000

There is also a section that specifies the various devices.  Here is  
a snippet of a kernel for an embedded PPC board I used to work on:


	# main (on-board io) bus
	obio0   at root
	pci0  at obio0

	# COM ports
	# Flags are 0xF00000 for fifo flags F; see com(4).
	# Default is 0; 1, 2, 3, 4 set receive fifo trigger to 1, 4, 8, 14;
	# 9 ignores the FIFO on 16550/16550AF.
	com0    at obio? addr "0xff600300" irq 3
	com1    at obio? addr "0xff600400" irq 4

	# Crystal Semiconductor Ethernet
	ce0     at obio? addr "0x7fe00c00" irq 24

	# Disk On Chip 2000 driver
	dc0    at obio? iomem "0x800d0000" iosiz 0x2000

This particular syntax specifies several things:

1)  The devices in a generic way
2)  How devices are connected
3)  The order to search for the devices

Again, QEmu would need something slightly different, but at least  
this demonstrates how a similar problem has been previous solved.

There are also pseudo devices

	pseudo-device   loop
	pseudo-device   pty
	pseudo-device sl      1

QEmu might be able to treat pseudo and "physical" devices the same,  
or maybe keeping them independent would be good.

Using python, or some general purpose scripting language, to  
create .c files for inclusion in the compilation seems like it may  
have some merit, though I see these as different issues.  I wrote a  
PPC virtual machine to run on PPC hosts (i.e., more like vmware).   
When I found that I wanted a little more than a simple ascii file, I  
settled on pretty much the standard sh syntax.  I have written (and  
am willing to contribute) an embedded version of sh which only calls  
builtin functions.  I used it both for my monitor as well as my  
config syntax (config files were essentially read by the monitor)

		-Paul



>> Personally though I don't see much benefit to simple syntax config
>> files over C files, that are being used now.
>
> Really? Take a look at ppc_prep_init()...
>
> I would love to see machine definition done in python.
>
> -- 
> Hollis Blanchard
> IBM Linux Technology Center
>
>
>
>

Re: [Qemu-devel] Re: QEmu as a Device Software Optimization tool

[Alexander Voropay]

"Paul Borman" wrote:

>Personally, I would have a goal  
> that the definition of a device would be simple enough that there  
> would be no reason to have anything more complicated than a simple  
> text file.

 Look at the Virtutech Simics emulator. (It's closed source product but free
for academic use). Their config file allows to "construct" a whole machine
from the "processor", "bus", PCI devices e.t.c. components.

http://www.virtutech.com/

script file to crate a Pentium machine with 440BX chipset:
===========
if not defined freq_mhz {$freq_mhz = 20}
if not defined cpi {$cpi = 1}
if not defined disk_size {$disk_size = 20496236544}
if not defined disk_image {}
if not defined rtc_time {$rtc_time = "2002-09-18 10:00:00 UTC"}
if not defined num_cpus {$num_cpus = 1}
if not defined memory_megs {$memory_megs = 256}
if not defined cpu_class {$cpu_class = "pentium-4"}
if not defined text_console {$text_console = "no"}
if not defined use_acpi {$use_acpi = TRUE}
###
add-directory "%simics%/targets/x86-440bx/images"
import-isa-components
import-pci-components
import-std-components
import-x86-components

$nb = (create-north-bridge-443bx)
$vga = (create-pci-voodoo3)
$nb.connect pci-slot5 $vga
$sb = (create-south-bridge-piix4)
$sio = (create-std-super-io)

$console.connect keyboard $sio kbd-console
$console.connect $vga
$system.connect chipset $nb
$system.connect interrupt $sb
$system.connect reset $sio
$nb.connect pci-slot7 $sb
$sb.connect $sio
$sb.connect ide0-master $disk

e.t.c.

--
-=AV=-

*******************************************************************************************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. Orange Business Services shall not be liable for the message if altered, changed or
falsified. If you are not the intended addressee of this message, please cancel it immediately and inform 
the sender.
*******************************************************************************************************

Re: [Qemu-devel] Re: QEmu as a Device Software Optimization tool

[andrzej zaborowski]

On 27/07/07, Paul Borman <paul.borman@windriver.com> wrote:
> The platform I started with was ppc_prep :-)
>
> So, is Python already part of qemu?  Personally, I would have a goal
> that the definition of a device would be simple enough that there
> would be no reason to have anything more complicated than a simple
> text file.  While I would not suggest that the BSD config file syntax
> should be used, I do think it is instructive.

The python thing is not in qemu and is (I think) a long term project
in not much sync with qemu now, but I don't know the details.

>
> It has a section for defining macros, really, the standard name/value
> pairs
>
>         options         KTR                     # kernel wraparound trace
> buffer support
>         options "KTR_SIZE=32768"        # trace buffer in bytes (def=8K)
>         options "KTR_COMPILE='~0'"      # compile in all traces
>         options "KTR_MASK=0"            # but turn none of them on
>
> Clearly there would be cleaner ways to specify this for QEmu
>
>         set memory_size 0x10000000
>
> There is also a section that specifies the various devices.  Here is
> a snippet of a kernel for an embedded PPC board I used to work on:
>
>
>         # main (on-board io) bus
>         obio0   at root
>         pci0  at obio0
>
>         # COM ports
>         # Flags are 0xF00000 for fifo flags F; see com(4).
>         # Default is 0; 1, 2, 3, 4 set receive fifo trigger to 1, 4, 8, 14;
>         # 9 ignores the FIFO on 16550/16550AF.
>         com0    at obio? addr "0xff600300" irq 3
>         com1    at obio? addr "0xff600400" irq 4
>
>         # Crystal Semiconductor Ethernet
>         ce0     at obio? addr "0x7fe00c00" irq 24
>
>         # Disk On Chip 2000 driver
>         dc0    at obio? iomem "0x800d0000" iosiz 0x2000
>
> This particular syntax specifies several things:
>
> 1)  The devices in a generic way
> 2)  How devices are connected
> 3)  The order to search for the devices
>
> Again, QEmu would need something slightly different, but at least
> this demonstrates how a similar problem has been previous solved.
>
> There are also pseudo devices
>
>         pseudo-device   loop
>         pseudo-device   pty
>         pseudo-device sl      1
>
> QEmu might be able to treat pseudo and "physical" devices the same,
> or maybe keeping them independent would be good.
>
> Using python, or some general purpose scripting language, to
> create .c files for inclusion in the compilation seems like it may
> have some merit, though I see these as different issues.  I wrote a
> PPC virtual machine to run on PPC hosts (i.e., more like vmware).
> When I found that I wanted a little more than a simple ascii file, I
> settled on pretty much the standard sh syntax.  I have written (and
> am willing to contribute) an embedded version of sh which only calls
> builtin functions.  I used it both for my monitor as well as my
> config syntax (config files were essentially read by the monitor)

I think python or other scripting language are a much better idea than
a custom syntax with only variables and static content. I would hate
to write 121 lines to set up initial states of the 121 gpios present
in pxa-based machines, I would use a loop.

In my experience embedded machines even those with very similar
capabilities and coming from the same manufacturer have huge hardware
differences between models. My experience is only with ARM. The common
parts between the different ARM-based computers are usually only the
CPU (which fortunately embeds many peripherals) and if there's an
external chip onboard that two devices use in common then it usually
is wired differently or there are other quirks that will force you
dirty your hands in C code and rebuild (which doesn't really take
significantly more time than editing a config file which is loaded in
runtime). Take as an example a peripheral that has one of the signals
connecting it with the cpu/bus, inverted/pulled up/unconnected, it
would be very hard to make a simple text syntax that accounts for
that, and python might potentially do it without much pain (this
example is a very usual case between PDAs).

Regards

Re: [Qemu-devel] Re: QEmu as a Device Software Optimization tool

[Paul Sokolovsky]

Hello,

Andrzej Zaborowski wrote:

> There is some interesting work being done on a similar project by Paul
> Sokolovsky for his and Maria Zabolotnaya's Google Summer Of Project.

  Yes, there's such project, being done from Handhelds.org, with the
motivation that the project works on porting Linux to several dozens of
PDA, while having less than a dozen people active in any given time,
and concentrating on small subset of devices. Thus, to leverage
emulation technology to our devices (and this brings obvious
benefits), there would need to be rapid prototyping technology
allowing easy reuse of already existing components.

  The project itself is more proof-of-concept though.


Friday, July 27, 2007, 12:46:29 PM, Paul Borman wrote:

> The platform I started with was ppc_prep :-)



> So, is Python already part of qemu?

  No, but fortunately it's not required at all. The idea is to have
Python wrapper for entire QEMU functionality, so that QEMU can be
completely controlled from Python code. Its relation to QEMU is the
same as that of PyGTK+ and GTK+ - the former should not be part of the
latter.

  Such a design besides being a technical best practice, also rooted in
the outcome of the mentioned Oct 2006 discussion, when it became clear
that flexible configuration won't be a part of QEMY any time soon ;-).

[]

> Using python, or some general purpose scripting language, to  
> create .c files for inclusion in the compilation seems like it may  
> have some merit, though I see these as different issues.

  That's not purpose of the Python module in question. Being a wrapper
around QEMU, it would allow to use Python's dynamical and high-level nature
to easily "construct" virtual board as well as handle "boring" tasks
like configuration file parsing, logging etc. So, the module itself
allows to specify machine in "imperative" description. I'm great
proponent of declarative descriptions myself, but designing such would
need more work. Plus, as the old discussion showed, there's no
unanimity even regarding what syntax it should use! (I for one find it
amusing that in 2006 people could think that writing XML parser would
be a prerequisite for XML use, and in even in 2007 come with idea of
"simple ascii files" ;-)).

>   I wrote a  
> PPC virtual machine to run on PPC hosts (i.e., more like vmware).   
> When I found that I wanted a little more than a simple ascii file, I  
> settled on pretty much the standard sh syntax.  I have written (and  
> am willing to contribute) an embedded version of sh which only calls  
> builtin functions.  I used it both for my monitor as well as my  
> config syntax (config files were essentially read by the monitor)

  Good luck pushing it upstream! As I wrote yet back in that thread,
there're more political than technical reasons why QEMU still doesn't
have it, and won't have it for some time more. But of course, raising
awareness and lobbying actions should help with this.

>                 -Paul



>>> Personally though I don't see much benefit to simple syntax config
>>> files over C files, that are being used now.
>>
>> Really? Take a look at ppc_prep_init()...
>>
>> I would love to see machine definition done in python.
>>
>> -- 
>> Hollis Blanchard
>> IBM Linux Technology Center
>>
>>
>>
>>





-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [Qemu-devel] QEmu as a Device Software Optimization tool

[n schembr]

 
-snap-


>Personally though I don't see much benefit to simple syntax config 

>files over C files, that are being used now. 



Config files implies a self check process.  A better question might be, has qemu grown to the point where an outsider is going to define a new  platform?  

Could an arm based cell phone manufacture use the config files to define the hardware for the emulator without a full port? Iphone anyone :)

Nicholas A. Schembri 
state  college pa usa 


 










          

[Qemu-devel] Re: QEmu as a Device Software Optimization tool

[Brian Johnson]

n schembr wrote:
> 
> -snap-
> 
>> Personally though I don't see much benefit to simple syntax config
>> files over C files, that are being used now.
> 
> Config files implies a self check process.  A better question might
> be, has qemu grown to the point where an outsider is going to define
> a new platform?

Absolutely.  I've been using it to prototype firmware for a NUMA 
chipset.  I've had to invent ugly command-line hacks for specifying the 
number of nodes, per-node consoles, etc.  And I still need to use a 
debugger to override variable values in my init. code when I want to 
test "odd" cases which my hacks don't support.  I could make good use of 
a generalized configuration file.

Brian