On 27/07/07, Paul Borman <[EMAIL PROTECTED]> 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
